Açık kaynak projeleri, tasarımları veya mimarileri hakkında dokümantasyon olmadan nasıl başarılı olabilir?

Ünlü açık kaynaklı projeleri inceleyerek programlama becerilerimi geliştirmek istiyorum, ancak kaynak kodlarına atlayarak kaybolmanın kolay olduğunu düşünüyorum.

Bu yüzden önce kodlarının organizasyonu hakkında genel bir fikir edinmek için tasarımları veya mimarileri (UML diyagramları gibi) hakkındaki belgelerini okumaya karar verdim. Ancak, sürpriz olarak, Hibernate, Spring, ASP.NET MVC, Rails, vb. Gibi büyük açık kaynaklı projeler için herhangi bir mimari belge bulamıyorum.

Bu yüzden merak etmeye başladım: Yeni gelen geliştiricilerin okuyacak mimari / tasarım belgeleri yoksa veya proje yöneticisi kaynak kodunu yeni açtı ancak belgelerini kapattıysa, açık kaynaklı bir proje nasıl başarılı olabilir?

Yeni gelen geliştiricinin okuyacak mimari / tasarım belgesi yoksa neden açık kaynaklı bir proje başarılı olabilir?

Her zaman ne yaptığınızı bildiğiniz ve ne göreceğinizi (ve görmeyi beklediğiniz) makul bir şekilde kavradığınız varsayımı varsayılır.

Örneğin, Symfony çerçevesinin PHP koduna bakarsanız, bağımlılık enjeksiyonu, olaylar, model / görünüm / denetleyici deseni vb. Hakkında bilgi sahibi olmanız beklenir.

Aynı şekilde, linux çekirdeğinin C koduna dalarsanız, varsayım, modülerlik, sinyaller, süreçler, iş parçacıkları ve neyin olmadığı konusunda gerçekçi bir şekilde yetkin olacağınızdır. Ayrıca, tüm gün onaltılık bir yemek yemeniz ve dev bir kürekle çekirdek döküntülerini kazmanız bekleniyor.

Koruyucular, mimariyi belgeleme zahmetinden geçmeyecekler, çünkü bu aslında bir şey. Bazen, kaynak ağacın içinde neyin yattığını gösteren bir taslak bulacaksınız. Daha tipik olarak, kaynak ağacın düzenlenme biçimi işleri açıklayıcı hale getirir.

Kısacası, bakıcıların kodlarına göz attığınız zaman bilmenizi bekleyecek becerilerden herhangi birine sahip değilseniz, muhtemelen ödeme derecenizin üzerinde olan şeyleri araştırıyorsunuzdur. Önce kavramları tanıyın - MVC modeli nedir? Bağımlılık enjeksiyonu nedir? Vb Sonra dalış.

En başarılı açık kaynak projeleri başarılı oldu, çünkü her şeyden önce, program etkileyiciydi veya o sırada başka bir programın yapamayacağı bir şey yaptı. Bu, kaynağın iyi belgelenmiş olduğu anlamına gelmez, çünkü projeye başlamak için başlayan programcılar kodu gerekmeyecek kadar iyi bilirler. Açık kaynaklı projelerin iyi belgelenmesi gerekmeyen talihsiz bir gerçektir. Ya iyi bir program ya da vasat bir program olmalı ama programcıların bu programa ilgisini ifade edebilecekleri iyi belgelenmelidir.

Açık kaynak geliştiricileri genellikle yetenekli oldukları ve uzmanlık alanlarında proje seçtikleri için, kafataslarında zaten "dokümantasyon" vardır. Az abartı ile, ancak bunlardan herhangi birine sahip değilseniz kapsamlı dokümantasyona ihtiyaç duyulur: o)

Dürüst olmak gerekirse, bilinmeyen kod temeli ile karşılaştığımda gerçekten "belgeleri" okumadım. Hızlı bir giriş, belki birkaç kavramsal eskiz ve doğrudan kod içine! Deneme yapın, küçük değişiklikleri deneyin. İyi tasarlanmış kod için mükemmel çalışır. Korkunç bir karmaşa ile karşılaşırsam, onları öğrenmenin en iyi yolu, netliği arttırmak için yavaş yavaş yeniden düzenleme yapmaktır (ideal olarak birim test yardımı ile).

Bunun bir başka nedeni de bu projelerin organik tasarım kökenleri olabilir. Mimarlık, daha sonra, geliştiricilerin zihninde belirtilen "belgelenmiş" varlıktan ziyade gelişmiş bir vizyondur.

Bu tür belgelerin sıklıkla bulunmamasının nedeni oldukça basittir: Programcılar dokümantasyon yazmak yerine programlamaktan hoşlanırlar. Özellikle geliştiricilerin serbest / boş zamanlarında sıklıkla katkıda bulunduğu açık kaynak projeleri ile.

Temel olarak, dokümantasyon yazmak eğlenceli değildir. Ve eğer bunun için ödeme almazlarsa, kim boş zamanlarını eğlenceli olmayan bir şey yaparak geçirmek ister?