«Особенности agile-разработки интернет-проектов»
TRANSCRIPT
Особенности agile разработки интернет проектовна PHP/Yii, Python/Django и Java/Spring
Текст
AgileЧто в нем?
Почему agile?Нет времени на waterfall, продукт устареет прежде чем выйдет. Мы хотим чаще
Общение - наше все
Неявные риски рулят: «Мы узнаем о проблеме, когда столкнемся с ней»
Разрабатывать ПО дорого и мы заплатим любому, кто сделает этот процесс дешевле!
Клиент не знает что он хочет. По крайней мере пока не знает
Не совсем очевидные следствия
Очень часто встречается MVC, MVVC или MVP или как вы там это называете
ORM, Object mapping или что-то в этом роде (но есть примеры и без него, только писать много придется)
Каждая agile команда уникальна => нет унифицированного agile процесса разработки, нельзя внедрить «по книжке»
Клиент должен быть внутри процесса, а не снаружи
Fixed price - очень рискованно. Проще начать на T&M, и подумать о FP после 3-5 итераций
Все участники примерно равны потому что а) делают одно дело; б) самоорганизуются, а не подчиняются.
Не совсем очевидные последствия часть II
Code less, gain more or die hard
Энергия команды ограничена, а эклог все растет…
Мы вас обратно спрашивать не будем
CI/CD? Всегда!
Тесты, как бы неприятно это не было. Потому что скорость
Очень Scaffolding надо
Что внутри?
Backend
Frontend
Mobile
DevOps
Q&A
PM
Дизайн
Аналитик
Что важно?Скорость разработки
Скорость разработки
Цена
Достижение полезных результатов (качество)
Скорость доставки продукта
Жизнь - это боль бег
Важное замечаниеМы не обсуждаем чисто технические аспекты фреймворков
Пусть они останутся на их совести
Мы говорим о том как фреймворк влияет на agile разработку и влияет ли
И мы говорим о прикладном использовании, т.е. используем фреймворк, а не пишем новый
Текст
PHP/YiiНизкий порог вхождения (ха-ха)
ПлюсыЛюдей, которые в той или иной степени знают PHP достаточно много на рынке труда
Стоимость среднего PHP разработчика все-таки ниже…
Выделение компонентов помогает успешно повторно использовать код
Автоматическое построение URLов (controller/action)
Да и вообще хостинг самый дешевый!
Кодогенерация (Gii)
Можно грамотно переносить быстро сделанные сайты на нормальные рельсы
Условные минусы
Много спагетти кода
Не всегда «взрослое» community, но нужно отметить что взрослеет
Если клиент говорит «PHP», то это значит, что экономить он будет на всем и не всегда оправдано
Интеграция с jQieru (оно же и плюс, кстати)
Текст
Python/DjangoСовременно, молодежно и достаточно серьезно (на самом деле RoR тоже где-то здесь).
Основные принципы
DRY (do not repeat yourself)
Слабая связанность компонентов фреймворка
Широко используется ORM
Автопостроение админки
Батарейки. Потому что вставил и заработало
Generic Class Based Views если правильно понять и использовать сэкономят вам кучу времени
ПлюсыPython :)
Много чего «из коробки» (авторизация, админка, мультисайтовость, сайтмапы и много еще чего)
Качественные компоненты (reusable Django apps) - более 3000 готовых компонентов
Есть даже встроенное решение для GIS (GeoDjango)
C NoSQL решениями все еще пока не очень хорошо
Условные минусы
Проблема выбора и поиска нужного компонента
На shared хостинге не надо. Начинается с VDS
Ограниченное количество кадров на рынке
Текст
Java/SpringЗрелая платформа для зрелых проектов (на самом деле для зрелых команд)
Плюсы
Зрелость
Enterprise с «человеческим лицом»
Можно использовать специалистов из Enterprise (актуально во время кризиса)
Активноразвивающиеся средства кодогенерации и бутстрапинга (Spring Boot) - уменьшает время старта проекта
Еще более развитые средства кодогенерации (JHipster - Yeoman, Maven, Spring и Angular «в одном флаконе»)
Много оттестированных production и enterprise ready компонентов. Для банков актуально, например
Условные минусы
Сложнее всего из тройки найти кадры
Самый высокий порог входа
Стоимость инфраструктуры
Java постоянно «хоронят»
Почему-то все думают что Java сама по себе есть много памяти. Не думайте о памяти, разработчики все-равно дороже!
А памяти в требованиях все-равно стоит от 1 Гб
Текст
Итоги и обсужденияИтого:
Выводы для flame warsФреймворк влияет, но это аспект больше социальный, а не технологический
Экосистема может быть большой, но если большое плохо пахнет, то это все-равно не поможет
Экономьте деньги в разработке и выбирайте компромис между вашим желанием сделать хорошо сейчас, хорошо потом и/или за приемлемые деньги
Чем больше кода можно повторно использовать - тем лучше, ну или DRY
Выбирайте команду, которая с меньшими затратами реализовать ваши задачи на том фреймворке, который ей хорошо знаком. Тут нет религии. Только деньги
Всем добра!
Петр Курышев
skype: peter.kurishev
Спасибо что пришли!
Всем добра, Docker’а, KISS, DRY и всего наилучшего!