Мне нравится подходы в которых происходит систематические улучшения. Даже если эти улучшения настолько маленькие, что по одному незаметны. Зато прогресс в целом меня мотивирует
Правило бойскаута именно об этом. Это философия, которая говорит о том, что каждый раз после твоих изменений кодовая база должна становиться лучше. Если каждый раз код будет становиться лучше, чище и читабельнее, то с проектом станет приятнее работать.
Но вот как-то не сложилось у меня с нравилось бойскаута, как и с другими общепризнанными практиками.
Я считаю, что во время реализации фичи, нужно сконцентрироваться именно на реализации этой фичи. Я всегда стараюсь сделать новый функционал максимально независимым от существующего функционала. А в идеале и новую фичу закрыть фиче тонком.
Мой опыт подсказывает, что незапланированный рефакторинг приведет к проблемам. Правя чужой код не всегда понятен весь контекст задач, в которой он выполнялся. А самое неприятное, что тебе может казаться, что ты понимаешь, но это не так. В таких условиях пропустить какой-то случай, и наплодить ошибок очень просто.
Так же такой подход противоречит правильной работе с системой контроля версий. В одном комитете должны быть атомарные изменения. В идеале один коммит (Или ветка, если так удобнее) - одна фича. Такой подход позволяет с одной стороны переиспользовать функционал если он еще не влит в основную ветку, а с другой стороны точно понимать, какого рода изменения были в фиче, и откатить ее.
Представь себе ситуацию, когда ты добавляешь код валидирующий форму на страницу, а попутно правишь роутинг приложения. Будет весело потом искать в каком комите приложение стало неправильно перенаправлять пользователя.
Тем не менее, я не считаю, что правило бойскаута совершенно неприменимо. Как я говорил выше такая философия очень близка мне. Просто оно не работает для больших интерплайзных приложений. В которых стабильность гораздо важнее скорости разработки фичи. Все большие приложения стараются не падать, поскольку каждое падение это потеря денег и аудитории. А вот в Стартапах, где скорость разработки это скорее вопрос выживаемости правило бойскаута может в недалеком будущем принести бенефиты;
Но даже в больших и устоявшихся приложениях, правило бойскаута можно применять. Только бойскаут должен быть не таким резким, и не должен сразу бросаться в бой. В таких приложениях все нужно делать через берлог.
Например я пилю фичу, и понимаю, что было бы неплохо отрефакторить текущий функционал, и вынести переиспользуемый код в отдельный модуль. Я делю сво фичу на две интерации. В первой итерации я пишу фичу без рефакторинга, возможно даже с дублированием кода. Зато это позволяет мне не трогать существующий функционал, а так же скрыть новую фичу под фиче тонком.
После чего завожу задачу на рефакторинг и кладу ее в беклог. Во время каждого спринта у меня есть время, когда я закрываю технический долги, именно тогда, я могу сделать код лучше.
В этом случае бизнес не получит рабочую фичу быстрее. Тестировщики будут иметь тест кейсы на старый и новый функционал и им будет проще тестировать техническую задачу на рефакторинг. Ну а я как пожилой и занудный бойскаут сделаю код лучше. А еще бывают ситуации, когда после релиза новой фичи становится очевидно, что она работе и не так, должна работать по-другому, или вовсе не нужна.
И тогда мне гораздо проще удалить сепарированный код, и не оставлять в коде ненужные абстракции.
Так еж у меня есть телеграм канал, буду рад твоей подписке
