В одном из проектов год назад перед коллегой встала задача: построить сложный график операторов. Нужно было объединить кучу данных: расписания, отдых, отгулы и все это наложить друг на друга и вывести в некоторый массив данных и выводить в API для отрисовки в UI.

Программист, который работал над этим, был немного слабоват в ООП, в сложных абстракциях, но был довольно опытным. Он по пути наименьшего сопротивления создал кучу процедур в виде статических методов и работал с простыми программными сущностями: простые какие-то объекты с данными, их массивами.

На ревью пришел я (ваш слуга) и мой тим-лид. Не держа во главе простоту и сложнсоть в целом, мы строчка за строчкой заставляли писать его все больше новых абстракций, городить сложные Value objects, наслаивать типизированные коллекции (в языке PHP нет дженериков, но если бы и были — они слегка бы уменьшили число кода и сильно лучше бы не стало), начали заставлять его слоить решение на слои (инфраструктура, бизнесуха).

Итог: решение только в малой мере стало низкосвязанным от имеющих сущностей, но внутри это стало огромным франкенштейном со сложными связями и наслоенными абстракциями. Хотя в целом работа была над чистыми данными — нужен был простой код.

К сожалению, программист не стал отстаивать свое решение, я понял проблему слишком поздно, а лид не понял. В итоге коллега делал все, что ему говорят и, испытывая дичайший стресс, городил слой за слоем. Мне стыдно, что простой код (пусть и якобы на статике) был лучше и проще, а заставили его городить сложный и непонятный. Процедурные задачи должны решаться процедурным подходом.

Хорошим итогом этого процесса было бы то, что программист стал бы защищать свое решение, но этого не было.