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