Harus ketat atau pragmatis?

Saya mulai menyadari bahwa mengembangkan perangkat lunak (antara lain) adalah proses untuk terus bertanya pada diri sendiri. Pertanyaan mengenai kualitas kode, pemisahan masalah, meminimalkan ketergantungan, ...

Tetapi pertanyaan utamanya adalah: seberapa jauh Anda bisa pergi tanpa berakhir di rumah sakit jiwa?

Saya melamar pekerjaan baru. Kemarin saya dengan calon majikan di masa depan yang ingin menguji kemampuan pemrograman saya. Salah satu latihan adalah: jelaskan apa yang dilakukan kode ini. Saya telah melalui beberapa kode aplikasi (winforms di vb.net) yang mereka kembangkan (ini adalah aplikasi administratif untuk rumah sakit). Ini memberi saya kesempatan untuk benar-benar melihat bagaimana mereka mendekati sesuatu dan itu agak mengecewakan.

Beberapa contoh:

• Saya melihat di suatu tempat: Panggil [masukkan nama subrutin di sini] -> Saya terkejut: bukankah itu sesuatu dari VB6?
• Mereka memiliki datalayer terpisah, menggunakan ado.net, tetapi satu metode yang harus saya periksa mengembalikan dataset ke lapisan panggilan. Pisahkan datalayer atau tidak, aplikasi terikat ke ado.net (yang juga bisa menjadi masalah jika mereka tidak pernah beralih ke pendekatan akses data lain).
• Dataset itu dibaca apa adanya, sehingga masih merupakan pendekatan data-sentris (tentu saja, orang dapat memperdebatkan berapa banyak logika / perilaku yang dapat Anda masukkan ke dalam kelas seperti "Pasien" atau "LabAnalysisRequest".
• Saya juga percaya telah melihat pembangunan kueri sql dengan penggabungan string.
• Mereka menggunakan prosedur tersimpan (yang, bagi saya, berarti: hamburan logika)
• tidak menyebutkan pandangan / pengontrol: semuanya didorong oleh bentuk
• Hal paling jelek yang saya lihat adalah:

      Jika TestEnvironment.IsTesting maka
         someVar = [beberapa nilai kode keras]
      lain
         someVar = [beberapa nilai yang diambil secara dinamis]
      berakhir jika
      [sisa dari fungsi di sini]
  

Itu semua sangat berbeda dari apa yang saya pelajari di sekolah: lapisan domain (kegigihan agnostik), lapisan kegigihan, lapisan presentasi, pengujian unit, ...

Jadi saya ulangi pertanyaan saya: seberapa fundamental atau dogmatis seseorang seharusnya? Sejauh mana seorang programmer harus berpegang pada prinsip-prinsipnya atau hanya menulis kode yang berfungsi?

Saya tahu itu tidak langsung menjawab pertanyaan Anda, tetapi saya masih merasa ini lebih berharga daripada komentar:

Ketika Anda melakukan wawancara kerja, Anda mewawancarai mereka sebanyak mereka mewawancarai Anda . Hentikan kebiasaan melihat wawancara sebagai sesuatu yang Anda lakukan dengan merangkak meminta mereka untuk menawarkan sesuatu kepada Anda. Mereka membayar Anda, tetapi Anda membayarnya juga. Jika mereka tidak menyukai Anda, mereka tidak akan mempekerjakan Anda. Jika Anda tidak menyukainya, jangan bekerja di sana.

Ya, di industri ini, dengan basis kode lawas yang berusia sepuluh tahun yang telah diretas dari waktu ke waktu oleh tiga lusin pengembang dengan latar belakang, keterampilan, dan hasrat yang berbeda, didorong oleh tenggat waktu yang ketat, kurangnya sumber daya, dan kendala keuangan, kode ini tidak akan pernah lihatlah cara Anda (seharusnya) telah mempelajarinya. Anda harus membuat beberapa konsesi. Tetapi berapa banyak, dan di mana Anda menarik garis, itu sepenuhnya terserah Anda.
Tentu saja, pekerjaan lebih sulit untuk menemukan lebih sedikit konsesi yang Anda buat. Tetapi mereka mungkin lebih menyenangkan.

FWIW, sejauh ini saya (> 10 tahun di industri) tidak pernah bekerja di perusahaan besar dengan banyak pengembang (~ 30 pengembang adalah yang paling, selusin norma), karena jauh lebih mungkin Anda mengubah sesuatu dalam skala kecil. perusahaan. Selama saya menghasilkan uang yang cukup untuk tidak membuat anak-anak kelaparan, saya tidak ingin menjadi roda gigi kecil di sebuah perusahaan besar, di mana yang harus saya lakukan adalah untuk menyelaraskan dengan sisa roda gigi.
Saya menolak tawaran pekerjaan setelah melihat tes yang mereka inginkan agar saya lulus. Saya seorang pengembang C ++, dan ada banyak tes C ++ di luar sana yang sangat buruk sehingga membuat kuku kaki Anda melengkung dengan jijik, dan saya tidak ingin menghabiskan waktu saya melawan kincir angin karena mereka mempekerjakan orang-orang bodoh yang tidak dapat menulis kode bersih.
Saya juga meninggalkan pekerjaan setelah beberapa bulan karena filosofi pemrograman mereka (tujuan jangka pendek, apalagi tahun depan) tidak sesuai dengan kemampuan saya (stabilitas kode jangka panjang), meskipun mereka mengatakan berbeda dalam wawancara.

Jangan pernah menulis kode yang hanya melakukan pekerjaan. Namun, sediakan sama baiknya untuk memeriksa doktrin Anda. Hanya karena Anda mempelajarinya di sekolah, tidak berarti itu pemikiran saat ini, atau bahkan pemikiran yang valid. Siklus hidup desain perangkat lunak menjadi usang, karena pemrograman harus lebih reaktif terhadap dunia bisnis. Kadang-kadang solusi perangkat lunak yang terhubung secara canggung dihubungkan secara canggung karena bagian-bagian diganti sesuai waktu yang diizinkan.

Berikut adalah daftar masalah yang saya kompilasi yang akan menentukan seberapa baik Anda masuk ke gaya hidup pengkodean sebuah perusahaan.

1. Berapa nilai mereka menyisihkan waktu untuk refactor dan menjadikan basis kode mereka mutakhir. Cara mereka melihat pembaruan basis kode akan menjadi faktor penentu utama seberapa baik Anda menyesuaikan diri.
2. Seberapa sering mereka membeli pihak ke-3 alih-alih membuat kode sendiri.
3. Apa yang mereka pikirkan tentang perangkat lunak sumber terbuka. Apakah mereka menyadari bahwa mereka memiliki fleksibilitas dalam mengubah kode. Apakah mereka melihatnya dengan cara yang sama seperti membeli pihak ke-3.
4. Anda akan bekerja pada lapisan abstraksi tertentu. Apakah tim Anda berinteraksi dengan menentukan antarmuka Anda untuk Anda? Lapisan / tim / sisi antarmuka mana yang lebih berkuasa dalam pengambilan keputusan.
5. Seberapa banyak pengawas mendengarkan para programmer ketika membuat keputusan. Ketika seorang programmer melempar bendera merah, apakah pengawas berhenti dan meninjau keputusan mereka.
6. Apakah Anda menganggap manajemen programer berpengalaman? Bagaimana mereka melihat pengalaman mereka? Apakah pengalaman mereka valid? Apakah mereka membiarkan pengalaman yang sudah usang mempengaruhi pengambilan keputusan?
7. Seberapa lengket basis kode?
8. Seberapa sering mereka memperbarui alat pemrograman mereka (IDE, dll.)

Jawaban atas pertanyaan-pertanyaan ini lebih sesuai dengan bagaimana Anda akan menghargai gaya hidup pemrograman mereka, daripada melihat apakah mereka cocok dengan dogma Anda.

Dogma pasti akan rusak (kami hanya tidak punya waktu untuk memperbarui X). Namun, prioritas akan menentukan seberapa banyak Anda berbenturan dengan gaya dan pengambilan keputusan mereka.

Saya pikir Anda harus mempertimbangkan ini sebagai bagian dari keseluruhan. Saya ingat bahwa salah satu pekerjaan pertama saya adalah posisi dalam kelompok yang memberi tahu saya bahwa mereka melakukan berorientasi objek C ++ - yang baru saja saya lakukan beberapa tahun di sekolah.

Penilaian diri mereka salah - mereka melakukan agak chunky C. Itu masih sangat fungsional dirancang di alam dan saya harus pergi sendiri buku C untuk mengajar diri sendiri printf dan getf dan mekanisme C lainnya yang saya tidak pernah pelajari. Fakta bahwa tidak ada seorang pun di tim yang menyadari bahwa C menyukai kode mereka menunjukkan betapa tidak pantasnya "desain C ++" ini jatuh. Tujuan saya pada saat itu adalah melakukan pengembangan OO, jadi ini agak mengecewakan.

Tapi saya senang, pada akhirnya, bahwa saya terjebak dengan tim. Mereka adalah kelompok yang dinamis dari orang-orang yang sangat cerdas dan kaki saya basah dengan banyak masalah yang sulit, saya harus mengerjakan seluruh siklus hidup dan hal-hal yang saya pelajari tentang domain masalah (PKI) telah memicu karir saya sejak saat itu. Pekerjaan yang dilakukan tim di ruang fungsional itu luar biasa dan saya masih sangat menyukai produk itu dan pengalaman kerja itu. Lebih baik lagi - saya masih bekerja dengan beberapa dari orang-orang hari ini (beberapa perusahaan kemudian), mereka masih menjadi inspirasi, dan kami masih melakukan pekerjaan yang baik.

Saya tidak berpikir bahwa implementasi yang sempurna dari praktik terbaik dari bahasa pengkodean adalah hasil atau istirahat dari pengalaman kerja yang baik atau tim yang baik - pekerjaan yang mendorong karir jauh lebih dari itu, dan jika produk memiliki kemampuan yang layak kualitas, tim memiliki kondisi kerja yang layak (seperti Tes Joel) dan tim penuh dengan orang-orang yang cerdas dan menyelesaikan sesuatu, maka kesempurnaan pelaksanaannya adalah sekunder. Singkirkan faktor-faktor seperti pekerjaan yang baik, orang-orang yang baik, kondisi kerja yang baik - dan tidak ada gunanya bertahan - apakah kode secara aneh disatukan.

bagaimana fundamental atau dogmatisnya seseorang? Sejauh mana seorang programmer harus berpegang pada prinsip-prinsipnya atau hanya menulis kode yang berfungsi?

Yang paling penting untuk diingat di sini adalah apa tujuan Anda ?

Di sebagian besar perusahaan, tujuan hidup Anda bukanlah menulis kode yang sempurna. Tujuan Anda adalah untuk memberikan nilai bagi pengguna. Menulis kode yang baik biasanya merupakan cara terbaik untuk menghasilkan produk yang baik yang juga mudah dirawat, mencari masalah dan mengembangkannya.

Kode yang baik adalah alat yang harus Anda terapkan di mana ia memberi Anda ROI yang baik.

Beberapa contoh:

1. Saya akan menghabiskan banyak waktu merancang dan mengkode API saya, terutama API tingkat bisnis saya. Banyak pemrogram lain akan menggunakannya dan itu akan menghemat banyak waktu dan masalah jika mereka dirancang dengan benar
2. Saya akan sedikit mengendurkan aturan di lapisan presentasi saya. Di sana saya akan lebih cenderung mengorbankan kode "kesempurnaan" demi menambahkan lebih banyak fitur

Intinya, Anda perlu memiliki prinsip tetapi Anda juga harus cukup fleksibel untuk melanggar prinsip-prinsip itu ketika mereka membawa lebih banyak kerugian daripada nilai.

Saya bekerja untuk pengecer e-commerce selama beberapa tahun. Ketika saya mulai di sana, kode untuk aplikasi internal mereka semua ditulis dalam VB untuk MS Access, dan itu mengerikan untuk sedikitnya. Saya memiliki tim yang terdiri dari 3 pengembang, dan selama beberapa tahun berikutnya kami mengganti ini dengan aplikasi VB.Net yang tepat.

Tetapi karena anggaran perekrutan saya sangat terbatas, saya hanya bisa membeli programmer junior. Dan, tentu saja, kode yang mereka hasilkan tidak terlalu bagus. Tapi itu berhasil, dan perusahaan menggunakan aplikasi ini untuk menghasilkan uang, setiap hari.

Dan kemudian saya mulai bekerja dengan teman-teman saya. Sedikit pelatihan dalam OOD, dalam desain basis data, dalam MVC, dan C #. Dan selama bertahun-tahun, banyak hal membaik. Ketika saya pergi setelah 4 tahun, basis kode itu masih tidak bagus, tapi 100 kali lebih baik daripada ketika saya mulai.

Situasi seperti yang Anda gambarkan seringkali merupakan konsekuensi dari harus berurusan dengan sumber daya yang tersedia. Kami tidak hidup di dunia yang ideal. Pada saat yang sama, ini adalah peluang besar untuk benar-benar membuat perbedaan.

BTW: beberapa aplikasi ini masih digunakan, hampir tidak berubah dari sekitar 3 tahun yang lalu, dan mereka masih menghasilkan uang.

Saya pikir berpegang teguh pada prinsip Anda sangat penting. Anda harus selalu berusaha untuk menghasilkan kode terbaik dalam batasan yang diberikan. Namun, jika Anda menambahkan "seharusnya tidak perlu membaca atau mengubah kode buruk" ke daftar prinsip Anda, Anda akan mengalami banyak kesulitan dalam mencari pekerjaan. Ingatlah bahwa 50% programmer lulus di bagian bawah kelas mereka. Bahkan di tim satu orang, "hari ini Anda" memiliki kualifikasi lebih baik untuk menyelesaikan masalah daripada "bulan lalu Anda." Mampu bekerja dengan kode yang tidak ideal hanyalah sebagian dari pekerjaan.

Banyak pemberi kerja mengakui hal itu, sehingga kode yang mereka berikan untuk Anda baca mungkin mewakili kode terburuk dalam basis kode mereka, bukan yang terbaik. Jika itu tidak jelas dari konteksnya, Anda harus bertanya. Seorang kolega yang kadang-kadang saya wawancarai memiliki halaman kode yang sengaja ia tulis dengan buruk hanya untuk digunakan sebagai pertanyaan wawancara.

Dalam 99% persen kasus, Anda harus tetap berpegang pada «dogma» sebagaimana Anda menyebutnya. Dogma ini dibuat oleh orang-orang yang berpengalaman selama bertahun-tahun berlatih, dan apa yang tampaknya pragmatis pada beberapa titik seringkali tidak. Ini biasanya lebih relevan daripada kenyataan bahwa Anda tidak cukup baik untuk menangani masalah itu dengan benar.

Namun, jangan ikuti dogma secara membabi buta. Ingat kesimpulan apa yang membuat orang mengikuti dogma itu. Karena Anda akan menemukan sebagian kecil dari kasus di mana tidak boleh diikuti. Bagaimanapun, kasus-kasus itu akan sangat langka dan Anda harus selalu berdiskusi dengan beberapa programmer berpengalaman lainnya sebelum mengambil keputusan seperti itu.

Bersikaplah tegas ketika itu penting. Gaya penjepit (atau konvensi pengkodean lainnya)? Itu tidak masalah. Gunakan yang digunakan toko. Memecah enkapsulasi (atau prinsip pemrograman mendasar lainnya) tanpa alasan yang jelas? Tidak sepele.

Stack Exchange menggunakan tabel untuk tata letak (seperti halnya banyak situs web utama lainnya yang menghasilkan uang ). Apakah itu membuat asap keluar dari telinga para puritan? Tentu saja. Tetapi pragmatisme menang atas kemurnian, setiap saat. Produk pengiriman menang karena sempurna, setiap saat.

Seluruh lapisan domain, lapisan ketekunan, lapisan presentasi, pengujian unit masih relatif baru, dari sudut pandang historis. Ada banyak sekali perangkat lunak di luar sana yang masih menggunakan model Client / Server, dan tidak akan diubah ke gaya arsitektur terbaru hanya karena itu "lebih baik."