Pilih upaya desain kode atau kemalasan di dunia Bank

Saya telah bekerja selama dua tahun di Bank Investasi yang hebat.

Saya membuat beberapa proyek teknis dengan keinginan membuat kode yang paling optimal, dengan menghormati pola desain yang baik, prinsip SOLID, hukum demeter dan menghindari segala macam kode duplikat ...

Ketika pengiriman dalam produksi => nol bug, semua telah terjadi seperti yang diharapkan.

Tetapi, sebagian besar pengembang mendatangi saya untuk memastikan bahwa semua kode saya terlalu kompleks untuk dapat dipahami. Saya mendengarkan misalnya: "buat jika dan contoh, lupakan polimorfisme sehingga akan sangat mudah untuk memperbaiki bug produksi darurat". Saya tidak suka menjawab ......

Mengetahui pengembang ini tidak penasaran sama sekali, menolak upaya untuk memahami desain yang baik (misalnya, 90% pengembang tidak tahu apa itu Pola Strategi dan membuat kode prosedural dan tidak pernah o-desain karena mereka ingin, kata mereka, kesederhanaan ), manajer proyek saya mengatakan kepada saya bahwa saya benar-benar salah dan terlalu idealis untuk dunia Bank.

Apa yang akan Anda beri tahu saya? Haruskah saya menjaga keinginan kode yang benar-benar bagus atau menyesuaikan saya dengan mayoritas pengembang yang, saya ulangi, benar-benar tidak menarik dengan kode desain yang menurut saya, semua keindahan pekerjaan pengembang kami.

Atau sebaliknya, haruskah mereka mempelajari prinsip-prinsip OO dasar dan praktik terbaik untuk menyesuaikan diri dengan kode saya?

manajer proyek saya mengatakan kepada saya bahwa saya benar-benar salah dan terlalu idealis untuk dunia Bank.

GTFO!

Waktunya pergi dan mengasihani mereka. Mengapa Anda harus peduli? Anda tahu itu akan membuat mereka kehilangan uang dalam jangka panjang dengan staf tidak kompeten mereka. Ini bukan permainan diskusi teknis. Ini tentang politik. Mintalah mereka melatih pengembang lain atau GTFO! Jika Anda tidak memiliki cukup bobot politik, maka GTFO! Cari perusahaan dengan praktik yang lebih baik.

Satu-satunya alasan untuk tinggal di sana adalah kompensasi yang memadai untuk sakit kepala Anda. Jadi mereka lebih baik membayar jauh di atas rata-rata atau GTFO! Saya ragu Anda dapat tumbuh di sana sebagai pengembang perangkat lunak juga. Pertumbuhan dalam profesi kami sebagian besar dicapai dengan bekerja dengan orang-orang yang lebih baik daripada Anda dan yang mendorong praktik terbaik. Dan semakin baik Anda, semakin tinggi nilai pasar Anda bagi perusahaan yang peduli.

Ya, saya tahu ini bukan salah satu jawaban saya yang biasa, tetapi sungguh, jika Anda tidak dapat memainkan permainan politik di perusahaan ini, GTFO.

Apa yang akan Anda beri tahu saya? Haruskah saya menjaga keinginan kode yang benar-benar bagus atau menyesuaikan saya dengan mayoritas pengembang yang, saya ulangi, benar-benar tidak menarik dengan kode desain yang menurut saya, semua keindahan pekerjaan pengembang kami.

Saya tidak akan bekerja untuk perusahaan yang ingin saya memberikan solusi optimal. Saya ingin mengukir nama saya ke dalam perangkat lunak. Saya ingin bangga akan hal itu. Saya tidak menulis aplikasi prosedural dalam bahasa berdasarkan paradigma OO. Saya percaya pada perangkat lunak berkualitas tinggi dan jika perusahaan tidak, saya akan GTFO! Semoga Anda punya cukup "bercinta dengan Anda".

Tempat yang sulit. Saya pikir Anda dapat melakukan dua cara secara paralel, mendukung maksud Anda dan menunjukkan kemauan untuk berkompromi:

• Ini tentang uang. Sebagai pekerjaan dev sebenarnya, tetapi karena Anda menekankan lingkungan bank, ini harus bekerja lebih baik;). Tunjukkan pada mereka bahwa gaya Anda menghemat uang. Temukan contoh bagaimana perubahan dalam persyaratan dapat dilakukan dengan sangat mudah karena desain Anda. Cobalah untuk menemukan bagian dari kode lain (Anda harus memastikan Anda tidak menjadi terlalu agresif di sini, tapi hei, ini tentang membandingkan gaya kode) yang cenderung segera rusak, dan tunjukkan pada mereka bagaimana Anda tidak perlu Peduli tentang masalah seperti itu karena kode Anda lebih baik untuk memulai.

• Ini tentang uang. Bagaimana jika gaya pengkodean Anda sebenarnya membutuhkan biaya? Mungkin baik, jika orang lain menghabiskan lebih banyak waktu untuk mencoba memahami kode Anda daripada apa yang disimpan oleh desain yang tepat. Anda mungkin melakukan hal yang benar secara teknis dan masih belum berkontribusi positif untuk upaya tim. Juga, dimungkinkan untuk melakukan desain OOP secara berlebihan. Saya bersama Anda di sisi "desain yang bagus itu indah", tetapi saya mencoba membuat Anda sadar dari sudut pandang mereka dan bagaimana mereka sebenarnya benar dari sudut pandang mereka. Sejalan dengan poin sebelumnya, cobalah untuk menemukan tempat di mana Anda overdid. Itu memberi Anda beberapa ruang untuk bermanuver: Anda dapat mengatakan, ok, saya bisa sedikit lebih pragmatis di sana-sini, tetapi lihat, ada juga tempat-tempat di mana kode ini benar-benar lebih baik.

Tetapi, sebagian besar pengembang mendatangi saya untuk memastikan bahwa semua kode saya terlalu kompleks untuk dapat dipahami

Pernahkah terpikir oleh Anda bahwa mereka mungkin benar?

Saya bekerja dengan seseorang yang berusaha keras untuk menulis kode yang dia anggap elegan. Dia menghabiskan banyak waktu mengutuk pekerjaan orang lain karena tidak anggun. Ketika diperlukan untuk mempertahankan kode kodenya bukan kode saya akan memilih untuk memodifikasi. Ini sangat tepat dan menuntut sehingga mengubahnya sangat sarat dengan bahaya.

Kata menarik yang Anda sebutkan di sini adalah "kompleks". Kode yang dapat digambarkan sebagai rumit jarang dapat juga digambarkan sebagai sangat baik.

Pembuat furnitur era Victoria (setidaknya, mereka yang karyanya masih kita lihat sampai sekarang) adalah pengrajin nyata, apa yang mereka buat fungsional, indah, dibuat dengan baik dan dirancang dan dibangun untuk bertahan seumur hidup. Namun dalam 150 tahun terakhir, dunia telah berubah. Tidak banyak orang yang bersedia membayar untuk pengerjaan seperti itu, ketika alternatif yang lebih murah lebih pragmatis secara komersial ketika membeli meja ruang makan.

Banyak programmer ingin menjadi pengrajin lama, sayangnya, perdagangan menyatakan bahwa ini tidak dapat terjadi sepanjang waktu. Anda punya pilihan, beradaptasi atau pergi. Ada perusahaan yang menginginkan pengrajin, tetapi jumlahnya jauh lebih banyak daripada perusahaan yang menginginkan produk yang kebanyakan bekerja, murah dan sekarang.

Petunjuk bagi saya bahwa Anda tidak cocok untuk sebagian besar pengembangan perangkat lunak komersial adalah "Ketika pengiriman dalam produksi => nol bug,". Nasa bahkan tidak mencapai itu dengan pesawat ulang-alik.

Satu-satunya tempat di mana Anda memperhatikan detail, dan oleh karena itu biaya awal, kemungkinan dapat diterima adalah sistem kritis kehidupan tingkat 1 - misalnya Avionik / Aerospace, Otomotif, Militer dan Medis.

Masalahnya adalah Anda bekerja di tempat yang salah. Sepertinya Anda seorang programmer yang cenderung akademis. Anda tidak akan melakukannya dengan baik di lingkungan tempat Anda berada dan kemungkinan besar beberapa alasan akan diciptakan untuk menyingkirkan Anda dan kode "terlalu rumit" Anda. Anda mungkin akan diberi tugas sampah dan / atau diberi ulasan kinerja yang buruk dan semacamnya sampai Anda pergi dengan kemauan sendiri atau mereka memiliki jejak kertas penutup belakang yang cukup untuk memecat Anda.

Saya sarankan Anda mencari tempat kerja yang akan menghargai kecenderungan akademik Anda. Mereka diluar sana. Anda juga akan menemukan beberapa yang ada di pagar antara pragmatis dan akademik. Pekerjaan seperti itu mungkin menjadi pilihan terbaik Anda karena itu akan memungkinkan Anda mengundang beberapa kekacauan ke dalam pendekatan Anda saat Anda membantu orang lain mengendalikannya.

Sebelum mengambil tindakan drastis seperti mengganti majikan Anda, saya akan mencoba untuk meningkatkan kemampuan Anda sendiri dalam menjelaskan non-programmer seperti Anda para eksekutif mengapa cara pengkodean Anda lebih baik untuk perusahaan, dan menghemat waktu dan uang mereka. Dan juga, pastikan Anda tidak menerapkan pola desain hanya demi pola desain - apakah Anda yakin Anda juga mengikuti aturan KISS dan YAGNI? (Oke, pola strategi dan polimorfisme bukanlah ilmu roket, beri kolega Anda waktu untuk beradaptasi dan menjelaskan kepada mereka mengapa Anda memilih pendekatan itu.)

Di perusahaan saya, kami melakukan serangkaian lokakarya berdasarkan Pengembang Kode Bersih . Tujuannya adalah untuk membuat forum di luar bisnis normal sehari-hari dengan kesibukan dan tenggat waktu yang sibuk, di mana pengembang dapat belajar tentang prinsip-prinsip desain perangkat lunak (seperti yang Anda sebutkan), teknik pemrograman, dll. Dan merefleksikan proyek dan pekerjaan mereka sendiri.

Contoh kehidupan nyata dari proyek aktual juga dibahas. Umpan balik dari para peserta adalah AFAIK sangat positif. Namun, sulit untuk mengukur manfaat yang sebenarnya.

Kehadiran lokakarya tersebut sebagian karena waktu yang disponsori perusahaan, sebagian waktu luang peserta. Anda tidak akan menjangkau kolega yang tidak peduli tentang belajar dan hanya ingin melakukan pekerjaan mereka dan pulang, tetapi bagi siapa pun yang memiliki minat pada pekerjaannya sendiri, ini mungkin menarik.

Pertama-tama saya akan melakukan pengecekan bahwa cara Anda benar-benar lebih baik. Kode Berorientasi Objek bisa sangat bagus, tetapi juga bisa menjadi mimpi buruk efek samping tersembunyi dan setiap tindakan dapat memerlukan beberapa kelas yang berbeda.

Lebih baik pergi ke InfoQ dan Tonton pembicaraan Rich Hickey tentang "Simple Made Easy"

Anda harus menyerah sedikit jika Anda ingin terus bekerja di sana tanpa kesulitan. Grup dev yang semuanya prosedural tidak akan langsung menerima polimorfisme. Meskipun mereka mungkin tidak dapat mendesain dengan cara OO, mereka dapat belajar dari kode Anda. Mereka mungkin menghargai bahwa beberapa kode Anda lebih mudah dipelihara.

Sebagai catatan tambahan, Anda perlu mengajukan pertanyaan selama proses wawancara untuk melihat proses pengembangan dan metodologi pengkodean apa yang digunakan jika menurut Anda penting untuk mencocokkan preferensi Anda.

Keadaan darurat terjadi. Anda tidak sempurna dan tangan mereka akan merusak kode Anda di beberapa titik. Itu kecuali Anda tidak pernah mengambil cuti, yang, seperti yang akan dikonfirmasi oleh dokter Anda, tidak baik untuk kesehatan Anda. Dan mengarah pada peluang lebih tinggi untuk memancarkan kode yang buruk.

Kode Anda mungkin memiliki kualitas yang lebih tinggi, (fakta yang tidak terbukti) tetapi mereka memiliki kebijakan . (Tentu saja fakta sebenarnya)

Anda telah diperingatkan untuk mengikuti kebijakan, dan akan bertanggung jawab untuk tidak mengikuti mereka. Dalam situasi darurat. Dalam aplikasi perbankan. Maksud saya, jika tujuan Anda berakhir buruk dan di penjara saya dapat menemukan banyak cara yang lebih lucu dan lebih bermakna untuk mendapatkan hasil yang sama.

Anda teman satu sel, akan senang mendengar Anda mengoceh tentang kurangnya rasa ingin tahu mantan rekan kerja Anda.

(sekali lagi, perusahaan Anda mungkin tidak memiliki kebijakan internal terhadap desain OO, tetapi insinyur yang terlatih canggung COBOL yang akan mencoba untuk memperbaiki kode Anda akan membuat beberapa keluar dari udara tipis dan, IMHO, dalam skenario kasus terburuk, dia akan memiliki peluang 40% untuk mencetak hit kritis)

Cobalah untuk mengingat bahwa pemrograman dianggap oleh beberapa orang sebagai sarana untuk mencapai tujuan daripada untuk kepentingan dirinya sendiri. Pikirkan semua produk dan layanan yang Anda gunakan: apakah Anda menghabiskan banyak waktu mempertimbangkan jika kode di bawahnya dibuat secara elegan? Atau apakah Anda hanya menghargai mereka karena mereka hanya bekerja? Temukan industri atau alasan yang membuat Anda bersemangat, kemudian temukan organisasi dengan itu, lalu tawarkan solusi yang mencakup pemrograman tetapi tidak hanya itu. Masalah dapat diselesaikan dengan sangat baik dengan berbagai cara.