Настольная книга тимлида разработки ПО. Книга тимлида разработки по Издательские решения
 Скачать 0.67 Mb.
|
|
Обеспечение наилучших условий труда и инструментов Выбор инструментов разработки Под инструментами понимается IDE, средства хранения кода и тест-кейсов, ведения задач, документации, деплоя, коммуникации и, конечно, встречи команды. Как выбрать инструменты, которыми команда будет пользоваться? Есть несколько критериев, влияющих на выбор: – Функциональность и надежность – Стоимость – Опыт компании и коллег – Удобство пользования и знания работы этого инструмента Достаточно часто возникают споры и негативные эмоции, связанные с выбором инстру- ментов разработки. Для того, чтобы избежать этих конфликтов, необходимо вовлекать сотруд- ников в процесс выбора и объяснять им его критерии. Выбор любого инструмента должен быть обоснованным поскольку такой выбор важен и бывает нетривиальным. Процесс под- бора инструментов может быть сложным и ёмким, а может быть простым, но это не отменяет потребность в аргументации своего решения. Стоимость – критерий, который бывает очень весомым. Стоимость часа разработчика достаточно высока, а фонд оплаты труда специалистов значительно превосходит расходы на лицензии IDE. Бизнес никак не может отказаться от фонда оплаты труда, но от дополни- тельных расходов более чем, потому что выживаемость любого бизнеса зависит от его умения экономить. Встает вопрос – какую пользу приносит приведенный инструмент и сопоставима ли она с расходами. Ответ не всегда очевиден и приходится затрачивать время на объяснение ценности того или иного инструмента представителям бизнеса. Конечный выбор может даже представлять неудобство для команды, но нести в себе существенную экономию для всей ком- пании. Разработка своих собственных инструментов (если речь идет о значительных затратах времени) должна оцениваться бизнесом как длительные вложения. В. Большаков. «Настольная книга тимлида разработки ПО» 78 Автоматизация процесса разработки Основная выгод от автоматизации процессов разработки: – Снижение затрат на разработку – Уменьшение времени выполнения задач – Улучшение качества разработки – Повышение прозрачности и управляемости процесса разработки – Уменьшение зависимости от сотрудников К автоматизации процессов разработки относятся: – Средства автоматизированного планирования и контроля задач – Статический анализ кода – Генераторы кода – Автоматизированное тестирование – Средства автоматизации деплоя – Скрипты диагностики – Скрипты резервного копирования и восстановления резервных копий – Средства управления инфраструктурой Для автоматизации процессов разработки применяются инструменты, выбор которых описан выше. Не рекомендуется автоматизировать процессы, если они еще не эксплуатировались или находятся в состоянии отладки. Это значит, что новый процесс, который еще может изме- ниться, лучше несколько циклов выполнять вручную, пока не зафиксируется его стабильная версия. В. Большаков. «Настольная книга тимлида разработки ПО» 79 Управление продуктом Жизненный цикл продукта (цели, стратегия, дорожная карта) Любой продукт – это автоматизация бизнес-процессов. Каждый бизнес-процесс пресле- дуют определенную цель, а их набор в продукте создает определенную ценность для бизнеса. То есть продукт (информационная система) имеет конкретную ценность и целью его (продукта) создания является получение этой ценности. Жизненные стадии продукта это: – исследование; – планирование; – проектирование; – изготовление; – тестирование; – публикация. При этом стадии не пересекаются в рамках одной версии продукта: Продукт может быть: – Описан – Спроектирован – Разработан – Эксплуатируется – Архивирован Стратегия создания продукта может отталкиваться от Гибких границ проекта или от Фиксированных границ проекта. При этом под границами понимаются Стоимость, Требо- вания к продукту, Срок и Качество. В. Большаков. «Настольная книга тимлида разработки ПО» 80 Стратегия развития и дорожная карта должны вести преобразование продукта к опреде- ленной цели, которая будет уточняться со временем. В. Большаков. «Настольная книга тимлида разработки ПО» 81 Функциональные характеристики Проектирование функций (на базе бизнес-процессов) Функциональные требования к продукту: являются частью описания бизнес-процессов или раскрывают подробности выполнения различных бизнес-процессов. Например, классиче- ский интернет-магазин автоматизирует бизнес-процесс коммуникации организации с покупа- телем, при этом: – Каталог – выполняет роль справочника по товарам и ценам, некий прайс-лист с картин- ками. Он трансформировался из бумажного формата в электронный, и хотя способ передачи информации изменился, цель процесса осталась прежней. – Корзина и оформление покупки – автоматизируют формирование и прием заказа от покупателей. Раньше заказы принимали по телефону или с помощью почтовых отправле- ний. Карточки заказов шли в бумажных каталогах на последних страницах, чтобы можно было отправить письмом несколько заказов. – Контакты, О компании, … – информирование покупателей об условиях сделки, про- давце и т. д. Процессы могут иметь разные формы при одной и той же цели. Большая часть бизнес-подразделений недостаточно зрелая для того, чтобы сразу выда- вать описанные бизнес-процессы, поддержание которых стоит достаточно дорого для компа- нии. Продукты могут автоматизировать деятельность клиентов или взаимоотношения с кли- ентами. При таком раскладе функции продукта проверяются бизнес-гипотезами. Эффектив- ность бизнес-гипотез необходимо подтверждать увеличением вовлеченности, уровнем продаж и др. Другой случай – продукты, которые автоматизируют внутреннюю деятельность предпри- ятий. Они как раз не нуждаются в доказательстве эффективности тех или иных своих функ- ций. Их деятельность уже осуществляется в неавтоматизированном виде, что делает обратную связь от внедрения достаточно быстрой. Тимлид, как любой другой разработчик, может и должен подсказывать владельцу про- дукта наиболее оптимальные пути развития. Также в его полномочия входит извлечение дан- ных знаний из всей команды. Это позволит использовать полезные UI элементы и улуч- шить UX. Описание функций В главе «Качество постановки задач» рассматривались различные методы формализации задач. Выбор метода должен быть основан на необходимости более точной (качественной) реа- лизации задач и ориентированы на описание функций продукта. В некоторых компаниях существуют отдельные аналитики (системные аналитики или бизнес-аналитики), занимающиеся описанием бизнес-процессов или функционала продукта. Бизнес-аналитики фокусируются на проектировании, оптимизации и документировании биз- нес-процессов, ролях, должностных инструкциях. Системные аналитики проектируют интер- фейсы и UX на основании описанных бизнес-процессов. Достаточно часто бизнес-аналитики занимаются системным анализом и наоборот – системные аналитики занимаются бизнес-ана- лизом. Иногда этих специалистов привлекают к оценке бизнес гипотез. В. Большаков. «Настольная книга тимлида разработки ПО» 82 В случае, если в компании нет выделенной роли бизнес-аналитика или системного анали- тика, эту функцию может выполнять владелец продукта, тимлид, заказчик и др. Если эту роль выполняете вы сами (тимлид), то вам необходимо придерживаться следующих принципов: – Постоянно держите в фокусе основную цель продукта и основной бизнес-процесс зара- батывания денег. – Определите охват продукта и его пользователей. – Функции продукта должны отвечать потребностям пользователей, а также помогать им более эффективно и качественно выполнять свою роль в бизнес-процессе. – Проектирование UX должно обеспечивать удобство и простоту пользования без чтения документации. – Система понятно и предсказуемо реагирует на действия пользователей. – Приятное эстетическое ощущение от интерфейса продукта. – Обработка ошибок системы, дающая понимание того, что произошло и не требующая от пользователей дополнительных действий. В. Большаков. «Настольная книга тимлида разработки ПО» 83 Нефункциональные характеристики Архитектура приложений Тимлид может нести полную ответственность за архитектуру продукта, а может быть под- чинен решениям отдельного архитектора. Процесс работы над архитектурой продукта бывает сложным. Он представляет собой совещательный орган, принимающий решения по опреде- ленным критериям в необходимых случаях. Архитектуру информационной системы можно представить в виде слоев: – Технологический – Инфраструктура – Платформа – Информационный – Приложение – Данные – Бизнес – Сервисы – Процессы – Компетенции – Ценности Архитектура – это набор принятых и реализованных решений в отношении элементов (каждого слоя) и их взаимодействия. В. Большаков. «Настольная книга тимлида разработки ПО» 84 Этап первичного проектирования архитектуры часто сопровождается созданием доку- ментации – диаграмм и схем. Для этих целей используются UML диаграммы, эта нотация прак- тически не имеет достойной альтернативы на текущий момент. Проектирование приложения сводится к вопросам: – Как систематизировать и логически разделить программный код (функциональный, по типу объектов, по слоям объектов, по фичам) – Уровень отделения логических блоков (монолит, сервисная архитектура) – Платформа (serverless, на одном сервере, на разных физических серверах, в контейне- рах, на виртуальных машинах) Выбор технологий Основными критериями при выборе программного языка, фреймворка и инфраструк- туры будут: – Наличие компетенции в технологии – Способность технологии решить поставленную задачу – Эффективность решения данной задачи на заданной технологии (стоимость, скорость, расширяемость) – Доступность компетентных ресурсов в организации в нужный момент времени Выбор технологий – ответственное решение, которое будет дорого стоить организации. Для того чтобы принять правильное решение, настоятельно рекомендуется проводить встречи и стараться принимать его коллективным путем (это в равной степени относится к архитектуре приложения). Смена технологий в существующем продукте может быть связана с утратой компетенций или исходного кода. Смена архитектуры более частое явление, так как стоимость этой опера- ции меньше, и она завязана на частых инициирующих событиях (архитектурной ошибке, несо- ответствии архитектуры текущим потребностям и т.д.). Архитектурный контроль Принятые архитектурные решения необходимо реализовать в продукте. Контроль кор- ректности реализации архитектуры продукта – одна из важнейших функций тимлида. Про- цесс контроля встраивается в процесс ревью кода. В рамках ревью проверяется: соответствие архитектурному видению внесенных изменений в коде, необходимость изменить архитектуру, оправданность этих действий. Важно поддерживать документацию архитектуры и актуализировать ее при внесении изменений. Задокументированная архитектура в актуальном состоянии – маяк в море вариа- ций решений по каждой конкретной задаче. Вы дадите разработчикам возможность не тратить время на ненужные правки, а новым членам команды проще понять принципы, по которым необходимо вносить изменения в продукт. Аудит архитектуры необходимо проводить в случае, если нет жесткого контроля всех вносимых изменений в продукт. Таким образом в продукте: – могут появиться изменения, нарушающие его архитектурную целостность – документация могла потерять актуальность, и ее необходимо привести в соответствие с новой версией архитектуры. В. Большаков. «Настольная книга тимлида разработки ПО» 85 Технический долг Технический долг – это несделанная в проекте работа, которая если так и не будет выполнена, будет мешать развитию в будущем. В технический долг не включаются баги или отложенные низкоприоритетные фичи. Технический долг – это, например, плохо спроектиро- ванная архитектура или запутанный код. Управление техническим долгом – это его постоянный поиск, подсчёт стоимости и постепенное устранение. Что будет если не выплачивать технический долг? – Будет расти время разработки и стоимость поддержки системы. – Усложняется анализ кода, требуется много времени, чтобы разобраться в нём. – Тяжелее вносить изменения – системы с техническим долгом отличаются хрупкостью. – В какой-то момент станет невозможной дальнейшая поддержка системы. – Её придётся выводить из использования или переписывать с нуля. Почему копится технический долг? – Программист делает ошибки при разработке проекта, которые не отлавливаются на code review или статическом анализе; – Когда ситуация вынуждает писать код быстро и некачественно, к нему в будущем не возвращаются для рефакторинга; – Объем технического долга не известен руководству; – В команде не выделяется время на периодическое исправление технического долга; – Разработчики игнорируют мелкие дефекты качества и не пытаются их исправить на месте по правилу бойскаута. Как выявить технический долг? – Контроль качества внешним аудитом – Code Review – Автоматизация оценки качества кода Поддерживаемость и отказоустойчивость Документация – инструмент улучшения поддерживаемости продукта за счет сохране- ния знаний о продукте, его строении и процессе разработки. Правильно организованная пере- дача знаний позволит уменьшить риски при низком bus факторе. Стоимость создания и под- держки документации достаточно высокая, поэтому начинать работать с ней нужно с ответа на вопросы: – Кто потребитель документации? – Какой информации будет достаточно (наиболее важная)? – Какой вид документа будет максимально удобным для потребителя? Необходимо понимать, что, если не актуализировать документацию, она обесценится. То есть все вложенные инвестиции в ее создание ставятся под сомнение. Потребитель не знает в каком месте документация неактуальна, а следовательно, не может доверять ни одной строке. Распределение ответственности за код ведет к снижению поддерживаемости кода. Для больших продуктов вам придется искать компромисс между разделением области кода среди разработчиков и фокусировкой их деятельности в отдельной области. Прозрачность и гибкость архитектурного решения улучшает поддерживаемость за счет использования известных подходов, фреймворков и паттернов проектирования. Гиб- кость архитектурного решения создаст возможность дешево и быстро вносить изменения. В. Большаков. «Настольная книга тимлида разработки ПО» 86 Однако часто гибкость увеличивает стоимость, такие решения должны быть экономически оправданны. Хорошей практикой является измерение уровня сложности кода и «запаха» кода стати- ческими анализаторами. Отказоустойчивость решения достигается за счет: – Проверки выпускаемых версий (unit тестами, приемочными и интеграционными тестами, пентестами и статическим анализом кода на безопасность) – Построение отказоустойчивой схемы инфраструктуры – Уменьшение человеческого фактора в процессе публикации релизов Обеспечение высокой доступности также включает: – Резервное копирование – План восстановления (максимально автоматизированный) – Дублирование компонентов, масштабируемую архитектуру и кэширование – Защита от вторжений (brute force, XSS, ransomware, SQL injection, DDoS и др.) – Логирование – Метрики и алерты Производительность Управление производительностью начинается с прогнозов бизнеса о нагрузке на систему. Эти прогнозы строятся на своих показателях и не всегда легко превращаются в параметры системы. Вдобавок бизнес может иметь проблемы с долгосрочным планированием, необхо- димо учитывать неточность оценок и вероятность умышленной манипуляции прогнозом. Пла- нирование должно быть регулярным и обеспечивать процесс разработки преждевременной информацией о необходимых изменениях. На основании прогнозов бизнеса планируются задачи по обеспечению производитель- ности. Повышение производительности достигается за счет применения теории ограничений. Тестирование таких задач должно подтверждаться успешным нагрузочным тестом. При этом хорошим тоном считается способность системы выдержать х2-х5 нагрузки от плановых значе- ний. Необходимо встроить процесс обеспечения производительности в процесс разработки таким образом, чтобы изменения не приводили к деградации производительности продукта. Для этого на ревью оценивается производительность тех или иных алгоритмов, а тестировщик проверяет новую пропускную способность измененного участка. Есть ситуации, когда построить план по нагрузке физически невозможно, при этом нагрузка может скакать в диапазоне х10. В этих ситуациях бизнесу придется прибегнуть к дополнительным расходам, чтобы обеспечить доступность системы с использованием serverless архитектуры. Необходимо организовать процесс управления инцидентами нехватки производительно- сти. Структурированность в этом вопросе должна обеспечить минимальные потери и мини- мальный простой продукта, важно иметь рекомендации к быстрому реагированию на чрезмер- ную нагрузку. В рамках процесса выявляются первопричины и ставятся задачи по разрешению системных проблем. Безопасность Основные принципы проектирования и реализации безопасных систем: – Конфиденциальность – свойство информации быть недоступной или закрытой для неавторизованных лиц, сущностей или процессов. В. Большаков. «Настольная книга тимлида разработки ПО» 87 – Целостность – свойство сохранения правильности и полноты активов. – Доступность – свойство информации быть доступной и готовой к использованию по запросу авторизованного субъекта, имеющего на это право. – Невозможность отказа – подтверждение целостности и оригинального происхождения данных, которые исключают возможность подделки. Вся информация в любой момент может провериться сторонними лицами или пройти процесс установление идентичности (личности, документа, объекта). После данные с высокой степенью достоверности могут считаться под- линными без возможности опровержения. Требования безопасности необходимо выявить до начала работы над продуктом. Основные шаги выстраивания безопасности: – Сбор и выявление всех требований к безопасности (фактически реализации шагов ниже) – Требования к технологиям передачи, обработки и хранения информации – Выявление видов информации – Выявление ролей пользователей (для приложения и инфраструктуры) – Определение прав для каждой роли (операции чтения, удаления, обработки и измене- ния каждого типа информации) – Определение способа идентификации пользователя (в том числе в момент перебора паролей и ddos атак) – Правила согласования выдачи доступов и процесс выдачи доступов – Политика паролей – Регламенты информационной безопасности (профилактика, инциденты безопасности) – Журналирование важных для безопасности событий – Управление рисками безопасности (оценка угроз) – Использование средств активной защиты от атак Более того, требования могут быть наложены на сам процесс разработки: внесение изме- нений в код продукта, публикация новой версии продукта, использование последних версий библиотек и поддерживающих приложений. В подавляющем большинстве риски безопасности недооцениваются предприятиями, что возлагает на тимлида дополнительную ответственность за внимательное отношение к этому фактору. Для того чтобы переложить ответственность на сторону бизнеса, необходимо обозна- чить первостепенные действия и их стоимость, которые снижают риски безопасности. Часть действий будет выполнена и это позволит избежать некоторых неприятных ситуаций, но дру- гую бизнес не захочет оплачивать, в этом случае ответственность за принятие рисков будет лежать на них, как лицах, принимающих решение. Если вы не обозначите риски безопасно- сти, пути решения и стоимость для бизнеса – считайте, что во всех проблемах безопасности обвинят вас. В. Большаков. «Настольная книга тимлида разработки ПО» |