Перфекционизм – стремление к идеалу. И это может быть как идеальный порядок в личных вещах, стремление к абсолютной чистоте или попытка создания идеального кода. Среди профессиональных разработчиков перфекционизм достаточно сильно распространен. При этом я не говорю о начинающих, работающих по принципу, херак-херак в продакшен, а об настоящих хардкорщиках, которые стремятся к созданию лучшего продукта.
Для начала мне придется расстроить всех перфекционистов – идеал не достижим. Как в коде, так и в жизни. Невозможно создать код, который будет одинаково легко читаться, быть легко расширяемым, высоко производительным, минималистичным и при этом быстро созданным. Всегда хотя бы один из пунктов будет страдать в угоду другим.
Поэтому первое что хочется сказать, это не нужно добиваться идеальных показателей во всем. Необходимо расставить приоритеты и обращать внимание на те пункты, которые важны больше других. Я понимаю, что это может быть сложно, но для этого и есть требования заказчика или руководства. Обсудите, что является приоритетным и сконцентрируйся именно на этих пунктах.
Несмотря на то, что многие ругают перфекционизм, но я считаю, что это на самом деле очень полезная привычка. Она позволяет создавать действительно качественные уникальные продукты, которые смотрятся значительно круче, чем аналогичные конкуренты. Главное – не углубляться в погоню за качеством слишком сильно.
Лучшим способом для самоконтроля является установка жестких временных рамок, после которых результат должен быть опубликован не зависимо от качества. Главное, чтобы выполнялись минимальные технические требования.
То есть, изначально необходимо уделить время на реализацию самой главной поставленной задачи, потому что каким бы красивым и оптимизированным ни был код, толка от него ноль, если он не делает то, что от него требуется. А значит, сначала реализуем минимальные функциональные возможности, а потом все оставшееся время можем благополучно посвятить подбору более оптимальных алгоритмов, улучшению читабельности кода, оптимизации производительности и так далее.
И это правило подойдет и тем, кто, наоборот, стремится сдать готовую задачу как, можно быстрее не заботясь о качестве. Не спеши, проанализируй свой код, потрать оставшееся время на его улучшение, а не перескакивай сразу на следующую задачу.
Большое спасибо за прочтение! Пожалуйста, поставь лайк и подпишись на канал, чтобы не пропустить свежие статьи. Этим ты очень поможешь развитию блога!
Также рекомендую прочитать статью Парное программирование. Плюсы и минусы
И не забывай про мою группу ВКонтакте, Telegram и YouTube. Там еще больше интересного и полезного контента для программистов.
