Комментарии 9
Меня так смешат эти картинки. Ага собираются директор по продукту, разработчик, ещё какой нибудь скрам мастер, и обсуждают, как переменная решит все наши проблемы. Её можно использовать для сохранения объекта в поле данных! Как круто и замечательно. Я утрирую ну тут чуть сложнее, давайте создадим функцию которая решит все наши проблемы у которой будут разные поля, в которые можно передавать константы, а так же строковые поля, числовые и это функция будет решать нашу супер важную бизнес задачу!
Это кринжово смотрится потому что обычно джун должен решить эту задачу максимум за пару часов, ну совсем в тормозной и большой организации за сутки, выложить код с готовым алгоритмом иначе его выпрут на следующий день. И никакой владелец продукта не будет обсуждать такую задачу уровня джуна.
Самое смешное, что часто так в жизни и бывает. Не раз видел. Только там ещё и этот самый джун пытается доказать что старый код — это именно то как надо писать.
А мне вообще нравится такой подход, разбирать каждую мелочь. Многие скажут слишком много воды, но когда что то непонятно хочется чтобы разобрали тему как можно подробнее. Я заметил, что в основном в переводной английской литературе это почти всегда так. Всё разжёвывают. Да, воды много зато максмимально понятно, главное терпение всё прочитать.
И да, некоторые алгоритмы бывают не просты, и написать алгоритм или связку из нескольких абстракций, чтобы это всё работало, бывает не проще, чем понять как приложение работает целиком, как взаимодействуют разные слои приложения. Сложность зависит лишь от числа этих слоёв абстракций. Допустим я смотрел как делать сложные высоконагруженные приложения и кроме пары не известных мне фреймворков я понял абсолютно всё что говорил спикер, как делать разные инстансы, разворачивать их, высоконагруженные сервисы и так далее. Это не сложнее чем написать замысловатую функцию.
Джун не должен доказывать что старый код лучше, он может лишь предположить вывести гипотезу почему старый код лучше, чем то что предлагают коллеги, либо согласиться с ними.
На моих глазах женщина - топ менеджер, уже почтенного возраста, вообще не айтишница, на совещании придумывала архитектуру БД, на ходу выдумывая какие там будут поля и таблицы, как они будут заполняться, по какой логике (очень кстати замороченой логике), и что эти поля в каком случае значат. А все, зная её нрав только кивали и соглашались, не смея ей возразить. Когда она примерно через час закончила, все вздохнули, сфотографировали ее записи, и пошли воплощать в продакшн.
Хмм... А вы сейчас точно про энтерпрайз? Просто у нас в банке на такую задачу пару митингов с владельцем продукта, аджай покер с командой и занесение в бэклог. И не факт, что в ближайший спринт попадет. )))
.
Раньше клиенту надо было знать четыре функции, а после рефакторинга надо знать столько же полей (внутренней реализации) + название одной функции + оказалось, что с использованием строковых аргументов ещё и безопасность может быть нарушена, о чем в книге расскажут позже.
Мне кажется, с такими примерами надо быть поосторожнее. Одно дело сделать обобщенную функцию внутри, другое дело открывать такой метод наружу. Нет, когда-нибудь и где-нибудь вполне можно. Просто осторожно.
Иначе говоря, — не надо начинать срочно рефакторить код, создавая обобщенные методы.
Раз уж отсылаются к мастеру, то прям просится другая цитата оттуда:
“А сегодня я нашел два способа завязывать шнурки, один хорошо чтобы ходить, другой - что бы падать”
Старый код, конечно, попахивал, после рефакторинга - завонял. Раньше логика зависимая от строковой константы была хотя бы стыдливо спрятана в API, а теперь торчит наружу, поджидая неосторожного джуна или что еще хуже - клиента, чтобы тот выстрелил себе в ногу. И главное что статическим анализом кода такое уже не поймать, только дебаг, только хардкор, причем обязательно с заходом в функцию, чтобы понять чеж там происходит. “SOLID? Never heard about…”
Больше, понимаешь, книжек, хороших и разных.
Я всё понимаю, абстракции-шмабстракции. Но нормально работать с кодом, в котором вместо всех object.setPrice(x) написано object.set_prop('price', x), можно будет только когда синтаксический анализатор будет такое считать эквивалентным и находить, а пока - нет. Хуже бывает только ещё object.set_prop(to_lower('PRICE'), x)
Книга «Грокаем функциональное мышление»