Standar Python Coding vs. produktivitas

Saya bekerja untuk organisasi kemanusiaan besar, pada perangkat lunak pembangunan proyek yang dapat membantu menyelamatkan nyawa dalam keadaan darurat dengan mempercepat distribusi makanan. Banyak LSM sangat membutuhkan perangkat lunak kami dan kami berada di bawah minggu dari jadwal.

Satu hal yang membuat saya khawatir dalam proyek ini adalah apa yang saya pikir merupakan fokus berlebihan pada standar pengkodean. Kami menulis dengan python / django dan menggunakan versi PEP0008, dengan berbagai modifikasi misalnya panjang garis dapat mencapai 160 karakter dan semua baris harus sepanjang itu jika memungkinkan, tidak ada garis kosong antara impor, aturan pembungkus garis yang hanya berlaku untuk jenis tertentu kelas, banyak template yang harus kita gunakan, bahkan jika itu bukan cara terbaik untuk menyelesaikan masalah dll. dll.

Satu inti pengembang menghabiskan satu minggu menulis ulang bagian utama dari sistem untuk memenuhi standar pengkodean yang baru, membuang beberapa rangkaian tes dalam proses, karena penulisan ulang berarti mereka 'tidak valid'. Kami menghabiskan dua minggu untuk menulis ulang semua fungsi yang hilang, dan memperbaiki bug. Dia adalah pemimpin dev dan kata-katanya membawa bobot, jadi dia telah meyakinkan manajer proyek bahwa standar-standar ini diperlukan. Devs junior melakukan apa yang diperintahkan. Saya merasa bahwa manajer proyek memiliki perasaan disonansi kognitif yang kuat tentang semua ini, tetapi tetap menyetujuinya dengan keras ketika ia merasa tidak yakin harus berbuat apa lagi.

Hari ini saya mendapat masalah serius karena saya lupa menempatkan beberapa spasi setelah koma dalam argumen kata kunci. Saya benar-benar diteriaki oleh dua devs lain dan manajer proyek selama panggilan Skype. Secara pribadi saya pikir standar pengkodean itu penting tetapi juga berpikir bahwa kita membuang banyak waktu terobsesi dengan mereka, dan ketika saya mengucapkannya secara verbal itu memicu kemarahan. Saya dipandang sebagai pembuat onar dalam tim, tim yang mencari kambing hitam atas kegagalannya. Sejak diperkenalkannya standar pengkodean, produktivitas tim telah menurun secara drastis, namun ini hanya memperkuat obsesi, yaitu pemimpin dev hanya menyalahkan ketidakpatuhan kita pada standar karena kurangnya kemajuan. Dia percaya bahwa kita tidak dapat membaca kode satu sama lain jika kita tidak mematuhi konvensi.

Ini mulai berubah lengket. Sekarang saya mencoba untuk memodifikasi berbagai skrip, autopep8, pep8ify dan PythonTidy untuk mencoba mencocokkan konvensi. Kami juga menjalankan pep8 terhadap kode sumber tetapi ada begitu banyak amandemen tersirat pada standar kami sehingga sulit untuk melacak semuanya. Lead dev sederhana mengambil kesalahan bahwa script pep8 tidak mengambil dan berteriak pada kami dalam pertemuan stand-up berikutnya. Setiap minggu ada tambahan baru pada standar pengkodean yang memaksa kita untuk menulis ulang kode yang sudah ada, berfungsi, dan teruji. Syukurlah kita masih memiliki tes, (saya mengembalikan beberapa komitmen dan memperbaiki beberapa yang dia hapus).

Sementara itu ada peningkatan tekanan untuk memenuhi tenggat waktu.

Saya percaya masalah mendasar adalah bahwa pengembang utama dan pengembang inti lainnya menolak untuk mempercayai pengembang lain untuk melakukan pekerjaan mereka. Tetapi bagaimana cara menghadapinya? Kami tidak dapat melakukan pekerjaan kami karena kami terlalu sibuk menulis ulang semuanya.

Saya tidak pernah menemukan dinamika ini dalam tim rekayasa perangkat lunak. Apakah saya salah mempertanyakan kepatuhan mereka pada standar pengkodean? Adakah orang lain yang mengalami situasi yang serupa dan bagaimana mereka berhasil mengatasinya? (Saya tidak mencari diskusi hanya solusi aktual yang ditemukan orang)

Standar pengkodean bukan masalah. Masalahnya adalah manajemen tidak tahu apa masalahnya. Ini mengarah pada "Lakukan sesuatu ... apa saja!" mode. Anda sedang mencari solusi rasional, tetapi ini merupakan masalah irasional. Yang terbaik yang dapat Anda lakukan adalah:

• Berikan kritik konstruktif terhadap ide-ide mereka, tetapi begitu keputusan dibuat jangan terus mengeluh tentang hal itu.
• Lakukan apa saja untuk mempermudah penulisan ulang.
• Berhenti stres. Tenggat waktu yang terlewat adalah masalah manajemen, bukan milik Anda. Lakukan yang terbaik, tetapi jangan memikul tanggung jawab atas keputusan mereka yang buruk.
• Jika Anda tahu sesuatu yang mungkin bisa membantu, beri tahu mereka. Penyebutan standup Anda membuatnya terdengar seperti Anda mencoba gesit, tetapi sisanya tidak terdengar gesit. Lihat apakah Anda dapat memberikan fungsionalitas terbatas lebih awal daripada mencoba memenuhi tenggat waktu besar dengan segalanya. Buat cerita pengguna untuk penulisan ulang sehingga jelas bagaimana mereka memengaruhi jaminan simpanan.
• Mulailah mencari pekerjaan lain. Serius. Perusahaan dalam keadaan seperti itu tidak jauh dari mulai memecat orang.
• Dapatkan beberapa "sudah bilang" T-shirt dicetak :-)

Seseorang harus memutuskan apakah pengiriman atau kepatuhan terhadap standar pengkodean adalah prioritas utama. Saya tahu apa yang menjadi preferensi saya; jika itu melewati unit dan tes penerimaan, saya katakan kirim. Setelah dikirimkan, perusahaan dapat memutuskan apakah akan menghabiskan waktu dan uang untuk memperbaiki hutang teknis.

Masalah dengan spasi setelah koma mudah diselesaikan dengan alat prettifying kode. Temukan alat yang memberlakukan semua konvensi pengkodean Anda, dan jalankan alat itu pada semua kode yang dimodifikasi sebelum pembuatan dan pengujian dilakukan. IDE yang layak sudah melakukan ini, saat Anda sedang menulis kode.

Apakah saya salah mempertanyakan kepatuhan mereka pada standar pengkodean?

Itu tergantung pada grup. Secara pribadi , saya pikir semuanya harus dipertanyakan. Beberapa orang menganggap pertanyaan itu sebagai penghinaan; bahwa saya tidak mempercayai mereka.

Adakah orang lain yang mengalami situasi yang serupa dan bagaimana mereka berhasil mengatasinya?

Saya bertanya bagaimana standar ini meningkatkan produktivitas. Saya mengukur waktu yang saya habiskan untuk bermain-main dengan standar vs 'menyelesaikan pekerjaan'. Pada akhirnya, kekuatan yang diputuskan untuk tetap dengan standar. Itu terjadi. Saya mengeluh tentang mereka lebih keras dari biasanya ketika mereka menjadi penyebab saya tidak menyelesaikan pekerjaan, tetapi sebaliknya fokus pada menyelesaikan pekerjaan saya. Bertengkar tentang hal-hal yang terus menerus tidak baik untuk produktivitas ...

Jika, seperti yang Anda katakan, hal-hal yang terukur lebih buruk karena standar, maka mematuhi standar harus membatalkan argumen pemimpin dan meninggalkan Anda. Jika orang tidak dapat melihat bahwa korelasi objektif (sebagian besar) antara penerapan standar dan penurunan produktivitas, maka tidak banyak lagi yang dapat Anda lakukan. Belajarlah untuk menghadapinya, dan jika Anda tidak bisa, carilah tempat yang kurang birokratis.

Standar adalah sesuatu yang tidak boleh diberlakukan proyek terlambat dengan tenggat waktu yang menjulang. Ini adalah sesuatu yang seharusnya sudah ada di awal proyek atau ketika ada waktu yang disisihkan dalam jadwal proyek (lebih disukai setelah kapal awal) untuk (berpotensi) refactor kode besar yang menyinggung.

Jika ini sebenarnya dimasukkan terlambat dalam proyek, maka itu adalah kesalahan yang dilakukan oleh pimpinan Anda (IMHO).

Namun , ini tidak berarti bahwa jika Anda tidak setuju dengan pimpinan Anda bahwa Anda harus menyerang terlebih dahulu dengan pemberontakan. Ini pekerjaanmu . Anda bekerja sebagai tim . Anda punya petunjuk . Pasti harus ada tingkat demokrasi dalam tim, tetapi pada akhirnya yang memimpin adalah diktator. Jika dia mengatakan untuk melakukan sesuatu, lakukanlah.

Pada akhirnya, dalam memenuhi permintaan dan standarnya, Anda tidak memberinya kambing hitam mudah untuk tenggat waktu yang hilang.

Juga, aku besar penganjur standar pengkodean (terutama karena ukuran tim tumbuh), tetapi mereka harus dilaksanakan ketika masuk akal.

Pertanyaan Anda adalah '' Apakah saya salah mempertanyakan kepatuhan mereka pada standar pengkodean? '. http://c0x.coding-guidelines.com/Introduction.pdf (untuk bahasa pemrograman C) memiliki beberapa studi referensi tentang nilai pedoman pengkodean. Lihat bagian 9 mulai dari halaman 39.

Standar pengkodean diterapkan karena suatu alasan. Satu hal yang kelihatannya hilang dari pertanyaan awal adalah pemahaman atas alasan standar-standar khusus ini pada proyek tertentu (atau dalam organisasi tertentu). Keputusan untuk menerapkannya pada kode yang ada didasarkan pada beberapa logika. Tanpa mengetahui logikanya, sulit untuk berkomentar tentang 'kebaikan' dari keputusan itu.

Saya akan mendukung apa yang dikatakan seseorang bahwa standar diterapkan untuk 'produktivitas jangka panjang' - masalah seperti pemeliharaan kode. Mungkin beberapa peristiwa terjadi yang membuat proyek kembali parah karena kebingungan dan salah tafsir.

Kedengarannya ada banyak emosi di kedua sisi - cobalah untuk berdiskusi dengan beralasan.

Seperti yang mungkin Anda lihat dari jawaban dan komentar lain, proyek Anda memiliki masalah besar, jadi apa yang akan saya sarankan tidak memiliki peluang besar untuk sukses, tetapi itu adalah sesuatu yang dapat Anda coba tanpa risiko terlalu besar berkaitan dengan kulitmu sendiri.

Mintalah pertemuan antara empat mata dengan pengembang utama Anda. Katakan bahwa Anda tertarik untuk memahami secara mendalam manfaat menjadi begitu ketat dengan standar pengkodean dan mengapa basis kode berada dalam kondisi yang buruk sebelum memperkenalkannya. Sangat penting bagi Anda untuk tetap bersikap terbuka dan sikap "Saya mencoba belajar" selama diskusi ini. Pengembang utama Anda mungkin sudah lebih stres daripada Anda atau orang lain di tim Anda, dan mungkin akan sangat defensif begitu dia mencium beberapa kritik.

Cobalah untuk mendorong diskusi ke arah mencoba mencari cara untuk memenuhi tujuan bersama Anda; memberikan perangkat lunak yang berfungsi dan dirawat dengan cepat.

Misalnya, beberapa buah yang menggantung rendah adalah untuk tidak menambahkan apa pun pada pedoman pengkodean. Setiap kali itu terjadi, kode yang sebelumnya mematuhi pedoman tidak lagi berfungsi, dan ini menghasilkan Anda perlu menulis ulang potongan kode. Semoga pemimpin dev Anda dapat melihat bahwa bahkan jika aturan tambahan menambah nilai (dari sudut pandangnya), mungkin tidak ada gunanya memotivasi penulisan ulang pada fase proyek yang sudah terlambat ini.

Jika ini berhasil, Anda dapat mencoba membuatnya menghapus aturan yang lebih sewenang-wenang yang tidak dapat di-autoforming dengan beberapa alat.

Standar pengkodean baik. Mengubah standar pengkodean itu mahal (yah, itu mahal jika Anda membuatnya kurang permisif; jika perubahan ke standar membiarkan semua kode yang ada masih sesuai, itu bukan masalah), jadi seharusnya hanya dilakukan ketika benar-benar dibutuhkan.

Satu hal yang harus dilakukan, mungkin, adalah meminta pemimpin memeriksa semua kode sebelum melakukan / menggabungkan / apa pun untuk memastikannya sesuai dengan standar, karena tampaknya rantai alat yang ada tampaknya tidak dapat memeriksanya secara otomatis.

perangkat lunak yang dapat membantu menyelamatkan nyawa dalam keadaan darurat dengan mempercepat distribusi makanan

Saya percaya pada standar pengkodean yang baik, tetapi saya juga percaya bahwa menyelamatkan nyawa jauh lebih penting.

Prioritas terbesar Anda harus menyelamatkan nyawa orang . Bayangkan jika perangkat lunak ini mendistribusikan makanan untuk keluarga Anda, atau tim Anda. Ada lagi yang bisa datang selanjutnya.

Berita baiknya: Anda memiliki tes. Pengujian akan membantu Anda mematuhi standar pengkodean Anda tanpa merusak fungsi, tetapi ini harus terjadi setelah pengiriman , bukan sebelumnya.