Перевод руководства Lyft по написанию тех спек

Это перевд статьи https://eng.lyft.com/awesome-tech-specs-86eea8e45bb9.

Рассмотрим следующие кошмарные сценарии. 

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

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

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

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

Сама идея технической спецификации может казаться противоречащей этике Кремниевой долины. Двигайтесь быстро - ломайте вещи - быстро итерируйте - будьте исполнителем. Зачем тратить время на написание, распространение и обновление технической спецификации, когда это время можно было бы потратить на ее реальное создание?

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

(Почти) Безбаговые релизы

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

Документация

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

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

Быстрая итерация

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

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

Прежде чем вы начнете писать - дайте вашей технической спецификации цель

Принцип Парето - что только 20% ввода обычно приводят к 80% вывода - количественно определяет то, что большинство людей интуитивно понимают: некоторые виды использования времени более эффективны, чем другие. То же правило применимо к написанию технических спецификаций. Рациональное использование вашего времени и усилий принесет вам большие дивиденды позже. Хорошо продуманная техническая спецификация - это инструмент, который работает от вашего имени, облегчая вашу работу и делая вашу функцию лучше. У него есть цель - например, улучшение внутрикомандной коммуникации или прогнозирование и решение проблем заинтересованных сторон. Техническая спецификация без цели? Это пустая трата времени.

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

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

Написание технической спецификации - ключевые разделы

Хотя каждая техническая спецификация выглядит по-разному, начиная с шаблона, вы можете использовать известные передовые практики. Здесь мы представим свободный шаблон для технических спецификаций, проходя через спецификацию для гипотетического проекта под названием Spot the Bot - Twitter-бот, который будет твитить милые картинки щенков.

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

Резюме

Это абстрактная часть вашей технической спецификации: кто/что/когда/где/почему вашего всего предложения, сделанного кратким.

Spot the bot - это твиттер-бот, который твитит картинки собак на предопределенных хронологических интервалах. Изображения собак получаются с помощью GET-запроса к Dog API.

Контекст

Контекстуализируйте свой проект: зачем его строить? Какова мотивация? Какие пользовательские проблемы вы пытаетесь решить? Какие предыдущие попытки, если таковые были, были предприняты для решения этой проблемы?

Мы стремимся расширить наш бренд в сегменте миллениалов. Spot the Bot будет ориентирован на аудиторию миллениалов, предоставляя мгновенный доступ к высококачественным, кураторски отобранным картинкам собак. Мы отличимся от конкурентов, предлагая картинки более высокого качества.

Цели

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

1. Увеличить нашу аудиторию в Twitter на 20% в течение следующих трех месяцев.

2. Получить 500 ретвитов на каждый твит в течение первого месяца.

3. Получить положительные отзывы от пользователей о качестве изображений.

Нефункциональные требования

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

1. Spot the Bot должен быть доступен 99,99% времени.

2. Spot the Bot должен поддерживать минимум 500 запросов в минуту.

3. Spot the Bot должен поддерживать английский, испанский, французский и немецкий языки.

Обзор дизайна

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

Spot the Bot будет работать на основе сервера, который будет делать GET-запросы к Dog API каждые 30 минут. Каждый запрос вернет изображение собаки, которое затем будет твитнуто на нашем аккаунте в Twitter.

Детали дизайна

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

1. Сервер будет написан на Python и будет использовать библиотеку Tweepy для взаимодействия с Twitter API.

2. Сервер будет делать GET-запросы к Dog API с использованием библиотеки requests.

3. Сервер будет запущен на AWS и будет использовать DynamoDB для хранения информации о каждом твите, чтобы избежать повторения изображений.

Тестирование

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

1. Мы напишем модульные тесты для каждой функции нашего сервера, используя библиотеку unittest.

2. Мы напишем интеграционные тесты, чтобы убедиться, что наш сервер правильно взаимодействует с Twitter API и Dog API.

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

Развертывание и мониторинг

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

1. Мы будем использовать AWS CodeDeploy для развертывания нашего сервера.

2. Мы будем использовать AWS CloudWatch для мониторинга ошибок и производительности нашего сервера.

3. Мы будем использовать AWS CodePipeline для автоматического обновления нашего сервера при каждом изменении кода.

Сроки и владелец

Укажите, кто будет владельцем этого проекта и когда он будет завершен. Это поможет управлять ожиданиями и обеспечит ответственность.

Владелец проекта: John Doe

Ожидаемая дата завершения: 1 июня 2023 года

Вывод

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

Разбираемся с эстимациями: как они могут сделать вашу команду разработки непобедимой

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

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

Существует несколько методик оценки задач в Agile, каждая из которых имеет свои преимущества и недостатки. Некоторые из наиболее популярных методик включают в себя покер планирования, метод T-shirt sizes, и метод бакетов. 

Покер планирования использует карточную систему для оценки сложности задач, в то время как метод T-shirt sizes использует размеры одежды (S, M, L, XL) для оценки сложности. Метод бакетов, с другой стороны, группирует задачи по их сложности.

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

Покер планирования

Покер планирования, также известный как Scrum покер, является одной из самых популярных методик оценки задач в Agile. Этот метод был разработан и популяризован в 2002 году Джеймсом Греннингом и с тех пор стал стандартом в индустрии.

Принцип работы

Основная идея покера планирования заключается в использовании колоды карт для оценки сложности задач. Каждый участник команды получает колоду карт, где каждая карта представляет определенное количество "очков" сложности. Обычно используются последовательные числа в геометрической прогрессии, например, 0, 1, 2, 3, 5, 8, 13, 21, и так далее, что позволяет учесть неопределенность и риск в более сложных задачах.

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

Преимущества и недостатки

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

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

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

Метод T-Shirt Sizes

Метод T-Shirt Sizes - это еще один популярный подход к оценке задач в Agile. Этот метод использует размеры одежды - S (Small), M (Medium), L (Large), и XL (Extra Large) - для оценки сложности задач.

Принцип работы

Вместо использования числовых значений, как в покере планирования, метод T-Shirt Sizes использует размеры одежды для оценки сложности задач. Это делает его более абстрактным и менее формальным, что может быть полезно для команд, которые предпочитают более гибкий подход к оценке.

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

Преимущества и недостатки

Одним из преимуществ метода T-Shirt Sizes является его простота и наглядность. Он легко понятен и не требует сложных расчетов или детального планирования.

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

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

Метод бакетов

Метод бакетов, также известный как метод бакетной сортировки, представляет собой еще один подход к оценке задач в Agile. Этот метод основан на группировке задач по их сложности.

Принцип работы

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

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

Преимущества и недостатки

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

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

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

Метод точных оценок

Метод точных оценок - это еще один подход к оценке задач в Agile. Этот метод основан на прямой оценке времени, необходимого для выполнения задачи.

Принцип работы

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

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

Преимущества и недостатки

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

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

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

Метод аналоговых оценок

Метод аналоговых оценок - это подход, используемый в Agile, который основан на сравнении новых задач с похожими задачами, которые команда уже реализовывала в прошлом.

Принцип работы

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

Преимущества и недостатки

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

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

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

Метод Affinity Estimation

Метод Affinity Estimation - это еще один подход к оценке задач в Agile, который особенно полезен при работе с большими объемами задач.

Принцип работы

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

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

Преимущества и недостатки

Одним из преимуществ метода Affinity Estimation является то, что он позволяет команде быстро оценить большое количество задач. Это делает его особенно полезным для начального планирования или для проектов с большим количеством неизвестных.

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

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

Метод Delphi

Метод Delphi - это еще один подход к оценке задач в Agile, который основан на анонимных оценках и итеративном процессе для достижения консенсуса.

Принцип работы

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

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

Преимущества и недостатки

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

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

В целом, метод Delphi - это мощный инструмент для оценки задач, который может быть особенно полезен для команд, которые ценят демократический подход и стремятся к справедливому учету мнений всех членов команды.

Покер планирования: Подробная инструкция

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

Шаг 1: Подготовка

Перед началом сессии покер планирования убедитесь, что у каждого участника есть колода карт покер планирования. Эти карты обычно представляют собой набор чисел, который используется для оценки сложности задачи. Обычно используются числа Фибоначчи (1, 2, 3, 5, 8, 13, 21 и т.д.), поскольку они отражают неопределенность и риск в более сложных задачах.

Шаг 2: Обсуждение задачи

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

Шаг 3: Оценка

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

Шаг 4: Показ карт

Когда все участники выбрали свои карты, они одновременно показывают их. Это помогает избежать влияния мнения одного участника на других.

Шаг 5: Обсуждение

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

Шаг 6: Повторная оценка

После обсуждения команда повторяет процесс оценки (шаги 3-5), пока не будет достигнуто согласие. Согласие означает, что все участники команды согласны с оценкой сложности задачи.

Шаг 7: Запись оценки

Когда согласие достигнуто, оценка записывается и используется для планирования и отслеживания работы.

Помните, что цель покер планирования - не достичь "правильной" оценки, а помочь команде достичь общего понимания задачи и ее сложности.

Метод	Преимущества	Недостатки
Покер планирования	Позволяет достичь консенсуса, учитывает мнение каждого участника команды	Может быть времязатратным, требует активного участия всех членов команды
T-Shirt Sizes	Простота и наглядность, не требует сложных расчетов	Менее точен, сложно перевести в конкретные временные рамки
Метод бакетов	Позволяет быстро оценить большое количество задач, полезен для больших проектов	Менее точен, может быть сложно согласовать оценки между членами команды
Точные оценки	Простота и прямолинейность, не требует сложных систем оценки	Может быть менее точным для больших или сложных задач, подвержен проблемам с недооценкой или переоценкой
Аналоговые оценки	Использует реальные данные из прошлого, помогает командам лучше понять и анализировать свою производительность	Зависит от наличия подходящих "аналоговых" задач, может быть неэффективным для новых типов задач
Affinity Estimation	Позволяет быстро оценить большое количество задач, полезен для больших проектов	Менее точен, может быть сложно согласовать оценки между членами команды
Метод Delphi	Позволяет учесть мнение каждого члена команды, избегает проблемы "громкого меньшинства"	Может быть времязатратным, требует строгого следования процессу

7 характеристик эффективного ревью кода

Проверка кода (ревью кода), иногда называемая коллегиальной проверкой, включает в себя систематическое изучение исходного кода коллегой-программистом. В прошлый раз я предложил свою точку зрения на важность Code Review. Но каковы основные характеристики эффективного код-ревью?

Полнота

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

Своевременность

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

Конструктивная реакция

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

Инклюзивность

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

Регулярность

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

Сосредоточьтесь на общей картине

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

Использование инструментов

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

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

Ключевая роль ревью кода в создании программного обеспечения

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

Обеспечение качества кода

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

Способствование сотрудничеству и обучению

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

Поддержание консистентности

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

Распространение знания

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

Снижение рисков

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

Содействие владению кодом

Code ownership - это концепция, когда отдельные разработчики или команды берут на себя ответственность за определенные части кодовой базы. Несмотря на то, что это полезно с точки зрения ответственности и компетентности, это может привести к формированию знаний в "бункере", или изолированных областей. Ревью кода разрушает эти "бункеры", гарантируя, что ни одна часть кодовой базы не "принадлежит" или не "понимается" только одним человеком. Это необходимо в таких ситуациях, как ротация команды или увольнение сотрудника.

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

За что отвечает Machine Translation Engineer?

Ранее я писал ролях в ML. Сегодня напишу о еще одной роли.

В разработке программного обеспечения существует множество разных ролей и специализаций по нескольким причинам:

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

2. Экспертиза и специализация: Каждая роль обычно требует определенных знаний, навыков и опыта. Разделение на разные роли позволяет людям развивать экспертизу и специализироваться в определенных областях, что способствует более высокому качеству и эффективности работы.

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

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

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

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

Роль Machine Translation Engineer включает следующие обязанности:

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

2. Техническая интеграция: Инженеры машинного перевода работают над интеграцией систем машинного перевода в различные платформы и приложения. Они создают API (Application Programming Interface) и разрабатывают программное обеспечение, которое позволяет другим системам использовать функции машинного перевода.

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

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

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

Роль Machine Translation Engineer требует глубоких знаний в области компьютерной лингвистики, машинного обучения, статистики и алгоритмов. Они также должны быть знакомы с различными языками и культурами, чтобы понимать особенности перевода между ними.

Что такое Staff Software Engineer?

В связи с постоянным поступлением предложений о предоставлении программистов в штат компании через LinkedIn, я считаю важным объяснить смысл роли Staff Software Engineer.

Роль Staff Software Engineer, или Ведущий Инженер-программист, обычно относится к позиции старшего уровня в команде разработчиков программного обеспечения. Эта роль отвечает за предоставление технического руководства и экспертизы, а также вклад в разработку и доставку программных продуктов или проектов. Хотя конкретные обязанности могут варьироваться в зависимости от организации и отрасли, вот несколько типичных ожиданий и отличий для роли Staff Software Engineer по сравнению с другими инженерными должностями.

Техническая экспертиза

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

Лидерство и наставничество

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

Принятие решений

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

Проектирование системы и архитектуры

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

Сотрудничество и коммуникация

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

Техническая инновация

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

Важно отметить, что конкретные обязанности и ожидания от Staff Software Engineer могут варьироваться в различных организациях. Объем и уровень сеньорности роли могут отличаться в зависимости от размера компании, отрасли и организационной структуры.

Data Analyst VS Data Scientist VS Data Engineer

Эти 3 роли во много пересекаются и не всегда очевидно как они связаны с Machine Learning и чем отличаются друг от друга?

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

Data Analyst - находит в данных новые ответы и смыслы, и доносит эти смыслы до бизнеса, визуализируя найденное (еще проще "делает правильные запросы к хранилищу данных" и "рисует графики").

Data Scientist - анализирует данные и моделирует системы использую статические методы и машинное обучение. Этот "парень" умеет в SQL, R, Python (еще проще "умеет machine learning").

Data Engineer - создает и поддерживает системы обработки данных больших и/или не структурированных данных. Это такой админ / devops, который умеет построить pipeline на правильных инструментах. Часто он делает возможной работу Data Analyst и Data Scientist, решая задачи по получению, обработке, очистке и нормализации, хранению данных, в виде пригодном для анализа.