Connect with us

Разработка

Григорий Петров: Управление разработкой. Двадцатая колонка

Не буду нарушать хорошую традицию, двадцатая статья также будет кратко пересказывать предыдущие девять и немного рассказывать о планах на будущее.

Опубликовано

/

     
     

Неожиданно прошел год, как мы вместе с Апптрактором начали публиковать этот цикл статей. Десятую статью я сделал обзорной, кратко рассказав о предыдущих девяти статьях. Не буду нарушать хорошую традицию, двадцатая статья также будет кратко пересказывать предыдущие девять и немного рассказывать о планах на будущее.

Первые девять статей были вводными: в них я поделился своим видением специфики нашей отрасли, рассказал о проблеме сложности, познакомил с кошельком Миллера и некоторыми другими зверушками. Дальнейшие статьи, о которых пойдет речь в этой колонке, описывали уже более интересные и сложные моменты. При этом я старался сделать каждую статью самодостаточной и не придерживался какой-то последовательности изложения: рассказывал и о проблемах с написанием кода, и о вопросах управления, и даже по психологии прошелся пару раз.

Колонка номер 11: Гибкие методологии

11

Agile — популярное слово. В этой статье я попробовал увязать такую популярность гибких методологий с уже описанной спецификой нашей отрасли. Популярность какого-то подхода редко когда бывает «просто так». В случае с разработкой, Agile позволяет работать с неопределенностью, возникающей из-за нулевой цены копирования, проблемы сложности и общей молодости нашей индустрии. Понимание этих взаимосвязей позволяет применять инструменты Agile, такие как итерации, строго по назначению. И не скатываться в cargo cult «мы пытаемся использовать scrum, потому что это круто».

Колонка номер 12: Формирование навыков

Григорий Петров: Управление разработкой. Двадцатая колонка

Кошелек Миллера — не приговор, а возможность. С которой можно и нужно работать. Да, наш мозг ограничен так же, как наше тело. Но наши физические ограничения не мешают нам летать, возводить километровые здания и запускать спутники на орбиту. Все что нужно — это правильные инструменты. Один из способов работы с кошельком Миллера — это формирование навыков. И разработчики активно пользуются этим способом, создавая универсальные фреймворки и библиотеки. Повысив мастерство владения готовым кодом, разработчик получает возможность фокусироваться на действительно важных вещах, быстрее читать код коллег и решать более сложные задачи. Плата за это — время на изучение и необходимость работать в рамках, диктуемых фреймворком или библиотекой.

Колонка номер 13: О магии в разработке

13

В этой статье я продолжаю тему предыдущей, рассказывая о балансе плюсов и минусов при использовании готовых фреймворков и библиотек командной разработчиков. Как однажды сказал писатель-фантаст и футуролог Артур Кларк: «Любая достаточно развитая технология неотличима от магии». Активно развивающиеся фреймворки и библиотеки постоянно усложняются, давая разработчикам возможность фокусироваться на прикладных задачах и описывать сложную логику в несколько строк «магического» кода. Платой за скорость является все большая зависимость от используемых инструментов, когда сделать что-то не предусмотренное авторами зачастую требует непропорционально много сил и времени.

Колонка номер 14: Страшный зверь Team Lead

14

Team Lead — специфическая роль. Это не прораб, не «руководитель отдела» и не старшина взвода. И даже не дирижер. Специфика нашей отрасли требует выполнения особых задач: чтение кода, принятие технических решений, управление рисками, обеспечение коммуникации технических задач и еще много всего нужного и неинтересного. Традиционно этой работой занимается отдельный человек, обладающий высокой компетенцией в разработке, но при этом все свое время тратящий на то, чтобы помочь команде быть единым целом. Должен ли Team Lead писать код? Мое мнение по этому и другим вопросам вы узнаете из этой статьи.

Колонка номер 15: О роли английского языка в разработке

15

Пожалуй, самая спорная статья за пол года. В ней я поднимаю очень больной и избитый вопрос — должен ли разработчик уметь хорошо читать по-английски. Специфика нашей области такова, что языки программирования и инструментарий создают единицы, а пользуются ими во всем мире. Английский — это естественный язык разработки. Умение бегло читать документацию, статьи и сообщения об ошибках необходимо для наиболее эффективной борьбы со сложностью. А еще в статье рассмотрен вопрос о языке комментариев, ответ на который не так очевиден, как кажется на первый взгляд.

Колонка номер 16: Приручение неизбежности

16

Самая, на мой взгляд, полезная статья в этом полугодии. В ней я рассказываю как работает один из методов управления: «построение коридоров». Это один из немногих случаев, когда специфика нашей отрасли не мешает, а помогает. При организации работы в команде программистов «коридоры» удобно строить, используя автоматизацию рабочего процесса. Идея «коридора» заключается в создании условий, при которых неправильно делать работу намного тяжелее, чем правильно. А следящая за этим автоматика, к примеру ночная сборка и тестирование продукта, мягко подталкивает разработчиков в нужную сторону.

Колонка номер 17: Зачем в коде комментарии

17

Комментирование исходного кода программ — еще одна спорная область. Многие разработчики считают комментарии излишними, мотивируя это тем, что код — сам себе комментарий. Другие не мыслят создание программы, в которой каждый метод не снабжен подробным описанием для благодарных читателей, которых никогда не будет. В этой статье я использую построенную ранее теоретическую базу, чтобы показать, как комментарии связаны со сложностью. Код действительно должен сам отвечать на все вопросы. Но там, где уже скопилось много сложности, на помощь приходят комментарии, отвечая на извечный вопрос code review: «зачем это?».

Колонка номер 18: Забудьте слово «ошибка»

18

Другой сложный вопрос при организации работы — это вопрос коммуникаций. Слишком часто я видел, как сильные команды проваливали перспективные проекты, просто потому, что не могли договориться друг с другом или с руководством. Вопросам переговоров посвящены тысячи книг и сотни курсов, поэтому я не стал пересказывать всем известные истины и сфокусировался на малоизвестных проблемах. В статья я рассматриваю коммуникационные проблемы с точки зрения физиологии нашего мозга и того, как работает лимбическая система. Несмотря на то, что это всего лишь гипотеза, сделанные на ее основе практические рекомендации неплохо работают и позволяют сделать общение между разработчиками чуть менее болезненным.

Колонка номер 19: Предварительная оптимизация: инкарнация зла

19

В последней колонке этого полугодия я снова возвращаюсь к коду и рассказываю про преждевременную оптимизацию. В эту увлекательную игру по предсказанию дефектов в коде любят играть многие программисты. Но не многие знают, что игра не совсем честная: из-за специфики нашей отрасли шансы победить не то чтобы очень велики. А вот возможности по потере времени и сил очень широкие. О причине, почему у разработчиков не получается предсказывать будущее, и что нам с этим делать — читайте в статье.

Что дальше?

В следующих колонках нас ожидают Scrum и автобилд, микроменеджмент и wiki а также картина, написанная по мотивам принципа программирования YAGNI. Подписывайтесь на обновления и оставайтесь с нами.

Так как я пишу эти статьи прежде всего для повышения собственной квалификации, то мне очень важно ваше мнение и те сложности, с которыми вы ежедневно сталкиваетесь при управлении разработкой. Пишите мне о ваших проблемах, и, возможно, в одной из следующих колонок я анонимно разберу именно ваш кейс.

Мой email: grigory.v.p@gmail.com

Facebook: http://facebook.com/grigoryvp

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: