Comments 17
когда я слышу слово фабрика я хватаюсь за пистолет
фабрика фабрик
теперь я видел все
как это развидеть?
Приведённый код комментировать нет смысла - он плох.
Трактовка принципа SRP приведена неверно.
Однако темой поста было что то про спор разрабов на ревью... Тут все просто: при возникшем споре 2х разработчиков по предмету кода - надо позвать третьего, у кого большинство тот прав.
А где можно глянуть весь финальный код, чтобы сравнить как было и как стало?
Плохой код из примера по большей степени синтетический, был взят реальный кусок кода из одного из предыдущих проектов, обфусцирован (переменные, названия классов/методов, логика из следующих кейсов) и собственно этот кусок был переписан в ходе статьи (финальный результат)
Для дальнейших примеров и исследований работает данная практика всегда или нет, можно взять реальный код, который кажется плохим и нуждается в рефакторинге и попробовать переписать его под наименьшее количество тестов
Так где увидеть финальный результат?
Надеюсь я правильно понял запрос и данный гист то что нужно, в before.php - изначальный код, в файлах after_*.php - финальный результат
Скорее тут изначально не очень верный подход, и поэтому все пошло по одному месту.
Не понятно зачем вам такой плохой год метод нужен для создания всего?
Почему бы на месте не вызывать нужную фабрику?
Extractor чё, придется в каждую фабрику передавать? Зачем нужна фабрика эктракторов? для сахара - обернуть массив? Ну тогда new Extractor($params)
Почему бы параметры уже валидированными не подавать? А лучше вообще 2 конкретных типизированных параметра передать и разбирать данные уже слоем выше.
Далее у вас возникнет проблема data, который не понятно какой структуры - это массив?
Не понятно - это объект не существует или у него пустой data
Cтатья немного про другое, потому код и синтетический(оправдывать синтетику дело заманчивое, но пустое), вот вас назначили лидом в новую команду, вам прилетает похожий код, вы пишите мне все эти сообщения - я говорю: "A какой в этом смысл? все работает же, в бигтехе XXX так пишут и все работает отлично, и вообще, я не один такой проект закрыл, потому создавать бессмысленные абстракции не намерен", можем развести дискуссию на 100+ комментов в ревью, пока вам будет писать менеджер "Когда задача готова то будет? Леха говорит что уже вчера тебе на проверку отдал"
Если я лид, то я могу принять к сведению ваше мнение, задать пару уточняющих вопросов, после чего сам решу что дальше делать. Если делать не будете, то спор уже переходит а юридическую плоскость.
Бесспорно можете, особенно если сумеете избежать превращения уточняющих вопросов в холивар и восприятие ваших замечаний как дельных и нужных, а не показателем силы и придирок(все же работает!), так же как можете легко продать менеджменту необходимость покрытия кода тестами, а разработчикам увеличить цену на написание спагетти-кода и внесения в него правок, ввиду написания и правок тех же тестов
Если у человека не сдельная оплата, то что ему помешает по 100 раз переписывать один и тот же код ? Сиди да переписывай целыми днями, правь свой прошлый копи паст, почему нет ? Работа оплачиваеться, код пишеться, камиты пушаться.
По условиям задачи во времени на реализацию ограничений нет,но в жизни они есть. Это противоречие с жизнью неразрешимое.
Если люди пишут код каким то образом, то только потому что по другому не могут.потому что они так думают, если вы хотите получать от людей другой код, то вам надо перестроить их мышление. Для молодых перестроиться легко, они учаться им перестраивать еще не чего, а человеку с опытом ?
В жизни вы или принимаете человека с его недостатками или растаётесь, а научить писать по новому это большой труд и для вас и для человека, вы к этому готовы ? А человек готов ? Готов ли человек трудиться больше чем необходимо для решения задачи ?
Хотелось бы поблагодарить автора за авторскую статью с примерами кода.
Приятно натыкатся на хабре на что-то-то помимо копирайтерского треша и корявых переводов.
Добавить бы еще подстветку PHP-шного синтаксиса в во вставки кода.
Спасибо за статью!
Честно скажу, разбор всего кода не осилил. Но тезисно проблематика в первой части статьи интересна, и действительно, часто встречается в новых командах.
По моему опыту, полезно держать фокус на балансе скорость\качество, т.к. почти нигде не стоит задачи писать идеальный код. Исходя из этого можно использовать полезный подход от Джефа Безоса "I disagree but commit". Другими словами, когда возникает обсуждение, которое перетекает в академические споры, хороший техлид может поставить их на паузу и сказать что-то вроде: "ребята, это очень интересная дискуссия, но у нас нет цели писать идеальный код, так что давайте пока выберем вариант Х и будем двигаться дальше, а если увидим, что он приносит проблемы, то позже пересмотрим". Если правильно это подать, то люди, даже не согласные с выбранным подходом, согласятся ему следовать, просто потому что спорить можно бесконечно.
По поводу Unit tests и TDD - наверное, озвучу непопулярное мнение, но я стараюсь вообще отходить от юнит-тестов. По опыту они долги в написании, у них высокий maintenance cost, а ловят реально nasty проблемы они редко. Так что тут пришел к фразе одного умного человека:
Write tests. Not too many. Mostly integration.
Тесты писать нужно, но лучше на уровне абстракции повыше unit :-)
Улучшение кода без споров и цитирования известных практик