Пользователь
0,0
рейтинг
25 ноября 2013 в 20:33

Разработка → Как разрабатывать неподдерживаемое ПО перевод

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

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

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

Не используйте системы контроля версий
Я всегда удивляюсь, когда сталкиваюсь с большими проектами, написанными в последние несколько лет без системы контроля версий. Когда вы не используете контроль версий, следующий программист должен будет выяснить, какие файлы являются частью текущей системы, а какие — устаревшими или бэкапами. Следующий программист не будет иметь ни единого коммит-сообщения или чэнжлога, чтобы получить историю кода. Я рассказывал, как не использовать системы контроля версий в моей статье «Введение в Ущербно-Ориентированное Программирование».

Настраивайте свою среду разработки. Как можно сильнее.
Не облегчайте следующим разработчикам начало работы надо кодом. Требуйте специфичные версии языков и утилит, и не забудьте убедиться, что они конфликтуют с версиями, которые поставляются с операционной системой. Настраивайте Eclipse, или Visual Studio, или vim как безумный, затем пишите макросы и скрипты, которые работают только с этой средой. Не храните образ диска или сценарии для репликации вашей среды разработки, не беспокойтесь писать документацию — все и так будет интуитивно понятным.

Создавайте максимально сложную систему сборки и развертывания
Для веб-сайта развертывание на тестовый или боевой сервер должно быть чем-то из этого:

svn up
git pull
hg pull

Программисты могут спорить о простоте и элегантности кода, а затем резко разворачиваются и строят наиболее сложные и причудливые системы сборки и деплоймента. Это является одной из неотслеживаемых вещей, которые программисты делают без надзора клиента или ПМ'а (или без их понимания), поэтому это легко выходит из под контроля. Когда вы объединяете в цепочку восемь разных инструментов с различными языками сценариев, даже не думайте делать документацию.

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

Пишите все с нуля
Не связывайтесь с хорошо известными фреймворками вроде Django, Rails или CakePHP. Вы можее написать лучший шаблонизатор, ORM, алгоритм сортировки или хэширования. Я чешу затылок каждый раз, когда вижу комментарии вида «быстрее, чем нативный метод» или «замена библиотечной функции PHP, потому что порядок параметров — отстой».

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

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

Используйте кучу разных языков программирования и оставайтесь ультрасовременными
Каждый день HackerNews и Reddit жужжат о новых крутых языках. Попробуйте их за счет клиента. Любой приличный программист может выучить новый язык в мгновение ока, так что если следующий программист, который будет работать с вашим кодом, окажется нубом, то это не ваша проблема. Различия между языками, несовместимые API и форматы данных, различные требования к серверной конфигурации — это веселые приключения и посты на StackOverflow. Я действительно видел веб-сайты на PHP c вставками на Ruby, потому что каждый знает, что Ruby — круто, а PHP — отстой. Полувымученное кэширование, обрезанные проекты на Rails и Node.js и, особенно, NoSQL-решения («Они лучше масштабируются!») — это мой хлеб с маслом.

Где же программистские советы?
Не так заметно, если ваш код прекрасно объектно-ориентирован или блестящ и функционален — ведь программисты почти всегда видят спагетти-код, который им надо поддерживать. Я хорош в использовании diff, grep и Ctags, трассировке кода, рефакторинге и отладке. Я понимаю код. С самым прекрасным, элегантным кодом все еще сложно работать, если нет системы контроля версий, если слишком много зависимостей и настроек, если нет тестовой/промежуточной системы. Это как найти одну чистую и мило украшенную комнату в доме «Hoarders».
Перевод: Greg Jorgensen
Дмитрий @vovochkin
карма
27,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (93)

  • +3
    Интересный, но больно «грубый» перевод…
  • +14
    Обычно в наследство достается только каталог htdocs/. Какой-такой контроль версий?..
    • +2
      «Как какой контроль версия? Я же не дурак, я бакапы сохранял, за 2010 год, за 2011 и вроде в начале 2013. А с год назад что-то там поменяли мне в коде и сайт не работает с тех пор. Почините пожалуйста.»© :)
      • +1
        Видел использование git. Только там было около 5 коммитов. С продакшеном естественно не соответствовало.
        Так как «ну контроль версий мы использовали, но не часто. А код сразу заливали на сервер… на прямую, через перезапись». Так и не понял, зачем же они тогда его использовали.
    • +1
      А если по верх ещё чем-то зашифруют.
      Так же интересен код, пропущенный через всякий софт облегчающий вес. Ну когда убирают табуляцию, пробелы, закомментированные куски.
      • +1
        Хорошо, если только через компрессор. А то и обфускатором пройтись могут.
      • 0
        Видел JS на 27к строк кода с убранными пробельными символами (перенос строка оставили). Наверху было написано «код сжат, не редактируйте здесь, редактируйте исходник». Исходника нигде не было.
  • +40
    Хм.
    А может, проблема, в том, что программисту совсем никак не оплачивают написание документации и описание систем развертывания?
    По моему опыту, заказчику надо:
    а) чтобы работало здесь и сейчас
    б) чтобы это обошлось по возможности как можно дешевле

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

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

    Если бы автору ПО заплатили за то, чтобы он вернул свой технический долг — разве он бы этого не сделал?
    • +1
      >Мне никто ни разу не предлагал дополнительно оплатить обустройство системы так, чтобы это было понятно следующему разработчику

      Ну да, я прямо вижу, как заказчик с порога начинает кидаться словами вроде svn, github, и тому подобное. Откуда им знать что это такое?

      Продавайте хорошо, нагружая необходимыми допами, либо продавайте «как можно дешевле».
      Сколько стоит выгрузка на гитхаб?
      Сколько стоит написание минимальной документации?
      • +18
        Я встречал заказчиков «Ты начинай программировать, а мы пока подумаем, что писать в ТЗ». А вы говорите про документацию. :-)
        janvarev прав. В общей массе (если брать фриланс или частные заказы), клиенты действительно хотят быстрее, дешевле и без лишних затрат.
        Я сам спрашивал не раз, нужна ли документация, инструкция по коду, инструкция по настройке сервера. Всем всегда нужно было. Но стоило заикнуться о доп оплате за это и увеличении сроков, сразу же были отказы.
        • +5
          Я встречал заказчиков «Ты начинай программировать, а мы пока подумаем, что писать в ТЗ»
          Да, частый диагноз. Как правило объясняют это тем, что проект надо запустить как можно скорее, поэтому надо как можно скорее начать его реализовывать, иначе «все пропало, гипс снимают, клиент уезжает»©

          Нередкий симптом этой аудитории, что не только ТЗ могут «позже предоставить», но и с оплатой попросить подождать, т.к. «Вы же понимаете что сроки очень важно, Вы нам проект срываете, это неприемлимо».

          Помогает отчасти проникновенная речь на тему «Вы же понимаете как уникален Ваш проект, его нельзя делать по типовым шаблонам, поэтому сначала нужно ТЗ». Про оплату объяснить труднее:)

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

          А потом удивляются почему «технический долг» образовался…
          • 0
            Наша общая миссия состоит в просвещении заказчика. Заказчик тоже способен учиться (за исключением таких, которым уже ничто не поможет, но их ничтожно мало).
            • 0
              Тех кто готов учиться или хотя бы понимать. Тех я на руках носить готов. С такими заказчиками всегда приятно работать.
              А вот те кто только делают вид, что слушают. А потом через месяц разработки по согласованному ТЗ и срокам. Приходят с «У моей секретарши племянник, в школе делал сайт, вот он говорит вы всё не правильно делаете и денег много просите и вообще всё можно было сделать за пару дней на Joomla».
              • 0
                Зато когда через полгода после этого этот же заказчик рекомендует вас «тебе племянник будет городить ахинею про Joomla, так ты его не слушай — эти сделают как надо вообще… может и по срокам не очень быстро, но зато будет вообще то, что надо» — неужто не будет приятно.

                Я вообще, при объяснении тех или иных процессов экстраполирую на автомобильную тематику, и всем сразу становится все понятно. К примеру «чтобы построить хорошую машину, надо же чтобы и в двигателе была электроника, позволяющая его диагностировать и своевременно сигнализировать о неполадках… не достаточно же просто к железной коробке приделать 4 колеса и двс». Тогда все становится понятно. Особенно хорошо это работает когда случается что-либо нештатное, и возникает ситуация «я же говорил… а если бы я тогда не потратил 2 дня на разработку вот этого, я бы не смог быстро сделать это и это».
                • +2
                  Я тоже стараюсь использовать в общении не одни технические термины. А привожу аналогии из обывательской жизни. Где-то помогает, где-то нет.
                  С последним заказчиком сейчас буду судится. По началу тоже, слушал меня, соглашался. Даже порой останавливал объяснения с «да я всё понял». А потом пошли непонимания с «я такого не слышал», «я думал о другом». При том когда составлялось ТЗ и я ему предлагал если два варианта реализации, возможность выбора. Естественно расписав все плюсы и минусы каждого. Спустя время, он взял СЕОшников, те посмотрели на готовый функционал и предложили тот вариант который забраковал сам заказчик. Мне же было высказано, что это именно то что нужно и необходимо всё переделать. При том напоминание того, что он подписал ТЗ, показ ему того ТЗ от которого он отказался. На него никак не повлияло. Тупо включил режим дурака «я этого не помню». =)
                  • +6
                    Похоже на осеннее обострение. Тоже недавно получил подобную ситуацию, только у меня круче. Заказчик «позабыл» как подписывал акты приёма-сдачи работ. Мало того, начал намекать, что это я якобы подделал документ. Ему кое-как его же юристы объяснили что отказываться от собственной подписи чревато потерей лица и репутации. Не говоря уже про все шансы опрокинуться в суде и плюсом схлопотать 306 статью УПК (заведомо ложный донос).

                    Заказчик кстати занимается услугами в сфере микрофинансов. Разработка по-понятиям у этих ребят похоже в крови. Зарёкся вообще с такими общаться на будущее. И всем теперь советую обходить микрофинансистов стороной.
                  • 0
                    *стерто*
          • 0
            Про оплату объяснить труднее:)

            Если ситуация «Вы же понимаете что сроки очень важно, Вы нам проект срываете, это неприемлимо», то довольно просто.
        • +1
          Еще умиляют такие разговоры заказчиков (из реальной жизни): «Да нет… зачем все расписывать? Когда вы все сделаете, мы потом посмотрим и скажем вам, что не так».
          • +3
            У меня было ещё один подвид: «Сделай мне несколько вариантов, я выберу что мне понравится». :)
            • +1
              Это да. Вообще, по опыту — если давать заказчику «несколько вариантов», то он увлечется выбиранием настолько, что лучше сразу его бросать. Вариант должен быть один, по четким требованиям в соответствии с задачами. Один вариант — будет какая-никакая работа и прогресс… несколько вариантов — заказчик бесконечно будет играть в биг-босса.
          • 0
            Ну так вы деньги тогда вперёд берите. А как расскажу что не так — ещё берите.

            Agile в действии.
      • +1
        > Ну да, я прямо вижу, как заказчик с порога начинает кидаться словами вроде svn, github, и тому подобное. Откуда им знать что это такое?

        Когда отсутствие технического долга является важной частью проекта — чаще всего знают, или у меня есть возможность им об этом сказать и быть понятым.
        Хороший пример: меня пригласили быть архитектором проекта и руководителем группы программистов. Я должен написать часть кода, поставить процессы, а затем уйти, чтобы на меня, как на высокооплачиваемого архитектора, больше не тратились деньги.
        Разумные и осмысленные условия? Более чем — и я их готов принять.

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

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

        (Нет, наверное, еще бывает, что программист-раздолбай за один день улетает обретать просветление в Гималаи, и никому ничего не говорит… или фрилансер пропадает на три месяца, так что до него не дозвониться… но тут настолько серьезная проблема с людьми, что технический долг является к ним, скорее, довеском)
        • +3
          Куда более распространён совсем другой случай: сайт создаётся как часть большого, не-ITшного по своей сути, проекта и заказывается ровно также как заказывается витрина в фирме по изготовлению витрин и закупается мебель. То есть: как разовая задача, предполагающая сроки, оплату и сдачу. Задуматься о том, что существует ещё какой-то там «технический долг» они не могут потому что они не понимают чем создание сайта отличается от расстановки мебели.

          А отличается он даже не тем, что созданием сайтов люди занимаются совсем недолго, а тем, что технический долг в заказанной мебели виден кому угодно (если у вас столы соединены с лавками, то и ежу понятно, что их придётся переделывать, чтобы увеличить расстояние от стола до лавки...), а вот «технический долг» даже специалист по внешнему виду сайта не увидит (но он хотя бы догадывается о том, где он может таиться, а заказчик-то свято уверен, что ничего кроме пикселей вообще не существует в природе!).

          Исполнитель же, поставленный в условия, когда ему «насилуют мозг» зачастую сильно больше, чем ожидалось изначально и заранее знающий, что поддерживать это ему не нужно будет использует все возможные способы получить экономию «здесь и сейчас». А после нас «хоть трава не расти». Знание же того, что заказчик этого подвоха заведомо не увидит до выплаты денег вряд ли кого-то стимулирует делать «на века», так ведь?
          • 0
            А зачем с такими заказчиками задумываться о техническом долге? Кто не понимает, что сайт — это не витрина и не шкаф, а система, через которую осуществляются продажи и т.п., у тех сайт полгода-год просуществует, да и подохнет с миром в забвении.
        • –1
          Ситуация же в статье происходит, на мой взгляд, чаще всего ровно в одном случае — заказчик просто «рвет» отношения, возможно, не оплачивает обещанную часть работы, и после этого пытается найти хоть кого-то, кто заставит его систему заработать.


          Ещё частая — сайт сделан, сдан, всё оплачено, через некоторое время требования меняются, но разработчику уже предлагаемые условия неинтересны. Или его просто не найти через пару лет.
    • 0
      При чем тут намереное упрощение?

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

      1. создать репо на битбаскете ( там нет ограничения на количество приватных репозиториев в отличии от гитхаба)
      2. использовать стандартные фреймворки и библиотеки — ( для мелочевки flask, для чего посерьезнее django)
      3. комитьтся после каждой фичи
      4. pip, virtualenv, fabric для разветки девелоперского и боевого окружение

      ничего из этого не требует сколько бы нибыло серьезных затрат но сильно облегчает жизнь как мне так и последующему программисту ( например мне через полгода)
      • 0
        Нужно только учесть, что люди, которые знают как всё это делается — они уже люди с опытом и потому стоят дороже, а понять за что — заказчик не может. Ведь и сайт, сделанный «на коленке» за три рубля студентом как-то работает и сайт, сделанный профессионалом вроде вас — тоже. Так зачем платить больше?
        • 0
          Я немного про другое. Оратор выше спрашивал зачем прилагать дополнительные усилия для упрощения последующего сопровождения проекта.

          Но сейчас мы уже в такой стадии что инструменты достаточно развиты чтобы выкатывать приличный результат без дополнительных усилий. Скорее даже наоборот.
          • +5
            Но сейчас мы уже в такой стадии что инструменты достаточно развиты чтобы выкатывать приличный результат без дополнительных усилий. Скорее даже наоборот.

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

            Например, возьмем рекомендацию "(Не) Добавляйте зависимости от определенных версий библиотек и ресурсов..."
            Предположим, мой клиент захотел иметь возможность генерации DOCX-документов на сайте, и, конечно, для него это одна из многих фич, которая не может оцениваться дорого.
            Что сделаю я? Отыщу в интернете библиотеку, поставлю зависимости и быстро встрою в свой проект. Нет, я не буду специально запутывать код, но:
            — Буду ли я специально документировать зависимости этой библиотеки? Вряд ли.
            — Буду ли я специально в ней разбираться и вытаскивать одну функцию, которая мне действительно нужна, избавляясь от зависимостей? Вряд ли.
            — Буду ли я документировать способ встраивания? Тоже вряд ли.

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

            Вообще сложность систем всегда будет в среднем чуть выше, чем сложность стандартных инструментов для их создания. И мне кажется, что эти стенания относительно непонятности программ традиционны и больше зависят от людей, чем от самого процесса программирования:
            — раньше кто-то писал на ассемблере? — конечно, разобраться в программе сложно.
            — кто-то писал на Фортране? — тут же столько зависимостей, разобраться сложно
            — у вас ООП? — ну, у вас более 50 классов, я ничего не могу понять в вашей архитектуре
            — вы используете фреймворк и все делаете по гайдам, но вы прикрутили N сторонних библиотек? — черт возьми, в этом сложно разобраться!

            А истина, мне кажется, проста — нужно поддерживать доверительные отношения с программистом, который вам создал (заметьте!) часть инфраструктуры(!) бизнеса. Тогда в нужный момент он вам объяснит все непонятные места (а то и поправит код), и эти проблемы даже не возникнут.
      • 0
        Ну вот 4-й пункт вызывает сомнения. Репо и библиотеки/фреймворки сейчас стандарт де-факто (если нет желания подсадить заказчика на иглу), но вот инструменты автоматизированного или автоматического развертывания окружения и деплоя приложения требуют серьезных (пятью минутами не обойтись) затрат.
        • 0
          Да тут я немного слукавил.

          Мой воркфолу годится только для достаточно стандартизированного окружения и python разработки и пришел я к нему не сразу. Да и то некоторую степень ручной настройки они требуют. К примеру python-dev или libevent все равно руками ставить приходится. Ну и плюс работает только в unix подобных средах. И как справедливо заметили требует определенного профессионального уровня и опыта.

          В любом случае если процесс стоит правильно то деплоймент руками никто не делает — проще написать скрипт. А уж что тут будет fabric, maven, gradle, phing. Не важно и для любого стека есть свои стандартизированные инструменты. И на мой взгляд их использование серьезно экономит свои же усилия. А если проект не первый то затраты еще меньше. А это уже самодокументация

          Важный момент всетаки тут стек. К примеру java — там все давно заточенно под максимально простой и стандартизированный деплой приложения. Ruby, Python — тоже самое. Велосипедописание бессмысленно. За PHP я не слежу особо, но вижу что в этом направлении сделано очень много.
          • +1
            Сделано очень много, но субъективно более популярны в мире PHP инструменты для/на Ruby — chef, puppet, capistrano или для/на Java, что создает некий барьер для использования. Плюс со стандартизацией в мире PHP вообще всё плохо. Разве что самый распространенный способ деплоя — заливка по ftp (для продвинутых — по sftp). Да и VCS часто используются как простые бэкап-система — одна ветка и код в ней толком ничему не соответствует — ни дев серверу, ни стэйдж, ни продакшену. В общем инструменты есть, а культуры их использования — нет :(
            • +1
              ИМХО их скорее все же нет. Как вы справедливо отметили (если я правильно понял) с инструментами из других миров есть определенный барьер. Так например мои попытки использовать на проектах скажем TeamCity или Jenkins или еще какие инструменты из другого мира регулярно терпят фейл, по разным причинам. И кастомер вроде был не против, но споткнувшись один раз о какую нибудь проблемку, даже маленькую, связанную с применением инструментов с разных платформ, второй раз, третий и в итоге принимается решение использовать инструменты на php.

              А тут все не всегда здорово. Например вот не всегда удается скомпилить less`ы с помощью lessphp (попробуйте скомпилить css`ку кастомного бутсрапа с помощью plessc… стабильного релиза который компилится lessc под nodejs). Можно долго перечислять. А скажем про такой позор, адъ и израель как композер лучше вообще молчать.

              Вот и выходить, что инструменты вроде есть, но большинство из них в зачаточном состоянии. Вот и сижу я в полвторого ночи, приделываю как мне кажется нужную мне плюшку к PHPCI — еще один зародыш 18ти летней платформы. А кто еще, если не мы? — Десант Опен сурс он такой :)
    • 0
      проблема, в том, что программисту совсем никак не оплачивают написание документации и описание систем развертывания?

      Скорее дело в том, что есть кустарное производство и есть промышленное. В кустарном производстве каждая вещь делается почти как в первый раз, в промышленном изготовление вещей поставлено на поток, а значит есть и инфраструктура контроля качества. И эти виды производств — совершенно разные сферы, с разными заказчиками, разными деньгами, разными требованиями.
  • +5
    Забыли упомянуть о том что как можно чаще необходимо использовать coffee, typescript, dart, livescript, и желательно одновременно.
    • 0
      Разве вас заставляют поддерживать именно TS или CS? Слава богу на выходе у них вполне читабельный JS.
      • +1
        да, особенно если файлы сжаты
        про «разжиматели» не надо :)
        • +3
          Если предыдущий разработчик был дауном, то какая разница на чем он писал, его код все равно будет невозможно поддерживать :)
          • 0
            А кто вам сказал, что он был «дауном»? У него в ТЗ было что-нибудь про поддержку сайта? Не было? Было только про зелёненькие кнопочки и синие ссылки? Ну так чего вы паритесь: зелёненькие кнопочки и синие ссылки на месте, всё работает, ничего больше [с точки зрения заказчика] в природе нету — какие могут быть претензии к автору?

            У него самого, кстати, все исходники вполне могут быть… ну какое-то время, пока он их не потеряет.
            • +2
              О да — излюбленная позиция!
              «Этот пункт в ТЗ есть? Нет? ДЕЛАЮ ЧТО ХОЧУ», ну и потом «Это ваши проблемы, раньше надо было думать»
              Слова не мальчика но мужа!
              • +7
                Ну а вариант «Добавьте одну кнопочку, только одну. Кнопочку КУПИТЬ.» И ведь чтобы с ЛК было, с уведомлениями, системой для манагеров и так далее. Но подумаешь… одна кнопочка. :)

                С обоих сторон есть головотяпство, не стоит только одну сторону обвинять.
      • –1
        Какая-нибудь навороченная система деплоя может тупо затирать все изменения внесенные в JavaScript при каждом коммите. Или вообще JS не деплоить. То есть чтобы получить возможность нормально править JS, нужно провести нетривиальную для как минимум первого раза работу.
      • 0
        Вы, возможно, не поверите, но во многих организациях в репозитории и правда попадает именно coffee, less и т.п. и писать требуют именно на них.

        Т.е. по сути, люди диктуют не только то, на чём и что нужно писать, но и с помощью чего.
        • 0
          В это я поверю и даже более, считаю это нормальной практикой. Но я не думаю, что вас заставят в одиночку поддерживать код на coffee некоего прогрламмера, который написал некую хуиту и свалил, о чем, как я понимаю, и идет речь.
          • 0
            А я вот это не совсем понимаю. По крайней мере, на данный момент вижу в таком решении достаточно много неудобства для компании, как минимум в поиске JavaScript-программистов. Знаю несколько хороших js-программистов, которые не пользуются coffee, т.к. нативный js им удобнее.
    • 0
      Упомянули.
      Каждый день HackerNews и Reddit жужжат о новых крутых языках. Попробуйте их за счет клиента.
  • +16
    Работать с чужим кодом безусловно высокое искусство, но это крайне крайне интересно.
    Документированный и понятный код скучен и не несет в себе отпечатков личности писавшего:)
    Очень любим «возвращать технические долги», кроме шуток, это реально интересно.
    Смотреть и разбираться как кто и почему реализовал, это куда веселее чем тупо кодить очередное app()->encode.
    Бесплатным бонусом идет знакомство с чужими подходами, которых иначе бы и не увидели, а это всегда полезно, не замыкаться в рамках. И при чем эти подходы зачастую бывают на удивление элегантны, хотя (или благодаря этому?) и не вписываются в стандартные рамки паттернов проектирования и нормализованных баз.
    Код с техническим долгом не обязательно плох и не обязательно создан плохим программистом.

    По поводу создания технического долга — присоединимся к комментатору выше.
    Обычно прайс выглядит так.
    Создать сайт — Х денег и Y времени.
    Создать задокументированный по всем правилам сайт — 3*X денег и 3*Y времени.
    Мало кто из заказчиков готов платить.
    К тому же, для разработчика знакомого с проектом изменение документированного сайта занимает нередко больше времени чем недокументированного. Потому что документированный нельзя быстро и грязно хакнуть плюнув на гайдлайны. Носишься с ним как с писаной торбой:)
    • +4
      Никогда не подозревал, сколько матных слов я знаю, пока не открыл исходники от гореписак для битриха.
      Так что да, интересно.
    • +1
      >Работать с чужим кодом безусловно высокое искусство, но это крайне крайне интересно.

      А уж ЧСВ-то как поднимает ;)

      «Ну блин, ну какой идиот это писал?? Надо же вот так, вот так и вот так. Эх, какой я все-таки умный, не зря мне деньги платят» :D
      • 0
        «Ну блин, ну какой идиот это писал?? Надо же вот так, вот так и вот так… Ой! Ведь это я и написал… Ну-ка… Действительно, гениально написано!»
        • 0
          Нет, не так. "… Ой, это ведь я написал… Фигасе я тогда фигню порол… Зато сейчас — уууххх! Надо же, как я вырос за такое короткое время!" :D
  • +4
  • +5
    Спасибо за статью! Перевел одну из статей по ссылке: Ущербно-ориентированное программирование.
    • +1
      Спасибо! Исправил в посте ссылку — теперь она ведет на ваш перевод.
  • +11
    Выбиваю технические долги. Дорого.
  • 0
    Знаю другой способ разрбатывать неподдерживаемый код. Философия Unix: «Делайте что-то одно, но делайте это хорошо». Кажется никому в голову не приходит «отладка, исправление, поддержка и расширение функциональности» diff или grep или echo. Они просто работают. Без поддержки.
    • +8
      Именно точно так. Работают сасем-сасем без поддержки. А тот факт, что новый diff вышел 24 марта (текущего года, разумеется), grep вышел 26 октября (то есть меньше месяца назад), а coreutils (куда, в частности, входит команда echo) 14 февраля (догадайтесь какого года с одной попытки) — это так, случайность, к делу отношения не имеющая.

      Ах, да, echo же у нас ещё и в bash встроена. Не будем говорить на тему сочетаемости философии «делайте что-то одно, но делайте это хорошо» с программой, включающей в себя десятки команд, но вспомним-таки, что последняя версия bash'а тоже вышла в этом году — 7 марта, если быть точным.

      Любая сколько-нибудь сложная программа требует поддержки. Даже если у вас в ней всё идеально её всегда можно «чуть-чуть отрефакторить» так, чтобы в ней появилась ошибка, которая стрельнет в каком-нибудь весьма экзотическом случае. Говорю как человек, совсем недавно участвовавший в исправлении подобной ошибки (проявляющейся, разумеется, только и исключительно на Windows8) в программе длиной 315 строк. Стоит ли говорить о том, что написана программа была задолго до выхода Windows 8?
      • 0
        bash~>uname -a
        Darwin uvelichitels-MacBook-Pro.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
        bash~>diff -v
        diff (GNU diffutils) 2.8.1
        Copyright © 2002 Free Software Foundation, Inc.
        #По мне, ничего, работает.

        Разве хорошая программа обязательно должна включать в себя десятки команд? Разве это делает программу лучше?

        «Любая сколько-нибудь сложная программа требует поддержки.» Бесспорно. И чем меньше, тем лучше, на мой взгляд.
        • +1
          Поддержки не должно быть ни много, ни мало — ровно столько, чтобы программой можно было без проблем пользоваться. Но на практике оказывается что либо программа правится, либо обрастает набором костылей «снаружи»: глаза б мои не видели этих ваших «ничего, работает». Из-за вставшего в позу Apple'а, который не хочет обновлять системные утилиты приходится либо вставлять в программу кучу костылей, либо носить с собой половину GNU системы.

          Собственно код, который обсуждается в статье обычно тоже «работает». Ну там, «за исключением пары мелочей»
      • 0
        > а coreutils (куда, в частности, входит команда echo) 14 февраля (догадайтесь какого года с одной попытки) — это так, случайность, к делу отношения не имеющая.
        Тем не менее, не могу не отметить, что несмотря на редкие изменения, в основном, это дерьмо динозавров окаменело десятки лет назад вместе с багами, безумными алгоритмами и прожорливыми аллокаторами.
    • 0
      Подход Unix приводит к поистине живучей системе — если у вас отвалится diff, то всё остальное продолжит работать.
  • +3
    На самом деле, занятие актуальное. Выросло уже целое поколение говнокодеров начинавших когда то программистов, которые уже набрались опыта и расселись по уютным местам а проекты на которых они учились за деньги заказчиков теперь начинают выплывать. И зачастую тот кто когда то наколбасил наваял в одной конторе теперь исправляет чужие шедевры в другой. По сути это круговорот где одни заложили заработок для других. И это правильно, т.к. скупой должен платить дважды. Съэкономил на спецах, связался с мальчиком «умельцем», будь готов в будующем заплатить за это второй раз. В конечном итоге виноват тот кто принимал решение с кем и как работать, теперь пусть платит если решение было не правильным. И мне их не очень то и жалко, т к. когда то они с довольным лицом мне объявляли «мы решили с вами не работать т.к. Вася Пупкин вызвался сделать это в 3 раза дешевле и быстрее». От спецов им всеравно не уйти, выйдет только это теперь дороже и особого выбора у них уже не будет, и поделом.
    • +3
      Почему же не уйти? Иная контора успевает закрыться раньше, чем у неё возникает потребность в настоящем спеце. А, если нет разницы, зачем платить больше? (с)
      • 0
        У меня сейчас ситуация. Клиент захотел «второй интернет». За 3 месяца разработки, бизнес его накрылся медным тазом и он погряз в долгах. Всё от умения планировать (пустить крупную рекламу о «крупнейшем сайте по зарубежной недвижимости», за 2 месяца до запуска альфа версии сайта) бюджет и сроки. Когда он понял, что бизнес в пролёте и решил его закрывать, увольняя народ пачками и отменяя аренду офиса в самом дорогом БЦ города. Мне была сказана фраза «Я дальше платить отказываюсь, сайт мне не нужен». Вот теперь иду в суд, буду пугать договором.
    • +2
      Как мне это близко. Бывает часто еще какой-нибудь человек из тех. отдела, начавший изучать чего-нибудь из языков программирования, пишет какую-нибудь ерундовину, это замечают. И на каком-то из собраний какой-нибудь менеджер выдвигает тезис «а зачем нам платить за ту или иную систему, если у нас уже есть талантище, написавшее свою чудо-хрень»? Выясняется, что это прямо-таки то, что нужно, только надо вот тут еще допилить, сюда приделать и вот там еще тоже неплохо бы выгружать в 1С. С этого момента, можно сказать, начинается ад.

      Этот товарищ из тех. отдела, обложившись книжками, допиливает то, что нужно… и система начинает жить. Ее передают в поддержку настоящим программистам с претензией «смотри ка, Иванов чего нагородил, а ведь он не программист, но родил это за неделю… теперь поддерживать это будете вы». Вряд ли кому-то будет интересно слушать про «говнокод». Максимум — все понимающе состроят «домик» из бровей. В основном реакция такая «сами дураки, ничего не могут, только инициативных мальчиков обсирать умеют».

      В итоге, «инициативный мальчик» идет дальше проектировать целевые системы, а программеры вынуждены закапывать себя заживо в говнокоде… или (кто поумнее) в порядке ультиматума переписывают все это по-нормальному, рискуя быть уволенными за «концентрацию на нецелевых задачах».
      • +3
        Зачем же закапывать себя в говнокоде? Закопайте «инициативного мальчика». Согласитесь с тем, что система мегагениальна, посыпьте себе голову песочком и скажите, что раз автор — это их гений, то, разумеется он сможет поддерживать свою систему лучше, чем вы.

        Тут главное — продержаться пару месяцев и очень сочуственно кивать головой, когда это чудо будет тонуть — однако при этом всячески и категорически отвергать попытки свалить работу на вас под предлогом «ну тут же совсем чуть-чуть осталось» (отговорка железная: «да-да, осталось совсем чуть-чуть, так что ты уж поднпрягись, а я за пивом сгоняю — можно даже на свои деньги).

        Главное — не переоценить себя и не спутать ситуацию, когда человек явно полез явно не в своё дело от ситуации, когда код, в общем, не так и плох, просто написан не совсем так, как вы привыкли. В первом случае — он утонет, фирма потерпит убытки, но вам-таки зарплату повысит, во-втором — можно и без работы остаться.
        • 0
          Не всегда программистов спрашивают о том, кого на какую должность поставить. Так же и в случае с этим гипотетическим гением.
      • 0
        Да просто надо жестко отстаивать свою позицию перед руководством. А то как это часто бывает — спустили разнорядку сверху, маленький босс взял под козырек и спустил всё вниз. Внизу побурлили да и стали делать как велено.

        Кстати тот «человек из тех. отдела» проделал одну очень важную работу — выявил реальные требования «клиента». Пусть сделал говно, но оно делает почти все что нужно «клиенту». Т.е. сделал прототип. Обладая этими знаниями можно здорово ускорить переписывание с нуля.
    • 0
      Выросло уже целое поколение говнокодеров начинавших когда то программистов
      И не одно поколение. И новые подрастают. Они неисчерпаемы.

      Съэкономил на спецах, связался с мальчиком «умельцем», будь готов в будующем заплатить за это второй раз
      К сожалению серьезный подрядчик в галстуке и с Макбуком тоже не гарантирует никакого качества. Если заказчик ничего не понимает в разработке ПО — нужна третья сторона. Независмый аудитор. А что, это интересная тема… пошел думать.
      • 0
        Аудитор — это хорошо. Но смотрите, какая штука. Где-то недавно мелькал пост на Хабре про то, как проводили аудит системы, управляющей городским транспортным потоком где-то в Австралии. Я потом специально искал по нерусским источникам — и правда, фирма-аудитор указала в своем заключении «игнорирование лучших практик» и что-то там еще архитектурное. Иными словами, они в заключении указали «говнокод». И самое интересное — это приняли как аргумент. Вот уже что меня чрезвычайно ошарашило. На моем опыте еще ни один менеджер серьезно не отнесся к тезису «я не могу это сделать быстро (качественно) потому, что там-то и там-то говнокод». Или «это надо переписывать, т.к. если это оставить так, то в последствии мы вообще умрем».
        • 0
          На моем опыте еще ни один менеджер серьезно не отнесся к тезису «я не могу это сделать быстро (качественно) потому, что там-то и там-то говнокод». Или «это надо переписывать, т.к. если это оставить так, то в последствии мы вообще умрем»
          Мы недавно в вопросах говнокода и технического долга стали применять следующую практику: если заказчик прессует по срокам, мы говорим, ОК, можно сделать быстрее, если того требует бизнес (читай закостылить). Но таким решением мы накапливаем такой-то технический долг в человеко-днях. Этот долг прописывается в ТЗ и заказчик это подписывает. В следующих итерациях у нас есть право этот долг истребовать.
          Правда заказчик(менеджер по продукту) у нас внутренний, а РП(я) — бывший разработчик. Это видимо нечастая схема
          • +1
            Условно «написать абы как, а потом переписать по-нормальному» — это еще и увеличение трудозатрат. Условно, на 50%. Повторю — условно. А как заказчик отнесется к увеличению себестоимости?
            • 0
              Условно «написать абы как, а потом переписать по-нормальному» — это еще и увеличение трудозатрат. Условно, на 50%
              Условно так: сделать нормально — 100ч. Сделать костыль — 20ч + 100ч долга.

              А как заказчик отнесется к увеличению себестоимости?
              У заказчика есть выбор — делаем сразу хорошо, в сумме дешевле, но конкретная фича появится позже. Делаем быстро — потом за это расплачиваемся.

              Все зависит от приоритетов проекта. Если время — на деньги никто особо не смотрит, если деньги — готовы увеличивать сроки. Приоритеты конечно заказчик определяет.
  • +5
    Очень-очень странно.

    Был у меня опыт… один серьезный заказчик располагал целым штатом «специалистов». Им нужно было тоже побыстрее и попроще. Реализовано было проще некуда — фреймворк Kohana, все очень стандартно, в их стиле с комментариями в коде, суммарно тысяч на 10 строк кода (своего). Когда выяснилось, что поддержка сторонним разработчиком этой системы — дело очень дорогостоящее (сумма в месяц была раза в 4 меньше, чем зарплата среднего разработчика из их штата), решено было расширить штат и забрать проект из поддержки.

    Ну что ж, все когда-нибудь прекращается. Передал проект. И тут началось:
    1. Какой такой Сфинкс? Нельзя было использовать какую-нибудь библиотеку на php для индексации поиска? Помилуйте, говорю, использована стандартная на тот момент версия Сфинкса — чего же может быть проще? На что представитель тех. отдела презрительно усмехнулся…

    2. В повседневной жизни мною используется Phing + несколько написанных тасков для него. Для слияния статики, оптимизации ее, для оптимизации картинок без потери качества и т.д. Слово тех. отделу того заказчика: «Вы вообще о чем? Зачем все это? Это все вообще ни к чему… вот потому, что вы гнались за ведьмами, у вас ничего и не вышло.» Тут уже я начал беситься… ну, думаю, ладно.

    3. Тех. отдел: «А на чем все это написано? Какая Кохана? Зачем? Мы все всегда сами пишем и все замечательно работает… а у вас теперь надо разбираться».

    И все в таком духе. Нет, с большинством тезисов автора я согласен — сам сейчас вынужден поддерживать неповоротливого мамонта, написанного в стиле «мама, я вчера выучил новый язык программирования php». Этот мамонт написан целиком в авторском стиле и в своем роде уникален. Его можно прямо весь было бы отправлять на говнокод.ру (царствие ему). Но, как правило, о системах контроля версий, требованиях, системах сборки и тестирования… хорошо, если отдаленно слышали или «на хабре почитывали». В противном случае на тебя смотрят как на какого-то дурачка, которому лишь бы не работать, а только бы чего-то новое, непонятное и ненужное внедрить.
  • 0
    Я бы сюда еще добавил следующие проблемы, которые могут возникнуть в будущем из за необдуманной разработки:
    1) Патч чужих модулей. Например, патч модуля memc для nginx. При этом такой патченный модуль может не работать в новой версии nginx, а свежая версия модуля не подойдет т.к. исходный модуль был патченный.
    2) Использование специальных структур конкретного языка (например serialize в php) так же может навредить проекту. Если потом возникнет желание прочесть эти структуры в другом языке, то придется искать для этого специальную библиотеку, которая не факт что будет работать идеально.
    3) Использование nfs, симлинков, как мне кажется, так же делает код проекта более запутанным.
    4) Использование экстенсивного пути развития проектов — использование большого количества серверов вместо оптимизации алгоритмов. Когда серверов много и между ними масса различных связей, поддержка такого проекта является нелегким делом.
    5) Иногда при использовании сторонних хранилищ создаются бд, например для sphinx, но при этом конфигуация sphinx не ложится в свн и возможно даже не бэкапится и может быть утеряна при определенных обстоятельствах.

    Что касается вставок на руби в пхп — я не совсем понимаю как это может помочь работе скрипта. А вот вставка на луа вполне логична при использовании eval в redis.
    Так же не вижу ничего плохого в том чтобы писать админку на пхп, а внешнюю часть на другом языке, который лучше для этого подходит, например на луа.
    Так же я придерживаюсь иной точки зрения по поводу nosql решений. Более того, я считаю что такие грузоемкие бд как mysql не должны быть вообще в продакшене. Их можно использовать для админки, но не для большого трафика. Возможно я просто не умею их настраивать, пользоваться временными таблицами и т.д.
    • –2
      Что касается вставок на руби в пхп — я не совсем понимаю как это может помочь работе скрипта.

      Я встречал вставки в php, ассемблеровского кода. Правда там форма клеила 2 ЕХЕ файла в один. Но всё же. :-)
    • 0
      MySQL оптимизировать не хотите, а алгоритмы оптимизировать хотите (а все мы знаем, что это за алгоритмы такие — по крону кеш разогреть и без этого кеша не дать работать приложению, использовать хитрые технологические решения, требующие тонкой настройки). Раскидывать по серверам (читай, использовать сервисы) не хотите, потому что это неудобно, а писать на несколькоих языках (превед, развёртывание системы локально) хотите, потому что это почему-то удобно.

      Оптимизировать на единственной машине есть смысл в том случае, если это даёт прирост в разы. Гораздо проще и дешевле поставить ещё пару серверов (месячная аренда одного сервера обойдётся в дневную зарплату программиста). Опять же, не всегда, но чаще всего.

      В любом случае писать нужно изначально так, чтобы в случае чего можно было разнести по разным серверам.
      • 0
        В любом случае писать нужно изначально так, чтобы в случае чего можно было разнести по разным серверам.

        На одном сервере это может привести к падению производительности.
        • 0
          Я с этим согласен. Я хотел сказать, что если есть возможность оптимизировать скрипты и использовать меньше серверов (не обязательно один), то лучше использовать меньше серверов, даже если проект финансово окупает большее количество железа.

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

          Я использую редис как основную бд во многих проектах. И речь не идет о банальном кешировании KEY=VALUE, в редисе есть масса интересных структур — sorted set, set, возможность использовать встроенный язык луа и т.д. Работает он при этом очень быстро. Но чтобы использовать подобные структуры нужно изначально ориентировать алгоритмы работы на них.

  • +2
    Создавайте максимально сложную систему сборки и развертывания
    В OpenSource такое к сожалению сплошь и рядом. Когда над сборкой проекта приходится камлать больше суток, потому что скрипты сборки, оказывается, требуют наличия Perl определённой версии, Python (2.x, и только 32bit, под 64 не соберётся), Ruby с определённым набором gem'ов, плюс активно используются bash и make. И всё это одновременно!
  • –1
    Интересно, они встречают такое?

    image
  • +1
    > Используйте кучу разных языков программирования и оставайтесь ультрасовременными
    Куча разных ЯП не нужны. Достаточно одного Common Lisp, который не более ультрасовременен, чем Python. ;)
  • 0
    Вот тут уже вообще непонятная мешанина из реальных советов и сарказма. Вероятно, дело в переводе.
  • +1
    Добавляйте зависимости от определенных версий библиотек и ресурсов

    По-моему это хорошая практика. У нас (в python) зависимости обычно выглядят как-то так:

    Flask==0.10.1
    Jinja2==2.7.1
    MarkupSafe==0.18
    

    Такой подход позволяет уберечься от потенциальных проблем при деплое в продакшен, когда обновление внешнего пакета рушит ранее работающую систему. Замечу, что такой подход конечно же не подходит для разработки библиотек.
    • 0
      В этом плане мне очень нравится современный подход в bundler (ruby):
      — gem'ы (единицы пакетного менеджера, библиотеки в частности) зависят нестрого (всякие >=, ~>), в репозиторий не включается информация о конкретных версиях библиотек.
      — приложения зависят от фиксированных версий библиотек (естественно, с учётом зависимостей в библиотеках), что гарантирует ту же среду на боевом сервере, как и среда разработки. Обновление версий библиотек и их зависимостей в таком случае делается вручную (через bundle update), не давая сторонним библиотекам «случайно» поломать код. Особенно это актуально, если библиотека молодая и API ещё не устаканилось.
      • 0
        не давая сторонним библиотекам «случайно» поломать код

        Работает только при наличии интеграционных/функциональных тестов, покрывающих использование этой либы.
        • 0
          Естественно. Это лишь гарантия, что библиотеки в production и в test окружениях будут иметь одинаковые версии. И то, если нет edge-зависимостей (на ветку в git-репозитории, например).

          P. S. В случае edge-зависимостей в Gemfile.lock указан конкретный коммит.
    • 0
      При условии наличия файла requirements.txt
      Разворачивал один проект. Долго с одной зависимостью воевал. Кое как выяснилось, что дело в сабмодуле, который только в ветке бэта тестирования лежит у разработчиков. И тянется на прямую с гитхаба.
    • 0
      Читать нужно как «Добавляйте зависимости от определенных версий библиотек и ресурсов, но нигде их явно не объявляйте — все и так должны догадываться».
  • 0
    Советы «Пишите все с нуля» и «Добавляйте столько стороннего кода, сколько можете» выглядят противоречащими друг другу. Интересно, какой из них более эффективен.
    • 0
      Почему «выглядят»? Они действительно противоречат друг другу. А насчёт эффективности: мы по какому критерию оптимизируем вообще? Первый подход экономит ресурсы компьютера, второй — ресурсы программиста. Потому в разовой системе, которая создаётся под одну-единственную выставку «своего» и через неделю после запуска умрёт «своего» кода должно быть как можно меньше, а в системе, которую мы собираемся запускать на Юпитер и поддерживать десятилетиями без возможности upgrade железа — наоборот. Ну а большинство проектов живут где-то посередине.
      • 0
        Оптимизируем по критерию, указанному в заголовке — «Как разрабатывать неподдерживаемое ПО». Судя по фразе «Ниже несколько практик, которым вам надо следовать в своих проектах, чтобы не оставить меня без работы», неподдерживаемость является именно целью, а не условием «поддержка ПО не предполагается, можете сосредоточиться на других приоритетах».
        Противоречие между советами можно и обойти. Например, написать алгоритмическую часть с нуля, а GUI — исключительно внешними библиотеками, причём самыми экзотическими. Или наоборот, GUI — на голом WinAPI (или как оно называется?), а алгоритмы — с применением кучи библиотек и пары движков символьных вычислений.

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