Я хочу улучшить свои навыки программирования, изучая известные проекты с открытым исходным кодом, но я нахожу, что легко потеряться, просто прыгнув в их исходный код.
Поэтому я решил прочитать их документацию об их дизайне или архитектуре (например, диаграммы UML), чтобы сначала получить общее представление об организации их кода. Однако, к моему удивлению, я не могу найти никакой архитектурной документации для крупных проектов с открытым исходным кодом, таких как Hibernate, Spring, ASP.NET MVC, Rails и т. Д.
Итак, я начал задаваться вопросом: как проект с открытым исходным кодом может быть успешным, если новички-разработчики не имеют документации по архитектуре / дизайну для чтения или если менеджер проекта только открыл исходный код, но закрыл свою документацию?
источник
Ответы:
Всегда предполагается, что вы знаете, что делаете, и имеете достаточно глубокое понимание того, что вы собираетесь (и ожидаете) увидеть.
Например, если вы посмотрите на PHP-код инфраструктуры Symfony, вы уже должны знать о внедрении зависимостей, событиях, шаблоне модель / представление / контроллер и т. Д.
Точно так же, если вы погрузитесь в код C ядра Linux, предполагается, что вы будете реально компетентны в модульности, сигналах, процессах, потоках и тому, что нет. От вас также ожидают, что у вас есть умение есть шестнадцатеричный код в течение всего дня и выкапывать гигантские лопаты через свалки керна.
Сопровождающие не будут сталкиваться с трудностями документирования архитектуры, потому что это просто материал. Иногда вы найдете схему того, что находится в дереве исходных текстов. Более типично, однако, способ, которым организовано дерево источника, делает вещи самоочевидными.
Короче говоря, если вам не хватает каких-либо навыков, которые, как ожидают сопровождающие, вы уже знаете, к тому времени, как вы заглянете в их код, вы, вероятно, будете копаться в материалах, значительно превышающих ваш уровень оплаты. Сначала ознакомьтесь с понятиями - что такое модель MVC? Что такое внедрение зависимостей? И т.д. Затем ныряйте.
источник
Большинство успешных проектов с открытым исходным кодом стали успешными, потому что, прежде всего, программа была впечатляющей или делала что-то, что другие программы не могли сделать в то время. Это не обязательно означает, что источник хорошо документирован, так как программисты, которые начали проект с самого начала, знают код достаточно хорошо, чтобы не нуждаться в нем. Это печальная реальность, что проекты с открытым исходным кодом не должны быть хорошо документированы. Это должна быть либо хорошая программа, либо посредственная, но хорошо документированная, чтобы программисты могли проявить к ней интерес.
источник
Поскольку разработчики открытого исходного кода, как правило, талантливы и также выбирают проект в своей области знаний, у них уже есть «документация» в их черепах. С небольшим преувеличением полная документация необходима, только если у вас нет ни одного из них: o)
Честно говоря, я не читаю «документацию», когда сталкиваюсь с неизвестной базой кода. Краткое введение, возможно, несколько концептуальных набросков и прямо в код! Эксперимент, попробуйте небольшие изменения. Работает отлично для хорошо разработанного кода. Если я сталкиваюсь с ужасной неразберихой, то лучший способ выучить их - это поэтапно провести рефакторинг, чтобы улучшить ясность (в идеале с помощью юнит-тестирования).
Дополнительной причиной могут быть простые органические корни этих проектов. Архитектура тогда является скорее развитым видением в сознании разработчиков, чем заявленной «документированной» сущностью.
источник
Причина, по которой таких документов часто не существует, довольно проста: программисты любят программировать, а не писать документацию. Особенно это касается проектов с открытым исходным кодом, которые разработчики часто вносят в свободное время.
В основном, написание документации не доставляет удовольствия. И если им не платят за это, кто хочет тратить свое свободное время, занимаясь чем-то неинтересным?
источник