Membantu seseorang yang tidak dan tidak akan pernah menjadi programmer profesional menulis kode yang lebih mudah dibaca dan dapat digunakan serta diartikan [ditutup]

Saya Elvis, berusaha sangat keras untuk belajar menjadi Einstein. Saya bekerja untuk Mort.

Apa yang dibicarakan orang idiot gila ini??!? (Anda hanya perlu membaca beberapa paragraf pertama)

Jika Anda merasa tidak suka membaca tautan itu, pada dasarnya, saya adalah seorang programmer profesional, dan bos saya adalah (ini akurat secara skual):

programmer lini bisnis profesional yang tidak memiliki gelar dalam bidang ilmu komputer tetapi memiliki banyak keakraban dengan Office dan VBA, dan yang biasanya menulis aplikasi produktivitas yang dibagi di antara rekan kerjanya

Semua yang dikatakan, sebagian besar pekerjaan saya adalah mengambil kode berbatu dan membuatnya siap. Namun, gaya yang sangat buruk dan pemujaan muatan membuat ini sulit. Ini diperparah oleh kenyataan bahwa dia tidak mau membaca buku-buku pemrograman atau mengizinkan saya membantunya memperbaiki kode-kodenya.

Apakah ada beberapa strategi lain untuk membantu seseorang yang bukan programmer profesional, tidak akan pernah menjadi programmer profesional menulis kode ke depan yang lebih mudah dibaca dan dapat digunakan bagi saya untuk menggunakan dan menafsirkan?

Dalam melihat tanggapan Anda dalam beberapa komentar, saya tidak tahu apakah Anda menyadari bahwa apa yang Anda alami cukup umum, terutama ketika bekerja di bidang khusus di mana dibutuhkan pakar domain (sebut saja mereka ilmuwan) untuk mencari cara menggabungkan dan menyesuaikan algoritma untuk masalah yang dihadapi.

Daripada mengeluh tentang ilmuwan dan mengharapkan mereka berubah, sadarilah bahwa Anda tidak seharusnya mengharapkan ilmuwan peduli banyak tentang "kualitas kode". Seringkali sulit untuk membuat pengembang perangkat lunak lain peduli dengan "kualitas kode" apalagi seseorang yang minat utamanya terletak pada domain dan bukan pada pemrograman.

Ke mana Anda pergi dari sini sangat tergantung pada tingkat kepercayaan "ilmuwan" dalam kemampuan Anda untuk memahami pekerjaan mereka. Jika mereka memiliki keyakinan bahwa Anda dapat memahami kode mereka dan tidak akan membuangnya ketika Anda memodifikasi sesuatu maka biasanya tidak ada masalah. Mereka akan mengandalkan keahlian Anda.

Namun, jika ilmuwan tidak ingin Anda mengubah kode mereka maka sangat mungkin bahwa Anda belum "mendapatkan" kepercayaan diri mereka. Jika itu masalahnya maka daripada berfokus pada memperbaiki ilmuwan, Anda harus fokus pada "memperbaiki" diri Anda sendiri. Yang saya maksudkan adalah mengambil langkah-langkah untuk mendapatkan kepercayaan diri mereka. Mungkin cara termudah untuk melakukan ini adalah sebagai berikut:

Sebagai bagian dari proses pengujian Anda:

1. Mulailah mengubah algoritme menjadi sesuatu yang lebih mudah dipahami (misalnya diagram, PDL, notasi matematika)
2. Belajarlah untuk memahami algoritma.
3. Pastikan untuk mengidentifikasi kasus tepi.
4. Tanyakan kepada ilmuwan apakah representasi "alternatif" Anda yang disederhanakan benar
5. DAN PALING PENTING mengidentifikasi masalah yang Anda temukan; DAN tanpa terdengar "menuduh" mengatakan sesuatu seperti "Saya sedang melihat algoritma dan melihat XYZ apakah itu seharusnya melakukan ini atau itu seharusnya melakukan itu?". Tidak ada yang akan mendapatkan kepercayaan diri mereka lebih baik daripada peluru ini.

Setelah Anda mulai menemukan bug DAN menunjukkan minat pada bidang minat mereka, maka peluangnya menjadi jauh lebih tinggi sehingga setidaknya mereka akan membiarkan Anda mulai memodifikasi kode untuk membuatnya lebih "profesional". Seringkali, mereka bahkan tidak akan merasa perlu untuk membuat kode prototipe lagi. Mereka hanya akan menulis sesuatu di salah satu dari notasi "alternatif" yang telah Anda ajarkan kepada mereka (tanpa mereka sadari) dan mereka akan memiliki keyakinan bahwa Anda akan tahu apa artinya.

Dengan segala cara, upaya pertama saya adalah menawarkan beberapa saran tentang bagaimana ilmuwan dapat membantu "berkomunikasi" dengan lebih baik untuk membantu Anda; tapi sepertinya Anda sudah mencobanya. Jadi satu-satunya langkah yang Anda kendalikan adalah apa yang Anda lakukan. Hasilkan kepercayaan diri mereka dan hampir selalu pakar domain akan lega menyampaikan koding kepada orang lain dan tidak perlu khawatir tentang semua detail kecil yang masuk ke dalam penulisan kode. Mereka lebih suka berfokus pada peningkatan algoritma.

Terkadang, yang bisa Anda lakukan hanyalah menawarkan saran dan membiarkannya setelah itu. Anda tidak akan mengesankan atasan atau senior Anda jika Anda terus-menerus memikirkan sesuatu yang sudah mereka tolak atau putuskan tidak ingin mereka lakukan, bahkan jika Anda 100% benar. Bahkan, ini akan merusak suatu hubungan, apakah Anda adalah penasehat atau yang disarankan. Fokus saja pada apa yang ANDA bisa lakukan untuk membuat pekerjaan Anda lebih mudah.

Ketika ia benar-benar "seseorang yang bukan programmer profesional, tidak akan pernah menjadi programmer profesional" seperti yang Anda katakan dan ketika sebagian besar pekerjaan Anda benar-benar "mengambil kode yang dirakit dan membuatnya siap produksi", sepertinya Anda Tim dua orang akan lebih produktif ketika dia meninggalkan program untuk Anda dan berkonsentrasi pada bagian manajerial proyek.

Namun, ini mengasumsikan bahwa Anda benar. Kami programmer selalu cenderung mengabaikan kode yang ditulis oleh orang lain jauh lebih buruk daripada kode kami. Prasangka ini sangat sulit dikalahkan dan membuat kita meremehkan rekan kerja kita. Apa yang Anda anggap "pemrograman pemujaan kargo" mungkin "praktik terbaik yang terbukti" dari sudut pandangnya, dan apa yang Anda anggap "aplikasi elegan pola berorientasi objek" mungkin "rekayasa berlebihan yang tidak perlu" untuknya. Sulit untuk mengatakannya kepadaku, karena aku hanya tahu sisi ceritamu.

Penghinaan terhadap kode orang lain menjadi lebih kuat semakin berbeda gaya pemrograman kita. Dalam hal itu naluri positif, karena menggabungkan gaya pemrograman yang berbeda dalam satu proyek membuatnya sangat sulit untuk dipertahankan.

Ketika Anda berdua tidak dapat meniru gaya yang lain, maka Anda bisa mendefinisikan tanggung jawab yang jelas. Buat satu orang bertanggung jawab untuk satu bagian aplikasi dan orang lain untuk yang lain. Tentukan antarmuka yang jelas antara kedua modul bersama-sama, tetapi biarkan implementasi internal yang bertanggung jawab. Untuk membuatnya lebih mengetahui bug dalam kodenya, Anda dapat menulis unit-test untuknya dan menunjukkan ketika kodenya jelas tidak berperilaku sesuai dengan kontrak antarmuka yang Anda tentukan bersama.

Dengan membangun kepemilikan kode yang jelas, Anda dapat mencapai koeksistensi yang lebih baik dari berbagai gaya Anda. Juga, ketika Anda berdua bertanggung jawab untuk memperbaiki bug dalam kode mereka sendiri, Anda tidak harus sering menavigasi kode satu sama lain.

Anda harus bertanya pada diri sendiri: apa tujuan utama Anda di sini? 1. untuk membantu atasan Anda? 2. untuk membantu perusahaan? 3. untuk membantu diri sendiri? Dan sebelum Anda menjawab "semua hal di atas", pelan-pelan. Tugas pertama Anda adalah mendefinisikan dengan jelas tujuan utama Anda, karena jawabannya tergantung padanya.

Jika tujuan Anda adalah:

1. Bantu atasan Anda? Menyerah. Dia tampaknya tidak memintanya. Anda berkata, "Dia tahu kodenya buruk, tetapi ia melakukan apa yang dia butuhkan." Baiklah, akhir dari diskusi. Kecuali dan sampai bos Anda tidak puas dengan situasi saat ini, dia tidak akan berubah, dan dia akan membenci upaya Anda untuk membantunya. Jika suatu saat nanti dia memang "merasakan sakit" dari status quo, mudah-mudahan Anda akan menjadikan diri Anda sebagai mentor yang dapat dipercaya dan dia akan tahu ke mana harus mencari bantuan.

2. Bantu perusahaan Anda? Apakah situasi saat ini mengancam garis bawah? Apakah tenggat waktu berisiko? Apakah manajemen atas meningkatkan panasnya? Jika tidak, maka Give It Up. (Ini pada dasarnya adalah poin yang dibuat Jimmy Hoffa dalam komentarnya ke posting asli Anda.) Jika, bagaimanapun, situasi saat ini sebenarnya merupakan risiko yang tidak dapat diterima untuk departemen / perusahaan Anda, maka perubahan proses sedang dilakukan. Dalam hal ini saya menyarankan agar Anda duduk dan membuat garis besar yang berbedapembagian kerja. Kuncinya di sini adalah untuk menjelaskan bahwa waktu yang Anda habiskan untuk refactoring kode atasan Anda akan lebih baik dihabiskan untuk menulis kode baru. Anda bilang Anda tidak punya waktu untuk menulis semuanya sendiri, tapi bukan itu yang saya sarankan. Anda perlu memikirkan cara memaksimalkan kekuatan Anda masing-masing. Berhentilah memikirkannya sebagai Mort, dan anggap dia sebagai pengembang junior dengan pengetahuan domain yang unggul. Itu adalah pengaturan kerja yang sangat umum di industri ini, dan Anda harus belajar bagaimana berkembang di dalamnya. Misalnya, pastikan dia tahu bahwa Anda tahu betapa pentingnya keahliannya (ulangi langkah ini sering), laludengan rendah hati menyarankan strategi berikut (atau sesuatu yang serupa) sebagai jalan yang lebih cepat untuk mendapatkan pengetahuannya ke pasar: (a) memecah pekerjaan menjadi sprint "gesit", (b) berkolaborasi sangat maju (dalam setiap sprint) mendefinisikan lebih dari - Semua persyaratan dan arsitektur. (c) Biarkan dia pergi dan membangun prototipe untuk menyelesaikan semua keputusan algoritmik, sementara Anda membangun infrastruktur yang Anda sepakati pada langkah sebelumnya. (D) Terapkan algoritmanya ke struktur Anda saat dia membangun tes untuk memverifikasinya. (e) Lakukan V&V Anda bersama dalam lingkungan pemrograman rekan. (misalnya, "Tes ini gagal; mengapa? kesalahan logika algoritmik atau kesalahan pengkodean?"; beralih di sini).

3. Silahkan? Jujurlah di sini. Jika semua yang Anda lakukan adalah mengeluh bahwa Anda tidak menikmati pekerjaan Anda, saya sarankan Anda perlu menghabiskan lebih banyak waktu memikirkan # 2 di atas. Jika Anda tidak peduli dengan perusahaan DAN Anda tidak menikmati pekerjaan Anda, mulailah membagikan resume Anda. Jika Anda Peduli dengan perusahaan Anda tetapi tidak menikmati pekerjaan Anda, maka berfokus pada # 2 akan membantu pada KEDUA akun. Tetapi dalam hal itu, itu adalah "win-win" hanya jika jelas bagi semua orang bahwa hasrat Anda benar-benar berasal dari keinginan untuk Membantu Tim, dan bukan hanya dari frustrasi yang terpusat pada diri sendiri dalam tugas Anda.

Saya tidak yakin saya akan menambahkan sesuatu ke diskusi ini, tetapi telah bekerja dalam skenario serupa di mana pelanggaran akses mencapai pada baris dengan ShowMessage('Hello');atau serupa, hanya untuk mengetahui bahwa baris yang sama memiliki lebih banyak kode, keluar dari layar ke layar kanan,

Saya percaya bahwa Anda memiliki dua opsi dasar:

1. Biarkan kode berjalan . Jika kode berfungsi dan melakukan apa yang harus dilakukan, kecuali bos Anda secara khusus meminta Anda untuk memperbaiki kode mereka, biarkan saja apa adanya. Itu juga dapat membuatnya mengerti bahwa kode Anda terlihat lebih bagus dan menyerahkan pekerjaan kepada Anda (seperti juga ditunjukkan oleh Dunk dalam jawabannya).
2. Jika Anda sangat bertekad untuk membuat kode menjadi profesional, bangun perpustakaan / kerangka kerja yang dapat ia gunakan. Jika ada pola kesalahan / strategi yang biasa Anda perbaiki, Anda mungkin dapat membungkusnya menjadi beberapa file perpustakaan dan memberikannya sebagai "pustaka dasar untuk perusahaan" , yang juga dapat Anda gunakan sebagai antarmuka umum.