Вы получили или пришли на проект, которому d+дцать лет? PHP код был написан в перерывах между охотой на мамонтов и поэтому слегка не читаем? Вам предстоит это как минимум сапортить, как максимум — рефакторить или переписывать?

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

Это случается хотя бы раз в жизни каждого программиста, менеджера проекта или тимлида. Вы получаете целую кучу парного навоза. Если повезёт, то всего несколько миллионов строк. Первоначальные авторы давно улетели в тёплые страны, а документация, если она имеется, безнадёжно устарела.

Ваша задача: выбраться из этого бардака.

После того, как отпустила первая инстинктивная реакция (сбежать подальше), вы начинаете работать над проектом, отлично понимая, что руководители компании следят за вашими успехами. Провал не вариант. Но пока что, судя по раскладу, именно провал кажется наиболее вероятным исходом. Так что делать?

Мне (не) повезло оказаться в такой ситуации несколько раз. И мы с небольшой группой друзей выяснили, что при должных навыках это очень выгодное дело — брать на себя такие кучи дымящегося убожества и превращать их в здоровые поддерживаемые проекты. Вот некоторые хитрости, которые мы используем:

Проблемы legacy-кода знакомы подавляющему большинству разработчиков программного обеспечения. Процесс превращения кода в legacy неизбежен, ведь прогресс в программировании не стоит на месте. Проекты либо «умирают» навсегда, либо требуют постоянной поддержки и написания новых функций. Таким образом, в любом проекте на любом языке программирования legacy-код возникает и доставляет разные неудобства при дальнейшей разработке. На примере PVS-Studio, в этой статье я расскажу, как сразу начать использовать статический анализатор кода в своём проекте.

В TDD-сообществе существует совет, который говорит о том, что мы не должны использовать mock-объекты для типов, которыми не владеем. Я считаю, что это хороший совет, и стараюсь следовать ему. Конечно, есть люди, которые говорят, что мы вообще не должны использовать mock-объекты. Независимо от того, какого мнения вы придерживаетесь, совет «не имитировать то, что не ваше» – содержит в себе еще и скрытый смысл. Люди часто пропускают его мимо ушей, видя слово «mock» и впадая в ярость.

Привет. Меня зовут Иван Мельничук, я Head of Development Department в украинской IT-компании. В публикации хочу поделиться личными профессиональными подходами относительно решения вопроса legacy code в условиях стремительного развития проекта и рассказать о приемах, к которым прибегает наша команда в случаях “когда фичи нужно сдавать “на вчера”.

Разбираемся с проектом

Для того, чтобы передать насколько аккуратной, продуманной и кропотливой, должна быть работа с легаси, приведу аналогию с карточным домиком.


Именно так выглядит устаревший код. Если мы решим убрать или заменить хотя бы одну карту из этой постройки, мы рискуем завалить весь дом и сровнять его остатки с землей.

Примерно так же “ведет” себя легаси. Поэтому работа программиста, который взялся за задачу модернизировать и “вдохнуть вторую жизнь” в проект, должна быть в некой степени ювелирной. Большинство программистов пытаются избегать и вообще “спрыгнуть с темы” технического долга. Даже составил хит-парад самых распространенных цитат, которые приходилось слышать от программистов, оказавшихся в условиях legacy:

Хорошо, когда в команде есть кто-то более опытный, кто покажет что и как надо делать, какие грабли и за каким углом подстерегают, и где скачать лучшие чертежи велосипедов за 2007 год на DVD. Эта история о том, как желаемое было выдано за действительное, что получилось в результате, и как был преодолен кризис.

Это случилось в ту пору, когда я, имея весьма, как мне казалось, посредственный опыт в разработке, искал место, где можно из недоджуниора эволюционировать (или мутировать) хотя бы в уверенного джуниора. Неисповедимыми путями Господними такое место нашлось, в довесок к месту прилагался проект, и “олдскульный” программер, который за свою карьеру систем написал больше чем девок перепортил. “Отлично! Проект, а следовательно деньги на ЗП есть, наставник прилагается, живем!” — подумал я, но затем, как в описании к типичному хоррору, герои в темной тьме столкнулись с ужасным ужасом…

Данный материал посвящен работе по рефакторингу навигации в мобильной разработке.
В статье приведены примеры возможных проблем, а также выходов из сложных ситуаций, связанных с работой навигации в мобильной разработке на React Native.

Мы рассмотрим основные особенности и проблемы мобильного Legacy проекта, шаг за шагом пройдем цепочку действий, состоящую из постановки задачи, определения узких мест, поиска решений сложившихся проблем и получения желаемого результата.

Постепенно и незаметно складывается ситуация, когда сложность серьёзных C++ проектов становится запредельной. К сожалению, теперь C++ программист не может полагаться только на свои силы.

Привет!

15 февраля, в субботу, приглашаем на очередную встречу сообщества PHP-разработчиков в офисе Badoo. 

Митап будет целиком и полностью посвящен легаси, и вот почему. Мы часто слышим утверждения из разряда «о легаси все уже сказано», «о чем там рассказывать», «ну есть оно и есть, ничего не поделаешь». Но в то же время все продолжают читать и без конца рефакторить устаревший код, а возвращаясь с очередной конференции — вдохновленными новыми идеями и подходами — громко вздыхать и пускать скупую слезу на свой репозиторий.

Мы пообщались с разработчиками крупных компаний и попросили поделиться опытом. На встрече обсудим процессные и автоматические, тактические и стратегические подходы для борьбы с этим неприятным явлением. Будем надеяться, что эта концентрация разных практик и взглядов на легаси упростит кому-то жизнь.

Регистрация по ссылке, обязательная (важно: пишите свои данные кириллицей). Не забудьте дождаться подтверждения участия, оно придет дней за 10 до митапа. 

Первый доклад в 12:00. В программе пять докладов, практически не ограниченное свободное общение за кофе, викторина, розыгрыш билета на PHPRussia, а в качестве afterparty — очередная встреча сообщества BeerPHP Moscow. 

Toyota — мировой лидер автомобилестроения, один из самых дорогих автомобильных брендов и синоним слова «качество». Toyota известна своей сложной производственной системой, благодаря которой она стала мировым лидером. На её описание потребовалось 10 лет и 20 версий, в итоге появился документ «Философия Toyota 2001». Часть принципов из этой книги — кайдзен и канбан — используются в IT. Но эти принципы лишь часть системы постоянного обучения и непрерывного совершенствования, которая плотно интегрирована во все процессы корпорации.



В системе обучения много разных принципов и техник. Например, перед разработкой новой модели инженеры Toyota изучают передовые разработки поставщиков и технологии конкурентов: разбирают их автомобили, изучают и фиксируют удачные технические решения. При этом обучаются не только инженеры, но и вся компания. Для этого используются контрольные листки, матрицы качества, ретроспективы, таблицы навыков, базы данных стандартов и всех прошлых проектов. Всё это помогают сохранять и систематизировать знания, расти, обучаться и выпускать качественные продукты. Другими словами, в Toyota реализована почти идеальная система управления знаниями. Поэтому они лидеры.

История Toyota — отличный пример управления знаниями. Но что будет, если знаниями не управлять, а систему не выстраивать? Велосипеды, сломанные конвейеры, автобусы, «сжигание» денег на онбординге и legacy — все это случается с компаниями, когда они не задумываются об управлении знаниями.

It is easy to try a static code analyzer. But it requires skills to introduce it in the development of an old large project. If the approach is incorrect, the analyzer can add work, slow down development, and demotivate the team. Let's briefly discuss how to properly integrate static analysis into the development process and start using it as part of CI/CD.

Жил-был технический директор. Он жил долго и счастливо. И пригласили его на интересный и перспективный проект. Владельцы бизнеса размахивали руками, поднимая сквозняк в помещении — и рисовали маркерами прямо на оконных стёклах счастливое будущее, масштабность задачи, нули после первой цифры в зарплате. Звучит, как сказка.

Но я непросто так отметил, что техдир жил долго и счастливо. Потому что это был опытный техдир — и он знал, во что превращаются сказки, если из светлого зала из слоновой кости стейкхолдеров перейти в помещение, где стучат клавиатуры, кофе-аппарат перегревается от натуги, периодически доносится непереводимая игра слов обсценной лексики и сидят разработчики.

Техдир пришёл к ним, поздоровался и спросил: «Ребята, скажите честно, какой аццкий зверь меня ждёт в этом проекте? Потому что стейкхолдеры рассказали только о единорогах с радужными хвостами и розовых пони? Legacy, да?»

«Legacy, ...», — грустно ответили разработчики.

Сказка закончилась. Началась работа — и непростые решения.

If you use static analyzers, you will have, sooner or later, to address the task of making their integration into existing projects easier, where fixing all warnings on legacy code is unfeasible.

The purpose of this article is not to help with integration but rather to elaborate on the technicalities of the process: the exact implementations of warning suppression mechanisms and pros and cons of each approach.

Меня зовут Данил Мухаметзянов, я работаю бэкенд-разработчиком в Badoo уже семь лет. За это время я успел создать и изменить большое количество кода. Настолько большое, что в один прекрасный день ко мне подошёл руководитель и сказал: «Квота закончилась. Чтобы что-то добавить, нужно что-то удалить».

Ладно, это всего лишь шутка — он такого не говорил. А жаль! В Badoo за всё время существования компании накопилось больше 5,5 млн строк логического бизнес-кода без учёта пустых строк и закрывающих скобок.

Само количество не так страшно: он лежит, есть не просит. Но два-три года назад я начал замечать, что всё чаще читаю и пытаюсь разобраться в коде, который на самом деле не работает в продакшен-окружении. То есть, по сути, мёртв.

Эту тенденцию заметил не только я. В Badoo поняли: наши высокооплачиваемые инженеры постоянно тратят время на мёртвый код.

Я, как и многие программисты, довольно отрицательно отношусь к созданию велосипедов и изобретению колес и это более чем обосновано хотя бы стоимостью разработки для бизнеса. Но как показал мой опыт иногда приходится отходить от этого правила и, даже, получать от этого пользу. Я имею ввиду не только интерес и удовольствие от разработки, но и плюшки для проекта в целом. Об одном моем подобном опыте можно прочесть несколько слов под катом.

Most influential programmers say that code must be self-documenting. They find comments useful only when working with something uncommon. Our team shares this opinion. Recently we came across a code snippet that perfectly proves it.