Как на языке бизнеса доказать необходимость переписывания кода. Как бизнес может объяснить инженерам, что этого делать не нужно, либо как сделать это правильно с перспективы бизнеса.

1. Этот код плохой,
его нужно переписать
Нужно ли, когда, почему?

2. Частый вопрос
Как доказать бизнесу, что это нужно

3. Термины
Рефакторинг и переписывание

4. Если вы правы, то как
доказать это бизнесу?
Думай как бизнес - решай чужую проблему,
а не свою

5. с какой мы стороны
денег?
2*2 = ?
а мы покупаем или продаем?

6. Чаще переписывают
не плохой код
а вполне хороший, но больше не решающий
бизнес задачу

7. Критерии кодеров не
относятся к решению
бизнес задач
Кроме одного - они больше не могут деливерить.
Технические критерии не имеют значения -
паттерны, старые/новые языки, это все очень
интересно (самим кодерам)

8. мало кто говорит что его код
плохой.
плохой код всегда писали
предшественники

9. «Добро» и «зло» в
бизнесе и технологиях
одинаковы
Менеджер уходит за квартал до итогов года
Программист перед релизом

10. автор и технология
язык + фреймворк и/или библиотеки
проблемы могут быть и там и там
автор свой код переписывает или чужой?

11. Культура переписывания была
развита у XP программистов,
они рефакторили (постоянно)

12. Пишут код 1 раз
Читают 10+ раз
Разные люди.
Уважайте их и они будут уважать вас

13. 7ми летних детей учат
писать так, чтобы не
переписывать

14. Кто видел желающих
переписать любой
OpenSource проект?

15. Почему живет Legacy
код на Java 1.2, COBOL,
AngularJS 1?

16. Мейнфреймы. Их пытаются
закрыть, но клиенты
держатся "за любые деньги"

17. Почему вкладывают деньги
в поддержку Legacy,
а не переписывание?

18. Факт 1 - бизнес сделает
все, чтобы ничего не
переписывать

19. Кода на COBOL - море
• Он хорошо работает.
• С точки зрения не только джуна, просто с роли кодера
код на COBOL СЕГОДНЯ - ПЛОХОЙ.
• Программист - больше, чем кодер
• Бизнес - больше, чем программист

20. Что такое плохой код?
И почему это не объективно?

21. появление проблемы
до релиза первой
версии
MVP - этот код плохой и его .. - ОК

22. SoundCloud -
переписали на MSA
Почему? Код не плохой

23. Две крайности - «софт
пограничников» vs
«CTO стартапа растет»

24. Почему Google не пишет
фронт на JS/React, как парни
на соседней вечеринке?
Почему в начале чуждые фронтам схемы Java
to JS и тп?
Почему AngularDart, почему на AngularJS не
перешли раньше, почему проскочили весь JS?

25. Культура ценностей в компании
Личный интерес разработчиков
- конфликт или синергия?

26. Сдержать эгоистичных
разработчиков от
переписывания кода

27. Дать возможность
разработчикам с инженерной
этикой переписать код

28. Покажите
инженерную этику

29. ТЕХ. ДОЛГ
• Кто что кому должен?
• Кто одолжил? Он знает или у него просто взяли в долг
без его ведома?
• Кто будет возвращать?
• Проценты ниже доходов или выше?
• Процедура банкротства - переписывание

30. «Костыль»
сознательный (костыль) и неосознанный (делали на пределе
умений, но предел был ниже уровня сложности проекта)
костыль - все работает, ошибок нет
делаем новые фичи - появляются ошибки или долго делать
фичу, мешает костыль явно или неявно

31. Философия Windows,
Mac, FreeBSD, Linux
Обновления системы, апгрейд версии со стороны
разработчиков и пользователей
by design - судьба на десят лет +
вы не смените архитектуру после MVP

32. Если это что-то
важное, то оно с чем-
то связано
SOAP, REST, ПРИВЫЧКИ ЮЗЕРОВ
переписывайте компоненты,
но не интерфейсы

33. Совместимость
• ABI
• SOA
• MSA

34. Критерии для бизнеса
• время до выхода продукта на рынок
• время вывода новой фичи (SoundCloud MSA, DevOps,
TDD), цена фичи
• Цена фичи / ценность фичи
• Риски по качеству - «влет» из-за дефектов (после
релиза)
• Риски по кадрам - уйдут туда, где разрешат GraphQL

35. Вести ли переговоры
с террористами?
Что будет с бизнесом, если вся команда уйдет на
НОВЫЕ ТЕХНОЛОГИИ?

36. НОВОЕ
• зачем бизнесу emergent technology?

37. DevOps - бизнес
термин
При правильном DevOps ничего не придется
переписывать. Но где вы видели правильный
DevOps?
В треугольник цена, сроки, качество добавим
интеллект

38. Бизнес - это люди
• Собственники с правом решать
• Акционеры без права решать, но с рекомендацией
отправить все в облако, чтобы сэкономить
• CEO
• Менеджеры
• Линия потери смыслов - аутсорс

39. Пользователи - тоже
люди
• Пользователи не могут хотеть фичи (пользователь
входит в когорты и не имеет личности, только
настройки фона в кабинете)
• За них это делают представители бизнеса
• Они берут на себя РИСК проверить, будут ли
пользователи платить, ВЛОЖИВ В ЭТО ДЕНЬГИ, ЗА
КОТОРЫЕ ОНИ ОТВЕЧАЮТ

40. Бизнес вес фич и
предпосылки к
переписыванию
Второй критерий оценки - добавлять ли фичу?

41. Системное
мышление
Цепочки от хороших идей до больших проблем

42. Критерии качества
архитектуры
ISO-25010

43. Сквозная
функциональность

44. Очевидно -
Maintainability
Шаг вперед, два шага назад. Переписываем

45. Новые требования к
Reliability

46. Сильный рост
нагрузки
«Не тянем» нагрузку
Дорого тянуть

47. Новые требования к
безопасности

48. React Native ->
Native
Case как FB сделал Native app сам когда-то

49. React Native ->
Flutter
«Принцип торнадо»

50. В облако с или без
переписывания?
С переписыванием - операционка иначе
считается

51. Лямбды - повод
переписать?
Home Work

52. риски / возможности
• рост влияния рисков
• типы компаний по роли софта в бизнесе
• мы чем-то рискуем (новые конкуренты) или нам за это
заплатят пользователи? (обновление продукта)

53. На что переписать?
• Когда MS затеял TypeScript, они сначала написали что-
то на JS и решили это переписать (но без JS)?
• или решили создать язык ради языка или рынка
(лопаты золотоискателям)?

54. Переписывать на что
• Смена фреймворка (был «неправильный», появился
лучше (решающий бизнес задачу (меньше кода, лучше
структура)))
• Смена языка
• Смена поколения языка
• Смена архитектуры - SOA, MSA, MVC, introduce Kafka,
AWS

55. уровни экспертизы - выше
старого кода или ниже
• знание об этом менеджера исполнителя
• знание об этом клиента
• знание об этом пользователя
• знание об этом контролирующих органов (самолет)

56. как пережить кризис и не
переписывать?
• 1го года
• 2го года
• 3го года
• каждый продукт на Agile через 2-3 года заходит в
«опасные земли»

57. Когда мы перешли от
как переписать к как не
переписывать?
А это и есть главная цель - переписать нужно.
НО ОДИН РАЗ. Или даже не начинайте разговор

58. Когда таки нужно
переписывать?
• Есть план, как не переписывать снова через 2-3 года
• Скорость внесения новых фич сейчас делает убытки
бизнесу и ведет его к катастрофе
• Нефункциональные требования нельзя реализовать -
они не компонент системы, а ее свойство!
• Иначе кодеры уйдут, все развалится и бизнес тоже.
Дай террористам то, что они хотят, но не дай себя *** в
следующий раз

59. Код не плохой, но нужно
переписывать
• Чем меньше модуль, тем лучше - MSA - «да»
• Авторов м сервиса на Rust больше нет - MSA было «да»
• Код написан на Haskell и я его не понимаю (и не
должен, кому в голову пришло написать это на
Haskell?)
• Код написан сеньором, меня назначили сеньором, но я
не сеньор, бизнес в меня вкладывается

60. Спасибо
max.bezugly@gmail.com
International Software Architect Club (FB, T)