Ketidaksepakatan dengan pimpinan proyek tentang standar pengkodean [ditutup]

Jadi saya sedang mengerjakan proyek baru bersama dengan pimpinan proyek saya selama 1 tahun terakhir.

Awalnya kami memiliki sub-proyek kami sendiri yang tinggal di git repo yang terpisah, saya memiliki sedikit interaksi dengan kode-nya, sehingga bau kode tidak mengganggu saya. Beberapa 6 bulan kemudian saya mulai memelihara dan menambahkan fitur ke kode-nya, karena saya mengambil peran yang lebih besar dalam proyek tersebut.

Sekarang saya adalah pengembang utama untuk kedua sub proyek (tim akan tumbuh; dia masih di atas saya), hal-hal ini mengganggu saya dan saya ingin mengurusnya, tetapi ditolak:

1. Tidak ada kurung kurawal, fungsi kapitalisasi, penggunaan kuotasi campuran (dobel dan tunggal dengan logika tersembunyi), tidak menggunakan ===, kelas besar dengan fungsi besar. Intinya, bisa lebih baik.
2. Bergantung pada opsi PHP untuk mematikan pemberitahuan / peringatan. Kode penuh dengan penggunaan variabel dan kunci array yang tidak dicentang. Variabel didefinisikan dalam ifs.

Argumen untuk 2 masalah di atas:

1. Tidak ingin menerapkan gaya pengkodean pada orang.
2. Dianggap sebagai fitur bahasa, yang cocok untuk kode yang lebih pendek / lebih efisien.

Saya percaya bahwa beberapa aturan harus dimiliki dan kode harus bersifat defensif. Saya menawarkan untuk menggunakan pengaturan default PHPStorm untuk pemformatan, menggunakan kurung kurawal dan konvensi penamaan yang diterima komunitas.

Saya ingin menyelaraskan kedua proyek untuk menggunakan pedoman yang sama, karena keduanya tidak dapat dipisahkan.

Apakah saya salah? Apakah saya memaksakan preferensi pribadi saya?

Jika Anda dapat membuat alasan kuat mengapa alasan Anda lebih baik (dan masalah utama apa yang mungkin terjadi akibat penggunaannya), maka Anda tidak memaksakan preferensi pribadi, saya pikir, tetapi sebaliknya mencoba membuat proyek untuk sukses.

Jika dia bisa membuat alasan yang lebih kuat mengapa itu lebih baik dan masalah seperti apa yang mencegah Anda tidak bisa, maka dia membuat Anda bohong.

Manajemen atas yang layak harus dapat melihat manfaatnya, tetapi itulah poin yang akan (dan harus) mereka pedulikan: bukan apakah itu lebih mudah bagi pengembang atau "tidak ingin memaksa semua orang bekerja seperti robot" (yang adalah hal yang konyol, tetapi jangan menggunakannya sebagai titik sakit manajemen tingkat atas). Mereka (harus) peduli dengan stabilitas proyek yang sedang berlangsung.

Per komentar saya di atas:

Jika dia adalah pemimpin proyek, itu sepertinya menyiratkan bahwa itu pada dasarnya adalah panggilannya.

Itu adalah pikiran saya. Jika Anda ingin mengubah standar tetapi dia tidak mengindahkannya, a) mencari cara untuk melampaui dia, b) pergi ke tempat lain untuk bekerja, atau c) mencoba hal-hal kecil apa yang mungkin dapat Anda lakukan tanpa membuatnya kesal terlalu banyak.

Mendapatkan di atasnya hanya akan berhasil jika Anda membuat alasan kuat mengapa harus ada standar yang lebih baik.

Pada dasarnya:

• Anda tidak suka gaya pengkodeannya. Itu hak kamu.
• dia menemukan itu baik -baik saja dan menemukan menghabiskan hari / minggu / lebih hanya menyesuaikan gaya adalah buang - buang waktu . Itu haknya.

Tempatkan diri Anda pada posisinya. Apa manfaat dari usaha Anda, selain biaya perusahaan banyak uang (gaji Anda)? Apakah dia selalu begitu licik? Tidakkah dia melihat ada hal yang lebih penting untuk dilakukan sekarang?

Pada dasarnya, Anda harus menemukan semacam kompromi yang dapat Anda jalani, atau hubungan Anda akan menjadi masam. Tergantung juga pada bagaimana Anda berkomunikasi dengannya. Sisihkan ego Anda dan cobalah untuk membantu ... karena terakhir Anda menanyakan kepadanya hal-hal yang Anda sukai, bukan sesuatu yang dia minati. Dengan kata lain, Anda meminta bantuan padanya .

Ini juga sering tergantung pada bagaimana Anda bertanya. Contoh:

Apa maumu:

membuat kode lebih cantik

Apa yang tidak dikatakan:

kode Anda menyebalkan seperti itu

Apa yang harus dikatakan:

Saya akan sangat menghargainya jika saya bisa membuat kedua proyek konsisten, hanya dasar-dasarnya, dan itu hanya akan membuat saya sehari.

Apa maumu:

tidak ada lagi peringatan yang tidak dicentang

Apa yang tidak dikatakan:

kode Anda menyebalkan seperti itu

Apa yang harus dikatakan:

Saya tahu cara cepat menghilangkan peringatan ini dan itu. Kemudian, dengan mengaktifkannya kembali, kami dapat mendeteksi lebih cepat jika ada sesuatu yang rusak di masa depan.

Dan terakhir:

Saya tahu ini bukan prioritas. Jadi saya dengan senang hati dapat melakukannya setelah hal-hal prioritas tinggi keluar dari meja terlebih dahulu.

Atau, jika itu tidak berhasil atau Anda memiliki hubungan yang buruk dengannya, pertimbangkan untuk pergi. Jika Anda tidak bisa menyelesaikan masalah sekarang, sepertinya tidak akan menjadi lebih baik di masa depan ... dan kesampingkan ego Anda.

Catatan samping

Saya pikir lebih umum tentang orang tua untuk bersikap lebih lunak. Mereka tahu kode tersebut akan dibuang dalam satu atau dua dekade (karena perubahan teknologi, API juga, tim, mitra bisnis, persyaratan, keputusan global, apa pun ...). Mereka kurang memiliki ego dan fokus untuk membuatnya bekerja daripada menjadi sempurna. Meskipun saya sendiri cenderung sempurna, saya tidak bisa menyalahkan mereka.

Ini mungkin akan menjadi kontroversial tetapi ...

Kami berbicara dan setuju untuk tidak setuju dan meneruskannya ke manajemen yang lebih tinggi

Tidak pernah. Pernah. Melakukan. Ini. PERNAH. Setiap kali Anda melakukan ini, itu membuat kita kembali satu dekade. Ini adalah bagaimana ini akan dimainkan:

• Manajer senior 1: "Kami telah diminta untuk menangani masalah ini bla, bla, bla, sesuatu tentang standar pengkodean dan membuang-buang waktu."

• Manajer senior 2: "Dan mereka meminta kami untuk menyelesaikan perang wilayah kutu buku mereka karena?"

• Manajer senior 3: "Karena mereka bayi cengeng yang tidak bisa berkomunikasi dan tidak peduli / mengerti apa nilai bisnis itu? *"

• Manajer senior 2: "Pasti begitu. Siapa yang siap bermain golf?"

Kemudian tiba saatnya Anda dan ulasan kinerja bos Anda:

"[manajer senior untuk atasan Anda]: Saya minta maaf tetapi ada beberapa kekhawatiran bahwa Anda tidak dapat mengelola laporan langsung Anda dan Anda mungkin tidak mengikuti praktik terbaik (meskipun saya tidak tahu apa yang Anda lakukan kecuali mengetikkan beberapa omong kosong yang membuat perangkat lunak ini bekerja) "

"[manajer senior untukmu]: Maafkan aku, tetapi ada beberapa kekhawatiran bahwa kamu tidak berhubungan baik dengan teman-temanmu dan kesulitan mengikuti arahan atasan langsungmu."

Dan inilah sebabnya kami sebagian besar dibayar rendah dibandingkan dengan nilai yang kami buat. **

Anda perlu A) melewatinya atau B) pindah ke toko yang memiliki standar yang sedikit lebih dekat dengan keinginan Anda. FWIW, saya akan melakukan B (dan mudah-mudahan beralih ke bahasa yang tidak mengizinkan kekejaman seperti itu). Tetapi tidak pernah meningkatkan perselisihan teknis terhadap gugatan kecuali jika melibatkan sesuatu yang ilegal atau berpotensi menimbulkan bencana (celah keamanan menganga). Benar-benar menjengkelkan tidak memotongnya.

* Demi orang-orang yang akan membaca ini dan salah paham, saya tidak mengatakan bahwa OP dan bosnya seperti ini (saya menyadari bahwa kualitas / keterbacaan kode berdampak langsung pada garis bawah bisnis), saya katakan bahwa mereka akan dianggap seperti ini oleh manajemen non-teknis.

** Bagi orang-orang yang menganggap potret saya tentang manajemen atas sebagai orang yang tidak mengerti apa-apa adalah tidak realistis, pahami bahwa para manajer peduli (idealnya) tentang mengelola orang sebagaimana kita peduli dalam mengelola kode. Mereka mungkin tidak tahu apa-apa tentang masalah teknis, tetapi mereka mengenal orang-orang, dan itu semakin menjadi alasan yang membuat mereka berselisih bahwa A) mereka mungkin tidak memenuhi syarat untuk diselesaikan dan B) kalian berdua boleh dibilang bisa menyelesaikan tanpa bantuan membuatmu terlihat buruk.

*** Ya, saya sadar bahwa utang teknis dapat menumpuk hingga menenggelamkan bisnis. Saya hanya berpikir kurawal kurawal tidak akan menyelamatkan Anda (yang dikatakan, saya tidak pernah menghilangkan kurawal dan sangat lebih suka yang lain juga tidak).

IMHO, Anda menghadapi pengembang 'itu berfungsi', bukan yang akan peduli untuk yang berikutnya setelah mereka. Argumennya tidak berharga.

Semua yang Anda katakan tentang kodenya hanyalah kemalasan mentah di pihaknya. Memiliki proyek mengikuti standar pengkodean yang sama adalah tentang ketelitian. Anda bukan robot; Anda adalah insinyur; kamu seharusnya keras.

Anda dapat menunjukkan dengan beberapa contoh bahwa Anda mengalami kesulitan mengikuti membaca kode-nya, dan itu adalah kehilangan produktivitas yang sangat besar untuk Anda, tetapi saya tidak punya ide nyata bagaimana membawanya ke dia.

Tapi saya mungkin akan menjawab untuk Anda sesuatu nada:

Ini bekerja, tidak ada titik untuk berubah

Saran saya: jika dia benar-benar tumpul dan tidak ingin memimpin apa pun, biarkan saja. Tunggu kesalahan / bug / evolusi terjadi di proyeknya. Ketika datang, perbaiki dan tulis ulang bagian kode yang dimodifikasi / ditambahkan ke cara yang tepat; jangan pergi kepadanya untuk mengatakan apa-apa tentang itu. Dia tidak akan memaksakan pada Anda gaya pengkodeannya, karena Anda toh bukan robot ....

Ketika Anda mengerjakan suatu proyek, Anda harus menetapkan prioritas.

Prioritas # 1 adalah bergaul dengan rekan kerja Anda. Prioritas # 1 diikuti oleh kesenjangan yang sangat besar. Kemudian datang prioritas untuk hal-hal seperti kode yang berfungsi, dapat diuji, diuji, didokumentasikan, dipelihara dll. Kemudian muncul kesenjangan besar lainnya, dan kemudian datang standar pengkodean.

Dan mengubah kode yang ada agar sesuai dengan standar pengkodean baru sangat rendah pada daftar prioritas.

PS. "Mikro-optimasi" vs "komputer super cepat": Argumen yang benar-benar salah. Argumen terhadap optimasi mikro bukanlah bahwa komputer itu cepat, argumennya adalah waktu yang terbuang untuk optimasi mikro berarti Anda tidak punya waktu mengejar penghematan yang sebenarnya .

PS. Jika Anda hanya butuh satu hari untuk membuat perubahan yang membuat kode terlihat lebih baik bagi Anda, tetapi membuat rekan kerja Anda marah dan menjadikan Anda musuh, maka suatu hari Anda menyia-nyiakan sesuatu yang hanya kontra produktif.

PHP bukan kelompok paling elit dalam profesi kami. Sebenarnya Anda mengkritik sistem perangkat lunaknya yang mungkin sulit dimenangkan. Standar profesional Anda lebih tinggi sebagai standarnya.

Kemudian jika Anda tidak memiliki kelonggaran untuk meningkatkan kode di bawah tanggung jawab Anda, hanya ada satu solusi terakhir: lanjutkan .

Saya tidak tahu tentang pasar PHP saat ini di tempat Anda, tetapi Anda mungkin lebih dulu melakukan diversifikasi. Pelajari beberapa bahasa hype juga, atau ceruk seperti C #.

Anda mungkin tidak mendapatkan pekerjaan yang bagus, tetapi Anda akan maju lebih jauh, secara profesional. Jadi bersabarlah, dan lakukan belajar sendiri. Simpan uang. Kemudian mintalah beberapa kelonggaran dalam proyek Anda, atau ambil tawaran pekerjaan.

Saya merasa sulit untuk percaya bahwa # 1 adalah alasan sebenarnya karena tidak ingin mengubah standar pengkodean. Jika Anda memiliki basis kode, Anda harus dapat menerapkan standar pengkodean apa pun yang Anda (dan pengembang lainnya) setujui. Jika Anda mencapai konsensus dengan pengembang lain (dengan asumsi pemimpin tidak lagi melakukan pekerjaan pengembangan) maka tidak ada alasan baginya untuk benar-benar peduli, kecuali yang ini:

Apakah memperbaiki gaya basis kode penggunaan terbaik waktu Anda sekarang?

Saya yakin Anda memiliki kiriman. Berapa banyak waktu yang dibutuhkan untuk menjalani dan meningkatkan gaya di mana pun di basis kode lainnya? Bagaimana jika Anda memperkenalkan bug dengan memperbaiki gaya yang salah? Dari Paman Bob:

Tentu saja kode yang buruk dapat dibersihkan. Tapi ini sangat mahal. Sebagai kode membusuk, modul-modul itu saling menyindir satu sama lain, menciptakan banyak dependensi tersembunyi dan kusut. Menemukan dan memecahkan ketergantungan lama adalah tugas yang panjang dan sulit.

Meningkatkan gaya kode seperti ini hampir tidak pernah menggunakan waktu sebagai item sprint mandiri . Cara saya suka melakukan perbaikan semacam ini adalah apa yang saya sebut "Kebijakan Tetangga yang Baik": jangan berkeliling memperbaiki semua gaya dan struktur logika yang dapat Anda temukan, karena Anda mungkin menginvestasikan sebanyak waktu yang Anda inginkan dan masih akan tidak dilakukan. Alih-alih: setiap kali Anda membuat perubahan ke satu bagian kode, perbaiki gaya saat Anda berada di sana, dan biarkan lebih baik daripada yang Anda temukan. Jika Anda kesulitan menerapkan fitur karena kode ini didesain dengan buruk, perbaiki gaya untuk membuka blokir diri sendiri daripada membenturkan kepala Anda terhadapnya.

Dengan cara ini, setiap perubahan:

1. Memiliki motivasi bisnis disamping motivasi perfeksionisme teknis
2. Tidak akan dilihat sebagai investasi waktu besar (karena bukan!)
3. Akan membangun kebiasaan gaya yang baik justru karena Anda dan tim Anda melakukannya dari waktu ke waktu
4. Tidak akan menghadirkan risiko besar ke basis kode karena Anda tidak terlalu banyak mengubah sekaligus

Beberapa bulan dari sekarang Anda akan melihat dan melihat bahwa "paket mengerikan" tidak begitu buruk lagi dan bos Anda akan melihat bahwa timnya lebih bahagia. Tetapi karena itu bukan konfrontasi langsung, itu sudah akan dilakukan, dan dia tidak akan mengeluh apa-apa karena Anda tidak membuang waktu (dalam pikirannya) dengan menambahkan proyek refactoring besar ke daftar yang harus dilakukan. Dia kemungkinan tidak akan pernah memberi tahu Anda bahwa Anda benar, tetapi toh itu bukan tujuan (kan?)

Tanyakan pertanyaan-pertanyaan ini tentang petunjuk Anda.

• Apakah mereka terbiasa bekerja sendiri atau dengan tim yang sangat kecil?
• Apakah mereka sebagian besar berkode di toko yang satu ini?
• Apakah mereka terbiasa mengambil keputusan?
• Apakah mereka terbiasa "hanya menyelesaikannya"?
• Apakah mereka menulis sebagian besar kode?

Jika jawabannya "ya", maka saya akan melukis gambar dari jenis programmer memimpin tertentu. Jika itu cocok dengan apa yang Anda alami, mungkin itu akan membantu masuk ke kepala mereka. Jika tidak, abaikan jawaban ini .

Ini adalah seseorang yang telah berada di sana sejak hari pertama, telah menghabiskan bertahun-tahun di pekerjaan yang sama bekerja pada basis kode yang sama, terbiasa memiliki cara mereka sendiri, dan tidak memiliki banyak pengalaman dengan cara lain.

Mereka tidak mempertimbangkan orang lain ketika menulis kode karena semuanya masuk akal bagi mereka. Tentu saja, mereka menulisnya, atau mereka telah menghabiskan waktu bertahun-tahun memahaminya.

Mereka menganggap gaya pengkodean sebagai preferensi pribadi, bukan alat untuk mengurangi pemeliharaan dan bug. Ketika berdebat tentang gaya pengkodean, mereka akan kesulitan mendengar argumen Anda karena mereka mungkin tidak pernah berpikir banyak tentang mengapa mereka melakukan sesuatu dengan cara mereka. Apa yang akan mereka dengar adalah "Aku ingin melakukannya dengan caraku" atau "Aku ingin melakukannya dengan cara yang baru, mewah, dan trendi".

Mereka diatur dengan cara mereka. Karena mereka telah melakukannya dengan cara yang sama untuk waktu yang lama semua alat dan editor mereka dan otak dikonfigurasikan dengan tepat sesuai gaya mereka. Setiap penyimpangan dari gaya ini akan bertentangan dengan cara kerja yang diatur dengan hati-hati tetapi sangat rapuh ini. Upaya untuk mengubah akan menarik keluhan tentang editor mereka, alat, cara mereka suka bekerja, atau menjadi "sulit dibaca". Mereka menolak perubahan karena mereka telah membungkus diri mereka begitu ketat dalam status quo mereka tidak dapat berubah.

Ini adalah seseorang yang belum pernah belajar rekayasa perangkat lunak dan arsitektur perangkat lunak. Mereka hanya menyatukan apa saja yang berhasil.

Anda memiliki masalah orang, bukan masalah teknologi.

Anda harus melatih ulang lead Anda, atau Anda harus berhenti.

Pergi ke manajemen adalah pilihan terakhir . Baik untuk alasan @JaredSmith menunjukkan dan karena Anda akan kalah. Orang ini telah menghabiskan bertahun-tahun menghasilkan uang untuk mereka. Dia menulis perusahaan mereka. Dia melakukan banyak kebakaran. Untuk Anda dia seorang koki koboi membuat spageti. Bagi mereka, dia adalah pahlawan yang membangun dan menyelamatkan perusahaan.

Untuk melatih kembali Anda harus ...

• Dapatkan kepercayaannya.
• Cari tahu bagaimana dia berpikir.
• Atasi ketakutannya tentang perubahan.
• Buat perubahan lebih mudah.
• Tunjukkan bagaimana ini lebih baik untuknya .

Perhatikan gayanya dengan serius dan masuk ke dalam kepalanya. Tanyakan padanya tentang itu. Mengapa dia melakukan hal-hal seperti itu? Apa yang dia lihat ketika dia membacanya? Bagaimana cara berinteraksi dengan alat-alatnya? Bagaimana dia menelusuri kode? Mengetahui semua hal ini akan memungkinkan Anda untuk memahami dan mengatasi keberatannya.

Temukan akar obyektif dari keberatan subyektifnya, buat itu dapat ditindaklanjuti. "Sulit dibaca" bersifat subyektif, dan tidak memberi Anda informasi. Anda tidak dapat melakukan apapun tentang itu. "Saya buta warna dan penyorotan sintaksis tidak berfungsi" adalah objektif, ini memberi Anda informasi, dan Anda dapat melakukan sesuatu tentang itu. Saya akan merekomendasikan buku berjudul Getting To Yes untuk lebih lanjut tentang itu.

Setelah Anda mendapatkan masalah root, masalah sebenarnya yang dia alami, lihat apakah Anda dapat memperbaikinya atau mengatasinya. Maka itu tidak masalah. Mereka mungkin masih memiliki masalah emosional dengan perubahan, tetapi setidaknya mereka tidak dapat lagi berdebat bahwa ini adalah masalah aktual.

Lakukan sedikit demi sedikit. Ini adalah seseorang yang telah melakukannya dengan cara yang sama selama bertahun-tahun. Dia terbiasa melihat pola-pola tertentu dalam kode dan menggunakannya untuk memahaminya. Tiba-tiba mengubah semua pola itu akan membingungkan. Betapa frustrasinya untuk perlahan-lahan membawa mereka ke kecepatan dengan latihan yang dikenal baik, Anda harus berjalan melalui itu.

Advokasi untuk gaya komunitas standar. Ini menghilangkan argumen bahwa ini tentang preferensi pribadi dan memberikan tekanan pada mereka untuk membenarkan mengapa gaya mereka yang berbeda jauh lebih baik. Jika Anda berencana untuk merekrut, akan lebih mudah untuk mengintegrasikan karyawan baru.

Advokasi untuk gaya kode otomatis. Buat mengikuti gaya yang benar dengan menekan tombol. Gunakan alat yang dimulai dengan gaya standar, memungkinkan Anda mengonfigurasinya sesuai selera Anda, dan dapat menata ulang kode dengan menekan satu tombol. Membuatnya semudah mungkin mengikuti gaya menghilangkan banyak argumen tentang betapa sulitnya untuk mengikuti. Mereka dapat mengkodekan sesuka mereka, dan ketika selesai mereka menekan tombol dan mengikuti gaya yang dapat dibaca orang lain.

Karena orang ini tidak dalam pemikiran untuk memikirkan orang lain, Anda harus menunjukkan bagaimana perubahan ini menguntungkan mereka. Ini bisa sesederhana "karena ini adalah standar sekarang, Anda tidak perlu melalui pertarungan ini lagi dengan orang berikutnya yang Anda pekerjakan". Atau bisa juga "jika kami melakukan tes, Anda bisa lebih agresif mengubah kode dan tidak terlalu khawatir mengubah hal-hal". Atau "jika ada dokumen yang bagus, orang tidak perlu repot dengan pertanyaan tentang cara kerja kode". Agar ini menjadi efektif, Anda harus tahu apa yang mereka inginkan - beberapa orang suka diganggu, itu membuat mereka merasa penting.

Itu jalan yang sangat panjang. Anda harus memutuskan apakah Anda memiliki kesabaran untuk mengelola dan melatih kembali bos Anda. Pikirkan diri Anda lebih sebagai guru mereka daripada bawahan frustrasi mereka, dan Anda mungkin merasa lebih baik tentang hal itu.

Apakah saya salah?

Saya tidak tahu PHP, jadi saya tidak bisa membuat penilaian langsung, tetapi saya akan berasumsi demi argumen bahwa gaya pengkodean pilihan Anda "lebih baik" daripada kode yang Anda temui, karena Anda lebih sesuai dengan alat otomatis yang ada.

Maka Anda tidak salah untuk menyarankan perbaikan gaya pengkodean.

Intinya, bukan kode yang ingin saya gunakan

Anda mungkin salah untuk menolak bekerja dengan kode yang tidak memenuhi standar pilihan Anda, tetapi hanya sejauh bekerja dengan perusahaan Anda setuju untuk bekerja dengan kode mereka di tempat pertama. Pada akhirnya itu tidak "salah" untuk berhenti dari pekerjaan Anda jika itu menuntut Anda yang tidak menyukai Anda, karena itu adalah hak Anda, dan Anda mungkin menemukan pekerjaan yang lebih baik sebagai hasilnya.

Apakah saya memaksakan preferensi pribadi saya?

Tidak. Dia yang memimpin proyek dan kamu tidak. Itu panggilannya, meskipun dalam hal ini dia "didelegasikan ke atas".

Dia mungkin juga memutuskan untuk mendelegasikan ke bawah kepada Anda, sebagai pengembang utama sub-proyek, dan memberi Anda kebebasan untuk menetapkan standar pengkodean untuk sub-proyek dan kolega yang bekerja pada mereka di masa depan. Tetapi untuk alasan apa pun ia merasa sangat kuat sehingga Anda tidak perlu membuat standar. Bahkan jika dia salah tentang gaya pengkodean Anda tidak dapat mengharapkan untuk mengklaim otoritas yang tidak ia izinkan untuk Anda.

Namun, karena ia mengatakan "Saya tidak suka menerapkan gaya pengkodean", Anda setidaknya dapat menulis kode baru dengan gaya pilihan Anda (dan telah melakukannya). Pada akhirnya ini dapat menghasilkan peluang untuk menunjukkan manfaat obyektif gaya Anda. Itu akan menjadi saat yang tepat untuk melakukan yang kedua kalinya untuk menyelesaikan kasus Anda.

Anda juga dapat (saya pikir) bertanya secara wajar kepada orang yang mengedit file, untuk melakukannya dengan gaya file tersebut sudah ditulis. Itu memungkinkan Anda untuk mempertahankan standar dalam file yang Anda tulis. Sayangnya sisi lain dari ini adalah Anda harus mengedit file yang ditulisnya dalam sesuatu yang mirip dengan gayanya.

Bahkan dengan asumsi bahwa Anda memiliki test suite yang benar-benar bagus, dan karena itu dapat refactor dalam keamanan relatif, masih ada (diakui cukup marjinal) alasan untuk tidak membuka-buka dan mendesain ulang seluruh file. Yang utama adalah bahwa itu adalah mimpi buruk yang mencoba untuk menggabungkan, memesan ulang atau mengembalikan perubahan yang dibuat sebelum dan sesudah perubahan struktural besar. Tetapi mungkin saja dalam proyek khusus ini yang hampir tidak pernah terjadi.

[Manajer saya mengatakan dia tidak] suka menerapkan gaya pengkodean pada orang [karena] kita bukan robot.

Pernah bertanya-tanya mengapa kita tidak membuang kode sumber begitu saja setelah kita kompilasi dan melewati semua tes? Kode sumber adalah untuk manusia, dan bukan hanya untuk manusia untuk menulis, tetapi juga untuk membaca .

Cepat atau lambat, seseorang akan memiliki alasan untuk kembali dan membaca kodenya. Mungkin mereka harus mengubahnya, mungkin mendokumentasikannya, mungkin menggunakannya kembali. Masa bodo. Ini akan terjadi, dan kodenya akan jauh lebih mudah dibaca dan digunakan jika semuanya dalam gaya yang konsisten.

Bahkan gaya yang buruk lebih baik daripada tidak sama sekali.