Klien saya ingin 25% komentar di proyek saya saat ini, bagaimana bereaksi? [Tutup]

pengembang junior di sini.

Saat ini saya bekerja sendiri di aplikasi web untuk klien besar perusahaan saya. Saya mulai bulan lalu. Klien menginginkan setidaknya 25% komentar di setiap proyek perangkat lunaknya.

Saya memeriksa kode aplikasi sebelumnya dan berikut adalah pengamatan saya:

• setiap file dimulai dengan blok komentar (paket, tanggal terakhir diperbarui, nama perusahaan saya & hak cipta)

• semua variabel diberi komentar dengan namanya // nameOfCustomer public String nameOfCustomer

• semua getter dan setter dikomentari

• sangat sedikit komentar yang bermanfaat

Sepertinya pengembang hanya memberikan komentar sebanyak mungkin untuk mencapai ambang 25% itu, terlepas dari kualitas dan kegunaannya. Perusahaan saya memberi tahu saya bahwa "kami melakukannya sesuai keinginan klien".

Saya tidak berbicara langsung dengan klien tentang hal ini. Inilah argumen saya sejauh ini:

• baris tidak berguna untuk membaca dan menulis (buang-buang waktu)
• komentar terkadang tidak diperbarui (sumber kebingungan)
• pengembang cenderung menggunakan atau memercayai komentar yang sangat berguna

Apa saran Anda tentang hal ini? Bagaimana saya harus menangani situasi ini?

Semua jawaban dan komentar lain di sini benar-benar membuat saya marah, karena mereka sangat bertentangan dengan reaksi pertama saya dan juga bertentangan dengan sikap yang saya saksikan pada rekan kerja saya. Jadi saya ingin menggambarkan pendekatan alternatif, jika hanya demi menjadi suara yang berbeda pendapat .

Prinsip penuntun jawaban ini adalah, "Menyenangkan pelanggan". Menyenangkan pelanggan tidak hanya berarti memenuhi harapan mereka; itu berarti memahami permintaan mereka begitu dalam sehingga Anda dapat menafsirkan apa yang mereka katakan dengan cara mereka bersungguh-sungguh, dan memenuhi apa yang mereka minta. Jawaban lain tampaknya dipandu oleh prinsip kepatuhan jahat, yang menurut saya membenci; dan selain itu adalah praktik bisnis yang dipertanyakan karena ini cara yang buruk untuk mendapatkan pelanggan tetap.

Bagi saya, ketika saya mendengar klien berkata, "Saya ingin 25% komentar", itu adalah awal dari sebuah dialog. Bagi saya jelas bahwa implikasinya di sini adalah "Saya ingin banyak teks deskriptif, sehingga pendatang baru untuk basis kode ini dapat bangun dan berjalan dengan cepat", bukan "Saya ingin Anda menambahkan keacakan dalam kategori sintaksis tertentu" sebagai jawaban lain tampaknya mengambilnya. Dan saya akan menanggapi permintaan itu dengan serius, dan bermaksud untuk menulis banyak komentar yang deskriptif dan membantu, membimbing pendatang baru ke struktur kode, menunjukkan keputusan rekayasa yang mengejutkan dan menguraikan alasan yang masuk ke dalamnya, dan memberikan bahasa Inggris tingkat tinggi deskripsi bagian kode yang rumit (bahkan jika mereka tidak memiliki kejutan). Niat dan pengertian ini adalah titik awaldiskusi - itu bahkan sebelum kita mulai berbicara. Bagi saya implikasi dari permintaan itu begitu jelas sehingga bahkan tidak perlu klarifikasi itu; tetapi jika bagi Anda tidak jelas Anda tentu harus memeriksa dengan mereka!

Oke, jadi ke mana dialognya kalau itu titik awal? Bagian selanjutnya dari dialog seperti ini:

1. Saya berharap ini menjadi upaya tambahan yang serius, mungkin dalam fase kedua proyek, yang berada di atas dan di luar produksi alat yang mereka pedulikan bekerja. Mungkin perlu beberapa menit diskusi untuk membahas proses ini dan mengapa ini merupakan pekerjaan tambahan, tetapi saya akan mengabaikannya di sini karena sebagai programmer profesional saya berharap Anda tahu betapa sulitnya membuat komentar yang baik.
2. "Upaya tambahan yang serius" berarti kita mungkin memerlukan anggaran waktu yang lebih lama dan anggaran moneter yang lebih besar; atau kita mungkin perlu mengurangi anggaran fitur; ataukita mungkin perlu berkompromi pada kualitas dan kuantitas komentar. Bagian ini akan menjadi sedikit negosiasi. Tetapi menurut pendapat saya, Anda harus sangat di muka tentang biaya melakukan pekerjaan tambahan ini, dan memastikan bahwa itu adalah fitur yang penting bagi klien sehingga mereka bersedia menanggung biaya ini. Dan jika mereka - hebat! Anda mendapatkan waktu dan uang ekstra, dan mereka mendapatkan komentar berkualitas tinggi. Semua orang menang. Dan jika ternyata fitur komentar tidak begitu penting bagi mereka sehingga mereka rela kehilangan kemampuan untuk mengacaukan widget atau bersedia membiarkan tenggat waktu lewat hingga akhir Granuary, 20x6, maka semua orang menang lagi: mereka mendapatkan produk yang mereka inginkan. inginkan, dan Anda tidak perlu menghabiskan usaha ekstra yang diperlukan untuk membuat komentar berkualitas tinggi.

Di sinilah saya pikir dialog tidak boleh pergi:

3. Jangan mengancam klien dengan komentar berkualitas rendah. Biarkan mereka membantu Anda memilih tingkat upaya yang ingin mereka keluarkan dan bahwa mereka bersedia membayar. Jangan menjanjikan mereka 25% komentar dan kemudian memberi tahu mereka bahwa Anda berniat untuk memenuhi janji ini dengan autogenerating keacakan setelah proyek dibangun.
4. Jangan sembunyikan rencana Anda. Jangan menjanjikan mereka 25% komentar, dan kemudian secara otomatis membangkitkan keacakan tanpa memberi tahu mereka bahwa itulah yang akan Anda lakukan. Ketika mereka memperhatikan (bukan jika), Anda berdua kehilangan banyak waktu: mereka tidak senang dengan produk yang mereka dapatkan, dan Anda mendapatkan kata-kata negatif dari mulut ke mulut.
5. Jangan mencoba meyakinkan mereka bahwa mereka tidak ingin komentar. Mereka jelas menginginkan komentar. Diskusikan pertukaran dari berbagai pendekatan: ya! Diskusikan cara-cara alternatif untuk membuat pendatang baru yang ramah basis kode: ya! Katakan pada mereka bahwa mereka tidak tahu apa yang mereka inginkan: eh, tidak. Anda ingin bekerja dengan mereka untuk mendapatkan apa yang mereka inginkan; jadi pahami apa itu dan cari tahu cara terbaik untuk memberikan itu kepada mereka dalam anggaran yang mereka setujui, memprioritaskan fitur yang paling mereka pedulikan jika sumber daya yang mereka miliki tidak mencukupi.
6. Jangan membuat alasan tentang seberapa sulit komentar untuk ditulis. Menulis kode itu sulit; kode debug sulit; menulis komentar itu sulit. Jika mudah, mereka tidak akan mempekerjakan Anda. Lewati saja keluhan dan langsung ke titik yang mereka pedulikan, yaitu bagaimana upaya ekstra yang diperlukan mempengaruhi mereka.

Pelanggan adalah raja. Jadi sebagai kontraktor Anda harus memenuhi apa pun yang telah ditetapkan klien sebagai standar kualitas. Atau Anda berisiko keluar.

Ini dikatakan, sangat penting bagaimana standar kualitas (di sini buruk) didefinisikan:

• Standar kualitas kontraktual: kode yang dikirimkan harus mematuhi, atau jika tidak, ini merupakan pelanggaran kontrak. Tidak ada pilihan.

• Standar kualitas perusahaan formal: bahkan jika itu bekerja dengan sempurna, kode yang tidak mematuhi akan dianggap kualitas buruk oleh begitu banyak orang, sehingga Anda akan menjadi tua sebelum Anda mengubahnya menjadi praktik yang lebih baik. Lebih buruk: alat yang terkenal dapat digunakan untuk mengotomatisasi dan melegitimasi metrik kualitas semacam itu (misalnya, sonar cube ). Hampir tidak ada pilihan.

• Kriteria ad-hoc ditentukan oleh beberapa orang di klien. Di sini Anda bisa berdiskusi. Ada harapan :-)

Dalam kasus terakhir ini, mungkin ada beberapa fleksibilitas, dan Anda dapat mencoba secara diplomatis untuk menyampaikan maksudnya. Berikut beberapa argumen yang bertentangan dengan kriteria pelanggan:

• Masalah produktivitas: pengkodean dilakukan dua kali (sekali dalam bahasa Inggris dan sekali dalam kode).
• Masalah akurasi: jika perubahan dilakukan dalam kode, mereka harus dilakukan dalam komentar, atau komentar mungkin menjadi tidak berguna.
• Masalah refactoring: karena alat refactoring tidak memproses nama variabel dalam komentar.
• Masalah risiko: ambiguitas (atau keusangan) komentar dapat menimbulkan kebingungan dan risiko untuk meningkatkan bug.
• Kuantitas bukan kualitas
• Kumpulan komentar lucu yang tidak berguna ini di StackOverflow .
• Artikel ini yang berpendapat bahwa rasio komentar yang tinggi bahkan bisa menjadi tanda bau kode.

Tetapi alih-alih berbicara menentang yang buruk dan menghadapi pelanggan, mungkin Anda bisa mempromosikan pendekatan yang lebih baik:

• Kode bersih (sarankan buku untuk pelanggan Anda: ada bagian yang meyakinkan yang didedikasikan untuk komentar dan kode dokumentasi diri).
• Praktik dokumentasi: Hal-hal yang paling sulit untuk dipahami, dan karenanya informasi yang paling berharga, seperti misalnya hubungan dan interaksi antar kelas didokumentasikan dengan lebih baik dalam dokumen terpisah (misalnya dalam gambar UML daripada 1000 kata komentar?)

Jika pelanggan masih tidak yakin, Anda bisa mengusulkan alternatif eksperimental, menggunakan alat menghasilkan dokumentasi secara otomatis dengan komentar, seperti javadocatau doxygen. Usulkan untuk mengubah fokus dari kuantitas (25% dari kode) ke kualitas (menghasilkan javadoc dimengerti).

Klien menginginkan setidaknya 25% komentar di setiap proyek perangkat lunaknya.

Apakah klien benar-benar ingin 25% komentar atau apakah klien Anda ingin kode Anda sejelas mungkin?

IMHO, klien tahu apa yang dia inginkan, tetapi tidak apa yang dia butuhkan. Karena klien bukan pengembang itu sendiri dan mendapat umpan balik dari pekerja / pelanggannya sendiri, klien Anda hanya melihat bagian atas gunung es.

Saya kira klien Anda memiliki beberapa pseudo-knowledge dan ingin kode didokumentasikan dengan baik dan mudah dan murah dipelihara, dan alat untuk ini adalah komentar (dalam benaknya).

Cobalah berbicara dengannya dan siapkan beberapa cuplikan kode dengan kode yang ditulis dengan baik yang menjelaskan dirinya sendiri, dan satu lagi yang ditulis dengan komentar buruk. Hanya beberapa baris. Perlihatkan ini jika diperlukan dan gunakan sebagai gambar untuk kata-kata Anda.

Bicaralah dengan klien Anda / supervisor / apa pun dan cobalah untuk memberi tahu mereka prinsip-prinsip modern kontrol versi (tidak perlu komentar di awal file) dan kode bersih (saya merekomendasikan buku juga) dan dengan demikian menghasilkan kode yang menjelaskan diri.

Mungkin, jika Anda dapat menunjukkannya dengan cukup baik dan membuat klien Anda mengerti bahwa dia menginginkan kode bersih, bukan hanya komentar, Anda dan tim Anda dapat menulis kode yang lebih baik (dengan lebih sedikit komentar) dan segera menunjukkan bahwa Anda adalah pengembang yang baik yang patut dijaga .

Ini mengingatkan saya pada jawaban Stack Overflow konyol yang Anda lihat itu terdiri dari satu baris diikuti oleh, secara harfiah, "beberapa teks di sini untuk mencapai batas karakter minimum".

Ketika ini terjadi, argumen dapat dibuat bahwa dua kelompok orang yang bersalah:

1. Orang-orang yang membatasi - jelas itu berlebihan dan mencegah orang mengirimkan informasi mereka yang benar tanpa menambahkan suara buatan

2. Orang-orang yang mengirimkan informasi yang tidak terbentuk dengan benar, kemudian menambahkan suara buatan ketika sistem meminta mereka untuk menambahkan lebih banyak zat yang sebenarnya

Terkadang, sebuah pertanyaan akan sederhana dan sesuai topik, dan tidak ada banyak yang bisa dikatakan selain beberapa kata. Namun, ini sangat jarang. Dalam hampir semua kasus, ada banyak hal yang perlu dikatakan. Jika tidak ada yang lain, itu harus sangat jelas bahwa cara untuk mengatasi pembatasan karakter tidak hanya dengan membuang noise acak ke dalam posting Anda.

Situasi komentar yang Anda hadapi ini hampir sama. Pengembang Anda telah mengambil permintaan komentar, dan menerapkannya dengan memasukkan noise acak ke dalam kode mereka. Mendokumentasikan nama-nama variabel, tepat di sebelah deklarasi variabel, adalah vandalisme . Itu seharusnya tidak pernah terjadi.

"Tapi bagaimana lagi kita bisa mencapai 25%?" Dengan menulis komentar aktual tentang substansi. Gunakan lebih banyak kata, kata-kata yang lebih baik, kata-kata terbaik untuk mendokumentasikan efek fungsi. Perluas penjelasan Anda. Jelaskan kasus tepi secara lebih rinci.

Namun, kembali ke titik semula, klien juga sebagian bersalah di sini, karena "25% dari kode sumber" sangat sewenang-wenang. Namun, pada akhirnya, mereka adalah klien, jadi manfaatkan yang terbaik. Tapi maksud saya "terbaik". Bukan "terburuk", seperti yang telah terjadi sejauh ini.

Saya tidak tahu apa masalahnya dengan persyaratan ini.

Hanya dengan melakukan oksigenasi dasar kode Anda, Anda mungkin sudah mencapai 10% atau lebih. Dan mari kita ambil 5% lagi dari komentar yang telah Anda tulis sendiri (beberapa menulis lebih banyak, tetapi 5% sepertinya perkiraan konservatif jika Anda belum mengambil sumpah diam). Pada titik ini sekitar 15% (ya ya, saya tahu, 5% dari 90% kurang dari 5%, jangan rewel). Jika oksigen Anda kurang dari 10%, mungkin metode Anda sangat panjang; biasanya ide yang bagus untuk memecahnya menjadi yang lebih kecil (kebanyakan pribadi / terlindungi), atau menggunakan kelas pembantu yang lebih umum, dll.

Sekarang, untuk sisa teks komentar - masukkan pertimbangan desain dan skenario penggunaan di kelas / komentar tingkat file. Memiliki beberapa tabel atau ASCII-art (atau kode doxygen yang menghasilkan hal-hal yang tampak lebih bagus ketika dirender). Saya tidak tahu, tentu saja, tentang apa proyek Anda, tetapi saya yakin Anda dapat melakukan ini tanpa komentar palsu (selain pelat oksigen) dan mencapai sesuatu yang mendekati 25%.

Jika itu hanya, katakanlah, 20% dan bukan 25% - Saya yakin klien hanya memberikan nomor itu sebagai sesuatu yang sewenang-wenang, dan akan baik-baik saja dengan itu. Ngomong-ngomong, bicarakan dengan mereka untuk membahas apa yang harus dicakup oleh komentar; dan tunjukkan pada mereka contoh file komentar untuk melihat apakah mereka senang. Jika ya maka itu saja, jika mereka pikir ada sesuatu yang hilang mereka akan memberi tahu Anda apa yang hilang. Mereka tidak akan memberi tahu Anda "Kami tidak dapat menyarankan komentar tambahan yang mungkin tetapi kami masih ingin Anda menambahkan beberapa".

PS - Lihatlah kode kontainer Java standar untuk melihat bagaimana Anda dapat mencapai, oh, 70% atau lebih ...

Memiliki 25% komentar dalam kode Anda adalah tujuan yang sangat baik untuk dimiliki, dan itu membuat klien senang. Sekarang menulis 25% komentar pengisi jelek seperti "i + = 1; // naikkan saya dengan 1" harus ada di bawah Anda, jadi luangkan waktu Anda, tulis komentar yang bermanfaat, dan nikmati perasaan bahwa Anda sebenarnya dibayar untuk melakukan sesuatu yang harus Anda lakukan bagaimanapun.

Kita semua tahu ini adalah persyaratan omong kosong. Pertanyaan menarik di sini adalah

bagaimana bereaksi?

Saya sangat percaya dalam membuat masalah terlihat. Di sini saya akan menggunakan fakta bahwa uang berbicara.

Minta saya untuk melakukan ini dan saya akan mengatakan yakin, itu akan menambahkan 1% ke tawaran saya. Oh, tapi itu akan menambah 20% ke tawaran pemeliharaan di masa depan.

Hanya sekali mereka bertanya mengapa saya akan mengajar mereka bahwa maksud dari nama baik adalah untuk menghindari perlunya berkomentar.

Sebagai alternatif, saya akan mengusulkan membuat dokumentasi yang bertujuan untuk mendapatkan pemrogram pemeliharaan dengan seperangkat kualifikasi yang diasumsikan untuk mempercepat ide-ide di balik proyek. Atau yakin, saya bisa memberi Anda 25% komentar. Terserah kamu.

Ya, saya mengerti frustrasi Anda dengan aturan konyol. Saya sudah membaca banyak program dengan komentar tidak berguna seperti

x = x + 1; // add 1 to x

Dan saya berkata pada diri saya sendiri, Jadi ITULAH arti tanda plus itu !! Wow, terima kasih sudah memberi tahu saya, saya tidak tahu itu.

Namun demikian, pelanggan membayar tagihan. Karena itu, Anda memberi mereka apa yang mereka inginkan. Jika saya bekerja di sebuah dealer mobil dan seorang pelanggan mengatakan dia menginginkan sebuah truk pickup, saya tidak akan berdebat dengannya tentang apakah dia benar-benar membutuhkan truk pickup dan menanyai dia tentang apa yang dia harapkan untuk diangkut. Saya akan menjualnya truk pickup.

Oke, ada saat-saat ketika apa yang diinginkan pelanggan dan apa yang benar-benar dia butuhkan begitu jauh sehingga saya mencoba membahas masalah itu dengannya, mungkin meyakinkannya untuk menyetujui sesuatu yang lebih rasional. Kadang ini berhasil, kadang tidak. Pada akhirnya, jika aku tidak bisa berubah pikiran, aku memberikan apa yang dia inginkan. Jika dia kembali lagi nanti dan berkata, Oh, itu benar-benar tidak memenuhi persyaratan bisnis saya, maka kita dapat meminta bayaran lebih banyak untuk melakukan apa yang kita suruh dia lakukan pertama kali. Seberapa banyak Anda dapat bernegosiasi dengan pelanggan tergantung pada seberapa besar mereka memercayai keahlian Anda, bagaimana kontrak mereka dengan Anda cocok dengan organisasi, dan, jujur ​​saja, seberapa keras kepala mereka.

Ini akan menjadi kasus yang sangat langka di mana, dengan asumsi itu terserah saya, saya akan kehilangan kontrak karena saya pikir persyaratannya salah dipahami.

Ingatlah bahwa orang yang dinegosiasikan dengan perusahaan Anda mungkin atau mungkin bukan orang yang menemukan aturan 25% ini. Ini bisa menjadi aturan yang dikenakan pada mereka dari atasan.

Saya melihat lima kemungkinan tanggapan:

Satu. Yakinkan bos Anda atau siapa pun yang sedang bernegosiasi dengan klien untuk berdebat tentang hal ini. Mustahil ini tidak menghasilkan apa-apa, tetapi Anda bisa mencobanya.

Dua. Menolak melakukannya. Ini mungkin akan membuat Anda dipecat, atau jika perusahaan setuju dengan Anda, menyebabkan Anda kehilangan kontrak. Ini sepertinya tidak produktif.

Tiga. Tulis komentar tidak berguna untuk mengisi ruang, jenis komentar yang hanya mengulangi apa yang ada dalam kode dan bahwa setiap programmer yang mampu memodifikasi kode dapat melihat dalam 2 detik. Saya telah melihat banyak komentar seperti ini. Bertahun-tahun yang lalu saya bekerja untuk sebuah perusahaan di mana kami diminta untuk menempatkan blok komentar di depan setiap fungsi yang mencantumkan parameter, seperti:

/*
GetFoo function
Parameters:
  name: String, contains name
  num: int, the number
  add_date: date, the date added
Returns:
  foo code: int
*/
int GetFoo(String name, int num, Date add_date)

Keberatan bahwa komentar tersebut adalah beban pemeliharaan karena Anda harus tetap memperbaruinya tidak valid. Tidak perlu memperbarui mereka karena tidak ada programmer serius yang akan melihatnya. Jika ada pertanyaan tentang itu, pastikan untuk menjelaskan kepada semua anggota tim bahwa komentar yang tidak berguna dan berlebihan harus diabaikan. Jika Anda ingin tahu apa parameter suatu fungsi atau apa yang dilakukan oleh baris kode, baca kodenya, jangan lihat komentar yang tidak berguna.

Empat Jika Anda akan menambahkan komentar tidak berguna yang berlebihan, mungkin ada baiknya Anda menulis program untuk menghasilkannya. Sesuatu investasi di muka, tetapi bisa menghemat banyak mengetik di jalan.

Kembali ketika saya pertama kali memulai dalam bisnis ini, sebuah perusahaan tempat saya bekerja menggunakan program yang diiklankan sebagai "Menulis dokumentasi Anda untuk Anda! Dokumentasi lengkap untuk setiap program!" Sistem mengharuskan kami memberikan semua variabel pada dasarnya nama yang tidak berarti dan kemudian memiliki tabel yang memberikan nama yang bermakna untuk setiap variabel, jadi pada dasarnya yang dilakukan "dokumentasi otomatis" adalah mengganti nama yang tidak berarti yang memaksa kami untuk menggunakan dengan nama yang bermakna. Jadi misalnya - ini bekerja dengan COBOL - Anda akan memiliki garis dalam program Anda yang mengatakan

MOVE IA010 TO WS124

dan mereka akan menghasilkan garis "dokumentasi" yang mengatakan

COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE

Bagaimanapun, orang pasti bisa menulis sebuah program untuk menghasilkan dokumentasi yang sama tidak berharga dengan cukup mudah. Baca garis seperti

a=b+c

dan menghasilkan komentar

// add b to c and save result in a

Dll

Lima. Buat yang terbaik dari aturan konyol. Cobalah untuk menulis komentar yang bermanfaat dan bermakna. Hei, ini bisa menjadi latihan yang bagus.

Oh, omong-omong, bolehkah saya menambahkan bahwa Anda selalu bisa memainkan metrik.

Saya ingat ketika seorang majikan mengatakan bahwa mereka akan mulai mengukur produktivitas pemrogram dengan berapa banyak baris kode yang kami hasilkan per minggu. Ketika kami diberitahu hal ini di sebuah rapat, saya berkata, Hebat! Saya dapat dengan mudah meningkatkan skor saya. Tidak ada lagi tulisan

x=x+4;

Sebagai gantinya saya akan menulis:

x=x+1;
x=x+1;
x=x+1;
x=x+1;

Loop? Lupakan, saya akan menyalin dan menempelkan kode sepuluh kali. Dll

Jadi di sini, jika mereka akan menghitung baris komentar, buat setiap baris pendek dan lanjutkan ide pada baris berikutnya. Jika ada perubahan pada komentar, jangan perbarui komentar yang ada. Masukkan tanggal di atasnya, lalu salin seluruh teks dan tulis "Diperbarui" dan tanggal baru. Jika klien mempertanyakannya, beri tahu mereka bahwa Anda perlu menjaga riwayatnya. Dll.

Metrik sewenang-wenang tampaknya menjadi fakta kehidupan dalam terlalu banyak proyek ...

Ini sering terlihat dalam persyaratan bodoh seperti kompleksitas Siklomatik maksimum yang mengarah ke kode yang lebih kompleks, karena fungsi tidak perlu dipisah untuk memastikan kepatuhan, atau file yang dipisah karena melebihi beberapa panjang SLoC sewenang-wenang

Komentar harus ditambahkan ke kode, dan jelaskan apa yang sedang terjadi (dan tidak hanya mengulangi kode!).

Yang mengatakan, jika ini yang diinginkan pelanggan Anda, dan perusahaan Anda telah setuju untuk menyediakan, kecuali Manajer QA Anda mengembangkan dosis yang masuk akal, Anda mandek.

Dalam jangka pendek tidak ada yang bisa Anda lakukan. Ikuti saja.

Anda juga harus mengabaikan semua ide bodoh yang saya lihat di utas ini tentang protes agresif pasif dan lelucon konyol dalam kode.

Setelah Anda mengembangkan hubungan saling percaya dengan klien, mereka akan lebih siap untuk mendengarkan alasan Anda - Anda mungkin menemukan bahwa ini adalah permintaan konyol dari satu orang yang dulu berpengaruh dan bahwa ia memiliki sedikit dukungan di dalam perusahaan.

Dalam situasi apa pun sebaiknya Anda menentangnya tanpa izin klien.

Saya kecewa dengan kurangnya imajinasi yang ditampilkan oleh sesama programmer saya di sini.

Menurut saya klien melakukan riset. Dia mungkin telah membaca di suatu tempat bahwa kode kualitas biasanya berisi sekitar 25% komentar. Jelas dia peduli / khawatir tentang pemeliharaan di ujung jalan. Sekarang, bagaimana dia membuat beton itu dalam dokumen persyaratan yang harus terikat pada kontrak? Itu tidak mudah. Bahkan mungkin tidak mungkin. Namun dia ingin memastikan dia akan mendapatkan nilai untuk uangnya sehingga dia menyebutkan beberapa indikator kualitas.

Itu sama sekali tidak terdengar bodoh atau konyol bagi saya. Orang-orang yang menulis persyaratan kemungkinan besar bukan pemrogram. Mereka mungkin memiliki pengalaman buruk dengan proyek sebelumnya. Petugas pemeliharaan mereka mengeluh: "Semua omong kosong ini tidak didokumentasikan!" Ini berdering di telinga ketika mereka menulis persyaratan baru untuk proyek selanjutnya.

Jika Anda serius mendokumentasikan kode Anda dan menyediakan konteks untuk geng pemeliharaan, persyaratan ini akan dipenuhi secara otomatis. Jadi, jangan menjadi banci tentang itu!

Pada akhirnya, baik itu 21% atau 29%, tidak ada yang peduli. Klien akan memeriksa barang-barang Anda oleh beberapa pengembang independen dan dia akan lebih memahami apa yang Anda lakukan.

Saya telah bertemu banyak programmer yang tidak mengerti bagaimana orang ada yang saat ini tidak bekerja pada proyek ini.

Bagi mereka semua yang mereka tahu, ADALAH diketahui oleh semua orang.

Jika seseorang tidak tahu SEMUA yang mereka ketahui saat ini, maka orang-orang itu adalah "idiot" bagi mereka.

Dengan standar ini Anda dapat memaksa orang untuk terbiasa menulis komentar.

Mereka mungkin menulis komentar yang tidak berguna 99% dari waktu, tetapi kadang-kadang mereka mungkin benar-benar menuliskan salah satu hal yang "SEMUA ORANG TAHU", dan seseorang yang baru dalam tim mungkin sebenarnya tidak menghabiskan 16 jam untuk mencari bug (yang sudah dipecahkan beberapa orang, tetapi kemudian dibatalkan karena alasan lain) yang sudah jelas dengan komentar pada saat itu dalam kode.

Memiliki komentar di baris dengan bug yang tidak terlihat juga dapat membantu menghindari programmer di masa depan untuk benar-benar menghancurkan program secara tidak sengaja (terutama ketika bagian "sedang rusak" tidak jelas ketika melakukan tes cepat).