Я в стреляных воробьях разбираюсь не очень, но мне кажется, что стратегически более верно сначала найти новое место, а потом уже создавать бумажки на столе…
Автор говорит, что есть такое слово: «Н-Н-НАДА!», и когда оно звучит, то не имеет смысла созерцать свой пупок в ожидании наступления состояния просветления и моральной готовности пойти и наконец уже делать дело, а нужно оторвать пятую точку от дивана, пойти и сделать то, что нужно. И, говорит автор, магическим образом во втором случае вы получите свое ведро гормона счастья от того, что хорошо сделали свое дело, а вот в первом все будет строго наоборот, поскольку вдохновение с настроением так и не придут, а дело делать в итоге все равно придется.
У меня с чувством юмора все в порядке, но ничего смешного или забавного я в этом тексте не увидел. Это какой-то особенный юмор, наверное, доступный не многим.
Найдутся! В смысле — уже нашлись :) Пишите, пожалуйста, еще. Мавен — это инструмент, и им, как и любым инструментом, хочется «просто пользоваться» не затрачивая массу усилий на то что б понять, как же эту хреновину уже заставить работать и перейти к тем проблемам, из-за которых все тут собрались — собственно к программированию.
В условиях задачи было «поддерживать кучу тестов тоже напряжно», что подразумевает изменение поведения. Если эти сеттеры и геттеры начинают менять поведение, то на них и правда нужно писать тесты и это уже далеко не просто сеттеры и геттеры.
Если Сипуление коварно возвращает объекты ошибок, то не ваша ли задача скрыть это от вашего пользователя? Возьмите эти ошибки, превратите в нормальные исключения — пусть ваш API будет хорошим. Почему все остальные должны мучаться?
Я ж сказал «например». Может быть все, что угодно же. А «взять ошибки и превратить в нормальные исключения» — это хорошо, но мало что меняет. Беда остается на своем месте — во время написания теста по TDD ты не знаешь, что у тебя буквально тут же возникнет совершенно левая задача по конвертации ошибок в исключения, без реализации которой ты не сможешь приступить к той задаче, к которой хотел. Готово дело — сроки поплыли… :)
Если «поддерживать кучу тестов напряжно», то это значит, что они ломаются, иначе бы не напрягало. Если они ломаются, то значит вы изменили старое поведение на новое. А если вы изменили поведение, но не стали отражать этого в тестах, то в следующий раз сломаются уже не тесты (которых нет), а код на продакшене. Зачем это надо?
На месте Тима я бы трижды подумал — такой вот гений сбежит с проекта, а тем, кто останется его «магию» придется поддерживать…
Оператор «хрен знает», судя по виду :)
Или код — монолитное сильно связанное
говноговно…Вот до этого в заглавной статье и не дошли :)
Я ж сказал «например». Может быть все, что угодно же. А «взять ошибки и превратить в нормальные исключения» — это хорошо, но мало что меняет. Беда остается на своем месте — во время написания теста по TDD ты не знаешь, что у тебя буквально тут же возникнет совершенно левая задача по конвертации ошибок в исключения, без реализации которой ты не сможешь приступить к той задаче, к которой хотел. Готово дело — сроки поплыли… :)
А вот уволоку ка я это себе :)