Привет, Хаброжители!

Начинающим программистам требуется нечто большее, чем навыки программирования. Столкнувшись с реальной работой, вы моментально понимаете, что самым нужным вещам, имеющим критическое значение для карьеры, не обучают ни в университетах, ни на курсах. Книга «README. Суровые реалии разработчиков» призвана восполнить этот пробел.
Познакомьтесь с важнейшими практиками инжиниринга, которым обучают разработчиков в ведущих компаниях.

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

Ключевые концепции и лучшие практики для начинающих разработчиков — то, чему вас не учили в университете!

Ревью кода

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

Ваша команда ожидает, что вы будете участвовать в проведении ревью кода (code review) и в качестве рецензента, и в качестве разработчика. При рецензировании кода у вас может проявиться синдром самозванца или эффект Даннинга — Крюгера (мы рассматривали их в главе 2). Вполне естественно, что при ревью кода вы можете испытывать как тревогу, так и самоуверенность, однако со всем можно справиться, если использовать нужные навыки и практики.

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

Зачем нужны ревью кода

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

Ревью кода используется в качестве учебного материала для обучения вашей команды. Вы можете узнать много нового из обратной связи, которую получите из ревью кода. Рецензенты могут посоветовать вам библиотеки и практики программирования, о которых вы еще не слышали. Вы также можете столкнуться с запросами на рецензирование кода от более опытных коллег и узнать больше о кодовой базе, а также научиться писать промышленный код (см. главу 4 с подробной информацией о написании кода для продакшена). Кроме того, участие в ревью кода — хороший способ познакомиться со стилем программирования вашей команды.

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

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

Ревью могут даже потребоваться для обеспечения безопасности и соответствия нормативным требованиям. Политика безопасности и соответствия нормативным требованиям предписывает выполнять ревью кода для предотвращения умышленного изменения кода отдельным программистом.

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

Принятие ревью кода

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

Подготовьте свой запрос на ревью

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

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

Рецензенты: agupta, csmith, jshu, ui-ux
Название: [UI-1343] Исправление исчезнувшей ссылки в шапке меню
Описание:

# Краткое содержание
В шапке меню отсутствует ссылка на раздел "О нас". При нажатии кнопки меню ничего не происходит. Исправлено путем добавления правильного атрибута href.
Для проверки изменений добавлено тестирование Selenium.

# Список
Этот запрос на включение изменений:
- [х] Добавил новые тестирования
- [] Изменил публичные API
- [] Включает дизайн-документ

В данном примере запроса на ревью используются популярные техники. В тексте упоминаются не только отдельные рецензенты, но и вся команда UI/UX. В названии указывается ошибка, которую нужно устранить (UI-1343). Использование соглашения о стандарте форматирования ссылок на проблемы позволяет интегрировать системы, которые автоматически связывают номера для отслеживания проблем с ревью кода. Это полезно при последующем обращении к старым проблемам.

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

Снижение рисков с помощью черновика ревью

Многим программистам лучше всего думается во время написания кода. Создание черновика — хороший способ продумать все изменения, не потратив при этом времени на написание тестов, изменение кода или добавление документации. Вы можете отправить черновик ревью (draft review) на проверку и узнать, есть ли у вас какие-либо недочеты или ошибки. В таком случае вы создаете запрос, после чего в короткий срок получаете обратную связь от членов команды. Данный способ не даст вам увязнуть в ошибках и спасет от лишней работы.

Во избежание путаницы указывайте в запросе тип работы: черновик кода или незавершенный (WIP) код. Многие команды обсуждают черновики, так что обычно перед названием кода указано DRAFT или WIP. Некоторые платформы для ревью кода имеют встроенную поддержку: например, у GitHub есть «черновой запрос на включение» (draft pull request). Как только станет понятно, что в вашем черновике не так много ошибок, вы сможете перевести его из состояния «черновик», завершив разработку, выполнив соответствующие тестирования и составив документацию, а также отшлифовав детали. Четко определите, когда ваш код готов к полноценному рецензированию, а затем подготовьте запрос на ревью, как описано в предыдущем разделе.

Не отправляйте ревью кода для запуска тестирования

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

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

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

Прогон больших изменений

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

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

Начните прогон с предыстории изменений. Иногда может потребоваться беглый обзор проектной документации. Затем выведите изображение на экран и в ходе повествования перемещайтесь по коду в интегрированной среде разработки. Лучше всего проводить демонстрацию с самого начала: от загрузки страницы, вызова API и запуска приложения — и до завершения выполнения. Расскажите об основных концепциях, лежащих в основе новых моделей, для чего они используются и как вписываются в приложение.

Не пытайтесь склонить коллег к тестированию кода прямо во время прогона: они должны приберечь свои комментарии для рецензирования. Прогон выполняется, чтобы члены команды поняли, для чего вносятся изменения, а также чтобы предложить участникам несколько моделей для тестирования кода.

Не ассоциируйте себя с кодом

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

Рецензенты могут попросить внести изменения, которые кажутся неважными или которые можно внести позже. Старайтесь сохранять непредвзятость и понимать причину появления замечаний. Здраво воспринимайте критику и будьте готовы менять код на основе полученной обратной связи.

Развивайте эмпатию, но не терпите грубости

Каждый человек общается по-своему, однако нельзя терпеть грубости. Всегда имейте в виду, что краткие и точные слова для одного человека могут быть грубыми и бестактными для другого. Относитесь к рецензентам с пониманием, но дайте им знать, если их комментарии кажутся необоснованными или грубыми. Когда дискуссия затягивается или становится бессмысленной, обсуждение с глазу на глаз может помочь прояснить ситуацию и прийти к решению. Если вам по каким-либо причинам будет неловко, обратитесь к своему руководителю.

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

Проявляйте инициативу

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

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

Выполнение ревью кода

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

Рассмотрение запроса на ревью

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

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

Выделите время для ревью

Рецензирование кода аналогично оперативной работе (подробнее в главе 9): объем и частота выполнения ревью непредсказуемы. Когда вы получаете новый запрос на ревью, не спешите бросать то, чем занимались до этого. Вы можете сильно снизить свою продуктивность, если отвлечетесь от основной задачи.

Выделите в своем графике время, когда будете заниматься только рецензированием кода. Так вы сможете спокойно сосредоточиться на основной работе. Это улучшит качество вашей обратной связи — вы не будете спешить и переживать, что нужно вернуться к незаконченным делам.

Для больших ревью кода может потребоваться дополнительное время. Если вы получили код, на проверку которого уйдет больше пары часов, сформируйте отдельную задачу для отслеживания анализа кода. Вместе с руководителем выделите время на планирование спринта (подробнее о гибкой разработке читайте в главе 12).

Вникайте в изменения

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

Понимание мотивации изменений поможет понять их смысл. Иногда в результате вы можете решить, что в изменениях нет никакого смысла. Сравнив код до и после внесения изменений, вы проверите правильность принятого решения, а также рассмотрите другие возможности для внесения изменений.

Давайте исчерпывающую обратную связь

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

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

Поразмышляйте о том, какие библиотеки и службы можно использовать для внесения изменений. Для поддержки кода предложите паттерны из главы 11. Ищите уязвимости из топ-10 по версии OWASP (https://owasp.org/www-project-top-ten/), например внедрение SQL-кода, утечку конфиденциальных данных и межсайтовый скриптинг.

Не будьте слишком резкими — пишите комментарии так, словно вы сидите рядом с разработчиком и объясняете ему все лично. Ваши комментарии должны быть вежливыми и содержать как «что», так и «почему».

Убедитесь, что значение `port` будет ≥ нулю, и увеличьте значение InvalidArgumentException, если условие не выполнено. Значение порта не может быть отрицательным.

Отмечайте положительные стороны

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

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

Разница между проблемами, предложениями и придирками

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

Не стесняйтесь отмечать огрехи форматирования, однако дайте понять, что это некритическое замечание. Обычно к такому комментарию добавляется префикс nit (от nitpick — «придирка»):

Nit: Двойной пробел
Nit: Здесь и далее используйте стили snake_case для методов и PascalCase для классов
Nit: Название метода лично мне кажется странным. Как насчет maybeRetry(int threshold)?

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

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

Помечайте предложения, которые кажутся вам полезными и которые не нужно утверждать. При написании комментариев добавьте пометки «необязательно» (optional), «принять или нет» (take it or leave it) или «неблокируемый» (nonblocking). Оформите отличия предложений от изменений, которые действительно хотите внести, иначе разработчику будет сложно разобраться.

Не штампуйте ревью

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

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

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

Не ограничивайте себя веб-инструментами рецензирования

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

Локальная проверка кода позволит вам рассмотреть предложенные изменения в вашей интегрированной среде разработки. Если вы сталкиваетесь с объемными изменениями, то работа в веб-интерфейсах может вызвать некоторые проблемы. Интегрированные среды разработки, а также инструменты анализа на базе ПК упрощают просмотр вносимых изменений.

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

Не забывайте выполнять ревью тестов

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

Обязательно проверьте чистоту кода, а также возможность будущих улучшений. Ищите неудачные фреймворки тестирования: неправильный порядок выполнения, недостаток изоляции или удаленные системные вызовы. Для знакомства с полным списком лучших практик тестирования и ошибок, на которые нужно обращать внимание, просмотрите главу 6.

Делайте выводы

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

Указывайте на важность качества кода, однако не делайте из этого критерия непреодолимый барьер. Это противоречие при просмотре списка изменений обсуждается в статье Engineering Practices Documentation от Google (https://google.github.io/eng-practices/) (для обозначения списка предлагаемых изменений в Google используют термин CL):

Если CL не идеален, но его текущий уровень наполненности изменениями способствует улучшению общего состояния кода системы, рецензентам стоит одобрить такой CL.

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

Вы можете завершить ревью, пометив его как «Запрос на изменения» (Request Changes) или «Одобрено» (Approved). Если у вас много комментариев, может понадобиться краткое резюме отчета. Если вы запрашиваете изменения, укажите, что именно следует изменить для одобрения. Например:

Изменения хорошие. Есть несколько недочетов, но у меня только одна просьба — исправьте работу с портами. Код кажется ненадежным. Подробности в комментариях.

Если вы и автор кода не можете прийти к единому мнению, обратитесь к третьему лицу — другому эксперту, который поможет разрешить ваши разногласия.

Повышение уровня

Code Review Developer Guide от Google по ссылке google.github.io/eng-practices/review представляет собой хороший пример корпоративной культуры ревью кода. Только помните, что это руководство написано пециально для Google. Терпимость вашей компании к рискам, инвестиции в автоматизированные проверки качества и выбор в качестве приоритета скорости или стабильности могут привести к другой культуре ревью.

В любом случае ревью кода — это особый вид предоставления и получения обратной связи. Книга Дугласа Стоуна и Шейлы Хин (Douglas Stone, Sheila Heen) Thanks for the Feedback: The Science and Art of Receiving Feedback Well (Penguin Books, 2014) — отличное пособие по тому, как стать хорошим рецензентом и разработчиком.

Об авторах

Крис Риккомини уже более десяти лет занимается разработкой программного обеспечения. За это время он успел поработать специалистом по анализу данных и инженером-программистом в таких крупных технологических компаниях, как PayPal, LinkedIn, WePay и JPMorgan Chase. Крис также активно участвует в создании программ с открытым исходным кодом, занимается стартап-инвестированием и консалтингом.

Дмитрий Рябой работает инженером-программистом с начала 2000-х годов. Сотрудничал со стартапами по разработке программных продуктов для организаций (Cloudera), интернет-компаниями (Ask.com, Twitter) и исследовательскими институтами (Национальная лаборатория им. Лоуренса в Беркли). Участвовал в создании нескольких проектов с открытым исходным кодом, в том числе Apache Parquet. В настоящее время является вице-президентом по разработке программного обеспечения в компании Zymergen.

Более подробно с книгой можно ознакомиться на сайте издательства:
» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — README