Bagaimana proyek open source bisa berhasil tanpa dokumentasi tentang desain atau arsitekturnya?

Saya ingin meningkatkan keterampilan pemrograman saya dengan mempelajari proyek-proyek open source yang terkenal, tetapi saya merasa mudah tersesat hanya dengan melompat ke kode sumber mereka.

Jadi saya memutuskan untuk membaca dokumentasi mereka tentang desain atau arsitektur mereka (seperti diagram UML) untuk mendapatkan ide umum tentang organisasi kode mereka terlebih dahulu. Namun, yang mengejutkan saya, saya tidak dapat menemukan dokumentasi arsitektur untuk proyek open source besar seperti Hibernate, Spring, ASP.NET MVC, Rails, dll.

Jadi saya mulai bertanya-tanya: Bagaimana proyek open source dapat berhasil jika pengembang pendatang baru tidak memiliki dokumentasi arsitektur / desain untuk dibaca, atau jika manajer proyek hanya membuka kode sumber tetapi menutup dokumentasinya?

mengapa proyek open source dapat menjadi sukses jika pengembang pendatang baru tidak memiliki dokumen arsitektur / desain untuk dibaca?

Asumsinya selalu membuat Anda tahu apa yang Anda lakukan dan memiliki pemahaman yang cukup intim tentang apa yang akan Anda (dan harapkan) lihat.

Jika Anda melihat kode PHP kerangka kerja Symfony, misalnya, Anda diharapkan sudah tahu tentang injeksi dependensi, peristiwa, pola model / view / controller, dan sebagainya.

Demikian juga, jika Anda menyelami kode C dari kernel linux, asumsinya adalah bahwa Anda akan benar-benar kompeten dalam modularitas, sinyal, proses, utas dan apa yang tidak. Anda juga diharapkan memiliki bakat untuk makan heksadesimal sepanjang hari dan menggali melalui dump inti dengan sekop raksasa.

Pemelihara tidak akan melalui kesulitan mendokumentasikan arsitektur karena itu adalah hal yang sebenarnya. Kadang-kadang, Anda akan menemukan garis besar apa yang ada di mana di pohon sumber. Lebih khusus lagi, cara pohon sumber diatur membuat segala sesuatunya jelas.

Singkatnya, jika Anda tidak memiliki keterampilan yang diharapkan oleh pengelola Anda tahu pada saat Anda mengintip kode mereka, Anda mungkin menggali hal-hal yang jauh di atas nilai gaji Anda. Biasakan diri Anda dengan konsep-konsepnya dulu - Apa model MVC? Apa itu injeksi ketergantungan? Dll. Kemudian menyelam.

Sebagian besar proyek open source yang sukses menjadi sukses karena pertama dan terpenting, program itu mengesankan atau melakukan sesuatu yang tidak bisa dilakukan oleh program lain pada saat itu. Itu tidak berarti sumbernya terdokumentasi dengan baik, karena pemrogram yang memulai proyek untuk mulai mengetahui kode dengan cukup baik sehingga tidak membutuhkannya. Ini adalah kenyataan yang disayangkan bahwa proyek-proyek sumber terbuka tidak harus didokumentasikan dengan baik. Entah itu harus menjadi program yang baik atau menjadi program yang biasa-biasa saja tetapi didokumentasikan dengan baik untuk programmer untuk menyatakan minat di dalamnya.

Karena pengembang open source biasanya berbakat dan juga memilih proyek di bidang keahlian mereka, mereka sudah memiliki "dokumentasi" di dalam tengkorak mereka. Dengan sedikit berlebihan dokumentasi menyeluruh dibutuhkan hanya jika Anda tidak memilikinya: o)

Sejujurnya, saya tidak benar-benar membaca "dokumentasi" ketika menghadapi basis kode yang tidak dikenal. Pengantar cepat, mungkin beberapa sketsa konseptual dan langsung ke kode! Eksperimen, coba perubahan kecil. Bekerja dengan sempurna untuk kode yang dirancang dengan baik. Jika saya menghadapi kekacauan yang mengerikan, maka cara terbaik untuk mempelajarinya adalah dengan refactor sedikit demi sedikit untuk meningkatkan kejelasan (idealnya dengan bantuan unit-testing).

Alasan tambahan bisa menjadi akar desain organik polos dari proyek-proyek ini. Arsitektur kemudian berevolusi visi dalam pikiran pengembang daripada entitas "didokumentasikan".

Alasan mengapa dokumen seperti itu sering tidak ada cukup sederhana: Pemrogram suka memprogram, bukan menulis dokumentasi. Terutama dengan proyek sumber terbuka, yang sering disumbangkan pengembang selama waktu senggang / bebas.

Pada dasarnya, menulis dokumentasi tidak menyenangkan. Dan jika mereka tidak dibayar untuk itu, siapa yang mau menghabiskan waktu luang mereka melakukan sesuatu yang tidak menyenangkan?