Haruskah Anda menulis dokumentasi yang baik dan kode bersih untuk meningkatkan "Faktor Bus"?

Salah satu tujuan utama perusahaan pengembang perangkat lunak adalah untuk meningkatkan faktor Bus mereka. Hal ini juga dianjurkan dalam ceramah yang diselenggarakan oleh Google .

Itu berarti Anda harus membuat kode dan mendokumentasikan segala sesuatu dengan cara sehingga jika Anda ditabrak bus besok, proyek masih dapat dilanjutkan. Dengan kata lain, Anda harus membuat diri Anda mudah diganti oleh programmer lain dengan keahlian yang sama dengan Anda.

Menjadi replacable, bukankah itu bertentangan dengan minat pengembang? Dalam buku itu, 48 hukum kekuasaan Aturan 11 menyatakan bahwa Anda harus berusaha membuat orang bergantung pada Anda, untuk mendapatkan kekuasaan, yang kemudian diterjemahkan menjadi imbalan uang.

Terlepas dari skenario, di mana Anda memerlukan beberapa dokumentasi untuk diri Anda sendiri untuk melanjutkan proyek setelah 6 bulan jeda, tampaknya ada konflik kepentingan yang jelas antara pengembang dan perusahaan perangkat lunak.

Jadi sebagai seorang programmer, sebaiknya Anda benar-benar menulis dokumentasi yang bagus dan kode yang mudah dibaca untuk semua orang; atau haruskah Anda menulis kode dan dokumentasi sedemikian rupa sehingga berfungsi dan Anda sendiri dapat memahaminya, tetapi orang lain mungkin kesulitan memahaminya?

Anda harus berusaha untuk menjadi tak tergantikan bukan dengan menulis kode yang tidak dipahami orang lain, tetapi dengan mengumpulkan lebih banyak pengalaman dan pengetahuan daripada yang lain. Cara lama menjadikan Anda seorang pengembang yang setiap orang berusaha untuk tidak bekerja dengannya, karena mereka akan takut dan benci mempertahankan kode yang Anda tulis. Cara terakhir Anda menjadi anggota tim yang dicari, yang ingin dimiliki manajer di tim mereka.

Dalam pengalaman saya menulis kode yang bersih, didokumentasikan dengan baik (dan lebih baik didokumentasikan sendiri) selalu terbayar. Bahkan saya mengambil hampir setiap kesempatan untuk membantu dan mengajar orang lain (juga belajar dari mereka ketika mereka tahu sesuatu yang lebih baik), dan saya hampir tidak pernah merasa dalam bahaya digantikan oleh seseorang yang kurang mampu daripada saya. Bahkan, ini biasanya membantu seluruh tim bekerja lebih baik dan menyelesaikan masalah lebih cepat, yang merupakan impian setiap manajer - dan manajer yang masuk akal tidak ingin mengganti anggota tim yang baik.

Jika Anda akan memanipulasi organisasi atau orang dengan sangat transparan mereka lebih baik bodoh atau macet sehingga tidak ada pilihan lain. Toko pengembangan perangkat lunak yang dijalankan dengan baik akan melihat kode Anda yang tidak jelas dan dokumentasi yang hilang dan hanya memecat Anda sebelum Anda dapat melakukan banyak kerusakan. Jika mereka berjalan dengan buruk, atau tidak dapat membuat pengembang lain bekerja untuk mereka, mengapa Anda ingin memiliki sinecure dengan mereka?

PS Baik Tn. Greene maupun Machiavelli sebenarnya tidak banyak berhasil selain menulis buku yang mencoba menyanjung calon "pria tangguh" saat itu. Ikuti saran mereka dengan sebutir garam.

Jika Anda tidak tergantikan, Anda tidak dapat dipromosikan.

Anda tidak ingin tergantikan. Anda tidak ingin membuat orang lain merasa tergantung pada Anda, Anda ingin mereka menghargai Anda. Secara umum, Anda ingin tinggal jauh dari orang, yang percaya bahkan setengah dari hukum kekuasaan harus diterapkan pada hubungan (profesional atau pribadi).
Aturan-aturan ini adalah instruksi yang ditetapkan tentang bagaimana berhasil membangun situasi menang-kalah. Yang Anda inginkan, adalah situasi win-win .
Begitu orang mulai merasa, Anda mencoba mendorong mereka pada sisi yang kalah dari situasi menang-kalah, mereka akan melawan. Upaya membangun situasi menang-kalah sering berakhir dengan hasil kalah-kalah, karena Anda secara efektif menyia-nyiakan sumber daya untuk menempatkan pasangan Anda dalam posisi kalah, alih-alih menginvestasikannya untuk keseluruhan keberhasilan kemitraan Anda.

Jika Anda melakukan ini dengan majikan Anda, mereka akan mencoba untuk memaksakan tindakan pada Anda, untuk mengurangi monopoli pengetahuan Anda. Sebagian besar, ini akan menjadi pedoman konyol tentang bagaimana Anda harus melakukan pekerjaan Anda dan dengan demikian akan mengubah kehidupan kerja Anda menjadi neraka. Juga, mereka akan menelepon Anda pada jam 3 malam ketika sesuatu pecah, karena Anda adalah satu-satunya orang yang dapat memperbaikinya. Mencoba mengeksploitasi situasi seperti leverage akan menjadi bumerang dan menyebabkan Anda lebih banyak kesulitan.

Kuburan penuh dengan orang-orang yang sangat diperlukan.
- Gaulle, Charles De

Jadi potong omong kosong dan lakukan pekerjaan Anda dengan benar. Jika bukan karena hal lain, maka untuk Anda, karena Anda mungkin adalah jiwa yang miskin, yang harus membuat beberapa perubahan pada kode 2 tahun dari sekarang.

Tanggapan negatif tidak terlalu mengejutkan, mengingat jumlah programmer yang lebih baik dari rata-rata situs ini menarik. Orang-orang yang berbakat umumnya tidak perlu menggunakan taktik keamanan-melalui-kebingungan ini. Tetapi saya bekerja di pemasok otomotif Fortune 500 dengan beberapa pengembang yang tidak begitu berbakat yang telah mengukir sedikit demi sedikit untuk diri mereka sendiri, yang mereka jaga dengan penuh semangat dengan menciptakan sejumlah besar dokumentasi untuk antarmuka mengerikan yang telah mereka rancang.

Seluruh pekerjaan satu orang adalah menjaga kode untuk modul yang menjembatani dua subsistem yang sepenuhnya terpisah, memungkinkan modul pada setiap sistem untuk berkomunikasi melalui UART. Pada dasarnya, itu Serial Programming 101. Alih-alih hanya membuat antarmuka umum yang terlihat seperti ini:

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, data * tidak berlaku, size_t maxBytes);

dia membuat opcodes terpisah untuk setiap pesan yang mungkin ingin dikirim dua modul yang berkomunikasi kepada satu sama lain. Yang berarti modulnya perlu tahu tentang setiap pesan, dan perlu diperbarui setiap kali pesan ditambahkan atau diubah. Bicara tentang keintiman yang tidak pantas!

Masalahnya, orang ini menyimpan dokumen Word yang dengan rapi mencantumkan semua opcodes / pesan, dan dengan rajin memperbaruinya seperlunya. Itu menjadi seluruh pekerjaannya . Beberapa kali seminggu, dia mengirimkan revisi baru kepada semua orang yang kurang beruntung untuk membawanya ke jalur kritis mereka. Dan ini dipandang sebagai 'profesional', karena manajemen suka melihat dokumentasi. Agak membuat saya menangis untuk industri otomotif.

Saya kira maksud saya adalah: kadang-kadang menulis dokumentasi dapat, pada kenyataannya, melindungi programmer yang biasa - biasa saja. Manajer sering kali tidak dapat membedakan antara desain yang baik dan yang buruk, dan banyak yang terpaksa membuat keputusan teknis dengan informasi terbatas. Ini sangat menegangkan bagi mereka. Melihat dokumen Word dengan lusinan tabel yang diformat dengan rapi bisa sangat menghibur — bahkan jika yang dideskripsikan adalah ide yang pada dasarnya buruk.

Menjadi replacable, bukankah itu bertentangan dengan minat pengembang?

Aku benci membocorkannya padamu, tapi semua orang bisa diganti. Tentu, kadang-kadang mungkin sedikit tantangan untuk menggantikan Anda (jika Anda cukup berpengalaman dan cerdas), tapi itu tahun cahaya dari mustahil.

Cara untuk benar-benar menjadi komoditas berharga bagi atasan Anda (bukan hanya atasan saat ini, tetapi atasan mana pun ) adalah menunjukkan kemampuan untuk menulis kode yang mudah dibaca oleh siapa pun yang membaca kode (sedikit waktu tambahan untuk bekerja dengannya) dan mendokumentasikan kode (siapa pun bisa mendapatkan gambaran umum tingkat tinggi dari sistem Anda tanpa menggali ke dalam kode).

Sebenarnya mahir dalam dokumentasi kode adalah kualitas yang sulit didapat akhir-akhir ini, sehingga sendirian akan membantu membedakan Anda dari orang lain.

Kode yang bersih dan terdokumentasi dengan baik juga layak untuk dimasukkan ke dalam resume (setidaknya, hasil nyata dari itu, yaitu "kami dapat membawa npengembang baru dengan sedikit peningkatan dan bantuan karena dokumentasi saya), di mana dengan licik membuat diri Anda "tidak tergantikan" tidak.

Menjadi replacable, bukankah itu bertentangan dengan minat pengembang?

Tergantung apa kepentingan pengembang itu. Jika Anda adalah orang yang ingin bertahan dalam satu pekerjaan untuk seluruh karier Anda, jadilah sangat diperlukan bagi perusahaan yang menghargai ketidakmampuan dan menghasilkan uang yang baik maka ya, tentu saja.

Tetapi apa yang terjadi ketika perusahaan mogok, mungkin karena mereka mempekerjakan terlalu banyak orang seperti itu? Ke mana Anda akan pergi selanjutnya? Bagaimana ketika mereka bertanya mengapa Anda tetap berada di pekerjaan yang sama selama 15 tahun? Dan seterusnya.

Sekarang lihat dengan cara yang berbeda: Berapa banyak pengembang yang kehilangan pekerjaan karena menjadi seseorang yang menulis kode yang dapat dibaca siapa saja?

Satu-satunya kemungkinan hal itu terjadi adalah jika perusahaan dalam kesulitan dan membuat orang-orang menjadi berlebihan. Jika itu terjadi, Anda lebih baik keluar, dan Anda akan sangat siap untuk wawancara mendatang. Plus hati nurani Anda akan sepenuhnya gratis - Anda tidak akan meninggalkan kode yang tidak dapat dijelaskan yang Anda tulis untuk keuntungan diri sendiri.

Saya tidak tahu orang seperti apa Anda, tetapi itu melayani minat saya dengan lebih baik.

Secara pribadi, saya pikir salah satu kekuatan terbesar saya adalah dalam mengotomatisasi pekerjaan saya sendiri. Menurut Anda apa yang cenderung dipikirkan perusahaan ketika saya menjadi surplus dengan kebutuhan saya sendiri? Apakah mereka berpikir "baiklah, kita akan menyingkirkannya sekarang" atau apakah mereka berpikir "mengapa kita tidak memindahkannya ke peran lain dan membiarkan dia melakukannya lagi"?

Menjadi replacable, bukankah itu bertentangan dengan minat pengembang?

Anda benar, tetapi saya pikir Anda salah memahami makna yang bisa diganti. Saya dapat menemukan 1000 pengembang yang menulis kode sibuk, tidak berdokumen yang dapat dengan cepat berubah menjadi kekacauan yang tidak dapat dipelihara.

Seorang pengembang yang tidak hanya menghasilkan program yang stabil, tetapi juga kode bersih, dokumentasi informatif dan memastikan kelangsungan proyek, itu tidak hanya tak tergantikan, itu tak ternilai harganya .

Saya akan menjawab pertanyaan ini dari sudut pandang yang berbeda, karena sudah ada beberapa jawaban bagus.

Pertimbangkan apa yang terjadi ketika Anda bermain game kecil dengan mencoba membuat diri Anda "tak tergantikan" meskipun mencegah orang lain mempelajari cara kerja kode Anda. Anda tetap berada di pekerjaan yang sama menjaga kekacauan Anda sendiri selama perusahaan menoleransi Anda. Dan itu adalah skenario kasus terbaik, skenario terburuk adalah bahwa insinyur dan manajer yang lain, lebih berbakat, dan lebih etis di perusahaan Anda melihat halangan yang diterapkan oleh praktik buruk Anda pada perusahaan dan mereka memutuskan untuk melakukan sesuatu tentang hal itu: dengan memecat Anda dan menulis ulang semuanya dari awal. Sudah dilakukan. Sebenarnya, itu adalah hal yang cukup umum terjadi.

Sekarang pertimbangkan apa yang terjadi ketika Anda menulis kode yang baik dan dokumentasi yang baik. Anda membuat komponen atau sistem yang berfungsi dengan baik, yang setelah beberapa saat beroperasi, bug berfungsi dengan lancar dan sulit untuk dilihat. Dibutuhkan sedikit upaya untuk mempertahankannya. Anda kemudian dapat beralih ke proyek yang lebih besar dan lebih baik, dengan kemenangan yang solid di bawah ikat pinggang Anda. Orang-orang akan mengenali Anda karena telah melakukan pekerjaan dengan baik dan akan mulai menghargai pendapat Anda. Anda akan memiliki kemampuan untuk naik dalam rantai makanan dan membuat keputusan yang lebih bermakna, atau melakukan pekerjaan yang lebih penting dan berdampak besar, atau mengelola proyek di tingkat yang lebih tinggi. Karier Anda akan meningkat, Anda akan dipromosikan, Anda akan menghasilkan lebih banyak uang, Anda akan mendapatkan pengakuan dan persetujuan dari rekan-rekan Anda, Anda akan menambah lebih banyak dan lebih banyak keberhasilan dari proyek-proyek yang semakin banyak dan lebih penting dalam rekam jejak Anda.

Rute mana yang Anda pilih?

Jika Anda satu-satunya titik kegagalan, klien Anda (atau majikan) mungkin akan mencoba untuk menggantikan Anda; selalu ada titik di mana lebih murah untuk mengganti perangkat lunak daripada memeliharanya, tidak peduli betapa pentingnya kelihatannya. Ada alasan mengapa TI adalah salah satu profesi yang paling bisa di-outsource.

Di sisi lain, menjadi tergantikan memberi Anda beberapa manfaat tak ternilai:

• bisa berlibur
• tidak sedang dipanggil
• kebebasan untuk pergi dan bekerja pada proyek baru dan keluar

Jika Anda tidak menghabiskan 5 menit menulis beberapa dokumentasi cepat maka Anda akan menghabiskan satu jam membaca kembali dan menjelaskannya kepada orang-orang ketika mereka perlu menggunakan kode Anda.

Lebih buruk lagi mungkin menghabiskan waktu berhari-hari mencari pekerjaan baru karena bos Anda tahu Anda tidak menulis kode yang bisa dipertahankan.

Dokumentasi yang baik pada akhirnya akan usang dengan refactoring / evolusi, dan menjaganya agar tetap terbaru benar-benar memakan waktu.

Kode bersih + uji unit> dokumentasi yang sangat baik

Jawaban atas pertanyaan Anda adalah ya". Ya, Anda harus menulis dokumentasi yang baik dan kode bersih. Dengan sengaja melakukan sebaliknya menunjukkan kurangnya integritas, yang, sementara semakin lazim di dunia bisnis entah bagaimana tiba-tiba menjadi hal yang "baik".

Tidak ada yang tak tergantikan. Orang-orang yang membuat situasi di mana mereka pikir mereka cenderung untuk menemukan jalan yang sulit. Memproduksi co-dependency untuk diri sendiri kontraproduktif karena juga membatasi Anda, bukan hanya majikan Anda.

Salah satu tujuan utama perusahaan pengembang perangkat lunak adalah meningkatkan faktor Bus mereka

Premis palsu. Tujuan utama dari perusahaan pengembang perangkat lunak (setiap orang yang pernah bekerja dengan saya) adalah untuk menghasilkan perangkat lunak terbaik yang mereka bisa dan menghasilkan uang, tidak harus dalam urutan itu. Mengurangi "faktor bus" hanyalah salah satu cara untuk menghindari kehilangan uang.

Hukum 11 Belajarlah untuk membuat orang lain bergantung pada Anda.

Apa artinya itu bagimu?

Apakah Anda ingin orang-orang bergantung pada Anda karena Anda telah meremehkan mereka sedemikian rupa sehingga mereka hanya dapat bergerak maju dengan bantuan Anda? Atau apakah Anda ingin orang-orang bergantung pada Anda karena Anda cerdas dan berwawasan luas, dapat diandalkan, dapat dipercaya, dan dapat membantu orang lain melakukan pekerjaan mereka dengan lebih baik? Apakah Anda ingin membuat rekan kerja Anda terlihat buruk tanpa bantuan Anda, atau Anda ingin mereka menghargai Anda karena membuat mereka terlihat baik?

Ini panggilanmu.

(dengan asumsi kode produksi)

Saya cenderung melangkah lebih jauh. Saya telah menulis tentang membuat program "bukti idiot", tetapi saya tidak selalu memenuhi syarat itu: Saya menulis banyak kode yang tidak akan dilihat atau bekerja dengan orang lain (setidaknya, itulah harapan ketika ditulis). sayaadalah idiot yang saya coba pertahankan dari kasus itu. Ini adalah hal yang baik ketika program Anda mendeteksi masalah untuk Anda, dan masalahnya telah disederhanakan sehingga cukup jelas bahwa ada kesalahan, dan asalnya. Yang benar adalah, detail implementasi jelas ketika Anda menulis sebuah program (kecuali jika Anda mengimplementasikannya secara prematur), tetapi mereka harus diabstraksikan dan tahan kesalahan untuk klien (bahkan ketika lokalitas modul ada). Alasannya, program menjadi sangat kompleks. Terkadang Anda dapat memisahkan masalah, tetapi tidak setiap saat. Jika Anda menjaga komponen Anda sangat ketat, sederhana, dikemas dengan baik, dan bukti idiot, mereka cenderung untuk mengukur dengan baik dan sebagian besar cacat terdeteksi sebelum dikirim. Lebih mudah untuk digunakan kembali, dan Anda memiliki lebih banyak kepercayaan diri dan waktu yang lebih mudah menggunakan kembali program, Juga, program-program kompleks yang Anda tulis hanya menjadi lebih kompleks (bahkan untuk Anda) setelah beberapa waktu jauh dari program. Saat Anda membacanya dalam 6 bulan, dibutuhkan waktu yang tidak masuk akal untuk memahami dan men-debug dibandingkan dengan versi bukti idiot. Jika suatu komponen melakukan perubahan, ia bisa tidak terdeteksi untuk waktu yang lama. Programnya kompleks; Anda tidak dapat melarikan diri dari kenyataan itu, tetapi Anda dapat membuatnya menjadi bukti bodoh, yang akan membuat hidup Anda jauh lebih mudah ketika ada yang salah atau ketika harus digunakan kembali atau diubah. Oleh karena itu, pendekatan bukti idiot berarti bahwa perangkat lunak Anda dapat dipahami, digunakan kembali, atau dikelola oleh junior Anda atau orang-orang yang lebih baru di tim juga (bukan hanya orang yang sebaik / berpengalaman seperti Anda). Penggantian adalah masalah tersendiri: Jika orang suka bekerja dengan program Anda, Anda melakukan pekerjaan dengan baik - jangan Jangan khawatir tentang penggantian. Tentu, saya bisa membuat skenario di mana program yang tidak dapat dipahami dapat menyelamatkan pekerjaan Anda, tetapi menulis program yang baik yang dapat digunakan dan dipelihara orang lain jelas merupakan kejahatan yang lebih rendah (lihat tanggapan orang lain). Jika saya menemukan diri saya menulis sesuatu yang bukan bukti bodoh, saya mencoba memperbaikinya.

Terlepas dari skenario, di mana Anda memerlukan beberapa dokumentasi untuk diri Anda sendiri untuk melanjutkan proyek setelah 6 bulan jeda, tampaknya ada konflik kepentingan yang jelas antara pengembang dan perusahaan perangkat lunak.

Anda benar-benar tidak tahu apa yang Anda pikirkan beberapa saat ketika Anda meninjau kembali implementasi aktif. Ketika Anda benar - benar berpengalaman, maka masalahnya lebih sederhana karena Anda dapat lebih mengandalkan metodologi atau pendekatan yang Anda gunakan. Namun, itu juga mengasumsikan metodologi ini tidak berubah. Meskipun dokumentasinya mungkin lemah, Anda masih harus defensif dalam implementasi Anda (mis. Anda tahu lebih baik daripada lulus NULL dalam skenario ini - uji kondisi itu).

Jadi sebagai seorang programmer, sebaiknya Anda benar-benar menulis dokumentasi yang bagus dan kode yang mudah dibaca untuk semua orang; atau haruskah Anda menulis kode dan dokumentasi sedemikian rupa sehingga berfungsi dan Anda sendiri dapat memahaminya, tetapi orang lain mungkin kesulitan memahaminya?

Saya merekomendasikan pendekatan bukti idiot, yang bahkan lebih jelas dan lebih tahan kesalahan daripada pendekatan faktor bus. Tuliskan program dan dokumentasi Anda sehingga mudah dipahami oleh orang lain di luar proyek - ini juga baik untuk Anda. Melakukan hal itu akan meningkatkan nilai Anda kepada perusahaan dan tim Anda, mereka tidak akan mau menggantikan Anda.

Anda telah salah memahami permainan. Permainan ini bukan untuk terus melakukan hal-hal lama yang sama yang telah Anda lakukan sebelumnya, bertanggung jawab atas semua kode yang Anda tulis karena tidak ada orang lain yang mendapatkannya. Gim ini menyelesaikan proyek dan melanjutkan ke proyek berikutnya, meninggalkan kode yang mudah dipahami dan digunakan orang lain saat Anda tidak ada sehingga Anda dapat melakukan hal-hal baru dan mengambil tanggung jawab yang lebih banyak dan berbeda. Premis Anda hanya berfungsi jika Anda senang terjebak melakukan hal yang sama berulang kali tanpa kesempatan untuk belajar atau meningkatkan.

Saya juga akan menunjukkan bahwa jika Anda tidak memiliki kesempatan untuk melihat kode itu sangat sering, Anda juga akan kesulitan mencari tahu dalam enam bulan jika Anda mengaburkannya dengan sengaja.

Saya mendokumentasikan kode kecil apa yang saya tulis, bukan supaya orang lain bisa membacanya, tetapi supaya saya bisa membacanya dalam waktu 3 bulan! Ini tentang membuat perawatan lebih mudah. Jika Anda bertanggung jawab atas kode yang Anda tulis, dan Anda tidak dapat memperbaiki bug yang muncul kemudian, maka Anda akan ingin itu didokumentasikan dengan baik ... Cukup tidak relevan bagaimana Anda diganti jika Anda tidak dapat untuk melakukan pekerjaan Anda!

Setiap profesional komputer yang "tidak tergantikan" yang saya alami mengalami ketidakberuntungan diganti, sebagian besar karena mereka berusaha menyandera sumber daya majikan mereka. Ketika saya memiliki orang-orang yang melaporkan kepada saya bahwa waktu mereka adalah berharga untuk "membuang" dokumentasi, saya menggantinya sesegera mungkin.

Tampaknya jika seorang calon karyawan menganggap 48 undang-undang kekuasaan dapat diterima secara etis atau moral, maka Anda akan lebih baik tanpanya.

Jika Anda BENAR-BENAR ingin menjadi tak tergantikan (yang Anda mungkin ingin mempertimbangkan kembali setelah membaca semua jawaban ...) - mengapa berhenti dengan tidak mendokumentasikan kode?

Ada panduan yang sangat brilian tentang cara menulis kode yang tidak dapat dipelihara yang harus Anda baca: http://thc.org/root/phun/unmaintain.html

Nikmati! (Saya pasti melakukannya ...)