M
Поэтому иногда заносят какие-то костыли, которые компилятор пропускает.
какие?
Size: a a a
2020 March 27
JC
Ну вот есть архитектура портов и адаптеров
JC
Типо есть у тебя бизнес логика, а вокруг нее БД, фронт и все вот это
M
так, допустим
JC
А потом хуяк, дедлайн и ты в класс бизнес логики хуяришь общение с БД, потому что надо быстро
JC
И да, есть UML диаграмма, и так нельзя... Но..
JC
Работает же кое-как, да?
JC
А потом этот разраб уволился и вообще уже забыли, зачем это надо, но не переделывают как надо, потому что вдруг сломается
M
ну ты же можешь так и сделать, а после дедлайна изменить структуру, какая разница? даже если у тебя в момент прикручивания базы будут ошибки и кто-то решит тебе помочь, ему не нужно будет в голове держать больше 2-3 классов, чем в самой бизнес-логике
JC
Ну вот проблема в том, что "после дедлайна" идет еще один дедлайн и так далее
M
может быть, что ты прав, но я думаю, что это можно было бы отнести к мелочам разработки, т.к. до этого проект твой успешно выполнялся с использованием инструментов
M
а еще, может быть, всё зависит от тайм-менеджмента
JC
Ну если б это были мелочи, все эти книги по SOLID, паттернам и прочему не писали
JC
И не спрашивали на собесах
M
да не, солид и паттерны это не просто структура проекта. тебе самому легче будет с этим работать
JC
Офк
JC
Но это работа на будущее
JC
А у нас всегда настоящее)
M
да нет, в любой момент времени это полезно. внезапно логика на объекте изменилась, решил ты запросы поменять, ты заходишь в свой класс SqlManager (условно), меняешь логику, закрываешь класс - профит
M
и всё, не трогаешь его больше, пока логика не поменяется