Я думаю, все слышали про профессиональную деформацию, как в том анекдоте: "Заходит, забегает, запрыгивает, заползает тестировщик в бар..."
Не давно, я заметил другую, более тонкую профессиональную деформацию. Дело было так, я передал на тестирование какую-то фичу, которая как-то связано с бизнесс логикой, но ни как не связана со стилями.
Тестировщик мне скинул видео, в котором показал, что фича работает как и ожидалось, вот только, говорит иконки смотрятся в темной теме не очень.
На что я говорю, ну иконки то, никак не связаны с моей фичей, на что он согласился, просто отметил этот факт.
И вот тут кроется кардинальное различие в наших подходах в работе. Я во время работ стараюсь как можно сильнее сужать скоуп, чтобы не потерять фокуссировку на конкретных целях. Тестировщик же наоборот старается увидеть больше, поскольку только так можно увидеть неявные дефекты.
Оба этих подхода валидны для нашей работы. Программист должен соблюдать некоторые правила, чтобы не превратить задачу во что-то большое и неподъемное.
Во-первых, стоит избегать правок не связанных с текущей задачей. Да делать код чуть чище и понятнее чем он был до этого - это прекрасный подход, но "попутное" исправление может привести к появлению ошибок в коде, особенно если нет тестов, поскольку правится код, который выходит сейчас за контекст понимания.
Если увлечься "попутными" исправления, то можно в них погрязнуть, поскольку плохо код зачастую связан, и, исправив в одном месте, нужно будет поправить еще в десяти. В итоге, коммит разрастается, и если вдруг придется откатить бизнес функционал, откатится еще и твой рефакторинг.
Что можно сделать? Ну если я вижу плохой код в своем проекте, я ставлю специальный тег TODO, и периодически прохожу по этим заметками, и правлю их. Но в этот момент, я понимаю, что я буду заниматься только одной конкретной правкой, и это превращается в отдельную задачу на тех долг.
Во-вторых, преждевременная оптимизация. Я заметил обратную зависимость между читаемостью кода и его производительностью. В больших проектах я всегда жертвую производительностью в угоду читабельности, хотя на собеседованиях всегда некоторые компании (не будем показывать пальцем 🫵) ждут самых производительных решений.
В-третьих, всегда помнить, что самый хороший код - это ненаписанный код.
Но все хорошо в меру, если уходить в крайности, и не замечать очевидных проблем, если они не связаны с твоей текущей задачей, то можно сделать хорошо написанный, но неработающий проект.
А еще у меня есть телеграм канал, подписывайся и на него, будем видеться чаще!
Всем хорошего дня:)