ITGM#4 Технический долг 2.0
•Télécharger en tant que PPTX, PDF•
1 j'aime•1,720 vues
Доклад с IT Global Meetup #4 Санкт-Петербург 27.02 mp3 с записью можно скачать здесь http://maxbeard12.podfm.ru/my/2/ видео тут https://www.youtube.com/watch?v=WjQaiKMYIgQ
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à ITGM#4 Технический долг 2.0
Similaire à ITGM#4 Технический долг 2.0 (20)
ITGM#4 Технический долг 2.0
- 1. Импотека или как перестать залезать в долги версия 2.0 18+ @maxbeard12
- 2. О себе Шульга Максим 9 лет в погонах 14 лет разрабатываю софт Руководитель разработки “Код Безопасности” http://maxshulga.ru @maxbeard
- 3. Поговорим о чем мы • Парадокс технического долга • Виды долгов в работе разработчика • Как с ними бороться? • Итого @maxbeard12
- 4. Технический долг @maxbeard12 Что это такое?
- 5. Технический долг Разница между идеальным техническим решением и тем решением, которое принимается сейчас К долгу относится только реализация: “КАК” сделано, а не “Что” @maxbeard12
- 6. Технический долг Разница между идеальным техническим решением и тем решением, которое принимается сейчас К долгу относится только реализация: “КАК” сделано, а не “Что” => ДОЛГ РЕАЛИЗАЦИИ @maxbeard12
- 7. Долг реализации • неверные архитектурные решения • “костыли” - “временные” решения • невозможность рефакторинга @maxbeard12
- 10. @maxbeard12 Долг реализации (бороться как?)
- 11. Долг реализации (бороться как?) “***ь, чтоб дебажить эту судорожную сраку так время есть, а чтобы рефакторить нету” (с) Что будем делать? @maxbeard12
- 12. Долг реализации (бороться как?) “***ь, чтоб дебажить эту судорожную сраку так время есть, а чтобы рефакторить нету” (с) Что будем делать? @maxbeard12
- 13. Долг реализации (бороться как?) “***ь, чтоб дебажить эту судорожную сраку так время есть, а чтобы рефакторить нету” (с) • архитектура: баланс между “продумали” и “перемудрили” • “костыли” - только так, чтобы легко исправить в будущем и с фиксацией долга • РЕФАКТОРИНГ с умом @maxbeard12
- 14. Долг реализации (бороться как?) http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad- technical-debt @maxbeard12
- 15. Долг реализации (бороться как?) А что делать, если у меня legacy код? @maxbeard12
- 16. Долг реализации (бороться как?) А что делать, если у меня legacy код? @maxbeard12
- 17. Долг реализации (бороться как?) А что делать, если у меня legacy код? @maxbeard12
- 18. Долг реализации (бороться как?) А что делать, если у меня legacy код? Презентация про legacy http://www.youtube.com/watch?v=YruzQgWdv48 @maxbeard12
- 19. Технологический долг Отказ от применения новшеств в языках, фреймворках, инструментах • С++11 • boost • IDE • свои “велосипеды” @maxbeard12 “Почему программисты часто изобретают велосипед? Потому что текущий велосипед уже не велосипед, а астролябия для трёхлапых енотов” (с)
- 20. Технологический долг (бороться как?) • Проще убедить применять то, в чем разбираешься ты • Другие языки изучай ты - расширяй кругозор свой @maxbeard12
- 21. Процессный долг • Continuous Integration • Ревью кода • Статический анализ • Автотесты • Гибче, еще гибче :) @maxbeard12 Отказ или затягивание принятия решений по применению правильных инженерных практик:
- 22. Процессный долг (бороться как?) @maxbeard12 Просто берем и делаем: • Continuous Integration • Ревью кода • Статический анализ • Автотесты • Гибче, еще гибче :)
- 24. Долг компетенции Возникает из-за узкоспециализированной разработки, когда в команде есть человек(и) с уникальными знаниями Усугубляется отсутствием обмена знаниями @maxbeard12
- 25. Долг компетенции (бороться как?) • Больше общаемся • Меняемся задачами • Ревью кода • Парное программирование @maxbeard12
- 26. А что в итоге? Технический долг: • долг реализации • технологический долг • процессный долг • долг компетенции Кругом долги, как страшно жить :) Бери да помни: не штука занять, а штука отдать (с) @maxbeard12
Notes de l'éditeur
- В последнее время обсуждение того, что такое технический долг и к чему он приводит постоянно идет в сообществе. Как правило, все строится вокруг того какие технические решения принимаются и почему. Для нас, людей занимающихся разработкой программных продуктов, техническим решением является и то как мы будем делать (архитектурно), и то каким языком программирования будем пользоваться, и то какие практики будут использоваться, и то как это будет тестироваться, и тд и тп. Соответственно и долги будут свои в каждой из этих областей. И поборов, хотя бы одну из них мы серьезно облегчим себе жизнь.
- Как это не странно, нет устоявшегося определения технического долга. Уорд Каннигем дает его расплывчато. Зато все знают, к чему этот долг приводит. Если попытаться его сформулировать, то получится следующее. Обратите внимание на КАК. К долгу не относятся те фичи, которые мы не сделали. К долгу можно отнести только то, «как» фичи были сделаны. Например, долгом может считаться несоответствие в общем то работающего UI, каким-либо руководствам, стандартам и тп.
- То есть получается, что мы говорим о долге реализации. Что мы под ним понимаем?
- К долгу реализации можно отнести то, что обычно и называют техническим долгом. Кстати картинку смастерил на основе идеи @cartmendum (М.Дорофеев) Есть идеи почему она такая? Так вот, приобрести этот долг можно и приняв неправильные архитектурные решения, и добавив "костыли" в коде, и упростив процесс тестирования оставив там только "успешные" сценарии. Сюда же добавим и невозможность рефакторить исходный код, которая вызвана отсутствием тестов, что зацикливает эту проблему и вводит в клинч, когда все больше времени требуется на добавление новых фичей, потому что постоянно умирают старые. Или наоборот "рефакторится" все направо и налево, а проверяют все это тестировщики ручками.
- Ассоциация: Красивая картинка – луг, коровки, красота
- Шаг вправо, шаг влево… ногу поставил, а вытащить стремно, понимаешь что вонять будет…
- Возражения вида "все равно все сделают через ж**у" плохи уже тем что что предполагают не делать вообще ничего. Надо стараться оставлять мир код после себя чище: там где чисто – стыдно мусорить. Сюда же относится и популярная теория разбитых окон: если появляется одно разбитое окно и оно не ремонтируется, то скоро много окон в здании будет разбито.
- ?
- А давайте как и раньше?
- Архитектура: совет дать очень сложно. Самый напрашивающийся (и популярный) вариант: легко расширяемая, легко тестируемая и тд, и тп. А что это? И насколько это нужно будет в будущем (принципы YAGNI). Стараемся соблюдать баланс Наши горячо любимые костыли – использовать можно (ну никуда без с них). Но если используем, то только в тех местах, где они просто исправляются. Костыли недопустимы в архитектурных решениях. Фиксация этого долга обязательна (бага, задача и тп) Рефакторим только в тех частях кода, которые касаются текущих задач (особенно это касается тех, кто работает с тестировщиками)
- Картинки по Книбергу
- Предваряя возможный вопрос про legacy код. Кстати, а что это такое? Что делать? Вот как то так
- Ответ очень простой
- На самом деле все уже давно придумано за нас. Читаем, изучаем, применяем. Метод Микадо.
- На самом деле все уже давно придумано за нас. Читаем, изучаем, применяем. Метод Микадо.
- У меня на глазах пример использования С++, когда часто можно наблюдать осторожность (мягко говоря) во внедрении С++11, когда отказываются от использования boost'a, когда продолжают писать свои мега-крутые "велосипеды" игнорируя open-source библиотеки. Все это приводит к замедлению разработки, снижению качества и даже к снижению мотивации у людей, потому что они используют "несвежие" инструменты.
- Как правило эти ограничения накладываются из-за опасения того, что использование новые технологий несет риск сдвига по сроков (изучение), выявления возможных проблем и тд. Но, если нет возможности изучать это на работе, то изучай сам, приходи к начальнику и рассказывай (а главное показывай), как можно сделать круче (проще, быстрее и тд) Изучение других языков тоже помогает. Когда я возвращался к С++ после программирования на Python, я постоянно задавал себе вопрос как сделать на C++ так же круто (удобно, просто) как на питоне. Оказывается можно - boost, C++11. Получается не так изящно, но гораздо удобнее, чем голые плюсы.
- Время от времени встречаю команды в которых не работает ни один из этих пунктов. Отсутствие веры, желания, понимания важности этого всего приводит к тому, что эти задачи, как правило с нижайшим приоритетом, накапливаются в списке общих задач. Потому что у нас всегда есть суперсрочные и суперважные для продукта задачи. И как следствие, только для того чтобы просто понять, что свежесобранный сетап не работает, приходится тратить от 10 мин до N часов (зависит от навороченности продукта). Я не буду объяснять зачем это все надо, это тема отдельных докладов по каждому и пунктов.
- Тут рецепт простой: надо просто взять и сделать. Никто этого за вас делать не будет. Это ваша профессия, то, за что вы получаете деньги. Мастерство, если хотите. Особенно классно (для меня как менеджера), когда разработчики сами это делают. Я про CI много слышал, даже игрался. Но как то не пошло. Год назад в команде появился человек, который просто сказал, «а давайте я сделаю». Взял и сделал. Через месяц остальные с удовольствием подключились в игру «найди полезный плагин для Jenkins»
- ?
- Возникает из-за узкоспециализированной разработки, когда в команде есть человек(и) с уникальными знаниями. Это усугубляется отсутствием обмена знаниями или, хотя бы, обмена возникающими проблемами и принятым по ним решениям. Такое можно наблюдать в масштабе и целой компании, и даже маленькой команды. В итоге, принимаются решения заведомо неверные, которые у человека разбирающегося в вопросе вызывают дикое удивление. И это нас возвращает к долгу реализации. А если спец уходит, то вообще возникает вакуум и код, которые он суппортил, превращается в магический лабиринт из языковых инструкций, которые реализуют "нечто". К нему стараются не прикасаться без крайней необходимости, при первой же возможности к нему применяется паттерн "invented not here" и он помечается черной меткой под названием "переписать".
- Тут тоже ничего гениального.