Apa yang harus diketahui setiap programmer tentang pemrograman?

52

Tolong, tetap pada masalah teknis , menghindari masalah perilaku, budaya, karir atau politik.

experience  self-improvement  programming-practices 
— bigown
sumber
7
— pramodc84
Pertanyaan semacam ini sangat mengganggu saya. Itu hanya bisa muncul dari benak seseorang yang melihat dunia dalam istilah hitam putih. Tidak setiap programmer memiliki pekerjaan yang sama dan jika itu adalah penyebut umum terkecil yang Anda cari, jawaban di bawah ini menunjukkan bahwa Anda hanya berakhir dengan daftar kencing hewan peliharaan.
— Kapten Sensible

Jawaban:

92

  1. Bug ada dalam kode Anda , bukan kompiler atau pustaka runtime.

  2. Jika Anda melihat bug yang tidak mungkin terjadi, periksa apakah Anda telah membangun dan menyebarkan program Anda dengan benar. (Terutama jika Anda menggunakan IDE rumit atau kerangka kerja yang mencoba menyembunyikan detail berantakan dari Anda ... atau jika build Anda melibatkan banyak langkah manual.)

  3. Program bersamaan / multi-utas sulit untuk ditulis dan sulit untuk diuji dengan benar. Cara terbaik adalah mendelegasikan sebanyak yang Anda bisa ke perpustakaan dan kerangka kerja konkurensi.

  4. Menulis dokumentasi adalah bagian dari pekerjaan Anda sebagai programmer. Jangan biarkan "orang lain" melakukannya.

SUNTING

Ya, poin saya # 1 dilebih-lebihkan. Bahkan platform aplikasi terbaik yang direkayasa memiliki bagian bug, dan beberapa yang kurang direkayasa penuh dengan hal itu. Namun demikian, Anda harus selalu mencurigai kode Anda terlebih dahulu , dan mulai menyalahkan bug kompiler / pustaka saat Anda memiliki bukti jelas bahwa kode Anda tidak bersalah.

Kembali pada hari-hari ketika saya melakukan pengembangan C / C ++, saya ingat kasus di mana seharusnya "bug" optimizer ternyata menjadi karena saya / beberapa programmer lain telah melakukan hal-hal yang menurut spesifikasi bahasa memiliki hasil yang tidak ditentukan. Ini berlaku bahkan untuk bahasa yang dianggap aman seperti Jawa; mis. perhatikan model memori Java (JLS bab 17).

— Stephen C
sumber
17
Saya lebih suka mengatakan "Bug mungkin ada dalam kode Anda", karena saya telah menemukan bug di pustaka runtime beberapa kali. Saya belum pernah mengalami bug kompiler. Tetap memberi +1.
— Chinmay Kanchi
29
Jika Anda belum pernah menemukan bug yang bonafid di kompiler, Anda tidak cukup berani dengan pengkodean. ;)
— Mason Wheeler
8
@Chinmay, @ spudd86, @Mason - ya ... dan saya juga menemukan bagian bug penyusun dan pustaka dalam 30+ tahun pemrograman saya. Tetapi dalam pengalaman saya, 99 +% bug ternyata (setidaknya sebagian) kesalahan kode saya. Jawaban saya sengaja melebih-lebihkan ini untuk mendapatkan titik bahwa Anda harus selalu mencurigai kode Anda terlebih dahulu.
— Stephen C
5
Saya tidak mendapatkan ketakutan irasional yang dimiliki orang-orang dengan pemrograman multi-threaded. Saya curiga orang yang mengabadikan pandangan ini, tidak memprogram banyak kode multi-utas. Itu tidak terlalu sulit. +1 untuk semua yang lainnya.
— Steven Evers
4
Jika Anda sedang mengerjakan kompiler, maka bug tersebut mungkin ada di kode dan kompiler Anda;)
— Legooolas
84
  • Cara membaca kode orang lain.
  • Kode tidak ada jika tidak dicentang di Sistem Kontrol Versi.
— pramodc84
sumber
8
+10000 jika saya bisa untuk komentar kontrol versi. Riwayat dan perubahan pencatatan mutlak diperlukan dan merupakan alasan Anda harus meletakkan segala sesuatu di kontrol versi sejak awal.
— Legooolas
2
... dan repositori telah disinkronkan ke setidaknya satu lokasi lain. Penting dengan DVCS, tetapi juga dengan VCS terpusat.
Dalam hal ini, kode tidak ada kecuali ada item pekerjaan yang mengizinkan pengembang untuk menulisnya.
— Jesse C. Slicer
2
Saya akan menambahkan satu untuk belajar cara membaca kode orang lain. Lebih sulit yang disadari sebagian besar dari kita, tetapi merupakan bagian penting dari pemrograman yang sukses.
— bogeymin
ditambah satu untuk mempelajari cara membaca kode orang lain.
— itsaboutcode
76

Perhitungan titik apung tidak tepat.

— Chinmay Kanchi
sumber
22
— Adam Paynter
Jika ada yang tidak tahu apa yang saya bicarakan, baca tautan @ Adam. Ini adalah ringkasan yang sangat baik dari perangkap perhitungan floating point.
— Chinmay Kanchi
1
Dan jika mereka tidak tahu mereka bisa berada di antara set orang yang bertanya di stackoverflow setiap hari.
— Brian R. Bondy
1
@ Brian: Benar sekali. Saya berharap ada cara untuk mengidentifikasi pertanyaan yang dijelaskan oleh aritmatika floating point. Anda dapat membuat Aplikasi Stack yang menampilkan pertanyaan floating point yang berbeda setiap hari!
— Adam Paynter
63

Jangan berhenti belajar.

— systempuntoout
sumber
1
Terkait: Jangan berhenti percaya.
— Fishtoaster
3
Terkait: Jangan berhenti memikirkan besok.
— ocodo
7
Terkait: Jangan menghentikan musik.
— adamk
1
Terkait: Jangan berhenti bergerak! Ini hidup Anda, terus bergerak, lakukan dengan benar, Anda harus melakukannya dengan benar!
— ocodo
44

Hal # 1 yang dapat Anda lakukan untuk meningkatkan kualitas dan pemeliharaan kode Anda adalah MENGURANGI DUPLIKASI.

— Chris Holmes
sumber
4
KERING, ya! Bagaimana saya bisa lupa? ;-)
— Maniero
Ini sangat penting sehingga saya menjawabnya lagi .
Saya lebih suka mengatakan: KURANGI KONDISI. Setiap while / if / for adalah bug potensial.
— zvrba
1
Anda tahu, lucunya tentang KERING adalah diulang di mana-mana. :) +1
— Billy ONeal
39

Keterampilan Pemecahan Masalah dan Debugging

Mereka hampir tidak menghabiskan waktu pada topik ini di salah satu program pemrograman yang saya ambil, dan dalam pengalaman saya itu adalah salah satu penentu terbesar seberapa produktif seorang programmer. Suka atau tidak, Anda menghabiskan lebih banyak waktu dalam fase pemeliharaan aplikasi Anda daripada fase pengembangan baru.

Saya telah bekerja dengan soooooo banyak programmer yang melakukan debug dengan mengubah hal-hal secara acak tanpa strategi untuk menemukan masalah apa pun. Saya sudah melakukan percakapan ini puluhan kali.

Pemrogram Lainnya: Saya pikir kita harus mencoba untuk melihat apakah itu memperbaikinya.
Saya: Oke, anggap itu memang memperbaikinya. Apa artinya itu memberi tahu Anda di mana sumber masalahnya?
Programmer Lainnya: Saya tidak tahu, tetapi kita harus mencoba sesuatu .

— JohnFx
sumber
2
Saya akan memposting ini. Begitu banyak pekerjaan programmer memperbaiki bug, dan banyak orang cenderung tidak mampu melakukannya (terutama dalam kode orang lain).
— Dov
+1 Saya beralih dari javascript / php ke C # dan jatuh cinta dengan melangkah melalui kode. Saya berharap bahwa bahasa yang diketik secara dinamis dapat melakukan pekerjaan yang jauh lebih baik dari ini.
— Evan Plaice
Perilaku aneh lainnya adalah programmer bersikeras bahwa setiap bagian dari programnya benar sedangkan hasilnya jika salah. "-Anda tidak perlu mencetak array di konsol untuk memeriksa apakah array diurutkan karena baris di atas adalah array.sort ()." "-Nah ... kamu tahu, itu tidak berfungsi. Pasti ada yang salah di suatu tempat. Kamu tidak bisa hanya mempertahankan kodemu pada saat ini!"
— gawi
2
Saya pikir titik debugging untuk memvalidasi asumsi Anda di seluruh program Anda. Terkadang, Anda perlu memancing untuk mencari petunjuk. Ini harus dilakukan secara sistematis. Sangat sah untuk mencoba sesuatu yang mungkin memberi tahu Anda sesuatu yang baru. Saya sering melakukannya.
— gawi
37
  1. Jangan pandai; menjadi jelas.
  2. Gunakan sebelum digunakan kembali.
  3. Nama itu penting.
  4. Suatu fungsi melakukan 1 hal dan melakukannya dengan baik.
  5. Kecil lebih baik daripada besar.
— KevBurnsJr
sumber
2
Bisakah Anda menjelaskan "Gunakan sebelum digunakan kembali". Saya belum pernah mendengar itu sebelumnya.
— Tjaart
34

Dasar. Saat ini programmer mempelajari teknologi bukan konsep. Itu salah.

— clrod
sumber
Iya dan tidak. Anda terdengar seperti setiap prof yang pernah saya miliki di universitas ... yang semuanya tidak pernah menjilat perangkat lunak sepanjang hidup mereka. Pengetahuan, tanpa keterampilan tidak berguna dalam profesi kita.
— Steven Evers
4
+1, sangat benar. Ya, ini adalah sesuatu yang ingin dikatakan jenis menara gading, tetapi itu tidak membuatnya kurang benar bagi kita semua di parit.
— MAK
2
Dasar-dasar seperti ejaan? Its wrongseharusnya it's wrong, misalnya.
— Konerak
2
Tidak, dasar-dasar seperti tidak peduli dengan kesalahan ketik tetapi peduli tentang masalah pemrograman.
— clrod
5
Sangat mudah untuk mempelajari langkah-langkah untuk melakukan sesuatu dan seringkali sulit untuk mengetahui kapan Anda harus menggunakannya dan yang lebih penting ketika Anda bisa menggunakannya tetapi tidak boleh. Buku pelajaran sangat buruk dalam menunjukkan bagaimana tetapi tidak mengapa (dan mengapa tidak).
— HLGEM
27

Setiap programmer harus tahu bahwa dia selalu memasukkan asumsi dalam kode, misalnya "angka ini akan positif dan terbatas", "kode ini akan dapat terhubung ke server setiap saat dalam sekejap mata".

Dan dia harus tahu bahwa dia harus bersiap ketika asumsi itu hancur.

— Program Lenny
sumber
6
secara khusus nyatakan mereka dengan assert()- di mana-mana. assert()akan membantu Anda mendokumentasikan asumsi Anda dan menyelamatkan Anda ketika Anda salah.
— Dustin
@Dustin +1 Tidak mungkin Anda bisa mengingat semua asumsi Anda - dokumentasikan secara terprogram dan Anda akan diberi tahu dengan tepat kapan asumsi itu salah.
— Skilldrick
1
... kecuali dikompilasi dengan NDEBUG.
17

Pelajari konsep . Anda dapat Google sintaksisnya.

— pramodc84
sumber
Baik dalam teori, kecuali Google mengerikan untuk menemukan sintaksis spesifik : Mencari istilah seperti "referensi objek" atau "ini" memberikan hasil trilyun, dan mencari idiom seperti "$?" tidak memberikan hasil sama sekali.
— l0b0
14

Pengujian Unit. Ini adalah cara yang bagus untuk mengkodifikasi asumsi Anda tentang bagaimana kode akan digunakan.

— btlog
sumber
13

Itu lebih sulit daripada yang Anda pikirkan.

Meskipun mudah (ish) untuk menyatukan sesuatu yang berfungsi saat digunakan secara normal, mengatasi input yang salah, semua casing tepi dan sudut, kemungkinan mode kegagalan, dll. Memakan waktu dan mungkin akan menjadi bagian tersulit dari pekerjaan.

Maka Anda harus membuat aplikasi terlihat bagus juga.

— ChrisF
sumber
3
Saya pikir ini adalah sumber dari pepatah lama '90% dari pekerjaan membutuhkan 90% dari waktu. 10% terakhir mengambil 90% lainnya '
— GSto
Saya pikir banyak orang cenderung konsisten memperkirakan kompleksitas. "Seberapa keras X itu?" - Kata-kata terakhir yang terkenal: /
— Roman Starkov
@ GSU Saya tidak ingin bekerja 180% dari waktu, 100% baik-baik saja oleh saya!
— adamk
13

Pengetahuan domain. Spesifikasi tidak pernah 100%; mengetahui domain sebenarnya yang Anda kembangkan akan SELALU meningkatkan kualitas produk.

— Steven Evers
sumber
11

Pointer, tentu saja. :)

— Laurynas Biveinis
sumber
3
Pointer hanya benar-benar diperlukan dalam himpunan bagian bahasa untuk sekelompok kecil tugas. Untuk sebagian besar tugas, Anda dapat (dan seharusnya dapat) memprogram seolah-olah konsep pointer tidak ada.
— Chinmay Kanchi
14
@Chinay Kanchi No. Pointer harus dipahami oleh semua orang.
— alternatif
5
Itu benar-benar tergantung pada apa yang Anda maksud dengan pointer. Jika Anda maksud pointer C-style yang dapat Anda manipulasi (yang saya duga), saya berpendapat bahwa programmer Java / C # / Python tidak perlu tahu apa-apa tentang mereka. Jika Anda maksudkan pointer seperti pada "referensi" Java, yaitu, pointer yang tidak bisa diutak-atik, maka ya, beberapa pengetahuan tentang itu diperlukan, jika hanya untuk mencegah Anda tergelincir.
— Chinmay Kanchi
@mathepic Anda akan terguncang sampai ke inti Anda jika Anda harus belajar berapa banyak siswa CS lulus setiap tahun yang tidak mengerti hal pertama tentang petunjuk. Jika saya tidak pergi keluar dari jalan saya untuk mengambil penempatan setiap musim panas saya bahkan tidak akan diajarkan tentang petunjuk dalam C atau referensi di Jawa ...
— Mike B
5
@Chinmay: Seorang programmer Python / Java / C # yang tidak mengerti konsep pointer hilang. L = [[]] * 2; L[0].append(42) Bahasa yang berbeda menggunakan nama yang berbeda, tetapi tipuan sangat penting di mana-mana.
11

Kode Lengkap 2 - penutup ke penutup

— Kyle Ballard
sumber
Anda benar-benar harus mengetahui hal ini sebelum Anda menerima uang untuk diprogram. Jika Anda menemukan sesuatu yang tidak Anda ketahui di dalamnya, pertimbangkan perubahan karier atau periode belajar mandiri yang intensif untuk membuat Anda memahami semuanya. Dan kemudian minta maaf kepada rekan kerja Anda. Dan itu hanya mencakup dasar-dasar pemrograman.
— Tim Williscroft
11

Data lebih penting daripada kode.

Jika data Anda cerdas, kodenya bisa bodoh.

Kode bodoh mudah dimengerti. Begitu juga data cerdas.

Hampir setiap kesedihan algoritmik yang pernah saya alami disebabkan oleh data yang berada di tempat yang salah atau disalahgunakan arti sebenarnya. Jika data Anda memiliki makna, masukkan makna itu ke dalam sistem tipe .

— Gonzales
sumber
2
Anda memiliki saya sampai Anda mengatakan "ketik sistem."
10

Bahasa dan lingkungan mana yang paling cocok untuk pekerjaan itu. Dan itu tidak selalu menjadi favorit Anda.

— Dan Diplo
sumber
10

Memecah dan menaklukkan. Ini biasanya cara terbaik untuk menyelesaikan semua jenis masalah praktis mulai dari penjadwalan hingga debugging.

— Rick Minerich
sumber
8

Keahlian sejati tercermin dalam kemampuan mengeksekusi desain sederhana dengan baik, bukan pada kemampuan membuat desain yang rumit bekerja sama sekali.

Keterampilan ini berasal dari penguasaan yang lebih besar dari fundamental, bukan dalam penguasaan yang misterius. Seorang programmer berkaliber tinggi tidak ditentukan oleh kemampuan mereka untuk mengkodekan apa yang orang lain tidak bisa (menggunakan fungsi tingkat yang lebih tinggi, pemrograman fungsional lanjutan, apa-apa-Anda) tetapi lebih pada kemampuan mereka untuk memperbaiki pengkodean biasa yang sempurna. Memilih dekomposisi fungsionalitas yang sesuai antar kelas; membangun ketahanan; menggunakan teknik pemrograman defensif; dan menggunakan pola dan nama yang mengarah ke dokumentasi diri yang lebih besar, ini adalah roti dan mentega dari pemrograman kaliber tinggi.

Menulis kode yang baik yang Anda, atau orang lain, dapat kembali dalam seminggu sebulan atau setahun dan memahami cara menggunakan, memodifikasi, meningkatkan, atau memperluas kode itu sangat penting. Ini menghemat waktu dan tenaga Anda. Ini melumasi roda-roda produktivitas dengan menghilangkan penghalang jalan yang akan Anda temukan sebelumnya (mungkin mengganggu jalan pikiran Anda, atau mungkin mengambil berjam-jam atau berhari-hari usaha dari pekerjaan lain, dll.) Membuatnya lebih mudah untuk berkonsentrasi pada masalah-masalah sulit , dan terkadang itu membuat masalah sulit hilang.

Dalam satu kata: keanggunan. Setiap kelas, setiap metode, setiap kondisi, setiap blok, setiap nama variabel: berjuang untuk keanggunan.

— Baji
sumber
8

Jangan pernah menyalahkan pengguna apa yang bisa diperbaiki dengan pengalaman pengguna yang lebih bersih atau dokumentasi yang lebih baik. Seringkali, programmer secara otomatis menganggap pengguna adalah idiot yang tidak dapat melakukan sesuatu dengan benar, ketika masalahnya adalah pengalaman keseluruhan yang buruk atau kurangnya komunikasi. Program yang dimaksudkan untuk digunakan, dan memperlakukan pengguna dengan jijik berarti melewatkan titik pemrograman sejak awal.

— user8
sumber
6

Setiap programmer harus tahu cara menggunakan debugger, dan tahu cara menggunakannya dengan baik .

— Brian R. Bondy
sumber
4

Cara memperkirakan secara akurat berapa banyak waktu yang dibutuhkan fitur untuk mengimplementasikan. Lebih penting lagi, bagaimana cara menyampaikan bahwa Anda tidak membohongi diri sendiri saat mengirimkan perkiraan itu.

— wheaties
sumber
2
atau belajar bagaimana menjadi tamu dengan baik dan menyampaikan bahwa Anda tidak menjadi tamu ...;)
— Billy Coover
4

Masalah gaya pengkodean:

  • masalah lekukan yang konsisten,
  • penggunaan ruang putih yang konsisten (mis. di sekitar operator) penting,
  • penempatan hal {} yang konsisten,
  • masalah pengidentifikasi yang dipilih dengan baik,
  • dll.

... dan masalah desain yang baik.

Idealnya, programmer mempelajari hal-hal ini sebelum (atau selama) ulasan kode pertamanya. Dalam kasus terburuk, programmer mempelajarinya ketika bos mengatakan kepadanya untuk membuat beberapa perubahan non-sepele untuk beberapa kode mengerikan terburu-buru.

— Stephen C
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.