Подскажите, пожалуйста, кто какие подходы использует для изучения архитектуры Open Source проектов?
Есть, конечно, замечательная книга — The Architecture of Open Source Applications.
А как быть, если хочется разобраться, например, в архитектуре ClickHouse?
Принято публиковать исходники, но при этом далеко не всегда проект сопровождается архитектурным описанием.
Настоящему профессионалу достаточно исходников, чтобы разобраться в архитектуре?
Здравствуйте, _netrider_, Вы писали:
__>Подскажите, пожалуйста, кто какие подходы использует для изучения архитектуры Open Source проектов? __>Есть, конечно, замечательная книга — The Architecture of Open Source Applications. __>А как быть, если хочется разобраться, например, в архитектуре ClickHouse? __>Принято публиковать исходники, но при этом далеко не всегда проект сопровождается архитектурным описанием. __>Настоящему профессионалу достаточно исходников, чтобы разобраться в архитектуре?
Но если нужно понять архитектуру именно конкретного проекта, то ничего кроме собственно проектной документации не поможет разобраться без чтения кода, без экспериментов с ним и детального изучения ключевых мест.
Такое (отсутствие документации на огромный проект) случается, увы, не только в opensource...
Здравствуйте, A13x, Вы писали:
A>Такое (отсутствие документации на огромный проект) случается, увы, не только в opensource...
Да, и получается тогда, что все эти UML диаграммы классов, sequence diagrams и прочее — это все из области махрового enterprise, где есть разделение на роли архитектор — программист, на тех кто ставит задачи, пишет спецификации, и на тех, кто потом по этим спецификациям реализует. Для реальных проектов, где автор выдвигает идеи и сам же их реализует, в принципе, достаточно комментариев в коде и, собственно, хорошо написанного кода, хорошо спроектированных классов. Любому внешнему contributor, который будет подключаться к проекту и коммитить свой код также будет достаточно почитать код, чтобы разобраться в проекте.
Здравствуйте, _netrider_, Вы писали:
__>Да, и получается тогда, что все эти UML диаграммы классов, sequence diagrams и прочее — это все из области махрового enterprise, где есть разделение на роли архитектор — программист, на тех кто ставит задачи, пишет спецификации, и на тех, кто потом по этим спецификациям реализует.
UML и прочий буллшит был придуман в в начале 90-х когда было четкое деление на программистов и кодеров. Нормальных языков не было, абстракции дизайна были дремучими, а большие проекты все равно нужно было делать. 95% кода представляло собой тупую рутину, адаптивную кодогенерацуию тогда не умели, вот и придумали разделение труда: программисты придумывают, а кодеры кодируют.
__>Для реальных проектов, где автор выдвигает идеи и сам же их реализует, в принципе, достаточно комментариев в коде и, собственно, хорошо написанного кода, хорошо спроектированных классов. Любому внешнему contributor, который будет подключаться к проекту и коммитить свой код также будет достаточно почитать код, чтобы разобраться в проекте.
Недостаточно. Нужно быть в той же культуре что и разработчик. Если ты писал под винду, ты никогда не сможешь нормально контрибутить в линуковый проект и наоборот.
Здравствуйте, pestis, Вы писали:
P>Здравствуйте, _netrider_, Вы писали:
P>UML и прочий буллшит был придуман в в начале 90-х когда было четкое деление на программистов и кодеров. Нормальных языков не было, абстракции дизайна были дремучими, а большие проекты все равно нужно было делать. 95% кода представляло собой тупую рутину, адаптивную кодогенерацуию тогда не умели, вот и придумали разделение труда: программисты придумывают, а кодеры кодируют.
Лучше UML это просто клондайк для объяснения того как работает приложение. Только не надо использовать все сразу с максимальной детализацией. Разумный подход позволяет очень лаконично выразить те или иные тонкости работы.
Схемы только в прямоугольниках иногда раздражают, т.к. не всегда понятно что автор подразумевает под прямоугольником
Здравствуйте, diez_p, Вы писали:
P>>UML и прочий буллшит был придуман в в начале 90-х когда было четкое деление на программистов и кодеров. Нормальных языков не было, абстракции дизайна были дремучими, а большие проекты все равно нужно было делать. 95% кода представляло собой тупую рутину, адаптивную кодогенерацуию тогда не умели, вот и придумали разделение труда: программисты придумывают, а кодеры кодируют. _>Лучше UML это просто клондайк для объяснения того как работает приложение. Только не надо использовать все сразу с максимальной детализацией. Разумный подход позволяет очень лаконично выразить те или иные тонкости работы.
Можно пример? Куча же приложений в интернете... Сколько мне ни доводилось читать доки по всяким системам — UML видеть не доводилось. Вон, взять какого-нибудь монстра, куча схем, диаграмм, и никакого UML. И чем он может помочь?
_>Схемы только в прямоугольниках иногда раздражают, т.к. не всегда понятно что автор подразумевает под прямоугольником
Ещё хуже понимание, когда автор пытается вписать в UML-прямугольник то что он подразумевает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
