Принцып SRP самый простой и в тоже время самый сложный. Ошибка думать что он применим только к классу. Этот принцып применим вообще ко всему: сервис/программа, модуль, пакет, класс, метод, блок кода.
SRP+сервис = микросервисная архитектура
SRP+модуль = новые микро-модули (примеры: организация модулей в jackson, spring, etc)
SRP+код фильтрации коллекций = guava
p.s. как по мне это основа без которой сделать что-то более менее адекватное невозможно. (IMHO): все последующие принципы вытекают из данного (ISP — по факту говорит о SRP для интерфейсов), за редким исключением
скорее за все ответ "так сложилось исторически", обычно зависит от важности награды если это реал (или "коины" покупаемые за реал) то лучше в СУБД если "фантики" из вакуума то можно где угодно
Нет. Стероиды отключают иммунный ответ клеток, то есть убирают аллергию, воспаление. Но при этом иммунитет не работает, что может привести к инфекционным осложнениям и атрофии кожи (при длительном применении).
Это было неудачное сравнение, т.к. я не имел в виду «стероиды» в прямом значении этого слова. Задам вопрос по другому: у не посвященного человека, после прочтения статьи сложилось мнение что этот препарат, — панацея. Который можно использовать для ускорения заживления/восстановления кожи. Если это так (хотя бы отчасти) то как вы думаете будет ли он помогать когда у человека рак кожи и другие «тяжелые» заболевания?
да, именно а еще есть смысл брать во внимание куда направлена камера (тот же принцип что используется для прорисовки графики). Конечно если есть возможность получать такие данные с клиента.
naming conventions были сформулированы для того чтоб упростить жизнь девелоперам, однако это не означает что слепое следование решит все проблемы. К тому же Sun часто сами их нарушали (на счет oracle не в курсе).
Использовать наименования классов в виде IXService, IXComponent, IXDao — очень удобно т.к. простая подстановка "*" вместо конкретного названия сущности позволяет вам найти список всех компонент которые относятся к конкретному слою приложения. Необходимость в таком поиске часто возникает в долго играющих проэктах.
Откуда корни ростут… незнаю как у ТС а у меня из исходников java: префиксы Abstract, Base используются для маркировки абстрактных классов, однако в enterprise и так хватает длинных названий, поэтому намного удобнее использовать AXService вместо AbstractXService. А если можно для абстрактных классов то можно и для интерфейсов. В целом позволяет избавится от многих не всегда полезных приставок в названиях классов, если интерфейс называется AccountService скорее за все имплементация будет иметь имя: DefaultAccountService, AccountServiceImpl, RestAccountService или WebAccountService, которые полезной нагрузки практически не несут
p.s. сейчас не вспомню, но точно видел нейминг IInterface в какой-то достаточно популярной либе
Согласен со всем с автором кроме того что касается unit-testing. Если код низкого качества то обычно методы с бизнес логикой по 100+ строк в которых делается все и вся. Писать юнит тесты на такие методы не имеет смысла потому что вы банально не можете предсказать состояние системы после его выполнения: данных слишком много или результаты слишком разнообразны. Другая причина — вы банально не сможете покрыть все кейсы использования этого метода. Даже хороший код, который пишется на основе существующего кода низкого качества не получится сделать лучше в силу обстоятельств. Поэтому мой список действий по улучшению продукта:
-) terminology (Терминология должна быть общей для того чтоб избежать недопомниманий на любых этапах разработки, + документирование например на wiki. Терминология может отличаться от сервиса к сервису но должна иметь описание по которому можно было связать два разных сервиса)
-) naming conventions (название классов и методов должны дублировать общепринятую терминологию, пардон, java specific: а так же package naming)
-) database (практика показывает что качество data access layer в первую очередь зависит от структуры субд. Новые обьекты СУБД ссылаются на уже существующие и не позволяют сделать новые фичи — «хорошо», изменение существующей схемы можно делать кардинально или итеративно, желательно «per feature»)
-) presentation layer (PL) > business logic layer (BLL) > data access layer (DAL) (выделение 3х слоев в серверном приложении это один из важных шагов на пути к качественному коду: single responsibility. Написание качественного DAL невозможно без улучшения схемы СУБД, BLL без DAL, PL без BLL)
Только по коду:
-) code formatter (в идеале должен лежать в git вместе с кодом и подхватыватся IDE)
-) static code analysis (в идеале должен быть интегрирован в IDE. Developer должен думать о качестве кода во время разработки, что позволяет приобрести полезную привычку вместо надоедливых e-mail от CI&CD )
Заметка манагерам:
-) програмеры часто концентрируют все внимание на решении одной задачи (что является прямой противоположностью с менеджерской работой), поэтому им не только лень переключать внимание на что-то другое а еще и тяжелее (уровень концентрации выше), поэтому нужно сделать так чтоб они не тратили свое внимание и концентрацию на что-то другое. Девелоперы лажают с билдами? — Выделите время на автоматизацию процеса. Девелоперы лажают с деплойментом? Упростите процесс, сделайте билды более тонкими а деплойменты более частыми. Девелоперы плохо тестят фичи, баги? Выделите время на написание чего-то что поможет упроситить тестирование как для девелопера так и для qa
Принцып SRP самый простой и в тоже время самый сложный. Ошибка думать что он применим только к классу. Этот принцып применим вообще ко всему: сервис/программа, модуль, пакет, класс, метод, блок кода.
SRP+сервис = микросервисная архитектура
SRP+модуль = новые микро-модули (примеры: организация модулей в jackson, spring, etc)
SRP+код фильтрации коллекций = guava
p.s. как по мне это основа без которой сделать что-то более менее адекватное невозможно. (IMHO): все последующие принципы вытекают из данного (ISP — по факту говорит о SRP для интерфейсов), за редким исключением
скорее за все ответ "так сложилось исторически", обычно зависит от важности награды если это реал (или "коины" покупаемые за реал) то лучше в СУБД если "фантики" из вакуума то можно где угодно
Это было неудачное сравнение, т.к. я не имел в виду «стероиды» в прямом значении этого слова. Задам вопрос по другому: у не посвященного человека, после прочтения статьи сложилось мнение что этот препарат, — панацея. Который можно использовать для ускорения заживления/восстановления кожи. Если это так (хотя бы отчасти) то как вы думаете будет ли он помогать когда у человека рак кожи и другие «тяжелые» заболевания?
p.s. если что на хабре была статья о том что средний смартфон жрет в год больше энергии чем холодильник (из за частого заряда)
Использовать наименования классов в виде IXService, IXComponent, IXDao — очень удобно т.к. простая подстановка "*" вместо конкретного названия сущности позволяет вам найти список всех компонент которые относятся к конкретному слою приложения. Необходимость в таком поиске часто возникает в долго играющих проэктах.
Откуда корни ростут… незнаю как у ТС а у меня из исходников java: префиксы Abstract, Base используются для маркировки абстрактных классов, однако в enterprise и так хватает длинных названий, поэтому намного удобнее использовать AXService вместо AbstractXService. А если можно для абстрактных классов то можно и для интерфейсов. В целом позволяет избавится от многих не всегда полезных приставок в названиях классов, если интерфейс называется AccountService скорее за все имплементация будет иметь имя: DefaultAccountService, AccountServiceImpl, RestAccountService или WebAccountService, которые полезной нагрузки практически не несут
p.s. сейчас не вспомню, но точно видел нейминг IInterface в какой-то достаточно популярной либе
-) terminology (Терминология должна быть общей для того чтоб избежать недопомниманий на любых этапах разработки, + документирование например на wiki. Терминология может отличаться от сервиса к сервису но должна иметь описание по которому можно было связать два разных сервиса)
-) naming conventions (название классов и методов должны дублировать общепринятую терминологию, пардон, java specific: а так же package naming)
-) database (практика показывает что качество data access layer в первую очередь зависит от структуры субд. Новые обьекты СУБД ссылаются на уже существующие и не позволяют сделать новые фичи — «хорошо», изменение существующей схемы можно делать кардинально или итеративно, желательно «per feature»)
-) presentation layer (PL) > business logic layer (BLL) > data access layer (DAL) (выделение 3х слоев в серверном приложении это один из важных шагов на пути к качественному коду: single responsibility. Написание качественного DAL невозможно без улучшения схемы СУБД, BLL без DAL, PL без BLL)
Только по коду:
-) code formatter (в идеале должен лежать в git вместе с кодом и подхватыватся IDE)
-) static code analysis (в идеале должен быть интегрирован в IDE. Developer должен думать о качестве кода во время разработки, что позволяет приобрести полезную привычку вместо надоедливых e-mail от CI&CD )
Заметка манагерам:
-) програмеры часто концентрируют все внимание на решении одной задачи (что является прямой противоположностью с менеджерской работой), поэтому им не только лень переключать внимание на что-то другое а еще и тяжелее (уровень концентрации выше), поэтому нужно сделать так чтоб они не тратили свое внимание и концентрацию на что-то другое. Девелоперы лажают с билдами? — Выделите время на автоматизацию процеса. Девелоперы лажают с деплойментом? Упростите процесс, сделайте билды более тонкими а деплойменты более частыми. Девелоперы плохо тестят фичи, баги? Выделите время на написание чего-то что поможет упроситить тестирование как для девелопера так и для qa