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


48

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?


41
Buku Greene cocok untuk para lalim dan antek-antek yang mencari bantuan di wilayah kekuasaan. Bukan filosofi moral yang baik untuk kerja tim. Untuk sedikitnya! [Perhatikan bahwa wikipedia mengkategorikan buku ini di bawah "sosiopati"]
Steven A. Lowe

27
Saya tidak akan pernah mempekerjakan Anda: D
deadalnix

37
Pemakaman penuh dengan orang-orang yang tak tergantikan.
Pekerjaan

20
Anda tidak pernah ingin menjadi tak tergantikan - bagaimana Anda mendapatkan promosi jika Anda tidak dapat diganti? Kecuali jika Anda benar-benar bahagia di mana Anda berada, selamanya, 'Faktor Bus' selalu penting.
Dave

11
"Buku ini berbagi elemen tematik dengan The Prince karya Niccolò Machiavelli dan telah dibandingkan dengan risalah klasik Sun-Tzu, The Art of War." Saya tidak berpikir saya ingin bekerja dengan siapa pun yang melihat tempat kerja mereka seperti politik Italia abad ke-16 atau ... perang Tiongkok kuno.
Cascabel

Jawaban:


110

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.


1
Sangat menarik bahwa ini diangkat sekarang, karena hanya beberapa hari yang lalu saya diberitahu betapa berharganya beberapa diagram yang saya buat dari salah satu proyek yang sedang saya kerjakan, untuk orang-orang yang kemungkinan tidak akan pernah sentuh kodenya. Itu, dan tentu saja memberi saya pandangan tingkat tinggi dari berbagai modul dan bagaimana mereka berinteraksi. Gambaran umum itu mungkin tidak terlalu dibutuhkan saat ini ketika saya memiliki semuanya dalam memori baru, tetapi hampir pasti akan membantu ketika saya meninjau kembali kode dalam waktu setahun ...
CVn

2
Beberapa orang yang menulis kode (buruk, dikaburkan) yang membuat mereka "tak tergantikan" di tempat kerja saya tidak lagi bekerja di sini. Pemrogram yang lebih baik melihat pekerjaan mereka selama ulasan kode atau memperbaiki hal-hal saat mereka sedang berlibur. Melihat "kualitas" dari pekerjaan mereka, dan mereka dikalengkan.
CaffGeek

44

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.


42

Jika Anda tidak tergantikan, Anda tidak dapat dipromosikan.


14
Lebih buruk, di beberapa tempat, jika Anda pernah menunjukkan bahwa Anda dapat mengambil kode orang lain yang tidak berfungsi dan membuatnya berfungsi, Anda tidak akan pernah lagi diizinkan untuk mengerjakan kode Anda sendiri, karena akan dianggap lebih murah untuk membiarkan orang lain kasar tumpukan mengepul besar, dan kemudian memiliki Anda membersihkan dan memoles kata tumpukan mengepul besar.
John R. Strohm

argumentasi terbaik yang pernah ada di topik
ZJR

2
Jawaban klasik memang.
Sarawut Positwinyu

@ JohnR.Strohm Bung !!!! Saya pernah ke sana dan itu terasa sangat buruk. Dengan menjadi insinyur yang lebih hati-hati, saya akan mengambil sedikit lebih banyak tugas. Jadi manajer mulai membiarkan orang lain menulis kode lusuh dengan cepat dan kemudian meminta saya membersihkannya dalam ulasan kode. Saya merasa benar-benar disalahgunakan karena peran itu menjadi relevansi saya dengan tim meskipun itu bukan yang saya inginkan. Tak perlu dikatakan, saya meninggalkan tim segera setelah saya menyadari hal ini.
davidXYZ

17

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.


Saya menemukan bahwa setiap kali saya mencoba membangun situasi "menang-menang", orang akan ingin menang dan tampil superior. Hampir seperti buku itu tentang cara kerja Mafia: jika Anda memperlakukan teman sebaya dengan setara, segera dia akan menganggap dia lebih unggul dari Anda. Ini bekerja pada desainer grafis yang baru keluar dari perguruan tinggi selama 3 tahun - semakin saya menghormatinya, semakin dia memperlakukan saya seperti kotoran. Dan sekarang saya terlihat lebih unggul pada awalnya, dan lebih banyak orang menghargai saya. Ini aneh. Tetapi tempat perbedaan harus memiliki budaya yang berbeda. Saya bekerja di startup lembah silikon cut-tenggorokan.
nopole

1
@ 動靜 能量: Ini terdengar seperti menang-kalah. Inti dari win-win bukanlah untuk bersikap baik kepada semua orang tanpa syarat. Jika Anda merasa seseorang memperlakukan Anda seperti kotoran, Anda harus mengatasinya secara terbuka, jelas, dan wajar. Dapat dengan mudah ditunjukkan, bahwa jika seseorang dalam tim Anda berperilaku seperti bajingan, itu tidak bermanfaat bagi kinerja tim secara keseluruhan.
back2dos

Apakah "kalah menang" merupakan situasi khusus dalam sistem "menang-menang" atau "menang-kalah"? Saya tidak dapat menemukan banyak info tentang itu ... tetapi perhatikan bahwa tidak semua hal di dunia ini dapat saling menguntungkan. Rekan kerja yang ingin menjadi direktur atau pemimpin tim pasti tidak akan menang-menang. Atau rekan kerja yang ingin tampil sebagai bintang super atau mendapatkan promosi, atau mendapatkan kenaikan gaji, atau melindungi gelar "arsitek" -nya, atau tidak dipecat sebelum tanggal vesting opsi saham 1 tahun, pasti tidak akan melihatnya sebagai "Menang-menang" ketika dia harus menurunkanmu. Sekarang saya bahkan tidak ingin masuk ke situasi "kalah menang" untuk memulai dengan ...
nopole

alasannya adalah, jika dia memperlakukan saya seperti tanah dulu, saya mungkin akan sedikit membencinya, dan itu tidak akan menjadi hubungan yang baik setelah itu. Jika saya tampil superior dan dia agak menghargai saya, maka hubungan itu bisa berlanjut lebih baik tanpa turun naik. Tapi benar, saya menemukan bahwa di lembah silikon tenggorokan, jika Anda "menerima" dan "toleran", Anda menjadi keset yang suka diinjak orang. Jadi pasti membalas dengan tepat atau memberi tahu dia ada konsekuensinya.
nopole

@ 動靜 能量: Silakan ikuti tautan di posting saya. Dalam kasus Anda, Anda harus secara terbuka menganjurkan menang-menang atau tidak ada kesepakatan. Seringkali segala macam interaksi berubah menjadi perkelahian, ketika sebenarnya menghabiskan waktu untuk membahas cara interaksi didekati akan menyelesaikan masalah. Ini sesederhana: "Saya lebih suka hubungan kita menjadi kolaborasi, daripada kompetisi dan bersedia membuat komitmen yang sesuai. Jika Anda tidak melihat itu sebagai pilihan, jujur ​​saja untuk memberi tahu saya sekarang. Jika Anda mencoba untuk menggunakan ini untuk mengakali saya, saya akan merobek bola Anda. " Meskipun Anda mungkin ingin mengulangi bit terakhir;)
back2dos

15

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.


Perspektif yang menarik.
scribu

Ini tidak hanya terbatas pada industri otomotif. Saya pikir organisasi besar mana pun, yang tidak berada di bidang perangkat lunak / teknologi itu sendiri tetapi mempekerjakan pengembang perangkat lunak (di antara Staf TI lainnya), akan menderita hal semacam ini pada tingkat yang lebih rendah atau lebih besar.
CraigTP

Saya percaya pada nilai dokumentasi, tetapi dokumentasi bukanlah yang melindungi pekerjaan orang ini. Dia hanya ada di sana karena manajemen yang tidak kompeten dan rasa puas diri. Sungguh mengherankan bahwa tidak ada yang menghabiskan 90 menit dari hari mereka untuk menulis memo yang berjudul: Bagaimana cara menyimpan jutaan dolar DAN membangun produk yang lebih baik. Mungkin ini adalah bagian dari alasan mengapa perusahaan seperti GM dan Chrysler menemukan diri mereka dalam lubang yang sangat dalam, sangat mahal.
Caleb

1
@ Caleb: Dalam organisasi besar mana pun, tidak ada perbuatan baik yang tidak dihukum. Adalah jauh lebih mudah untuk membiarkan orang lain menjadi wilayah kekuasaan mereka dan mengukir wilayah kekuasaan untuk diri Anda sendiri, jika Anda bisa.
Gilbert Le Blanc

3
@ Caleb: Kami keluar dari topik, tetapi saya dan orang lain seperti saya telah memutuskan untuk tidak melawan sifat manusia. Anda mungkin mencapai meritokrasi dalam kelompok teknologi informasi kecil (<20), tetapi begitu Anda melewati 100 atau lebih pengembang perangkat lunak, organisasi Anda akan menjadi penguasa, baik suka atau tidak.
Gilbert Le Blanc

14

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.


-1: Saya benci untuk menjelaskannya kepada Anda, tetapi semua orang bisa diganti. - Ya, tetapi beberapa orang lebih sulit untuk diganti daripada yang lain.
Jim G.

10

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"?


9

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 .


7

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?


4

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

-1: Jika Anda satu-satunya titik kegagalan, klien Anda (atau majikan) mungkin akan mencoba untuk menggantikan Anda; - Tidak dalam pengalaman saya. Silakan lihat jawaban @evadeflow.
Jim G.

3

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.


3

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


1
Sepakat. Saya tidak bisa memberi tahu Anda berapa banyak proyek yang telah saya kerjakan di mana semua orang di tim (termasuk saya) memutuskan bahwa kami akan "melakukannya dengan benar kali ini" dan menggunakan doxygen atau CppDoc untuk mendokumentasikan semuanya dan terus mengusahakannya. tanggal. Itu belum terjadi. Jadwalkan proyek seperti apa adanya, dokumen pasti akan keluar dari sinkronisasi sehubungan dengan kode, dan cakupan pengujian kami akan minimal atau tidak ada. Sekarang saya cenderung menatap anak panah pada siapa saja yang menyarankan menggunakan doxygen, dan meminta mereka untuk menunjukkan kepada saya tesnya terlebih dahulu. Dokumentasi untuk kode tanpa tes apa pun hanyalah paket kebohongan.
evadeflow

Ini agak penting - tes unit yang bagus adalah dokumentasi. Anda hanya menganjurkan berbagai kode bersih dan terdokumentasi tertentu, tidak mengatakan itu tidak boleh dilakukan.
Cascabel

2

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.


2

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.


1

(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.


1

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.


1

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.


0

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!


-1: Mengapa Anda tidak berusaha untuk mendokumentasikan kode sendiri? Bertentangan dengan, paling tidak, dokumentasi yang berlebihan, dan yang terburuk, dokumentasi yang akan menjadi usang dengan sangat cepat? Silakan lihat jawaban @xsAce.
Jim G.

0

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.


-1: Ketika saya memiliki orang-orang yang melapor kepada saya memberi tahu saya bahwa waktu mereka adalah berharga untuk "membuang" dokumentasi, saya menggantinya sesegera mungkin.
Jim G.

@ Jim G: Bagus. Saya akan berasumsi bahwa Anda menghabiskan waktu Anda adalah untuk membuang-buang dokumen yang berharga ...
John Percival Hackworth

0

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 ...)


Ada juga "Refuctoring" :)
CraigTP
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.