Существуют ли в opensource-проекты с хорошей архитектурой?

Question

[trauus]

Хочу зарыться в какой-нибудь крупный opensource-проект с более-менее качественной архитектурой, чтобы увидеть, как на деле реализуются принципы SOLID, DRY, KISS, YAGNI и прочие. Особенно интересует сфера мобильной и десктопной разработки.

Начал с TelegramAndroid, т. к. сам пользуюсь им и было интересно, как реализованы те или иные фичи. Когда увидел ChatActivity.java на 30 тысяч строк кода, стало понятно, что это не то.

Как искать проекты с хорошей архитектурой? Как понять, что в том или ином проекте архитектурные решения хорошие?

Или может быть знаете конкретные проекты (на C#, Java) приложений и веб-сервисов, код и архитектуру которых можно считать более-менее качественными?

Comments

[Максим Федоров]

KISS/YAGNI учат делать проще, но не значит, что проекты будут простыми

В этом их суть, проекты могут быть настолько мощными и тяжелыми, что если не придерживаться разных подходов и принципов, то поддержка/развитие или даже создание проекта могут стать неподъемными

Answer 1

[DollyPapper]

Надо исходить из изначального посыла - что такое хорошая архитектура и надо различать понятия дизайн и архитектура. Архитектура это высокоуровневая концепция. Это вопрос какую БД выбрать, какой прокси сервер, определение нагрузки на приложение. Так же архитектура это то сколько и какие слои в вашем приложении будут. А вот SOLID это как раз про дизайн отдельных модулей и классов. Итак. Какие изначальные постулаты "хорошего дизайна"?

1. Понятность/читаемость кода
   
2. Слабая связанность и сильная связность (зацепление) отдельных модулей
   
3. Разделение компонентов по ответственностям
   
4. Возможность повторного использования компонентов
   
5. Надежность (вопрос устойчивости и корректности ПО)
   
   

Исходя из этих критериев и нужно рассматривать архитектуру приложения. Но вот так просто "с улицы" зайти в проект и понять хорошая там архитектура или плохая ИМХО нельзя. Если пресловутые принципы SOLID нарушаются в приложении, то может так и задумано? Мартин вот категорично говорит, что нельзя зависеть от конкретных реализаций. Если у вас в зависимостях есть конкретный класс, а не интерфейс, то это якобы плохой дизайн, вы нарушаете принцип SOLID. Так ли это важно и нужно? Да не особо. Если нет смысла зависеть от интерфейса, то не надо пихать его. В этом и заключается чуйка архитектора. Если он считает, что реализация меняться не будет, то не нужно усложнять код. Если он считает, что требования будут меняться и следственно реализация, то вероятно стоит защитить конкретный компонент и выделить интерфейс. Если класс на 30к строк это не значит, что там плохая архитектура. Кто-то скажет, что это вполне себе Domain Model паттерн, вместо Anemic Model и это хороший дизайн, кто-то скажет что нарушается SRP. Нет четких правил, тут именно что нужно понимать предметную область с которой работаешь и вырабатывать чуйку.

Answer 2

[mayton2019]

SOLID может на каком-то этапе противоречить например KISS. Например вы, как старший разработчик можете видеть "вперед" и прогнозировать потребность бизнеса в расширении какого-то функционала. И будете закладывать Open/Closed и прочие философии. А разработчик уровня Junior который неделю назад пришел на проект - этого не знает и будет писать "как чукча". Тоесть буквально то что надо сделать - тои напишет. И между вами может возникнуть спор как раз на тему SOLID против KISS. Но вы можете ошибаться в своём прогнозе потребности бизнеса. Или бизнес может передумать. В этом случае правда оказалась на стороне святой простоты (Santa simplicitas).

Как вы понимаете такие антагонизмы не могут быть удовлетворены аж никогда. Поэтому вы никогда не найдете проекты которые удовлетворяют ВСЕМ философиям которые перечислены в списке одновременно.

Answer 3

[Александр Скуснов]

Книга Александра Гранина "Функциональная архитектура"

Comments

[nozd up]

Книга же про Haskell. Понятно, что базовые принципы можно, наверное, перенести на целевой ЯП (C#, Java у сабжа), но по постановке вопроса также понятно, что это будет излишне сложно. Надо что-то попроще.

[Александр Скуснов]

Насколько я понял, ключевой момент Free Monads.

Answer 4

[GavriKos]

Когда увидел ChatActivity.java на 30 тысяч строк кода, стало понятно, что это не то.

Ни в одной парадигме не написано, что нельзя делать класс на 30 тысяч строк. Если по парадигме ему надо быть таким - значит он будет таким, и все.

Мой посыл в том, что парадигмы там могут быть, и это нормально, и критерий 30к строк никак с ними не связан

Comments

[mayton2019]

По моему Java не регламентирует ограничений на объем кода в исходном виде. Хотя существует
лимит в байтах на JVM метод. Там кажется 64килобайта в байткоде.

По поводу тех кейсов когда это приемлемо. В современном проекте бывает кодогенерация.
Это связано с техниками генераторов парсеров (Antlr, JavaCC), или SOAP реализаций.
В этом случае обычно генерируемый код помечается аннотацией
@Generated
и как-бы исключается из скоупа разработки. Грубо говоря, мы не желаем смотреть в код
написанный роботом. Мы доверяем этому коду. Но если надо вносить изменения - то меняем
соотв. исходник этой кодогенерации.

По поводу пределов восприятия для обычного модуля (класса) или метода (процедуры).
На лимит модуля кажется Никлаус Вирт ставил ограничение в 4000 строк. А по поводу
метода есть метрики Холстеда (Haltsted) которые буквально в виде числа выводят
сложность метода для человеческого восприятия. Тоесть я-бы исходил не из 30 тысяч
строк а из того насколько сложно (или не сложно) разбираться в этих строках человеку.