Доклад с IT Global Meetup #4 Санкт-Петербург 27.02
mp3 с записью можно скачать здесь http://maxbeard12.podfm.ru/my/2/
видео тут https://www.youtube.com/watch?v=WjQaiKMYIgQ
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Как попасть на следующий уровень карьеры и зарплаты в C#geekfamilyrussia
Есть ли потолок заработной платы? Что делать, если Вы уперлись в него. Как преодолевать уровни сопротивления и избегать в ловушек в карьере .net разработчика. Результат анализа более 6.000 резюме C# разработчиков в Москве.
Алексей Лустин. Непрерывная проверка качества кода.ScrumTrek
Я расскажу о нашем двухлетнем опыте использования инженерной практики «Continious Inspection» и платформы SonarQube при организации кросс-языковой разработки в процессе «непрерывной поставки» (CI-CD для языков Java, C#, JavaScript, typeScript и Gherkin) при автоматизированном code-review.
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Как попасть на следующий уровень карьеры и зарплаты в C#geekfamilyrussia
Есть ли потолок заработной платы? Что делать, если Вы уперлись в него. Как преодолевать уровни сопротивления и избегать в ловушек в карьере .net разработчика. Результат анализа более 6.000 резюме C# разработчиков в Москве.
Алексей Лустин. Непрерывная проверка качества кода.ScrumTrek
Я расскажу о нашем двухлетнем опыте использования инженерной практики «Continious Inspection» и платформы SonarQube при организации кросс-языковой разработки в процессе «непрерывной поставки» (CI-CD для языков Java, C#, JavaScript, typeScript и Gherkin) при автоматизированном code-review.
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
XP Days Ukraine 2014 - Refactoring legacy codeDmytro Mindra
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.
У вас древний проект? Все зовут его «Legacy», а вас «неудачник»? Возможно они даже смеются над вами.
Давайте взглянем на ситуацию с другого ракурса. Все (все, Карл!) успешные проекты рано или поздно превращаются в Legacy-проекты.
Я затрону тему Legacy не просто как явление, а как возможность быть постоянно в тренде, прослыть супер-спецом (даже если ты знаешь всего два фреймворка), сделать карьеру, как делать, то что ты хочешь, а не то что тебя просят. Ладно, ладно, я наврал про два фреймворка, но все остальное чистая правда. Я покажу, что вы можете творить, имея правильный подход к Legacy коду.
Суть в том, что Legacy — это не грустно/уныло/немодно, это просто/клево/весело, если с умом подойти к задаче!
Agile Kitchen November 2013
Долгое время наша команда работала с собственным кодом, применяя различные методологии и подходы, писала качественный код и можно сказать жила в раю, но вот настал день, когда изменилось всё☺. Когда мы взяли на поддержку чужой объемный продукт и завязли по колено в легаси. Нам пришлось активно подключить наш agile mindset, чтобы изменить ситуацию и адаптироваться под новые условия. В общем, мы расскажем почему базовые практики того же scrum плохо работают с legacy, что нам пришлось изменить в команде и во взаимоотношениях со стейкхолдерами, и к чему это привело.
Ну а если вы еще сомневаетесь, то попробуйте ответить себе на пару следующие вопросов: приходилось ли вам брать на поддержку чужой продукт целиком с его непонятными правилами, устаревшим поведением, неработающим функционалом? Приходилось ли отвечать за него по SLA? Если хотя бы на часть из этих вопросов вы ответили да, то вам точно будет интересен наш доклад, в котором мы расскажем, как наша сплоченная команда выбиралась из этого ада.
Clinton Nixon describes some common problems found when inheriting legacy PHP applications and how to deal with them. He presents a solution that will encapsulate business logic and clean up the view layer without requiring a full-fledged MVC framework.
PHP 7.1 is all ready to replace 7.0, adding even more features and goodness to the ground-breaking previous version.
Visibility for class constant, key specifications for list, void return type, mcrypt() deprecation, negative offset and warning for integer conversion.
We'll cover new features, deprecated ones and incompatibilities, so you're ready for your next migration.
Transforming legacy PHP applications with Symfony2 and VarnishCraig Marvelley
The careerswales.com platform manages the education and professional progression of millions of people in Wales. When challenged with upgrading its ageing application stack to suit modern standards, we devised a solution with Symfony2 at its core. In this talk I'll discuss how the new stack was implemented, focussing on how we took advantage of Symfony2's first-class support for reverse-proxy Varnish to phase the deployment of the new system and improve performance by a significant amount. I'll also talk about the API we created to bridge its SQL Server / MySQL database platforms, and how Symfony2 was used to provide a single-sign-on solution across all of its web applications.
So you have spent the last few years building PHP applications but now the business requirements have changed and you need to provide a full featured REST API.
You could invest time, money and energy building it yourself, but have a look at Apigility. This is a full REST management application build on ZF2 allows you to tap into your existing legacy PHP application and provide 100% REST endpoints to the outside world.
In this talk I go over the challenges we had to deal with creating our own REST implementation, throwing it all away because we only had 20% of the features of Apigility and setting up and managing Apigiltiy using our existing legacy PHP application.
After this talk you will get a good understanding how to use Apigility to manage your REST API̢
Practical tips for dealing with projects involving legacy code. Covers investigating past projects, static analysis of existing code, and methods for changing legacy code.
Presented at PHP Benelux '10
XP Days Ukraine 2014 - Refactoring legacy codeDmytro Mindra
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.
У вас древний проект? Все зовут его «Legacy», а вас «неудачник»? Возможно они даже смеются над вами.
Давайте взглянем на ситуацию с другого ракурса. Все (все, Карл!) успешные проекты рано или поздно превращаются в Legacy-проекты.
Я затрону тему Legacy не просто как явление, а как возможность быть постоянно в тренде, прослыть супер-спецом (даже если ты знаешь всего два фреймворка), сделать карьеру, как делать, то что ты хочешь, а не то что тебя просят. Ладно, ладно, я наврал про два фреймворка, но все остальное чистая правда. Я покажу, что вы можете творить, имея правильный подход к Legacy коду.
Суть в том, что Legacy — это не грустно/уныло/немодно, это просто/клево/весело, если с умом подойти к задаче!
Agile Kitchen November 2013
Долгое время наша команда работала с собственным кодом, применяя различные методологии и подходы, писала качественный код и можно сказать жила в раю, но вот настал день, когда изменилось всё☺. Когда мы взяли на поддержку чужой объемный продукт и завязли по колено в легаси. Нам пришлось активно подключить наш agile mindset, чтобы изменить ситуацию и адаптироваться под новые условия. В общем, мы расскажем почему базовые практики того же scrum плохо работают с legacy, что нам пришлось изменить в команде и во взаимоотношениях со стейкхолдерами, и к чему это привело.
Ну а если вы еще сомневаетесь, то попробуйте ответить себе на пару следующие вопросов: приходилось ли вам брать на поддержку чужой продукт целиком с его непонятными правилами, устаревшим поведением, неработающим функционалом? Приходилось ли отвечать за него по SLA? Если хотя бы на часть из этих вопросов вы ответили да, то вам точно будет интересен наш доклад, в котором мы расскажем, как наша сплоченная команда выбиралась из этого ада.
Clinton Nixon describes some common problems found when inheriting legacy PHP applications and how to deal with them. He presents a solution that will encapsulate business logic and clean up the view layer without requiring a full-fledged MVC framework.
PHP 7.1 is all ready to replace 7.0, adding even more features and goodness to the ground-breaking previous version.
Visibility for class constant, key specifications for list, void return type, mcrypt() deprecation, negative offset and warning for integer conversion.
We'll cover new features, deprecated ones and incompatibilities, so you're ready for your next migration.
Transforming legacy PHP applications with Symfony2 and VarnishCraig Marvelley
The careerswales.com platform manages the education and professional progression of millions of people in Wales. When challenged with upgrading its ageing application stack to suit modern standards, we devised a solution with Symfony2 at its core. In this talk I'll discuss how the new stack was implemented, focussing on how we took advantage of Symfony2's first-class support for reverse-proxy Varnish to phase the deployment of the new system and improve performance by a significant amount. I'll also talk about the API we created to bridge its SQL Server / MySQL database platforms, and how Symfony2 was used to provide a single-sign-on solution across all of its web applications.
So you have spent the last few years building PHP applications but now the business requirements have changed and you need to provide a full featured REST API.
You could invest time, money and energy building it yourself, but have a look at Apigility. This is a full REST management application build on ZF2 allows you to tap into your existing legacy PHP application and provide 100% REST endpoints to the outside world.
In this talk I go over the challenges we had to deal with creating our own REST implementation, throwing it all away because we only had 20% of the features of Apigility and setting up and managing Apigiltiy using our existing legacy PHP application.
After this talk you will get a good understanding how to use Apigility to manage your REST API̢
Practical tips for dealing with projects involving legacy code. Covers investigating past projects, static analysis of existing code, and methods for changing legacy code.
Presented at PHP Benelux '10
"Этот код плохой, его нужно переписать". Слышали? Как обосноватьMaksym Bezuglyi
Как на языке бизнеса доказать необходимость переписывания кода. Как бизнес может объяснить инженерам, что этого делать не нужно, либо как сделать это правильно с перспективы бизнеса.
От заката до рассвета | Максим Безуглый | Zlit TechZlit
Светлое будущее.
Карго-культ.
Деловые отношения между бизнесом и разработчиками.
Человеческие и профессиональные отношения между фронт и бек разработчиками
Семён Факторович (Noveo) рассказывает о карьерных лестницах и различных профессиях в IT-индустрии, 20.02.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
День ADV на Russian Digital Week: Масштабирование решений - проекты, которые ...ADV/web-engineering
Доклад Алексея Строева, технического директора ADV/web-engineering, на секции ADV на Russian Digital Week 2013 (http://conf.tagline.ru/program/7/mgmt-prod-hr). Секция была посвящена повышению качества производимых студиями интернет-проектов.
Tech Talks @NSU: Рассказ о разных профессиях в IT-индустрии, или почему не вс...Tech Talks @NSU
http://techtalks.nsu.ru
20 февраля 2013. Рассказ о разных профессиях в IT-индустрии, или почему не все выпускники IT-специальностей пишут код (Семён Факторович, Noveo)
«Семен Факторович (Noveo, Новосибирск) рассказывает о разных профессиях в IT-индустрии и о вариантах карьерного роста IT-специалиста»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
DevOps Fest 2020. Максим Безуглый. DevOps - как архитектура в процессе. Две к...DevOps_Fest
Сотни вопросов о структуре и процессах, которые ставят и решают архитекторы и практики DevOps на примере решений в своем проекте.
Взаимоопределяющие вопросы архитектуры, DevOps, бизнеса и разработки.
Взрыв сложности - представьте, что вместо простого gmail подобного почтового SPA вам нужно построить и развивать новый sendmail на сервере + thunderbird для клиентов (desktop, мобильную и веб версию) по SAAS multi tenant модели.
IT CAMPUS. How to Stop Worrying and Clear Your Technical Debt [RUS]Alex V. Petrov
В конференционном блоке слета IT Campus 2014 (Калужская обл., 25 – 27 июля 2014 г.) состоялся доклад Алексея Петрова на тему «Как перестать беспокоиться и погасить технический долг?». Из него слушатели узнали, что такое «технический долг» проекта и почему разработчики — не единственные, кто должен про него знать; что нужно для выплаты долга, в чём состоят «техническая инфляция» и «техническое банкротство»; когда можно принимать «технический долг» и чего следует опасаться; как оценить «технический долг» и как его правильно погашать. Завершило дискуссию обсуждение мифов и заблуждений, сопровождающих метафору «технического долга», и рассмотрение личного опыта докладчика и участников слета.
Как не стать заложником одной платформы (MBLTdev)Алексей Панфилов
Презентация с конференции MBLTdev "Как не стать заложником одной платформы" на примере Parallels Access. О том как мы добивались кросс-платформенности в нашем приложении.
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
В последнее время во фронтенде появляется столько нового и внедряется настолько быстро, что не все успевают осознать последствия. Хорошо это или плохо? Рассмотрим некоторые новинки с точки зрения «за», а главное – «против».
Конференция FrontTalks, Екатеринбург, 19 сентября
Видео: https://vimeo.com/107694664
5. Технический долг
Разница между идеальным техническим
решением и тем решением, которое
принимается сейчас
К долгу относится только реализация:
“КАК” сделано, а не “Что”
@maxbeard12
6. Технический долг
Разница между идеальным техническим
решением и тем решением, которое
принимается сейчас
К долгу относится только реализация:
“КАК” сделано, а не “Что”
=> ДОЛГ РЕАЛИЗАЦИИ
@maxbeard12
7. Долг реализации
• неверные архитектурные решения
• “костыли” - “временные” решения
• невозможность рефакторинга
@maxbeard12
11. Долг реализации (бороться как?)
“***ь, чтоб дебажить эту судорожную сраку так время есть, а
чтобы рефакторить нету” (с)
Что будем делать?
@maxbeard12
12. Долг реализации (бороться как?)
“***ь, чтоб дебажить эту судорожную сраку так время есть, а
чтобы рефакторить нету” (с)
Что будем делать?
@maxbeard12
13. Долг реализации (бороться как?)
“***ь, чтоб дебажить эту судорожную сраку так время есть, а
чтобы рефакторить нету” (с)
• архитектура: баланс между “продумали” и
“перемудрили”
• “костыли” - только так, чтобы легко исправить в
будущем и с фиксацией долга
• РЕФАКТОРИНГ с умом
@maxbeard12
14. Долг реализации (бороться как?)
http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-
technical-debt
@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
26. А что в итоге?
Технический долг:
• долг реализации
• технологический долг
• процессный долг
• долг компетенции
Кругом долги, как страшно жить :)
Бери да помни:
не штука занять, а штука отдать (с)
@maxbeard12
В последнее время обсуждение того, что такое технический долг и к чему он приводит постоянно идет в сообществе. Как правило, все строится вокруг того какие технические решения принимаются и почему. Для нас, людей занимающихся разработкой программных продуктов, техническим решением является и то как мы будем делать (архитектурно), и то каким языком программирования будем пользоваться, и то какие практики будут использоваться, и то как это будет тестироваться, и тд и тп. Соответственно и долги будут свои в каждой из этих областей. И поборов, хотя бы одну из них мы серьезно облегчим себе жизнь.
Как это не странно, нет устоявшегося определения технического долга. Уорд Каннигем дает его расплывчато. Зато все знают, к чему этот долг приводит.
Если попытаться его сформулировать, то получится следующее.
Обратите внимание на КАК. К долгу не относятся те фичи, которые мы не сделали. К долгу можно отнести только то, «как» фичи были сделаны. Например, долгом может считаться несоответствие в общем то работающего UI, каким-либо руководствам, стандартам и тп.
То есть получается, что мы говорим о долге реализации. Что мы под ним понимаем?
К долгу реализации можно отнести то, что обычно и называют техническим долгом.
Кстати картинку смастерил на основе идеи @cartmendum (М.Дорофеев)
Есть идеи почему она такая?
Так вот, приобрести этот долг можно и приняв неправильные архитектурные решения, и добавив "костыли" в коде, и упростив процесс тестирования оставив там только "успешные" сценарии. Сюда же добавим и невозможность рефакторить исходный код, которая вызвана отсутствием тестов, что зацикливает эту проблему и вводит в клинч, когда все больше времени требуется на добавление новых фичей, потому что постоянно умирают старые. Или наоборот "рефакторится" все направо и налево, а проверяют все это тестировщики ручками.
Шаг вправо, шаг влево…
ногу поставил, а вытащить стремно, понимаешь что вонять будет…
Возражения вида "все равно все сделают через ж**у" плохи уже тем что что предполагают не делать вообще ничего.
Надо стараться оставлять мир код после себя чище: там где чисто – стыдно мусорить.
Сюда же относится и популярная теория разбитых окон: если появляется одно разбитое окно и оно не ремонтируется, то скоро много окон в здании будет разбито.
?
А давайте как и раньше?
Архитектура: совет дать очень сложно. Самый напрашивающийся (и популярный) вариант: легко расширяемая, легко тестируемая и тд, и тп. А что это? И насколько это нужно будет в будущем (принципы YAGNI). Стараемся соблюдать баланс
Наши горячо любимые костыли – использовать можно (ну никуда без с них). Но если используем, то только в тех местах, где они просто исправляются. Костыли недопустимы в архитектурных решениях. Фиксация этого долга обязательна (бага, задача и тп)
Рефакторим только в тех частях кода, которые касаются текущих задач (особенно это касается тех, кто работает с тестировщиками)
Картинки по Книбергу
Предваряя возможный вопрос про legacy код. Кстати, а что это такое?
Что делать? Вот как то так
Ответ очень простой
На самом деле все уже давно придумано за нас. Читаем, изучаем, применяем. Метод Микадо.
На самом деле все уже давно придумано за нас. Читаем, изучаем, применяем. Метод Микадо.
У меня на глазах пример использования С++, когда часто можно наблюдать осторожность (мягко говоря) во внедрении С++11, когда отказываются от использования boost'a, когда продолжают писать свои мега-крутые "велосипеды" игнорируя open-source библиотеки.
Все это приводит к замедлению разработки, снижению качества и даже к снижению мотивации у людей, потому что они используют "несвежие" инструменты.
Как правило эти ограничения накладываются из-за опасения того, что использование новые технологий несет риск сдвига по сроков (изучение), выявления возможных проблем и тд.
Но, если нет возможности изучать это на работе, то изучай сам, приходи к начальнику и рассказывай (а главное показывай), как можно сделать круче (проще, быстрее и тд)
Изучение других языков тоже помогает. Когда я возвращался к С++ после программирования на Python, я постоянно задавал себе вопрос как сделать на C++ так же круто (удобно, просто) как на питоне. Оказывается можно - boost, C++11. Получается не так изящно, но гораздо удобнее, чем голые плюсы.
Время от времени встречаю команды в которых не работает ни один из этих пунктов.
Отсутствие веры, желания, понимания важности этого всего приводит к тому, что эти задачи, как правило с нижайшим приоритетом, накапливаются в списке общих задач. Потому что у нас всегда есть суперсрочные и суперважные для продукта задачи. И как следствие, только для того чтобы просто понять, что свежесобранный сетап не работает, приходится тратить от 10 мин до N часов (зависит от навороченности продукта).
Я не буду объяснять зачем это все надо, это тема отдельных докладов по каждому и пунктов.
Тут рецепт простой: надо просто взять и сделать. Никто этого за вас делать не будет. Это ваша профессия, то, за что вы получаете деньги. Мастерство, если хотите.
Особенно классно (для меня как менеджера), когда разработчики сами это делают. Я про CI много слышал, даже игрался. Но как то не пошло. Год назад в команде появился человек, который просто сказал, «а давайте я сделаю». Взял и сделал. Через месяц остальные с удовольствием подключились в игру «найди полезный плагин для Jenkins»
?
Возникает из-за узкоспециализированной разработки, когда в команде есть человек(и) с уникальными знаниями.
Это усугубляется отсутствием обмена знаниями или, хотя бы, обмена возникающими проблемами и принятым по ним решениям.
Такое можно наблюдать в масштабе и целой компании, и даже маленькой команды. В итоге, принимаются решения заведомо неверные, которые у человека разбирающегося в вопросе вызывают дикое удивление. И это нас возвращает к долгу реализации.
А если спец уходит, то вообще возникает вакуум и код, которые он суппортил, превращается в магический лабиринт из языковых инструкций, которые реализуют "нечто". К нему стараются не прикасаться без крайней необходимости, при первой же возможности к нему применяется паттерн "invented not here" и он помечается черной меткой под названием "переписать".