Downloaded 13 times
Uploaded byMaxim Shulga
ITGM#4 Технический долг 2.0
Документ обсуждает различные виды технического долга, включая долг реализации, технологический долг, процессный долг и долг компетенции, а также предлагает методы борьбы с ними. Основное внимание уделяется тому, как неправильные архитектурные решения и недостаток рефакторинга могут вызвать проблемы в разработке программного обеспечения. В заключение подчеркивается важность обмена знаниями и применения хороших инженерных практик для минимизации долгов.
![IT CAMPUS. How to Stop Worrying and Clear Your Technical Debt [RUS]](https://cdn.slidesharecdn.com/ss_thumbnails/itcampus-140728094855-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
ITGM#4 Технический долг 2.0
- 1. Импотека или какперестать залезать в долги версия 2.0 18+ @maxbeard12
- 2. О себе Шульга Максим 9лет в погонах 14 лет разрабатываю софт Руководитель разработки “Код Безопасности” http://maxshulga.ru @maxbeard
- 3. Поговорим о чеммы • Парадокс технического долга • Виды долгов в работе разработчика • Как с ними бороться? • Итого @maxbeard12
- 4.
- 5. Технический долг Разница междуидеальным техническим решением и тем решением, которое принимается сейчас К долгу относится только реализация: “КАК” сделано, а не “Что” @maxbeard12
- 6. Технический долг Разница междуидеальным техническим решением и тем решением, которое принимается сейчас К долгу относится только реализация: “КАК” сделано, а не “Что” => ДОЛГ РЕАЛИЗАЦИИ @maxbeard12
- 7. Долг реализации • неверныеархитектурные решения • “костыли” - “временные” решения • невозможность рефакторинга @maxbeard12
- 8.
- 9.
- 10.
- 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. Процессный долг • ContinuousIntegration • Ревью кода • Статический анализ • Автотесты • Гибче, еще гибче :) @maxbeard12 Отказ или затягивание принятия решений по применению правильных инженерных практик:
- 22. Процессный долг (боротьсякак?) @maxbeard12 Просто берем и делаем: • Continuous Integration • Ревью кода • Статический анализ • Автотесты • Гибче, еще гибче :)
- 23.
- 24. Долг компетенции Возникает из-заузкоспециализированной разработки, когда в команде есть человек(и) с уникальными знаниями Усугубляется отсутствием обмена знаниями @maxbeard12
- 25. Долг компетенции (боротьсякак?) • Больше общаемся • Меняемся задачами • Ревью кода • Парное программирование @maxbeard12
- 26. А что витоге? Технический долг: • долг реализации • технологический долг • процессный долг • долг компетенции Кругом долги, как страшно жить :) Бери да помни: не штука занять, а штука отдать (с) @maxbeard12
- 27.
Editor's Notes
- #4 В последнее время обсуждение того, что такое технический долг и к чему он приводит постоянно идет в сообществе. Как правило, все строится вокруг того какие технические решения принимаются и почему. Для нас, людей занимающихся разработкой программных продуктов, техническим решением является и то как мы будем делать (архитектурно), и то каким языком программирования будем пользоваться, и то какие практики будут использоваться, и то как это будет тестироваться, и тд и тп. Соответственно и долги будут свои в каждой из этих областей. И поборов, хотя бы одну из них мы серьезно облегчим себе жизнь.
- #6 Как это не странно, нет устоявшегося определения технического долга. Уорд Каннигем дает его расплывчато. Зато все знают, к чему этот долг приводит. Если попытаться его сформулировать, то получится следующее. Обратите внимание на КАК. К долгу не относятся те фичи, которые мы не сделали. К долгу можно отнести только то, «как» фичи были сделаны. Например, долгом может считаться несоответствие в общем то работающего UI, каким-либо руководствам, стандартам и тп.
- #7 То есть получается, что мы говорим о долге реализации. Что мы под ним понимаем?
- #8 К долгу реализации можно отнести то, что обычно и называют техническим долгом. Кстати картинку смастерил на основе идеи @cartmendum (М.Дорофеев) Есть идеи почему она такая? Так вот, приобрести этот долг можно и приняв неправильные архитектурные решения, и добавив "костыли" в коде, и упростив процесс тестирования оставив там только "успешные" сценарии. Сюда же добавим и невозможность рефакторить исходный код, которая вызвана отсутствием тестов, что зацикливает эту проблему и вводит в клинч, когда все больше времени требуется на добавление новых фичей, потому что постоянно умирают старые. Или наоборот "рефакторится" все направо и налево, а проверяют все это тестировщики ручками.
- #9 Ассоциация: Красивая картинка – луг, коровки, красота
- #10 Шаг вправо, шаг влево… ногу поставил, а вытащить стремно, понимаешь что вонять будет…
- #11 Возражения вида "все равно все сделают через ж**у" плохи уже тем что что предполагают не делать вообще ничего. Надо стараться оставлять мир код после себя чище: там где чисто – стыдно мусорить. Сюда же относится и популярная теория разбитых окон: если появляется одно разбитое окно и оно не ремонтируется, то скоро много окон в здании будет разбито.
- #12 ?
- #13 А давайте как и раньше?
- #14 Архитектура: совет дать очень сложно. Самый напрашивающийся (и популярный) вариант: легко расширяемая, легко тестируемая и тд, и тп. А что это? И насколько это нужно будет в будущем (принципы YAGNI). Стараемся соблюдать баланс Наши горячо любимые костыли – использовать можно (ну никуда без с них). Но если используем, то только в тех местах, где они просто исправляются. Костыли недопустимы в архитектурных решениях. Фиксация этого долга обязательна (бага, задача и тп) Рефакторим только в тех частях кода, которые касаются текущих задач (особенно это касается тех, кто работает с тестировщиками)
- #15 Картинки по Книбергу
- #16 Предваряя возможный вопрос про legacy код. Кстати, а что это такое? Что делать? Вот как то так
- #17 Ответ очень простой
- #18 На самом деле все уже давно придумано за нас. Читаем, изучаем, применяем. Метод Микадо.
- #19 На самом деле все уже давно придумано за нас. Читаем, изучаем, применяем. Метод Микадо.
- #20 У меня на глазах пример использования С++, когда часто можно наблюдать осторожность (мягко говоря) во внедрении С++11, когда отказываются от использования boost'a, когда продолжают писать свои мега-крутые "велосипеды" игнорируя open-source библиотеки. Все это приводит к замедлению разработки, снижению качества и даже к снижению мотивации у людей, потому что они используют "несвежие" инструменты.
- #21 Как правило эти ограничения накладываются из-за опасения того, что использование новые технологий несет риск сдвига по сроков (изучение), выявления возможных проблем и тд. Но, если нет возможности изучать это на работе, то изучай сам, приходи к начальнику и рассказывай (а главное показывай), как можно сделать круче (проще, быстрее и тд) Изучение других языков тоже помогает. Когда я возвращался к С++ после программирования на Python, я постоянно задавал себе вопрос как сделать на C++ так же круто (удобно, просто) как на питоне. Оказывается можно - boost, C++11. Получается не так изящно, но гораздо удобнее, чем голые плюсы.
- #22 Время от времени встречаю команды в которых не работает ни один из этих пунктов. Отсутствие веры, желания, понимания важности этого всего приводит к тому, что эти задачи, как правило с нижайшим приоритетом, накапливаются в списке общих задач. Потому что у нас всегда есть суперсрочные и суперважные для продукта задачи. И как следствие, только для того чтобы просто понять, что свежесобранный сетап не работает, приходится тратить от 10 мин до N часов (зависит от навороченности продукта). Я не буду объяснять зачем это все надо, это тема отдельных докладов по каждому и пунктов.
- #23 Тут рецепт простой: надо просто взять и сделать. Никто этого за вас делать не будет. Это ваша профессия, то, за что вы получаете деньги. Мастерство, если хотите. Особенно классно (для меня как менеджера), когда разработчики сами это делают. Я про CI много слышал, даже игрался. Но как то не пошло. Год назад в команде появился человек, который просто сказал, «а давайте я сделаю». Взял и сделал. Через месяц остальные с удовольствием подключились в игру «найди полезный плагин для Jenkins»
- #24 ?
- #25 Возникает из-за узкоспециализированной разработки, когда в команде есть человек(и) с уникальными знаниями. Это усугубляется отсутствием обмена знаниями или, хотя бы, обмена возникающими проблемами и принятым по ним решениям. Такое можно наблюдать в масштабе и целой компании, и даже маленькой команды. В итоге, принимаются решения заведомо неверные, которые у человека разбирающегося в вопросе вызывают дикое удивление. И это нас возвращает к долгу реализации. А если спец уходит, то вообще возникает вакуум и код, которые он суппортил, превращается в магический лабиринт из языковых инструкций, которые реализуют "нечто". К нему стараются не прикасаться без крайней необходимости, при первой же возможности к нему применяется паттерн "invented not here" и он помечается черной меткой под названием "переписать".
- #26 Тут тоже ничего гениального.