Apa yang harus diketahui oleh setiap programmer?

Terlepas dari bahasa pemrograman atau sistem operasi yang digunakan atau lingkungan yang mereka kembangkan, apa yang harus diketahui setiap programmer?

Beberapa latar belakang:

Saya tertarik menjadi programmer terbaik yang saya bisa. Sebagai bagian dari proses ini saya mencoba memahami apa yang tidak saya ketahui dan akan sangat bermanfaat bagi saya jika saya tahu. Walaupun ada banyak daftar di sepanjang baris "n hal yang harus diketahui oleh setiap pengembang [masukkan bahasa pemrograman]", saya belum menemukan hal serupa yang tidak terbatas pada bahasa tertentu.

Saya juga berharap informasi ini menarik dan bermanfaat bagi orang lain.

Cara menelan kesombongan dan mengakui kesalahan tanpa menganggapnya pribadi.

Bagaimana berpikir seperti pengguna, dan bukan seperti programmer geek techie.

Kapan meminta bantuan, dan kapan TIDAK meminta bantuan.

Cara membaca kode orang lain.

Keakraban dengan sistem kontrol versi. Tidak harus setiap orang, tetapi konsep dasar yang dapat diterapkan untuk semuanya harus diketahui.

Inilah 10 bit saya:

• Bagaimana menjadi rendah hati. Kita semua di sini untuk belajar. Anda mungkin lebih pintar dari yang lain, tetapi ada banyak orang yang lebih pintar dari Anda.
• Cara belajar / mengkonsumsi informasi. Saya tidak tahu tentang Anda, tetapi saya selamanya belajar! Buku, Internet, apa pun!
• Apa kamus itu dan bagaimana menggunakannya, dan bagaimana mengetahui akronim dengan cepat.
• Apa alat dasar perdagangan dan apa yang mereka lakukan (IDE, CVS et al).
• Ketahui terminologi umum dan apa artinya: pola desain, kegunaan, pengujian (ha!), Tumpukan, dll.
• Memiliki pemahaman tentang OOP.
• Jadilah "mampu" dalam setidaknya satu bahasa, tidak ada yang luar biasa, hanya tahu cara mengidentifikasi variabel dan metode, dll. Dari sini Anda dapat belajar FAST.
• Memahami bahwa orang pada akhirnya menggunakan perangkat lunak dan ingin membuat orang-orang bahagia

Mungkin terlalu halus, tetapi saya menganggapnya sebagai "mengetahui masalah mana yang harus dipecahkan." Banyak programmer (dan orang normal) menyia-nyiakan upaya luar biasa untuk menyelesaikan hal-hal yang sebenarnya tidak terlalu penting; atau mereka menciptakan solusi, dengan banyak pekerjaan ekstra, itu tidak cukup apa yang dibutuhkan.

Bagaimana cara santai. Itu rahasia produktivitas.

Akhirnya, kemauan keras dan kafein tidak cukup. Kontraksi konstan yang kita lakukan ini sangat merusak.

Ini masalah besar.

Tipe data dasar & teori algoritma. Hal-hal seperti notasi O Besar, array, antrian, dll.

Bagaimana memilih alat yang tepat untuk tugas yang tepat, dan tidak ikut serta dalam perang api konyol tentang alat pemrograman favoritnya.

Nah, ini $ 0,02 saya:

• Pembelajaran tidak pernah berhenti. Tidak peduli seberapa baik Anda berpikir Anda, selalu ada seseorang yang lebih baik daripada Anda, dan selalu ada sesuatu yang dapat Anda tingkatkan tentang diri Anda. Jika Anda berhenti belajar, Anda pasti akan menurun sebagai seorang programmer. Membaca buku-buku. Baca blog. Bicaralah dengan programmer lain.
• Coba pelajari beberapa bahasa. Setidaknya salah satunya berorientasi objek. Selain itu, Anda harus mengetahui sesuatu tentang berbagai teknologi yang terkait dengan bahasa yang Anda pelajari (mis. Jika Anda belajar Java, alangkah baiknya jika Anda tahu sesuatu tentang Spring, dan sebagainya ..).
• Refactoring. Cepat atau lambat Anda akan membutuhkan pengetahuan itu.
• Pelajari cara menangani kode lawas.
• Tulis tes unit. Pelajari tentang TDD.
• Belajar bekerja dalam tim.
• Tulis kode yang elegan dan mudah dibaca. Seperti pepatah lama: "Tulis kode Anda seolah-olah orang yang akan mempertahankannya adalah pembunuh berantai psikotik yang tahu di mana Anda tinggal."
• Belajar bagaimana menjadi malas dan disiplin pada saat yang sama. Pemrogram yang baik memiliki kedua kualitas ini. Aneh tampaknya, mereka tidak saling bertentangan, tetapi saling melengkapi.

Anda tidak dapat menguji kualitas menjadi suatu produk.

Setiap programmer harus memahami pola desain .

Saya sedikit terlambat untuk yang ini, tapi saya akan pergi dengan pengetahuan yang diberikan oleh Edsger Dijkstra:

Selain kecenderungan matematis, penguasaan bahasa ibu seseorang yang sangat baik adalah aset paling vital dari seorang programmer yang kompeten.

Jika Anda tidak dapat menulis paragraf yang bagus, kemungkinan Anda juga tidak bisa menulis kode yang baik.

Jangan terlalu terikat secara emosional, melekat pada, atau beragama tentang teknologi, OS, atau bahasa tertentu - tidak ada yang sempurna - dalam jangka panjang Anda akhirnya berharap Anda bisa membuat ala carte sendiri dari apa yang Anda inginkan. suka tentang masing-masing yang berbeda.

Pikirkan itu seperti mobil - Anda mungkin tidak pernah mengendarai mobil tertentu sebelumnya, tetapi mereka semua memiliki kunci, roda kemudi, akselerator, dan rem - Anda harus bisa masuk dengan cepat dan pergi begitu Anda memilah-milah di mana. Perlakukan OS dan bahasa dengan cara yang sama dan fokus pada mempelajari konsep-konsep penting yang mendasari mereka bahkan jika Anda berada di pergolakan spesifik dari setiap contoh yang diberikan.

Dan seiring waktu coba untuk memahami dan menghargai leluhur, warisan, dan kesamaan berbagai teknologi yang akan membantu Anda menjaga perspektif. Sadarilah misalnya bahwa, sementara pohon evolusi secara aktif bercabang dan penuh jalan buntu, teknologi dari waktu ke waktu cenderung berulang kali berkumpul di sekitar 'praktik terbaik' dan 'skala ekonomi' ( misalnya, perhatikan bahwa Mac tidak jauh berbeda dari PC di bawah tenda hari ini ...).

Terakhir, ingatlah betapa pun menyenangkannya Anda dengan semua itu, teknologi pada dasarnya mewakili lensa yang tidak sempurna antara apa yang dapat dibayangkan oleh pikiran Anda dan apa yang sebenarnya Anda hasilkan. Lakukan yang terbaik, belajar untuk belajar, dan tetap bisa beradaptasi ...

Cara memprogram dalam C.

Bahwa hari Anda berhenti belajar harus menjadi hari Anda tidak lagi seorang programmer.

Pengujian dan debugging unit.

• Ekspresi Reguler
  • Untuk apa mereka bagus
  • Bila tidak untuk menggunakan mereka
  • Cara menulis regex yang bisa dibaca
  • Cara debug mereka

Itu disebutkan sebelumnya tapi saya pikir itu layak untuk jawabannya sendiri.

Tidak seorang pun ingin menggunakan perangkat lunak. Mereka ingin masalah diselesaikan.

Kopi dan IntelliSense adalah teman terbaik Anda.

Cara mengamati objek rumit besar dan menguraikannya menjadi objek kecil sederhana yang masih menyelesaikan tugas yang sama ketika disatukan kembali.

Jangan pernah mempercayai pengguna ( terutama jika aplikasinya publik!), Mereka akan sering melakukan apa saja untuk menghancurkan aplikasi Anda dengan satu atau lain cara.

Jadikan itu bukti di masa depan & dapat diperluas - Anda tidak pernah tahu kapan Anda ingin mengembangkannya dalam beberapa tahun mendatang dan menyadari betapa banyak upaya yang diperlukan untuk membuat ulang kode yang dibuat dengan buruk.

Bahwa programmer tidak tahu segalanya dan harus selalu mencoba mempelajari bahasa / teknologi baru, dll.

Dasar-dasar desain UI yang baik dan desain komunikasi (grafis) .

Saya melihat begitu banyak aplikasi dan proyek hancur oleh desain yang buruk atau kegunaan yang buruk. Hanya mempelajari dasar-dasarnya dapat membuat dunia berbeda. Ditambah teknik pemecahan masalah visual (yaitu, bagaimana mengkomunikasikan konsep secara visual) adalah tantangan yang merangsang yang harus membuka mata Anda terhadap cara pandang baru, yang pada gilirannya akan berdampak pada kode Anda.

Buku yang direkomendasikan adalah Buku Desain Non Desainer oleh Robin Williams

Inilah yang dikatakan Joel Spolsky tentang hal itu :

Wow! Setiap orang harus melakukan beberapa desain grafis, dan tidak setiap tim perangkat lunak memiliki kemewahan desainer profesional. Buku yang sangat bagus dan tipis ini akan memberi Anda pemahaman tentang prinsip-prinsip di balik tata letak halaman, font, dll. Berita baiknya adalah, Anda dapat membacanya di bak mandi sebelum air menjadi dingin, dan hari berikutnya, kotak dialog dan powerpoint Anda dan halaman web akan mulai terlihat lebih baik.

Setiap programmer harus tahu cara belajar dengan cepat. Banyak kali Anda datang ke pekerjaan dan akan diminta untuk mengembangkan teknologi yang belum pernah Anda gunakan. Mereka mungkin memberi Anda sekitar satu minggu atau lebih untuk berdiri (jika Anda beruntung) sebelum Anda diminta untuk menulis kode kualitas produksi.

Kontrol versi. Dan mengutip teman perempuan saya: "Saya tidak hanya ingin Anda mencuci piring, saya ingin Anda menyukainya !"

Persyaratan berubah, kode Anda harus beradaptasi, dan itu mungkin atau mungkin bukan Anda yang harus menyesuaikannya.

Ada beberapa pertanyaan di sini terkait dengan topik yang dipengaruhi oleh ini.

Dari atas kepala saya:

1. Sangat sedikit masalah pemrograman yang membutuhkan matematika di luar penjumlahan, pengurangan, perkalian, dan pembagian. Jika Anda berpikir untuk menggunakan kalkulus untuk menyelesaikan masalah, teliti alternatifnya secara menyeluruh sebelum melakukannya.

2. Setiap kali Anda menebak-nebak cara kerja sesuatu, Anda salah melakukannya. Bukan tugasmu untuk menjadi telepati.

3. Orang yang memberi Anda spek jarang tahu semua yang dia inginkan sampai Anda menghapusnya.

4. Lebih dari setengah menjadi programmer hebat berasal dari berurusan dengan manusia. Berinteraksi dengan tim Anda, mengelola manajer Anda, dan menangani pengguna akhir adalah setengah dari pekerjaan.

5. Kode yang baik ditulis untuk dibaca oleh orang sebanyak yang dibaca oleh kompiler Anda.

6. Praktik terbaik dan realitas praktis akan bertentangan lebih dari yang dipikirkan oleh programmer, tetapi kurang dari yang dilakukan oleh manajer. Ketika mereka tampak dalam konflik, terserah Anda untuk melukiskan dan memahami konflik dan kemudian menyerah pada yang praktis. Solusi yang halus dan pintar hanya lebih baik daripada solusi yang jelek dan brutal jika lebih efektif dalam jangka panjang.

7. Alat yang hebat tidak bisa menjadi programmer yang hebat, tetapi alat yang buruk membuat kita sama buruknya.

8. Jangan pernah meremehkan teknologi, tetapi selalu mencari alternatif terbaik.

9. Semakin banyak bahasa yang Anda kenal, semakin baik Anda menggunakan bahasa yang Anda gunakan.

10. Jangan diganggu oleh lambannya pemikiran berorientasi pemrograman ke dalam kehidupan sehari-hari Anda. Bahkan ketika kita tidak berada di depan komputer, kita semua menderita keterbatasan bandwidth, memiliki penalti kinerja dari pengalihan tugas, dan perlu memuat sesuatu dari penyimpanan cadangan. Komputer seharusnya meniru pemikiran manusia dan analognya ada di mana-mana.

Membaca kode orang lain tidak akan merusak otak Anda, tetapi mencari tahu mengapa Anda tidak melakukannya dengan cara itu (jika lebih baik atau tidak adalah pertanyaan lain).

Ini memberi Anda pemrograman percobaan gedanken , dan kadang-kadang Anda menemukan seseorang yang mengimplementasikan sesuatu dengan lebih baik! Seperti cara yang lebih baik.

Jawaban ini secara alami diperluas untuk membaca kode Anda sendiri, sehingga diperluas untuk menggunakan kontrol versi dan DIFF, dan dengan demikian menjadi 42.