Apa * konsep pemrograman yang harus saya kuasai untuk memiliki pemahaman yang mendalam tentang keahlian saya (pemrograman)? [Tutup]

13

Dalam urutan kepentingan, jika memungkinkan untuk dilakukan dan mungkin tidak, dasar apa yang paling penting untuk mengetahui cara memprogram. Algoritma, iterasi, rekursi, dll?

Perhatikan bahwa tempat saya meletakkan dll. Adalah tempat pertanyaan saya berada. Saya baru-baru ini membaca posting Internet yang mengatakan 9 dari 10 programmer tidak dapat terkesiap !

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Saya ingin memiliki pengetahuan yang mendalam tentang apa yang sebenarnya saya coba capai ketika pemrograman dan pemahaman mendalam tentang alat-alat dasar yang saya miliki. Pada dasarnya saya ingin bisa melukis dengan semua warna angin.

programming-practices self-improvement concepts

— Kewigro
sumber

3

Tulisan Jeff Atwood sebenarnya bukan tentang pengetahuan pemrograman yang mendalam ... Ini tentang kenyataan bahwa banyak orang tidak memiliki wawasan mendasar dan mendasar tentang pemrograman, dan bagaimana kurangnya wawasan mendasar mencegah mereka mengembangkan keterampilan pemrograman yang signifikan.

— Robert Harvey

2

Saya tidak mengerti mengapa pertanyaan ini ditutup. Ini adalah pertanyaan yang telah dibintangi 5 kali dan memiliki banyak jawaban bermanfaat. Ini adalah jenis informasi yang ingin saya temui - hanya karena tidak ada jawaban sederhana tidak berarti informasi tersebut tidak bernilai baik, mungkin programmer.stackexchange.com perlu mengevaluasi kembali kriteria untuk pertanyaan penutup.

— Rocklan

@LachlanB Saya memilih untuk membuka kembali ... perlu 4 suara lagi untuk berhasil

— Michael Brown

Saya pikir ini adalah pertanyaan yang bagus tetapi jawaban yang masuk akal akan terlalu panjang untuk format situs ini. Setiap kurikulum universitas yang baik akan mencakup konsep-konsep ini, dan kenyataan bahwa kurikulum semacam itu membutuhkan beberapa tahun studi dan praktik khusus, diikuti oleh tahun-tahun tambahan yang mengerjakan proyek nyata harus menjelaskan mengapa jawabannya tidak cocok di sini.

— Giorgio

18

Daftar ini adalah awal ... Anda mengajukan pertanyaan besar!

Bagaimana memperjelas dan menuliskan apa yang diinginkan pelanggan ("persyaratan"). Ini adalah seni dalam dan dari dirinya sendiri. Jika Anda bisa melakukan ini, pekerjaan pemrograman Anda akan jauh lebih baik.
Cara memperkirakan dan merencanakan proyek. Orang-orang akan meminta perkiraan Anda, bersiaplah.
Cara meninjau kode orang lain secara konstruktif.
Pola desain. Ini yang besar. Tapi jangan terlalu bersemangat menggunakannya untuk itu.
Pelajari perbedaan antara bug, masalah, dan permintaan fitur
Tetap terbarui dengan frameworks / libraries. Anda tidak harus menggunakannya, tetapi Anda harus tahu apa yang mereka lakukan dan pro / kontra mereka. Jika sesuatu tampak terlalu sulit maka mungkin ada (semoga) cara yang jauh lebih mudah dalam melakukan sesuatu.
Cara mendokumentasikan algoritma yang rumit dalam bagan alur atau menuliskannya dalam bahasa Inggris. Jangan berharap bahwa seseorang akan menghabiskan 2 hari untuk mencoba merekayasa balik kode Anda.
Bagaimana mengatur struktur kode Anda sehingga orang lain dapat memahaminya
Bagaimana cara mengomentari kode Anda
Cara menulis unit test
Ketahui apa yang terjadi di bawah tenda. Misalnya memanggil layanan web - apa yang sebenarnya dilakukannya?
Bagaimana cara abstrak logika ke dalam kelas.
Cara memperbaiki kode
Pelajari inti beberapa bahasa pemrograman. Anda akan terkejut dengan apa yang dapat Anda pelajari dari area lain
Bagaimana cara memberitahu programmer lain apa yang harus ditulis.
Bagaimana menjelaskan kepada manajemen apa yang Anda lakukan dan mengapa.
Seperti kata Peter, cara men-debug. Saya setuju dengan semua yang dia katakan, programmer nyata men-debug, bukan hanya menebak.
Bagaimana cara bekerja dengan maniak. Ada banyak di luar sana.
Cara MENDAPATKAN STUFF DILAKUKAN. Semua teori di dunia tidak akan membantu Anda jika Anda tidak dapat menyelesaikan pekerjaan.

Saya menjawab pertanyaan lain di sepanjang baris yang sama (dengan konten serupa) di sini:

tips, pedoman, poin yang perlu diingat untuk memberikan kode profesional?

— Rocklan
sumber

1

+1: DAPATKAN STUFF DONE! Beberapa tahun yang lalu saya memposting kata-kata kasar yang mengatakan bahwa ini adalah ciri khas seorang insinyur - mereka menyelesaikan pekerjaan. Kadang-kadang itu tidak cantik, dan kadang-kadang Anda harus kembali dan mengulanginya, tetapi pada akhirnya mereka menyelesaikan pekerjaan!

— Peter Rowell

@PeterRowell: Anda mungkin menemukan ini bacaan yang menarik: brandonsavage.net/when-to-write-bad-code

— Marjan Venema

Sayangnya, pertanyaannya bukan pertanyaan yang sesuai dengan filosofi Q&A dan format situs, tetapi itu tidak mengurangi nilai jawaban Anda. Jika Anda ingin mengembangkannya dan menambahkan sedikit penjelasan untuk setiap poin, itu akan membuat posting blog yang bagus untuk blog komunitas kami .

— yannis

@MarjanVenema: Ya, saya sepenuhnya setuju dengannya. Kembali di tahun 80-an saya ditugaskan menulis spec untuk editor baru, untuk disetujui sebelum saya mulai coding. Saya menatap layar kosong itu selama lebih dari seminggu mencoba mencari cara untuk menggambarkan sesuatu yang saya tidak mengerti. Manajer saya menyatakan ketidaksenangannya dengan kurangnya kemajuan saya. Setelah 3 hari di akhir pekan, ia membawa angin di mejanya. Dia bertanya apa yang terjadi, dan saya mengatakan bahwa saya menulis editor selama akhir pekan, dan kemudian hanya menulis spek apa yang telah saya kerjakan. Saya memang menulis ulang beberapa kode, tetapi kebanyakan refactor / pembersihan.

— Peter Rowell

1

@YannisRizos - Saya tertarik menulis blog tentang ini. Apakah Anda ingin mengirim saya email dengan pedoman apa pun atau haruskah saya menulis sesuatu?

— Rocklan

22

Di bawah judul " dll. " Muncul sesuatu yang dapat dengan mudah mengambil 50% atau lebih dari waktu Anda.

Pelajari cara men-debug.

Ini berarti mempelajari Metode Ilmiah . Maksud saya benar - benar mempelajarinya. Dan kemudian menerapkannya dengan kejujuran diri yang brutal . Pelajari bagaimana menyatakan dengan tepat apa yang Anda tahu benar, apa yang Anda tahu tidak benar, dan hal-hal yang tidak Anda ketahui. Setiap kali Anda dengan sembarangan menetapkan item ke kategori yang salah, Anda baru saja membuat hidup Anda jauh lebih sulit.

Belajarlah untuk mengatakan "Saya pikir" bukannya "Saya tahu". Anda hanya bisa mengatakan "Saya tahu" ketika Anda "berpikir" sesuatu itu benar (atau salah), dan kemudian Anda membuktikannya!

Banyak bug sepele, tetapi mereka bisa sulit dilihat karena Anda "tahu" kode apa yang seharusnya ... kecuali tidak. Temukan teman untuk menjelaskannya. Minta mereka untuk menjadi "idiot ahli": seseorang yang tidak tahu kode Anda, tetapi siapa yang Anda tahu Anda tidak bisa menghancurkan BS masa lalu. Jangan kaget jika di tengah-tengah menggambarkannya kepada Anda, Anda tiba-tiba berhenti dan berkata, "jadi Anda bisa ... lihat ... lihat itu ... sh * t. Terima kasih."

Serangga nontrivial membutuhkan gudang teknik. Klasik yang dapat dengan cepat menyoroti sebagian besar bug yang tidak terkait waktu adalah Wolf Fence di Alaska. Ada serigala di suatu tempat di Alaska; membangun pagar memotong negara menjadi dua. Di sisi mana serigala berada? Potong sisi itu menjadi dua. Busa, bilas, ulangi. Melakukan ini 20 kali di tempat-tempat yang dipilih dengan baik dalam kode mengurangi area di mana bug (serigala) dapat mencapai 1/1048576. Bunuh serigala itu.

Kiat: cari gelombang tangan — fisik, mental, atau jenis lainnya. Segera setelah Anda (atau kolega Anda) tersentak / mengalihkan / memperkecil perhatian yang diberikan pada sebagian kode, jadi benar-benar gila . Karena area di mana Anda baru tahu bug tidak bisa, meskipun Anda telah menghabiskan berjam-jam / hari mencari hal d * mn dan masih tidak dapat menemukannya ... itu adalah lokasi probabilitas tertinggi untuk bug. Tidak ada yang mendapat 'bye' , tidak ada (termasuk mesin, OS, kompiler, atau Anda ) mendapat semacam "hormat". Ada bug. Titik. Akhir kalimat. Sekarang pergi, bunuh benda itu.

Saya tahu tidak ada sekolah yang mengajarkan debugging sebagai subjek tersendiri. IMNSHO, ini mungkin satu-satunya bukti paling mencolok bahwa mereka (universitas / profesor) tidak mengajari Anda untuk menjadi seorang programmer, mereka, sebaliknya, mengajari Anda untuk ... seperti mereka? Keras? Mungkin. Benar? Tentukan pilihan Anda sendiri. Sekarang buktikan.

— Peter Rowell
sumber

Anda mungkin tertarik dengan Saff Squeeze , teknik yang dijelaskan oleh Kent Beck yang menggunakan tes dan refactoring untuk debugging: Hit 'em High, Hit' em Low : Pengujian Regresi dan Saff Squeeze oleh Kent Beck, Three Rivers Institute (Abstrak: To secara efektif mengisolasi cacat, mulailah dengan tes tingkat sistem dan progresif inline dan pangkas sampai Anda memiliki tes sekecil mungkin yang menunjukkan cacat.) Kedengarannya sangat seperti Pagar Serigala Anda, menggunakan kemampuan Tes dan kemampuan Refactoring IDE.

— Jörg W Mittag

1

Jawaban bagus - siapa pun dapat menulis kode, debug programmer nyata.

— Rocklan

@ JörgWMittag: Saya penggemar berat pengujian regresi otomatis. Saya pertama kali menggunakannya pada proyek mesin pencari di pertengahan 80-an, dan saya terkejut (kaget!) Pada hal-hal yang akan jatuh setelah apa yang tampak sebagai perubahan "kecil" untuk beberapa potongan kode yang tampak tidak bersalah. (Catatan: ini adalah 200.000+ SLOC dari C, dan masalah manajemen memori adalah kutukan dari keberadaan kita.)

— Peter Rowell

3

Saya khawatir ini adalah pertanyaan yang cukup besar bagi siapa pun untuk menjawab secara meyakinkan atau otoritatif, terutama mengingat Anda menginginkan daftar yang diprioritaskan. Ada banyak programmer di luar sana, dan mereka mengerjakan hal-hal yang sangat berbeda - tentu saja, dasarnya tetap sama, tetapi apa yang Anda butuhkan untuk tetap aktif dalam ingatan Anda bisa sangat berbeda, dan memang ada banyak tugas di mana Anda dapat tetap cantik tingkat tinggi tanpa masuk lebih dalam.

Namun tampaknya Anda benar-benar peduli bagaimana menjadi pengembang yang lebih baik, dan bukan hanya sekadar pertukaran. Saya menemukan itu mengagumkan, dan saya dapat membagikan beberapa hal yang telah membantu saya belajar bagaimana memprogram.

Hampir semua pemrograman bermuara pada algoritma dan struktur data. Mereka, pada gilirannya, adalah contoh dari pertanyaan yang lebih besar - bagaimana kita memodelkan hal-hal dan proses dari dunia nyata ke dalam representasi sehingga komputer dapat mengerti. Jika Anda baru memulai, mungkin berguna untuk menggunakan bahasa pemrograman tingkat tinggi (seperti Java, Python, apa pun) untuk menjadi terbiasa dengan menerapkan struktur data dan algoritma.

Pada titik tertentu, setelah bermain-main dengan struktur data dan algoritma, Anda mungkin mulai mendapatkan pertanyaan yang menggerogoti "tetapi bagaimana kita beralih dari memberi tahu komputer apa yang harus dilakukan, ke komputer yang benar-benar melakukannya?" Kemudian Anda dapat melihat bagaimana komputer benar-benar menghitung - bagaimana memori dan CPU bekerja bersama untuk melaksanakan instruksi, bagaimana sistem operasi mengabstraksikan perangkat keras sehingga Anda dapat menulis sebuah program yang, katakanlah, membuka file, tanpa pengkodean ke tingkat rendah tertentu antarmuka hard-drive.

Ini mungkin titik yang baik untuk memulai - bagaimana algoritma dan struktur data memodelkan masalah dari dunia nyata, dan bagaimana komputer benar-benar melakukan komputasi. Mengetahui yang terakhir sangat berguna dalam menguasai bahasa tingkat rendah seperti C, yang memanfaatkan jauh lebih sedikit asap dan cermin daripada bahasa OO dan scripting :)

— RuslanD
sumber

2

YAGNI : "Selalu terapkan hal-hal ketika Anda benar-benar membutuhkannya, jangan pernah ketika Anda hanya meramalkan bahwa Anda membutuhkannya."

Dalam pengalaman saya, sangat umum bagi "programmer" untuk meramalkan banyak kasus di masa depan dan mencoba untuk "meningkatkan" kode dengan menambahkan kode untuk mengantisipasi mereka! Dalam kebanyakan kasus, kode yang mereka tambahkan hanya akan mengasapi kode dan menambah kerumitan pada kode.

— Louis Rhys
sumber

1

Hal paling penting untuk diketahui tentang menjadi seorang programmer adalah bahwa menulis kode adalah pekerjaan keras, dan sikap "kerah biru" yang cekatan dalam menghasilkan apa yang Anda bayarkan untuk menghasilkan akan membuat Anda lebih jauh daripada pembelajaran esoteris mana pun.

Belajar masuk ke zona tersebut. Maksud saya keadaan mental ketika Anda hanya berfokus pada tugas Anda dan Anda dapat mulai menyimpan banyak hal besar di kepala Anda dan bagaimana mereka saling beroperasi sekaligus. Setelah Anda terbiasa memasuki zona sesuka hati, mulailah mengkhawatirkan sisanya. Sampai Anda dapat mengeluarkan kode seperti semacam kode untuk mengeluarkan sesuatu, sisanya hampir tidak berguna.

EDIT:

Jika Anda tidak percaya ini dan Anda menurunkan saya, saya percaya bahwa Anda tidak tahu apakah Anda memiliki tekad untuk melakukannya selama 20 tahun. Saya tahu saya melakukannya karena saya menerima ini. ;)

— Nathan C. Tresch
sumber

0

Pertanyaan terbaru, terkait dengan beberapa cara untuk yang satu ini, dan Answer punya tautan ke blog ini yang membahas masalah yang sama dari sudut yang berbeda.

Mungkin konsep yang paling penting untuk setiap pengembang adalah "kerendahan hati" .... Setelah Anda menerima bahwa Anda tidak tahu semuanya, Anda terbuka untuk mencari solusi. Sebagian besar orang yang menulis blog tentang pemrograman berada dalam persentil teratas, dan masalahnya adalah masih banyak yang belum mengontrol kecenderungan narsis mereka .... itulah sebabnya mereka menulis blog ..... Anda perlu belajar mengidentifikasi blogger dan abaikan kata-kata kasar

Blog yang ditautkan benar-benar tidak lebih dari kata-kata kasar - Dalam setiap industri mengeluh bahwa lulusan baru tidak berguna adalah umum, bahwa dibutuhkan bertahun-tahun untuk menjadikannya bermanfaat dan produktif. Mungkin masalahnya adalah bahwa guru yang memproklamirkan diri ini sebenarnya berharap terlalu banyak dan lupa bahwa begitu mereka tidak akan bisa menyelesaikan FizzBuzz. Tidak semua orang dapat berada dalam 10 persen teratas, menurut definisi, setengah dari programmer berada di bawah rata-rata ......

— mattnz
sumber

Saya setuju bahwa orang banyak mengoceh, tapi saya pikir inti dari postingan yang Anda tautkan di atas adalah bahwa orang yang tidak tahu bagaimana menyelesaikan FizzBuzz melamar pekerjaan pemrograman , yang berbeda dari hanya menjadi pemula dan perlu membungkus kepala Anda di sekitar idiom pemrograman. Saya setuju dengan Anda tentang masalah kerendahan hati, dan banyak orang tampaknya tidak tahu apa itu.

— RuslanD