Форма входа
0/0
Настольная книга тимлида разработки ПО - Виктор Большаков
- Дата:29.07.2024
- Категория: Компьютеры и Интернет / Программирование
- Название: Настольная книга тимлида разработки ПО
- Автор: Виктор Большаков
- Просмотров:3
- Комментариев:0
Уважаемые читатели!
Тут можно читать бесплатно Настольная книга тимлида разработки ПО - Виктор Большаков. Жанр: Программирование. Так же Вы можете читать полную версию (весь текст) онлайн книги без регистрации и SMS на сайте Knigi-online.info (книги онлайн) или прочесть краткое содержание, описание, предисловие (аннотацию) от автора и ознакомиться с отзывами (комментариями) о произведении.
Описание онлайн-книги Настольная книга тимлида разработки ПО - Виктор Большаков:
Книга родилась из курса внутреннего обучения роли Тимлид в DatsTeam. Тем не менее её ценность для всего сообщества тимлидов заключается в обобщении необходимых компетенций. Этот набор компетенций формирует общий стандарт в отрасли разработки ПО.
Программирование
Аудиокнига "Настольная книга тимлида разработки ПО" от Виктора Большакова
📚 "Настольная книга тимлида разработки ПО" - это увлекательное путешествие в мир управления разработкой программного обеспечения. Вас ждет множество полезных советов, инсайтов и стратегий, которые помогут вам стать успешным лидером в IT-индустрии.
Главный герой книги - тимлид, который сталкивается с различными вызовами и проблемами в процессе работы с командой разработчиков. Он учится принимать решения, мотивировать коллег и эффективно управлять проектами, чтобы достичь поставленных целей.
Автор книги, Виктор Большаков, является опытным специалистом в области разработки ПО и управления проектами. Он делится своими знаниями и опытом, помогая читателям развить лидерские качества и стать успешными профессионалами в IT-сфере.
На сайте knigi-online.info вы можете бесплатно и без регистрации слушать аудиокниги онлайн на русском языке. Здесь собраны лучшие бестселлеры различных жанров, включая книги по программированию.
Не упустите возможность улучшить свои навыки управления проектами и стать успешным лидером в области разработки ПО с помощью аудиокниги "Настольная книга тимлида разработки ПО" от Виктора Большакова!
Погрузитесь в увлекательный мир IT-индустрии и станьте лучшей версией себя уже сегодня!
Программирование
Читем онлайн Настольная книга тимлида разработки ПО - Виктор Большаков
Шрифт:
-
+
Интервал:
-
+
Закладка:
Сделать
кода. В рамках ревью проверяется: соответствие архитектурному видению внесенных изменений в коде, необходимость изменить архитектуру, оправданность этих действий.
Важно поддерживать документацию архитектуры и актуализировать ее при внесении изменений. Задокументированная архитектура в актуальном состоянии — маяк в море вариаций решений по каждой конкретной задаче. Вы дадите разработчикам возможность не тратить время на ненужные правки, а новым членам команды проще понять принципы, по которым необходимо вносить изменения в продукт.
Аудит архитектуры необходимо проводить в случае, если нет жесткого контроля всех вносимых изменений в продукт. Таким образом в продукте:
— могут появиться изменения, нарушающие его архитектурную целостность
— документация могла потерять актуальность, и ее необходимо привести в соответствие с новой версией архитектуры.
Технический долг
Технический долг — это несделанная в проекте работа, которая если так и не будет выполнена, будет мешать развитию в будущем. В технический долг не включаются баги или отложенные низкоприоритетные фичи. Технический долг — это, например, плохо спроектированная архитектура или запутанный код.
Управление техническим долгом — это его постоянный поиск, подсчёт стоимости и постепенное устранение.
Что будет если не выплачивать технический долг?
— Будет расти время разработки и стоимость поддержки системы.
— Усложняется анализ кода, требуется много времени, чтобы разобраться в нём.
— Тяжелее вносить изменения — системы с техническим долгом отличаются хрупкостью.
— В какой-то момент станет невозможной дальнейшая поддержка системы.
— Её придётся выводить из использования или переписывать с нуля.
Почему копится технический долг?
— Программист делает ошибки при разработке проекта, которые не отлавливаются на code review или статическом анализе;
— Когда ситуация вынуждает писать код быстро и некачественно, к нему в будущем не возвращаются для рефакторинга;
— Объем технического долга не известен руководству;
— В команде не выделяется время на периодическое исправление технического долга;
— Разработчики игнорируют мелкие дефекты качества и не пытаются их исправить на месте по правилу бойскаута.
Как выявить технический долг?
— Контроль качества внешним аудитом
— Code Review
— Автоматизация оценки качества кода
Поддерживаемость и отказоустойчивость
Документация — инструмент улучшения поддерживаемости продукта за счет сохранения знаний о продукте, его строении и процессе разработки. Правильно организованная передача знаний позволит уменьшить риски при низком bus факторе. Стоимость создания и поддержки документации достаточно высокая, поэтому начинать работать с ней нужно с ответа на вопросы:
— Кто потребитель документации?
— Какой информации будет достаточно (наиболее важная)?
— Какой вид документа будет максимально удобным для потребителя?
Необходимо понимать, что, если не актуализировать документацию, она обесценится. То есть все вложенные инвестиции в ее создание ставятся под сомнение. Потребитель не знает в каком месте документация неактуальна, а следовательно, не может доверять ни одной строке.
Распределение ответственности за код ведет к снижению поддерживаемости кода. Для больших продуктов вам придется искать компромисс между разделением области кода среди разработчиков и фокусировкой их деятельности в отдельной области.
Прозрачность и гибкость архитектурного решения улучшает поддерживаемость за счет использования известных подходов, фреймворков и паттернов проектирования. Гибкость архитектурного решения создаст возможность дешево и быстро вносить изменения.
Однако часто гибкость увеличивает стоимость, такие решения должны быть экономически оправданны.
Хорошей практикой является измерение уровня сложности кода и «запаха» кода статическими анализаторами.
Отказоустойчивость решения достигается за счет:
— Проверки выпускаемых версий (unit тестами, приемочными и интеграционными тестами, пентестами и статическим анализом кода на безопасность)
— Построение отказоустойчивой схемы инфраструктуры
— Уменьшение человеческого фактора в процессе публикации релизов
Обеспечение высокой доступности также включает:
— Резервное копирование
— План восстановления (максимально автоматизированный)
— Дублирование компонентов, масштабируемую архитектуру и кэширование
— Защита от вторжений (brute force, XSS, ransomware, SQL injection, DDoS и др.)
— Дотирование
— Метрики и алерты
Производительность
Управление производительностью начинается с прогнозов бизнеса о нагрузке на систему. Эти прогнозы строятся на своих показателях и не всегда легко превращаются в параметры системы. Вдобавок бизнес может иметь проблемы с долгосрочным планированием, необходимо учитывать неточность оценок и вероятность умышленной манипуляции прогнозом. Планирование должно быть регулярным и обеспечивать процесс разработки преждевременной информацией о необходимых изменениях.
На основании прогнозов бизнеса планируются задачи по обеспечению производительности. Повышение производительности достигается за счет применения теории ограничений. Тестирование таких задач должно подтверждаться успешным нагрузочным тестом. При этом хорошим тоном считается способность системы выдержать х2-х5 нагрузки от плановых значений.
Необходимо встроить процесс обеспечения производительности в процесс разработки таким образом, чтобы изменения не приводили к деградации производительности продукта. Для этого на ревью оценивается производительность тех или иных алгоритмов, а тестировщик проверяет новую пропускную способность измененного участка.
Есть ситуации, когда построить план по нагрузке физически невозможно, при этом нагрузка может скакать в диапазоне х10. В этих ситуациях бизнесу придется прибегнуть к дополнительным расходам, чтобы обеспечить доступность системы с использованием serverless архитектуры.
Необходимо организовать процесс управления инцидентами нехватки производительности. Структурированность в этом вопросе должна обеспечить минимальные потери и минимальный простой продукта, важно иметь рекомендации к быстрому реагированию на чрезмерную нагрузку. В рамках процесса выявляются первопричины и ставятся задачи по разрешению системных проблем.
Безопасность
Основные принципы проектирования и реализации безопасных систем:
— Конфиденциальность — свойство информации быть недоступной или закрытой для неавторизованных лиц, сущностей или процессов.
— Целостность — свойство сохранения правильности и полноты активов.
— Доступность — свойство информации быть доступной и готовой к использованию по запросу авторизованного субъекта, имеющего на это право.
— Невозможность отказа — подтверждение целостности и оригинального происхождения данных, которые исключают возможность подделки. Вся информация в любой момент может провериться сторонними лицами или пройти процесс установление идентичности (личности, документа, объекта). После данные с высокой степенью достоверности могут считаться подлинными без возможности опровержения.
Требования безопасности необходимо выявить до начала работы над продуктом.
Основные шаги выстраивания безопасности:
— Сбор и выявление всех требований к безопасности (фактически реализации шагов ниже)
— Требования к технологиям передачи, обработки и хранения информации
— Выявление видов информации
— Выявление ролей пользователей (для приложения и инфраструктуры)
— Определение прав для каждой роли (операции чтения, удаления, обработки и изменения каждого типа информации)
— Определение способа идентификации пользователя (в том числе в момент перебора паролей и DDoS-атак)
— Правила согласования выдачи доступов и процесс выдачи доступов
— Политика паролей
— Регламенты информационной безопасности (профилактика, инциденты безопасности)
— Журналирование важных для безопасности событий
— Управление рисками безопасности (оценка угроз)
— Использование средств активной защиты от атак
Более того, требования могут быть наложены на сам процесс разработки: внесение изменений в код продукта, публикация новой версии продукта, использование последних версий библиотек и поддерживающих приложений.
В подавляющем большинстве риски безопасности недооцениваются предприятиями, что возлагает на тимлида дополнительную ответственность за внимательное отношение к этому фактору. Для того чтобы переложить ответственность на
На этой странице вы можете бесплатно читать книгу Настольная книга тимлида разработки ПО - Виктор Большаков бесплатно.
Похожие на Настольная книга тимлида разработки ПО - Виктор Большаков книги
- Настольная книга по домоводству. 1000 практических советов на все случаи жизни - С. Потапкин - Прочее домоводство
- Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова - Программирование
- Формирование технологии разработки и принятия предпринимательских решений - Д. Кенина - Управление, подбор персонала
- Исправление прошлого и исцеление будущего с помощью практики восстановления души - Альберто Виллолдо - Эзотерика
- Личное мнение - Павел Бессонов - Поэзия
