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