*Netpeak Talks — это серия ивентов от Netpeak Group в Одессе (при поддержке ассоциации продуктовых компаний IT-Products Odessa).
В рамках этих встреч есть возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
______________________
Тема #11: Как работать с legacy проектом, которому больше 10 лет?
Спикер: Денис Воскобойник — Team Lead отдела разработки внутренних продуктов в Netpeak Agency.
Тезисы видео:
✔ Построение процессов разработки.
✔ Подготовка команды к проекту.
✔ Внедрение / обновление стека технологий.
✔ Как рефакторить?
✔ Как понять, что нужно вынести отдельно и нужно ли это?
✔ Как тестировать то, что никогда не тестировалось?
✔ Code Review.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
Сайт: http://netpeak.group/talks
Facebook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
2. Кто я такой?
Team Lead отдела внутренних разработок
● В программировании c 2012 года
● Работал с более 60 проектами
● Создал 2 проекта в Netpeak, которые
работают уже больше 2 лет.
● Сейчас Team Lead команды из ~ 10
человек
4. О чем поговорим?
1. Легаси — это плохо или хорошо.
2. Построение процессов разработки.
3. Нужно развивать программистов!
4. Внедрение / обновление стека технологий.
5. Внедрить стандарты разработки.
6. IoC.
7. Как рефакторить? И нужно ли оно?
8. Как понять, что нужно вынести отдельно и нужно ли это?
9. Как тестировать то что никогда не тестировалось?
10. Code Review.
7. Почему плохо? 1. Никто не знает, как это работает.
2. Никто не знает, почему все работает именно так.
3. Время на внедрение фич постоянно растет.
4. Кол-во багов растет.
5. Внедрение фич делает код еще “легасее”.
6. Очень просто пропустить ошибку в безопасности.
7. Программисты превращаются в базу знаний проекта
и становятся незаменимы.
8. Построение процессов разработки
1. SCRUM не зря придумали
2. Не брать в работу фичу, пока программисты не
поймут какую проблему она решает.
3. Если на проекте нет тестирования — срочно начать!
4. Автоматизировать процесс деплоя.
10. 1. Команда, которая писала этот проект на разных
этапах и скорее всего не знает как писать правильно.
2. Человек, который давно сидит на проекте.
Что у нас есть?
11. 1. К разработке ключевых узлов системы подключить
как можно больше программистов.
2. Заставить читать книги, ходить на конференции.
Примеры книг: Эрик Эванс, http://martinfowler.com/
3. Подключить в тематическим чатам, примеры таких
чатов https://t.me/symfony_php,
https://t.me/prophp7
4. Настроить процесс code review
5. Организовать кружки по программированию
Что делать?
15. С новыми технологиями работать приятнее
1. Легко найти документацию
2. Легко найти ответ на свой вопрос
3. Много специалистов
4. Возможно найти больше готовых решений
18. 1. Использовать статические анализаторы кода.
Например phpstan, phan, psalm
2. composer outdated --direct
3. Долго тестировать работу продукта и ключевых его
модулей
Как обновить стек?
19. 1. Синтаксические стандарты — psr
2. PHP_CodeSniffer
3. Описать структуру директорий
4. Описать подходы используемые в разработке
Внедрить стандарты разработки
21. Inversion of Control (инверсия управления) — это некий абстрактный принцип, набор
рекомендаций для написания слабо связанного кода. Суть которого в том, что каждый компонент
системы должен быть как можно более изолированным от других, не полагаясь в своей работе на
детали конкретной реализации других компонентов.
Dependency Injection (внедрение зависимостей) — это одна из реализаций этого принципа
(помимо этого есть еще Factory Method, Service Locator).
IoC-контейнер — это какая-то библиотека, фреймворк, программа если хотите, которая
позволит вам упростить и автоматизировать написание кода с использованием данного подхода
на столько, на сколько это возможно.
Определения
22. 1. Явное указание зависимостей
2. Слабо связанный код
Что нам даст внедрение IoC
27. 1. Код должен стать чище
2. В процессе рефакторинга не создаётся новая
функциональность
3. Все существующие тесты должны успешно проходить
Что нам говорит refactoring.guru?
29. 1. Убирает возможность привязаться к другому модулю
2. Возможность использования в нескольких системах
3. Легкость обновления
4. Выделение конкретной команды на конкретный сервис
5. Возможность тестирования новых подходов на одном
маленьком сервисе
6. Распределение нагрузки
7. Отказоустойчивость
Чем отдельные сервисы лучше?
30. 1. Сложность трассировки запросов (https://zipkin.io)
2. Асинхронное взаимодействие
3. Распределенные транзакций
4. Сложности деплоймента
В чем минусы?
34. 1. Автоматизировать ревью стилистических ошибок
2. Не жалеть время на ревью
3. Максимально упростить процесс ревью
4. Новые решения обсуждать всей командой и
регламентировать
Правильный code review
35. 1. Использовать специализированный софт
2. Упростить создание ревью
3. Упростить процесс ревью
4. Упростить отчетность по ревью
Максимально упростить процесс ревью
36.
37. 1. Есть возможность автоматического создания ревью
2. Встроенная web IDE
3. Полная интеграция c PhpStorm
4. Интеграция с таск трекерами JIRA and YouTrack
5. Если у вас другой таск трекер, то есть хуки
6. Настройка dashboards
Чем удобен upsource
42. Ответы на вопросы
1. Как решать проблемы с проектом, на которые нет
времени? (выполнение Duty задач)?
2. Какие “угрозы” есть в долгом использовании legacy кода
в проекте?
3. Критерии легаси проекта.
4. Какие появились инструменты, для работы с SEO на
период начала 2019 года?
5. Какой процесс обработки документации использовать,
когда её много и она не систематизирована?