Legacy-код — это рак

http://www.sitepoint.com/legacy-code-cancer/
  • Перевод
Все чаще и чаще я вижу, что люди уклоняются от новейших технологий, делая выбор в пользу обратной совместимости. «Мы не можем повышать минимальные требования к PHP до 5.5, потому что у нас 50% пользователей еще на 5.4» говорят они. «Нет никакого способа обновиться до Guzzle 4+, у нас бекенд на версии 3 и переделывать его слишком долго и дорого». И самый лучший аргумент от WordPress: «Мы не может придти к полному ООП, потому что большинство пользователей сидят на shared-хостингах с 5.1 или не знают про MVC».

Нонсенс.

Legacy-код – это большое НЕТ


Возможно, это спорный вывод, но я твердо уверен, нет места для legacy-кода в современных системах. Скажу несколько слов, прежде чем вы начнете точить свои вилы и зажжете факелы. Я имею ввиду, что не должно быть ни малейшего повода поддерживать старый функционал, вы добавляете обновления задним числом к старой версии только потому, что некоторые люди все еще используют ее. Даже если этих людей большинство — не делайте так.

Для уточнения: исправление ошибок предыдущих версий до тех пор, пока их контракт на долгосрочную поддержку не закончится, да. Добавление нового функционала, который можно выпустить в версии X, в версии X-1, только для того, чтобы не обижать пользователей X-1 — абсолютно и 100% нет. Аналогично, добавление X-1 кода в версию X только потому, что он может «пригодиться», должно быть признано недопустимым. Если вы по-прежнему берете с людей плату за X-1 и строите свои апгрейды поверх этого, то у вас очень плохой бизнес-план.


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

Если вы когда-нибудь делали проекты на ZF1, то знаете, этот фреймворк — вихрь из костылей и анти-паттернов. Когда приложение начало показывать признаки ухудшения из-за увеличения трафика, я перестроил фронтенд наиболее интенсивно используемой части приложения полностью на работу через ajax и вызовы API. Нагрузка резко упала и этим мы купили себе достаточно времени для переноса всех остальных частей приложения на Zend Framework 2. Тем, кто делал что-то подобное известно, что это все та же смесь из костылей и анти-паттернов, но чуть менее плотная.

Я пытаюсь сказать, что большие изменения и рефакторинг может произойти лишь в том случае, когда за ними стоят способные люди. Если все что вы делаете — это сплошные agile-митинги и мозговые штурмы, то никакое количество LTS контрактов не может помешать вам глупо выглядеть в течение пяти лет.

Даже если вы делаете бесплатную и/или open source работу, конечно же вы не должны ломать совместимость для X-1 пользователей. Делая им одолжение, развивая старые версии, при глобальном обновлении вы можете столкнуться с потенциальной потерей обратной совместимости. Просто усвойте одну вещь — они должны либо приспособиться, либо умереть.

Так все же почему мы должны изгнать legacy-код из современных систем?

Бесконечное LTS проклятие


Подписываясь под подходом «поддерживаем все так долго, как только можем», вы хоронитесь в бездонную яму, и, глядя на себя через несколько лет, когда вы окажитесь вынуждены поддерживать четыре различные версии вашего продукта, вы будете биться головой об стену из-за того, что не отказались от пользователей V1 и V2, если могли. В попытке сохранить аудиторию разработчики часто выходят за рамки своих возможностей и несправляются под гнетом тонн legacy-кода. По той же причине WordPress и оказался в своем нынешнем состоянии. Не позволяйте приковывать себя к старой версии.



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

Поддерживая старые версии слишком долго, вы насылаете на себя WP-проклятье. Старые версии уязвимы, их поддержка требует все больше сил и усилий по исправлению багов. Потратьте лучше эти часы на создание новых версий и наймите разработчиков, которые будут помогать пользователям с переходом.

Вы отчуждаетесь и негативно влияете на продвинутых пользователей


В последний раз я сталкивался с отчаянным legacy-кодом, когда устанавливал CMS, что оказалось очень трудным занятием в среде Vagrant — не только из-за проблем с symlink, которые сейчас широко известны всем (даже создателю Vagrant), но и с тем, что многие оставляют устаревшие версии CMS, т.к. часть модулей/плагинов еще не выпустили свои обновления. Раз нет обновлений модулей, то к чему обновлять ядро? Зачем торопить события, если ты к ним не готов?

Оставляя legacy-код в новой версии, вы в конечном итоге получаете монстра Франкенштейна, который вроде как по-прежнему работает, но плохо, и новый код, имеющий потенциал, не может его развить из-за беспорядка в унаследованной кодовой базе. Такой подход хоть и делает работу компаний-разработчиков, которые все еще застряли где-то в 90-х, проще, но в тоже время продвинутым пользователям становится сложнее работать с продуктом. Решениями, принятыми для толпы, которая уже давно и безнадежно отстала от технологий, вы отчуждаете и негативно влияете на продвинутых пользователей, способных принести гораздо большие деньги.



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

Неудачи иногда предвещают успех


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

Большинство отговорок вроде «пока еще не хватает Py3 пакетов» и «у нас слишком много кода в Py2, чтобы переписать все это» получают от меня ответы — «портируйте то, что вам нужно» и «Бедные программисты, их заставляют писать код», соответственно. Согласен, тут было несколько аргументов, но и те, как правило, берут в пример проекты, которые были изначально неправильно спроектированы, что и вылилось в их абсурдно большой размер.

На самом деле сейчас противостояние Py2 против Py3 уже превратилось в разлом, по обеим сторонам которого стоят программисты. Но многие не задумываются о том, что к тому времени как будет Python 4, люди, которые так яростно отказывались от перехода на версию 3+ будут по прежнему оставаться на Py2 и несовместимость станет еще больше. К тому моменту они могли бы уже освоить другой язык, а не противиться изменениям в текущем. С другой стороны, те, кто «отважился» переступить через разлом и переписал свой код на 3+ без долгих колебаний, получат все новейшие возможности будущих версий с нулевыми трудозатратами.



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

Приложения vs Библиотеки/Пакеты


Также есть вопросы по поводу противостояния приложений и библиотек. Другими словами, если правило «не устаревать» применимо для приложений, например при получении нового релиза фреймворка, то должно ли оно распространяться и на библиотеки?



Да.

Библиотеки, получившие бамп X+1, должны четко следовать пути к прогрессу — с момента, когда ваша версия библиотеки стала публично доступна, поддерживайте только багфиксы последней.

Приложения, которые используют такие библиотеки, находятся в более сложной ситуации из-за их зависимости от API, которые, возможно, могут измениться. Разумный подходом будет ждать отзывов из комьюнити о стабильности, прежде чем начать переход. В течении переходного периода, как старая, так и новая версии библиотеки/фреймворка могут оставаться в использовании, и после того, как все необходимые части будут модернизированы, старая версия должна быть удалена. Ведь это не займет много времени, правда?

Не бывает достаточно большого приложения


«Но Бруно, некоторые приложения огромны и их переписывание займет несколько месяцев», скажете вы. «Переход с ZF1 на ZF2 — это год работы!», на что я отвечаю: чушь. Нет достаточно большого веб-приложения, апгрейд которого займет подобные сроки. Я пойду еще дальше и скажу, что на самом деле нет веб-приложений достаточно больших, которые могли бы сравниться по размерам с Symfony или Zend.

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

Схема обновления


Как правильнее всего обновляться? Есть только один приемлимый вариант обновления программного обеспечения, которого должны придерживаться разработчики независимо от популярности их приложения/библиотеки:

  1. Создайте новую ветку для новой версии
  2. Пометьте старую версию/ветку как deprecated
  3. Публично заявите, сколько вы еще будете поддерживать старую версию
  4. Предупредите всех пользователей старой версии
  5. Внедряйте новые функции ТОЛЬКО в новой ветке, в старой — багфиксы
  6. Когда время жизни старой версии истечет, обрывайте все концы. Не исправляйте, не советуйте, вообще удалите упоминание о старой версии из документации. Убейте ее.

После прохождения данной процедуры вы никогда не получите в наследство неприятности.

Один из проектов, следущий этому пути — Guzzle. У него есть 3+ версия и 4+, для тех, кто хочет жить в ногу со временем и всегда быть на пике прогресса.

Вывод


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

А что думаете вы? Следует ли legacy-код хранить неограниченное время? Определенное число версий? Возможно не все? Как вы относитесь к legacy-коду в сторонних проектах? Должен ли разработчик волноваться о проблемах с legacy в библиотеках, которыми он пользуется? Ошибся ли я в этой статье? Данным постом я хотел начать дискуссию об этом — в конце концов, мои взгляды на проблемы и переживания — лишь моя точка зрения. Дайте знать в комментариях ниже.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 43
  • –1
    С Py2 против Py3 всё не так однозначно, как написано в статье, это известно любому питонисту.
    Но если рассматривать статью, как наброс, то получилось вполне.
    edit: скорее всего именно как наброс Бруно её и писал, судя по количеству комментов к другим его статьям в блоге.
    • +13
      Пишу на Python 2, на 3-ю версию переходить пока не планирую. А зачем, собственно? Профит от этого весьма туманен, в отличии от головняка с переписыванием и тестированием всего.
      Рак — это новизна ради новизны. Если легаси технология на 100% удовлетворяет текущим потребностям, то тратить ресурсы на ее замену это какое-то контрпродуктивное дрочево. Работает — не трогай, в общем.
      • +4
        А где провести черту, когда уже будет пора уходить с Py2 на Py4/5/6?
        • 0
          Или когда Py2 совсем перестанет поддерживаться сообществом и разработчиками либ, или когда Py3/4/5 предложит мне какие-то действительно крутые и нужные фичи. Использовать Py3 для новых проектов и сейчас ничего не мешает, в принципе.
          • 0
            когда можно провести черту, когда можно переселяться в новый, большой удобный дом/дворец/личный город? Что мешает это сделать сейчас?
            Привычен и вполне достаточен старый? Нет денег на новый дом?

            Нужно просто помнить, что для бизнеса — программирование это всего лишь часть бизнес-плана, и терзания по поводу версии, заказчику до лампочки. Нужно сделать чтобы все работало по ТЗ и как можно дешевле.
            Просто в НОРМАЛЬНОМ бизнес-плане, вопрос дешевле включает в себя разумное дешевле.
            Переплачивать просто за новое решение ради нового решения (вдобавок внутренности все равно видят ТОЛЬКО айтишники) — совершенно нет смысла.

            • 0
              Когда Python 2 перестанет запускаться или понадобится библиотека, которой под Python 2 нет.
              • 0
                возможно, речь отчасти о том, что когда появится библиотека, которой нету в Py2, то вам придется сразу перепиливать всё приложение. если же заранее запустить этот процесс — всё может быть немного менее болезненно
            • +1
              Ну как сказать… тумана как такового нет. Все достаточно ясно. asyncio, улучшенный GIL, unicode и так далее…
              • 0
                asyncio

                Для Py2 есть много достойных либ и фреймворков реализующих то же самое.

                улучшенный GIL

                Нууу, кординального улучшения производительности thread based параллелизма в CPython он не дает, и если нужна скорость — то в любом случае прийдется использовать процессы :(

                unicode

                С тем что в Py3 юникод реализован более адекватно — я согласен, но не могу сказать, что работа с ним в Py2 сильно напрягает.
            • +6
              Все это конечно очень интересно.

              А примеры успешных проектов, следующих данным советам есть?
              • +2
                Многие так рассуждают, а побеждает все равно С++ и python 2.
                • 0
                  Будто бы что-то плохое.
                  • +1
                    Ну явно хорошее, если legacy побеждает. Вообще, любое решение по поломке обратной совместимости, обрекает тысячи незнакомых людей на лишнюю работу, а люди не любят делать лишнюю работу даже во имя чего-то светлого и великого типа функции print вместо оператора.
                    • +1
                      Кстати, если говорить о С++, то в случае с более новыми версиями есть ряд действительно интересных в реальной жизни новшеств (auto, лямбды, улучшения по части метапрограммирования, итп.) которые люди и сами хотят использовать без какого-либо принуждения со стороны разработчиков языка. Жаль о Python вряд-ли можно сказать то же :(
                      • 0
                        Ну, не то чтобы совсем нельзя. В Python 3 — exception chaining, аннотации функций, синтаксис для keyword-only аргументов.
                        extended tuple unpacking, nonlocal, отдельное целочисленное деление, расширенный функционал range(slice, count, index...), yield from.
                        Сам уже где-то год как полностью перешел на python 3. Использую в основном в научной сфере(numpy, scipy, matplotlib, cython) и слегка tornado. Год назад еще были отдельные косяки с некоторыми библиотеками, а сейчас всё ок вроде бы.
                • +5
                  Был бы Бруно бизнесменом, он бы думал по другому.

                  ps: Лично я гневно против легаси, но иногда он маст би.
                  • +18
                    Пусть автор попробует писать код на фреймворке, который с каждым релизом меняет api, не заботясь об обратной совместимости, посмотрим, насколько его хватит.
                    • +5
                      Эти пользователи — мертвый груз, они должны быть уничтожены вне зависимости от того сколько денег они вам приносят. Дайте им возможность перехода и двигайтесь дальше, если они способны, то догонят вас. Если же нет, то они того не стоят.


                      Просто пример из жизни:

                      В рабочем проекте мы привязаны не столько к версиям SDK и прочих third-party (которые мы поддерживаем в максимально актуальном состоянии), сколько к версии операционной системы, которую мы поддерживаем (что закрывает для нас возможность использовать САМУЮ актуальную версию некоторых third-party и, в результате мы иногда сами повторяем функциональность более новых версий). И, с одной стороны, это наша боль и наше страдание.

                      А с другой стороны, инком, который генерят пользователи, сидящие на «неактуальной» версии операционной системы — достаточен чтобы оплатить большой отдел разработчиков, которые и поддерживают эту старую систему. И еще останется. В частности на людей, занимающихся глубинным рефакторингом и пишущий код с большим количеством #ifdef для улучшения производительности на разных версиях. И вот смогли бы вы ДОКАЗАТЬ, что внедрение новых и хипстоватых инструментов даст вам такой бонус в новых пользователях, способный покрыть (и перекрыть) уже существующий доход?
                      • +11
                        А вообще — это программирование ради программирования. По-моему не стоит забывать, что программисты работают, чтобы решать задачи пользователей, а не для того, чтобы красиво и удобно разрабатывать.
                        Фраза «пользователи — мертвый груз» — это вообще, на самом деле, за гранью.

                        Можешь обосновать выгодность новых технологий для бизнеса (например, стратегической выгодой, что переход на новый инструментарий значительно увеличит ретеншн засчет повышения стабильности и быстродействия сервиса — и желательно в цифрах и на основе какого-то опыта) — вперед, делай. Не можешь — плачь, колись, продолжай жрать кактус.
                        • –2
                          Тут речь идет о разработке «for developers» приложений/библиотек/фреймворков/языков. Их основная задача как раз сделать так, чтобы можно было красиво и удобно разрабатывать.
                          • 0
                            И для этого есть прекрасный пример :-) Reactive Cocoa, которые пользуясь новыми фичами языка были вынуждены поднять минимальную версию iOS, причем значительно.

                            Или если ваша IDE в один прекрасный момент откажется собирать для старой версии.

                            Или компилятор C++, который после обновления откажется компилировать старый код и не предложит инструментарий для миграции.

                            Вообще — в этом плане очень хорошо поступили разработчики XCode — делая какое-то существенное и значимое изменение — они вместе с тем предлагают и инструментарий по адаптации вашего кода к этому.
                            И это хорошая практика.

                            В остальных случаях — можно понять разработчиков, но это их решение приносит иногда весьма существенные затраты на адаптацию. И черт его знает, насколько это хорошо в общем смысле.
                            • +1
                              Разработчики — тоже пользователи, если рассчитывать только на новых, то старые уйдут и создадут плохую славу (заслуженно), так что новых и не появится. Несовместимые изменения иногда приходится делать, но это должен быть компромисс, либо должно быть четко обозначeно, что это альфа/бета версия и на продакшене использовать пока нельзя. Иначе это действительно программирование ради программирования.
                        • +15
                          Нет в мире достаточно больших приложений, которым нужно более двух месяцев для полного перехода, а если и есть, то они должны быть переписаны с нуля — веб намного проще, чем вы всегда предполагали.


                          Прекрасный максимализм. Не знаю юношеский или просто по неопытности.
                          • +9
                            В статье много идеализаций. Особенно в экономической части:
                            Эти пользователи — мертвый груз, они должны быть уничтожены вне зависимости от того сколько денег они вам приносят.… они того не стоят.
                            Сколько бы денег не приносили — они того не стоят? А если миллионы? А если миллиарды?
                            Потратьте лучше эти часы на создание новых версий и наймите разработчиков, которые будут помогать пользователям с переходом.
                            Мы только что отказались от миллиардов, так на какие деньги нанимать разработчиков? Впрочем, ответ следует дальше:
                            Решениями, принятыми для толпы, которая уже давно и безнадежно отстала от технологий, вы отчуждаете и негативно влияете на продвинутых пользователей, способных принести гораздо большие деньги.
                            На самом деле сложно оценить кто больше принесёт денег: продвинутые пользователи, внимание которых ещё нужно заслужить, или толпа, которая уже приносит нам деньги?

                            В целом я тоже за прогресс, но не стоит забывать и о бизнесе. Если не будет денег, то не будет никаких разработчиков и новых продуктов вообще. Статья какая-то однобокая.
                          • 0
                            Я конечно согласен с автором, что мажорные релизы имеют право ломать совместимость с прошлыми версиями, но «забить на клиентов» которые приносят деньги? ХаХа.

                            Если контора где я работал сделала бы именно так, то ее бы уже не существовало. Да, мы пишем новый проект, но старый кормит всю компанию и его тоже надо поддерживать и не важно что ему уже 8 лет. Выйдет новая более крутая замена — но этого времени надо еще дождаться.
                            • +3
                              Всё вокруг Lagacy-код. Включая цивилизацию и структуру ДНК. Давайте выкинем всё на фиг.
                              • +1
                                Как это верно! Долой жирафов!
                                ru.wikipedia.org/wiki/Возвратный_гортанный_нерв

                                • +3
                                  Это что — у нас сетчатка чувствительной стороной внутрь головы направлена. Вот это говнокодище в продакшен выкатили.
                                  • 0
                                    Да, ладно! Серьезно? Пруф есть? (пригодился бы)
                                    А, вот креативисты, используют глаз как подтверждение своей т.з. Дескать: «не может эволюция создать такой сложный орган как глаз». Хм. И к кому после этого аппелировать?

                                    Хотя… тут время разработки продукта нааамного превосходит время использования. Иными словами, что бы (условно) с «windows 3.1» перейти на «windows 10» надо пройти реинкарнацию…
                                    • +1
                                      Ну, в той же википедии, а дальше по ссылкам )
                                      Вот, например, картинка.
                                      www.vetmed.vt.edu/education/Curriculum/VM8054/EYE/RTNADGRM.JPG
                                      Light идёт сверху, а Pigment Cell внизу. И Signal обратно пошёл.
                                      • +1
                                        Ну так может это наоборот фича — защита от черезмерной засветки и «сжигания сенсора»? Зачем фичу сразу багом-то называть?
                                        • 0
                                          Это не баг, это просто со старого проекта код тупо перетащили. Нужно было бы отрефакторить, но решили просто нейроны пустить через сетчатку туда и обратно. Правда слепое пятно образовалось, но вообще работает, так что лучше не трогать.
                                          • 0
                                            Оп-па, выходит, в этой цитате с баша есть доля правды:
                                            Kotyabra: Как все в природе мудро устроено! Заметили? Ведь дырочки на шкурке у кошки именно там, где у кошки глазки!
                                            Torin: Если б кошку писали программисты, глаза были бы на ж*пе, под кожей, а для передачи изображения использовалась бы система зеркал!

                                            bash.im/quote/406246
                              • +7
                                Ненавижу, когда меня заставляют переходить на новые версии программ, старые версии которых прекрасно работали и решали свои задачи.

                                Зачастую в новых версиях появляются новые баги, портится дизайн, снижается скорость работы (из расчета производителя, что я должен обновить не только их программу, но и купить новый компьютер/телефон); внедряются шпионские и другие ограничительные функции, появляется реклама, выкидываются «устаревшие» функции, которые именно у меня находили хорошее применение. Если продукт сложный — то у меня могут быть свои разработки, связанные с ним, и при переходе на новую версию все мои старые разработки ломаются, их нужно адаптировать. Мгновенно и бесплатно это не делается. Обновление версии почти всегда сопряжено для пользователя с издержками. И далеко не всегда выгода от обновления превышает эти издержки.
                                • +2
                                  Добавлю. Разработчику всегда кажется, что новая версия во всем лучше старой. И по молодости лет я, бывало, удивлялся, что пользователи моих программ не всегда страстно желают немедленно обновить версию и отказаться от старой навсегда. Потому, что продукт был критичный, в новых версиях могли (помимо моего желания и старания) сломаться некоторые функции, которые раньше надежно работали. Тестировать абсолютно все функции было нереально. Вот и осторожничали пользователи, обновляясь только тогда, когда выгода от обновления (новые нужные им функции) превышала издержки (риск того, что сломаются старые; затраты на тестирование).
                                  • +2
                                    И еще скажу. Если вы пишете программу не для себя (а профессиональное и коммерческое программирование, как правило, только для этого и существует) — то вы должны понимать, что вы только разработчик программы, а не ее пользователь. Ваш труд — разработка. А для пользователя ваша программа — это орудие его труда, его инструмент. Использование программы является для пользователя трудом. И как при использовании любого другого орудия труда, пользователь должен к нему приспособиться. Это занимает время и усилия; в период приспособления производительность труда уменьшается. Это как если вы научились хорошо забивать гвозди одним молотком, а производитель молотков постоянно совершенствует их, и заставляет вас постоянно менять молотки. Может быть, новые молотки где-то лучше старых, но к ним все равно надо приспосабливаться, пока рука почувствует баланс, и вы снова станете хорошо забивать гвозди новым молотком.
                                  • +3
                                    Скажите, где вы работаете, чтоб я точно знал, что с вами не имеет смысла связываться?

                                    P.S. я уже увидел что перевод, спасибо.
                                    • 0
                                      Bruno is a coder from Croatia with Master’s Degrees in Computer Science and English Language and Literature. He’s the editor of SitePoint’s PHP channel and a developer evangelist for Diffbot.com. He avoids legacy code like the plague and when picking projects makes sure they’re as cutting edge as possible. He’s a treadmill desk enthusiast and active (board)gamer who sometimes blogs.

                                      www.sitepoint.com/author/bskvorc/
                                      • +1
                                        Если молодой — еще есть шанс, что исправится. Юношеский максимализм проходит вместе с юностью.
                                    • +1
                                      Поскольку я вдоволь наслушался аргументов типа «ну мы уже столько тут написали, что переделать это не реально», или «а зачем? оно же как то работает — будем поддерживать» что бы не упало, то позволю себе согласится с автором статьи.

                                      Я стараюсь ставить вопрос иначе: Хотим мы внедрять, что либо новое, или нет? Нужен ли нам этот опыт?

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

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

                                      В общем, если желания нет, то никакие аргументы из серии «быстрее, выше, сильнее!» не будут восприняты.
                                      • 0
                                        Еще раз встряну насчет того, к чему все сводится.

                                        В подавляющем количестве случаев, вопрос «хотим мы внедрять что-либо новое или нет», стоит ПОСЛЕ вопроса «кто за это заплатит». Редкие исключения — когда что-то делается с нуля и стоимость практически одинакова.
                                        • +1
                                          Если программисту постоянно нужно думать о бизнесе и деньгах, то пропадает все веселье :c
                                          • 0
                                            Ну так пускай веселится, если не хочет думать о бизнесе и деньгах. Только за свой счёт, пожалуйста.

                                            P.S. Даже я это понимаю, при том, что программист и люблю веселье.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.