Дорабатывать или переписывать

    Основная мысль этой статьи: переписывайте с нуля работающий и внедренный проект только под дулом пистолета.



    Далее, представим, что вы работаете один, и ни с кем не делитесь печеньками.

    Ситуэйшн №1: маленький проект


    Представьте, что вы студент. Пишете ваш первый студенческий проект – больше, чем лабораторная, но меньше, чем реальный коммерческий проект. Размер примерно 1000 строк кода.
    Вы написали его и захотели улучшить. Но вдруг обнаружили, что в архитектуре у вас ошибка, и исправление проблемно. Переписали. Потом еще раз. Станете ли вы переписывать его в четвертый раз? Возможно.
    Небольшие проекты можно переписывать бесконечно, пока они не будут доведены до совершенства. Но вот проблема: где эта грань между совершенством и сумасшествием?
    Я думаю, что хоть немного средний проект нельзя довести до совершенства, ведь сегодня вам кажется, что совершенны одни методы, а завтра – другие. А время будет потеряно. В конце концов вы можете сдать полурабочий проект, который застрял на стадии третьего переписывания (вы ведь студент, и в первом проекте решили не использовать VCS, ведь это мейнстрим).

    Ситуэйшн №2: свободное плавание


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

    Ситуэйшн №3: чужой код



    Это самый опасный путь, скользкая, мерзкая и пакостная дорожка. Итак, представьте, что свой студенческий проект вы кое как сдали, свой личный проект забросили (извините, конечно же отложили, чтобы вернуться, когда будет время!).
    И вот, к вам попадает чужой код в 10-15 тысяч строк. Говнокод. По-вашим представлениям. Внедрение обновлений равносильно выстрелу себе в ногу. Переписываем?
    Не торопитесь. Сначала оцените свои возможности. Сколько времени вам потребуется, чтобы это переписать? Как это будет оплачено? Заложено ли нужное время?
    Переписывание чужого кода чревато несколькими проблемами.
    Первая проблема: код, скорее всего, уже внедрен и работает. В этом случае, вам не только нужно будет заново разработать весь его функционал, но и учесть все костыли, на которые наткнулся бывший говнокодер.
    Вторая проблема: вы можете не потянуть проект, начать прокрастинировать, и в конечном итоге, окончательно завалите проект.
    Третья проблема: почему вы так уверены, что вы сами не напишете такой же говнокод?

    Ситуэйшн №4: устаревший проект или специфичные инструменты


    Возможно, это единственное частичное оправдание полному переписыванию проекта. Известно, что сейчас многие работающие программы стары, как дерьмо мамонта, но люди продолжают ими пользоваться. Потому что они работают, отлажены, и ошибки в них возникают известно где. Такой проект действительно можно переписать с нуля, при учете жестко и четко сформулированных требований, моря тестов и многих часов отладки. Однако помните, что даже в этом случае нет гарантий, что проект заработает сразу, как нужно. Возможно поэтому до сих пор существуют программы, старые как… ну вы поняли.



    Итак, когда не надо переписывать проект:
    1) Когда вы дорожите своим временем, и временем других людей, которое они вложили в проект;
    2) Когда вы не уверены, что сможете точно повторить функционал проекта;
    3) Когда вы не до конца разобрались с проектом, не знаете его особенностей;
    4) Когда вы говнокодер;
    5) Когда никто не угрожает вашему любимому хомячку.
    6) Размер проекта превышает 10000 кода, без учета инструментов и фреймворков. Даже этого будет много чтобы оценить, стоит ли овчинка выделки.

    Когда, возможно, стоит переписать проект:
    1) Когда внедрение доработок занимает чрезвычайно много времени и/или очень много средств из-за чрезмерной сложности системы;
    2) Когда вы изучили проект досконально и знаете каждую его деталь;
    3) Когда вам доставляет удовольствие в пятидесятый раз переписывать свой любимый калькулятор;
    4) Когда заказчик пришел к вам домой и настойчиво утверждает, что ваш или чей-то чужой говнокод очень плохо работает, и он хочет, чтобы вы сделали все замечательно с первого раза;
    5) Когда вам предлагают невообразимую кучу денег за небольшой проект.

    И еще помните, что серьезные люди считают, что переписывание проектов с нуля – это признак непрофессионализма.
    Удачи.
    Поделиться публикацией

    Комментарии 182

      +13
      Можно еще тесты написать. Получится быстрее, чем «все с нуля», и можно будет потихоньку по частям рефакторить.
        +10
        Покрытие юнит-тестами незнакомого кода — это безусловно хорошая практика. Но далеко не всякий код хорошо тестируем (более того, если он хорошо тестируем, возможно он не так уж и плох) и зачастую приходится провести некислый такой рефакторинг, чтобы этой самой тестируемости добиться =)
          +5
          Не на всякий лапшекод можно написать тесты, так, что бы быстрее. К примеру, недавно, мне попался один замечательный год-обжект (там где он мне попался, еще с пару десятков таких): 2 публичных метода и 12 (или 13 уже не припомню) тысяч строк кода, около 40 приватных методов и вызов еще трех таких вот год обжектов.

          По сути то интеграционный тест накатить можно — вполне понятно что будет после вызова и первого, и второго методов. Собственно так и поступили. Но полноценно растащить все у меня получилось только через полтора дня (рефакторинг от идеи очень облегчил работу). Но и тут для тестирования были проблемы, состояние многих объектов было «нестабильным», в лучшем случае — неполным. Они прокидывались через 10-20-30 методов, перед тем как улететь в очередной внешний объект забивались левыми данными, потом подчищались (благо в комментариях люди поясняли зачем это было сделано). Где-то зачем-то копировались.

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

          Переписали бы с нуля гораздо быстрее было бы — уже бы закончили, пару таких вот модулей переписали уже. Но, к сожалению, старый код тоже надо активно сопровождать (хотя там сопровождения на 10-20 минут в день — тут поменять, там запилить, тут что бы вместо ААА было ААА + БББ). Поэтому такой вот компромисс — часть времени за задачу, несравнимая часть на рефакторинг.
            +2
            Когда стоит переписывать проект- когда вы говнокодер и хотите набраться опыта…
              0
              Браться переписывать готовый, работающий, действующий проект с целью набить руку — не лучшее решение. Чужой код несет новое и не всегда плохое. Большинство своих знаний программист получает именно из чужого кода.
                0
                Внимательно читать чужой код в процессе переписывания тоже нужно, так что это полезно. Ведь переписывая, его нужно также и переосмыслить
            +66
            Я стараюсь предерживаться правила, достаточно четко сформулированного в старом-добром анекдоте:
            - Папа, а почему солнце всегда встает на восходе, а заходит на западе?
             папа поворачивает голову с красно-воспаленными глазами к сыну
             - Всегда восходит на востоке?
             сын: - Всегда
             папа: - заходит всегда на западе?
             сын: - Да
             папа: - ничего не глючит? все работает нормально?
             сын: - да, все нормально
             папа: - Ну так и не трогай там нихрена!
            
              0
              Хороший анекдот, тоже его люблю)
                0
                Вот это верно. Работает — не трогай.
                  +1
                  Главное — не распространять этот принцип на утюги, чайники и т.д.
                    0
                    не работает — меняй.
                    нафига возиться со старым умершим чайникм, когда можно купить новый.
                    в общем-то.
                      0
                      Если можно купить — хорошо, а если самому сделать чайник, вместо того, чтобы подпаять…
                        +1
                        Если денег совсем некуда девать.
                        В стиральной машине автомате за почти 15 лет работы четырежды поменял прокладку-сальник в выпускном насосе. Первый раз она стОила около рубля, последний раз — рублей 40. Общая сумма меньше меньше сотни. Четыре стиральных машины это тоже несколько меньше сотни. Только тысяч.
                        ЗЫ. Кстати, у коллеги случилась как-то такая же проблема. Вызвал он сертифицированного мастера. Тот ему поменял насос. Старый вручил в руки со словами — он годный, только прокладка износилась, а мы прокладки менять не сертифицированы. Сумма ремонта — 6 тыс руб. Патамушта Бош и его не чинят. Его меняют.
                          0
                          ну вот если кто-то из топовых производителей тупо меняет книго читалки — киндлы кажется…
                          в моей конторе, например тоже модемы если пересыхает, грет и не работает тоже меняют
                            0
                            В конторе — это хорошо. Можно попросить заменённый прибор забрать себе для опытов и, если повезёт и починка лёгкая, получить +1 к опыту и +1 прибор за бесценок :).
                              0
                              то, что забирается на замену — выкидывается как неремонтопригодное еще сервиниками ))
                              нет смысла возиться.
                                0
                                Не очень понял кто на ком стоял… Наверное, в больших забюрократизированных конторах всё сложно — я тоже встречался со всякими актами на списание и специальной службой, принимающей сгоревшую технику для последующей сдачи на драгметаллы… Но в небольших таки попроще.

                                Ну, и к слову… Вот совсем недавно у одного некта сдох блок питания в компуктере. Нект вызвал мастера. Мастер заменил БП. Сгоревшая деталь всегда оставляется клиенту. Ну, я у некта взял умертвие для опытов. Вздулся конденсатор (заводской дефект этой модели) и выгорели защитные варисторы на входе. Общая цена ремонта — где-то на 10 рублей комплектухи, 10 минут гугленья, 20 минут на распаковывание паяла-кусачек-отвёрток, сборку-разборку, впайку-выпайку, демонстрацию детишкам кишок БП, процесса пайки, торжественного включения и поддержания образа немерянной папиной круторы :). Дополнительный бонус — вновьобретённый прибор оказался мощнее и совершеннее моего домашнего, был вставлен в домашний контупер, а старый блок пошёл на другие опыты по мастыренью из него зарядного устройства для автомобильного аккумулятора, севшего по причине «внезапных» для сибири холодов ниже -35 (зимой ещё было дело).

                                Было бы желание и, главное, интерес поколупаться.
                                  0
                                  интереса колупаться в чипе, который через 5 минут перегревается и умирает — нету.
                            0
                            Обычно дохнет подшипник на барабане, а не сальник… И его смена — многочасовой геморрой с фиговым результатом.
                      +20
                      Иногда люди готовы платить деньги за то, чтобы ты ничего не переделывал, но смог, в случае чего, подставить костыль. Им спокойней так живётся, т.к. проверенное старое легче поддаётся управлению (читай – планированию).

                      Прибегает молодой сын-юрист к старому отцу-юристу и кричит:
                      - Отец, поздравь меня! Я выиграл дело, которое ты не мог выиграть всю свою жизнь!
                      А тот ему в ответ:
                      - Дурак, я с него кормился всю свою жизнь!..
                        +2
                        ТимЛид - молодому программисту:
                        ты только что закрыл BUG который кормил нас два года !
                          +1
                          А потом все возмущаются, чего же у нас дороги-то такие херовые… И венда тормозит
                        +1
                        у вас какой то до чет :) в первой строчке.

                        на третий строке возвращался три раза и понял, что наверное «встает на востоке», а не «встает на восходе»

                        :) или все таки я не прав?
                        0
                        Как раз столкнулся недавно с такой ситуацией: дали мне с коллегой для тестирования ПЗС-камеру, в комплекте — только виндовые драйверы. Их установили, но оказалось, что без дорогущей проприетарной поделки ни кадра мы с этой камеры не получим (а поделка не имеет CLI, т.е. работать с ней бессмысленно).
                        Благо, нашелся линуксовый софт. Однако, при компиляции он не заработал. Модуль ядра был допилен до современного, однако клиентский софт постоянно падал. Внутри — уйма страшного кода без проверок значений, возвращаемых функциями, поддержка уймы матриц, кроме конкретно нашей.
                        Вот и думай, что здесь делать: переписывать с нуля («выдрав» лишь то, что нужно для работы с конкретной камерой), или же пытаться «допилить» имеющееся (~28 тысяч строк) до рабочего состояния (а там еще проблема в том, что оно не на С, а на C++)…
                          +3
                          Не рассматривайте камеру и софт отдельно друг от друга, относитесь к ним вместе как к продукту. Тогда возможно поставить вопрос, а не проще ли сменить продукт?
                            0
                            Согласен. Однако, во-первых, меня никто не спрашивал, покупать ли эту камеру; во-вторых, продукция сильно специфическая и узнать о ней подробную информацию до покупки часто просто невозможно (т.е. пишет, например, продавец, что у него все ОК, а на деле — ничего не работает, или работает совершенно не так, как было заявлено).
                          +1
                          Согласен с автором!

                          Кроме того, переписывание с нуля может привести к тому, что команде придется сопровождать два совершенно разных решения для одной и той же задачи. Эта ситуация происходит в том случае, если «старое» решение уже внедрено у нескольких клиентов, и обновлять его клиенты не собираются.
                            +13
                            Когда я купил свой первый велосипед (китайон), решил улучшить в нём в се узлы по мере возможностей. Начал с замены подшипников. Однако по неопытности поставил их не той стороной и как следует испоганил оси. С тех пор я твёрдо держусь правила: не сломалось — не чини.
                              0
                              Очень хорошее правило, но слабо применимое к активной разработке ПО. Поясню на примере. Сейчас имею дело с одной очень старой системой где очень так хорошо следовали этому правилу. В итоге такого 3.14%$!@#а, я не встречал давно. Тут можно весь день искать то место куда бы влепить костыль и навсегда забыть про это место. Это будет самое лучшее решение, ну или по крайней мере оно не будет выделяться из общей массы кода.

                              За то недолгое время, которое мне пришлось поработать с этим кодом, я могу сказать следующее: в моих руках находиться история. Я вижу слои программного кода, которые отчетливо показывают как же все таки развивалась java в последние 10 лет, начиная с третьей, и думаю скоро появиться, седьмой версией. Я вижу что поиск и отладка занимают до 90% моего времени.

                              В сравнении с тем новым кодом, который я пишу, где поиск занимает жалкие 5% времени, а отладка… тут все сложно — тесты пишутся вместе с кодом, поэтому на тыканье этого всего ручками тоже не больше 10% времени, по большей части что бы убедиться, что действительно все так прекрасно.

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

                                +1
                                Правило применимо к любой сфере и не имеет ограничений. Суть его, как видно, может показаться не явной.

                                От велосипеда требуется только езда. Если он едет и ездока это устраивает, нет смысла в нём что-то чинить.

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

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

                                  Без этого они погибают, ну или как

                                  И правильно говорят, что код пишется не для компилятора, а для человека. По другому никак.
                                    0
                                    Текс, продолжаем:

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

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

                                    Так же и программы, если его дне подпиливать, не подтачивать, не переделывать — то без этого они погибают, ну или как зомби становятся — вроде они и есть, что-то делают, но лучше не трогать, что бы мозг был в целости и сохранности. Посмотрите сейчас на то, что не правилось в последние несколько лет, но исправно выполняет свои обязанности — сразу поймете о чем я.
                                      0
                                      Вам так хочется помусолить очевидные вещи?
                                      Читайте пожалуйста внимательнее.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Может приведённые советы и кажутся очевидными, но поверьте — армия программистов их не соблюдает, вот прямо здесь, в вашей компании, и если не завтра, то послезавтра вы сами пострадаете от этого.
                                  +18
                                  Мой опыт показал, что если есть архитектурные просчеты, блокирующие развитие — то лучше сразу переписать, чем навешивать гроздья костылей.

                                  А по поводу старого, но хорошего или незаменимого кода — если его грамотно «обернуть» и задокументировать, то он прослужит очень и очень долго.
                                    +3
                                    Код вообще, сам по себе, очень живуч. В конце прошлого года зашел на один из тех сайтов, которые я поддерживал, в начале своей карьеры. Смотрю — тот же девелоперский бекдор, залез, посмотрел историю в svn — 5 лет без обновления, та система виджетов которую запиливал. Из документации — только комментарий. Количество виджетов за это время выросло с 10 до около 80 (80 разных наследников класса Widget). Зачем так много — кто его знает, посмотрел на несколько, можно было бы удалить вообще, если немного подправить сам базовый класс. Но его почему-то никто не трогает.
                                    +5
                                    Стараюсь если и переписывать, то по частям, и покрывать код тестами.
                                      +3
                                      Вопрос к автору: как вы относитесь к рефакторингу?
                                        +1
                                        К рефакторингу я отношусь замечательно, если его делаю не я)
                                        К сожалению, лишь в немногих фирмах выделяется время на рефакторинг, а когда он проводится во время внесения доработок – это совсем зло.
                                          +1
                                          А почему рефакторинг во время внесения доработок — это зло?
                                            +1
                                            Потому что можно в нем случайно утонуть.
                                            Допустим, вам дали доработку и вы ее оценили. В процессе вы поняли, что неплохо бы эту часть улучшить, код не читается, алгоритм неоптимален. Вы переработали часть + внесли доработку за время, отведенное только на доработку (либо за большее время, т.е. не уложились в срок), и не успели адекватно протестировать. В лучшем случае, можно будет просто откатиться. В худшем, не дай кодобог, ошибка попадет в продакшн.
                                              +1
                                              Согласен, спасибо.
                                                +4
                                                Проблема не в рефакторинге, а в неправильном планировании и управлении проектом. Некоторые доработки трудно встроить в существующую архитектуру проекта. В таком случае принимается решение к доработке архитектуры под новые изменения. На это необходимо запланировать соответствующее время. Данная техника рефакторинга освещается в книге Фаулера (ниже я уже оставил ссылку)
                                                  +2
                                                  Рефакторинг должен влючаться в оценку в таком случае. Если вы достаточно давно в проекте, вы должны знать все топкие места, и либо сразу понимать, сколько там понадобится на рефакторинг, либо взять немного времени для того, чтобы посмотреть и дать оценку.
                                                    +1
                                                    Поэтому тесты должны быть до рефакторинга и внесения изменений. «Зажимаете» тестами «окрестности» кусков, которые предполагаете доработать, пишите тест на доработку, пишите саму доработку.
                                                  0
                                                  Я вот очень плохо отношусь к тому времени, которое выделяют на рефакторинг. Сейчас попытаюсь объяснить почему.

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

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

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

                                                  Но это не касается тех ситуаций, когда необходим архитектурный рефакторинг — или 2-3 дня только им заниматься, а уже потом новый код (иначе никак) или десяток костылей за те же 2-3 дня но на текущей архитектуре.
                                                +6
                                                Недавно исправлял ошибки в одной системе и заодно немного рефакторил. Код был омерзительным, его «девелоперы» не знали даже про модульное программирование, код был сплошной простыней с кучей вложенных ифов и исключительно глобальными переменными.
                                                После окончания проекта подумал, что было бы дешевле(быстрее) раза в полтора-два переписать все с нуля, чем исправить часть, которую я сделал.
                                                Но работодатель думал, что мы могли обойтись малой кровью.
                                                  +1
                                                  Забыл написать. Кода было 1мб, а половина была переписана в 40кб(убрано нерельное количество копипаста и мертвого кода).
                                                  +1
                                                  В одной из книг натыкался на интересное предложение. Если изменения кода модуля (компонента, класса и т.п.) затрагивают больше его четверти — то дешевле будет переписать его полностью. На самом деле, наверное, не стоит относится к величине 25% как к какому magic number. Но, совершенно точно, нужно понимать, что всегда есть порог, которые разделяет две крайности — переписывание и рефакторинг. И любое принятое решение — это компромисс.

                                                  Иногда очень трудно решиться на то, чтобы оставить в продукте какой-то старинный модуль, особенно после того как в него посмотришь… Но у него есть важное преимущество — он уже есть и он уже давно работает. Но если есть понимание, что требования изменились настолько сильно, что этот старый модуль придется изрядно переделать/доделать — почти наверняка проще сделать его заново. Потому что как себя поведет старый код в новых условиях, на которые он не был изначально рассчитан — большая загадка.
                                                    0
                                                    Если изменения кода модуля (компонента, класса и т.п.) затрагивают больше его четверти — то дешевле будет переписать его полностью
                                                    От кода все зависит. Если так посчитать то мой последний «перепишем все с нуля» был от того, что необходимо было поправить около 1% кода т.е. чуть более 50 строчек кода. Правда это были основные строчки. В итоге оказалось так, что либо переписываем все и забываем обо всем на свете. Либо эти 20 строчек выделяем в стратегию и используем либо старую (которая работает для всего-всего), либо новую которая работает только для достаточно малой части тех модулей которые имеются в обвесе, но зато так, как необходимо на текущий момент.

                                                    Первым шагом был второй вариант, а там в течении той же недели и остальное под новый вариант перепилили. Как водиться — с нуля.
                                                      0
                                                      Зависит от обстоятельств. Я видел один отчетик, который постоянно «апгрейдили» методом копипаста. Там можно вместо сотен нефти кода прописать парочку функций и сделать все гораздо проще и удобнее, но разработчик свято следовал правилу «работает? — пусть работает». И ведь работает…
                                                        0
                                                        Вы сами ответили на свой вопрос — оно работает! Для практических задач это часто перевешивает все внутренние недостатки.
                                                        Могу привести не то чтобы контрпример. Жила была система, ей было лет 15, технологии устарели, разработчики сменились, количество заплаток и вставок превысило все разумные пределы.
                                                        Наконец-то было принято решение все переписать заново. Была сделана система, которая гораздо надежнее, масштабируемее, функциональнее. По крайней мере теоретически. Дело за малым — реализовать это на практике. Программа большая, писало её много народу и все немножко ошибались (куда без этого). Наверное еще года 3 — и система станет почти такой, какой должна стать…
                                                          0
                                                          Говорю же, от обстоятельств зависит. Лично я многие вещи каждый раз с нуля делаю, и достиг в этом определенного мастерства. После такого стыдно смотреть в свой же старый код. И чужой код не гнушаюсь в порядок приводить, очень помогает в дальнейшем. А то, что работает — это еще не значит, что хорошо работает.

                                                          Но при этом я не агитирую за однозначное переписывание всего и вся. Для этого опыт нужен, знание как лучше сделать.
                                                      +2
                                                      Что я нового прочитал в этой статье студента-фрилансера?
                                                        0
                                                        Вроде, я не указывал, и не претендовал на новизну.
                                                        И почему интересно вы решили, что я – студент-фрилансер?
                                                          +4
                                                          Посмотрел профиль, 22 года — студент, или вы решили не учиться?)
                                                          Понимаете, проблема даже не в том, что статья не интересна. Перед тем как кого-то учить, постарайтесь объяснить во введении, почему вы знаете про это лучше других, каков ваш опыт, иначе доверия к вашим советам не будет.
                                                            0
                                                            Не судите людей по каким-то внешним признакам. Я мог написать, что мне 35 лет, я живу в штатах и работаю в Google. При этом было бы больше доверия?
                                                            Хорошо, я учту пожелания)
                                                            К слову, я получаю диплом, и имею опыт коммерческой разработки 3 года. Это не очень много, согласен, но я считаю, что мне есть, чем поделиться.
                                                              +9
                                                              Да, если бы вам было 35 и вы работали бы в Google, вам было бы больше доверия. Об том и речь.
                                                                0
                                                                Сюда как раз уместно будет: встречаем по одёжке, а провожаем по уму…
                                                                Прочитав пост ничего нового для себя не открыл, но согласен с описанным опытом почти во всём, поэтому в гугле человек работает или в универе учится — вообще без разницы в данном случаи, вы же его не на работу присматриваете. ;)
                                                                +1
                                                                «Людям надо верить, особенно когда они говорят правду».

                                                                                                                                     («Времечко»)
                                                                +1
                                                                если работать с 16-18 на постояне(офис или удаленка), то опыт серьезный уже и к 22.
                                                            +5
                                                            реальность состоит не только из студентов которым трудно разобраться в том что есть но и из профессионалов которые переписывают проект т.к. его принято и оценено решение его сделать заново.

                                                            Примеры полностью переписанных систем
                                                            MS Windows 3.11 -> MS Windows 95
                                                            MacOS — > MacOS X

                                                            Внутрикорпоративные системы также нередко полностью переписываются. Главное чтоб решение об этом принималось обоснованно.

                                                            Основная причина полной переделки — архитектура на момент создания не учитывала появившиеся со временем изменения в рабочем процессе т.к. заранее всё учесть невозможно.
                                                              +1
                                                              Примеры полностью переписанных систем
                                                              MS Windows 3.11 -> MS Windows 95

                                                              В этом месте мне вспоминается история о том, что в Win7 есть окно (кажется, добавления шрифтов), которое осталось там ещё со времён 3.11
                                                                +10
                                                                Оно было в Vista, но в Win7 его убрали.

                                                                Vista

                                                                Win31

                                                                Теперь систему можно считать полностью переписанной!
                                                                  +5
                                                                  Ну наконец-то. А я уж дождаться не мог!
                                                              +4
                                                              «И еще помните, что серьезные люди считают, что переписывание проектов с нуля – это признак непрофессионализма.»
                                                              Чьего непрофессионализма, того кто изначально написал какашку или менеджера, который допускает экономически невыгодные действия (рефакторинг, зачем если и так работает)?

                                                              Был у меня случай когда предложили поработать с проектом (на ведущей роли) который разрабатывался более двух лет, командой из 4-5 человек. Сам проект еле шевелится на нагрузках, переписать сами понимаете нереально, дорабатывать как бы тоже (структура БД не позволит).

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

                                                              Особенно сложно рефакторить «динамические языки» (вроде JS), и крайне сложно когда нет единой структуры использования этих языков (куча разнородного JS кода раскидано по страницам, никаких классов, никаких неймспейсов). Все нужно загрузить в голову (язык ведь не компилируемый), чтобы найти общую часть, отследить связи, построить иерархию и тд.
                                                                –3
                                                                Треш
                                                                  0
                                                                  Лучше дорабатывать переписывая, eсли проект это позволяет.
                                                                    +3
                                                                    Для быстрорастущих проектов очень часто переписывание с нуля — это единственный шанс остаться на плаву.
                                                                    Когда у вас есть 1000 пользователей, вы справляетесь, но когда появляется 100.000 пользователей, то становится очевидным, что текущая архитектура не позволяет держать такую нагрузку.

                                                                    А дальше у вас 2 пути: либо переписать всё с нуля, либо тратиться на более дорогое железо до тех пор, пока стоимость обслуживания каждого следующего пользователя не станет выше того дохода, который он приносит. А потом всё равно переписывать всё с нуля.

                                                                    Я это видел уже в двух компаниях, когда проекты вдруг становились очень высоконагруженными и приходилось всё переписывать.
                                                                      0
                                                                      Есть и такое, согласен. Вдруг высокая нагрузка – это всегда проблема для программистов.
                                                                        0
                                                                        Ну до какого-то момента можно дотянуть натягивая обертки из кеширования и разнесения на два сервера — файлы и БД. А потом да, уже нужно думать о полном переписывании.
                                                                        +16
                                                                        >Размер проекта превышает 10000 кода
                                                                        это как 100 нефти?

                                                                          +10
                                                                          Первый комикс переведён неправильно. «OH MY. I've done it again, haven't I?» — это совсем не «Я ведь сделал всё правильно?..», от этого теряется половина смысла.
                                                                            +2
                                                                            Бывает берешься за чужой проект и начинаешь его допиливать, думаешь, так ведь быстрее получится, чем заново на грабли наступать, а потом увязаешь в этом говнокоде и через полгода осознаешь что за эти полгода можно было запросто проект с нуля написать и через все грабли пройти.
                                                                              +14
                                                                              Выводы спорные. Блестящий аналог проекта — жена. Нет универсального решения, что быстрее и лучше — перевоспитать текущую жену или развестись и завести себе новую.
                                                                                +4
                                                                                Ну нет, жена это сложный биоробот =D
                                                                                  0
                                                                                  Отличная аналогия! Хотя доработка жены в большинстве случаев будет очень и очень трудозатратна и если нужно много дорабатывать, то лучше уж наверно завести новую =)
                                                                                    0
                                                                                    А кто вас застрахует от того, что новая жена будет хуже после того, как снимет «розовые очки»?
                                                                                  +1
                                                                                  Серьезные люди считают, ага. Я посмотрел бы на этих серьезных людей если бы им внезапно пришлось поддерживать код в котором встречалась javascript-переменная isIE4
                                                                                    +2
                                                                                    Рефакторинг — наше все.
                                                                                    Советую прочитать книгу:
                                                                                    Мартин Фаулер — Рефакторинг. Улучшение существующего кода.
                                                                                    www.ozon.ru/context/detail/id/1308678/
                                                                                      +1
                                                                                      Главное — после прочтения не словить рефакторинг головного мозга.
                                                                                      В тяжелых клинических случаях программист 95% времени начинает заниматься исключительно рефакторингами.
                                                                                      +1
                                                                                      6) Размер проекта превышает 10000 кода, без учета инструментов и фреймворков. Даже этого будет много чтобы оценить, стоит ли овчинка выделки.

                                                                                      Когда файл старой версии класса занимает 114кб вообще без комментов, а новая версия с минимальными комментами — 14 кб и делает тоже самое, но без багов + ещё чуть-чуть — начинаешь очень сильно задумываться о необходимости переписывания всего, что попадает под руку в этом проекте…
                                                                                        0
                                                                                        >Когда файл старой версии класса занимает 114кб
                                                                                        Вот на этом этапе уже нужно задумываться о том, чтобы переписывать. Задумываться, не значит переписывать.
                                                                                          +2
                                                                                          Просто я к тому, что иногда существуют такие проекты, когда проще переписать половину, чем внести какое-либо незначительное изменение. Хотя опять же, как показывает практика — это бесполезно, если в разработке участвуют авторы предыдущей версии…
                                                                                          +1
                                                                                          7) размер проекта превышает 500 000 кода без учета инструментов и фреймворков — их там просто нет.

                                                                                          Переписывать однозначно, но надо сохранять совместимость — все равно не сможешь переписать всё.

                                                                                          В итоге получаем еще один уровень наслоений на этом говне мамонта. Но может 500 000 кода превратятся в 400 000 кода и последователям будет попроще.
                                                                                            0
                                                                                            Переписать пол-миллиона строк? Вы трудозатраты себе представляете?
                                                                                            Ещё стоит учесть, что при переписывании с нуля неизбежно будут внесены новые баги.
                                                                                            Не говоря уже о том, что в коммерческом продукте это действо просто экономически нецелесообразно.
                                                                                            Не нравится код — для тебя придумали рефакторинг.

                                                                                              0
                                                                                              <сарказм>
                                                                                              Рефакторинг это совсем-совсем не переписывание. Достаточно просто посмотреть и все само рассосется.
                                                                                              </сарказм>

                                                                                              Касаемо трудозатрат — как насчет добавления новых фич? Особенно, если требуемый функционал на пару тысяч строк размазан где-то по всему проекту?
                                                                                                0
                                                                                                Размазан функционал? Перерабатываем проблемные пару тысяч строк, реализуем новую фичу, а остальные 498К строк продолжают лежать и ждать своего часа.
                                                                                          0
                                                                                          серьезные люди считают, что переписывание проектов с нуля – это признак непрофессионализма

                                                                                          самый правильный вывод во всей статье
                                                                                            0
                                                                                            Как то в одном веб приложении переписывал «Главную» функцию, которая обсчитывала всё что можно и которая использовалась везде где только можно, т.к. на больших объёмах данных всё ложилось. На входе — что то около 7 параметров. На выходе — 31 массив. Около 2000 строк кода. Недели 2 разбирал что как устроено. Еще столько же переписывал. И месяц ушел на то, чтобы при различном наполнении БД и различных входных параметрах выход старого и нового экземпляров был идентичным.

                                                                                            С тех пор с большой опаской отношусь к оптимизациям :) Хотя и без нее было нельзя, и «рабочее время» на нее было выделено.
                                                                                              +1
                                                                                              Интересно почему у Вас сложилось отрицательное впечатление, Вас не устроил результат?
                                                                                              Доводилось ли Вам после этого длительно сопровождать этот проект?
                                                                                              Что получилось вместо вышеприведенной функции с 7 параметрами?
                                                                                              Использовались ли юнит-тесты при проведении рефакторинга?
                                                                                                0
                                                                                                Я не сказал, что негативное. Просто столько «души» вынула эта переработка, что прежде чем браться за подобное — 100 раз подумаю. Сам результат меня устроил в том плане, что именно с этим моментом, меня больше не напрягали.

                                                                                                В общей сложности проект я 2 года сопровождал. Изначально было много народу, когда я туда пришел. Потом, буквально за пол года на этом проекте я один остался.

                                                                                                А получился такой же «ящик» с идентичным входом и выходом, только другой начинкой + в последствие было кеширование навешано. Т.к. обновление автоматически накатывалось порядка 60 клиентам, то переписывать кардинально было чревато. Да и «добро» на это не дали.

                                                                                                Юнит тесты не использовались. Не до того было.
                                                                                                  +1
                                                                                                  Юнит тесты не использовались. Не до того было.
                                                                                                  И очень зря.
                                                                                                  Тесты могли бы существенно облегчить стадию «чтобы при различном наполнении БД и различных входных параметрах выход старого и нового экземпляров был идентичным».
                                                                                                0
                                                                                                Думаю вся проблема была в том, что это была «главная функция». Я такое тоже встречал и мне говорили о таких местах кода так: делай что хочешь — а вот это не трогай, даже не смотри туда. Один раз посмотрел. Функция которая делает по сути все и ничего одновременно. Когда критическая масса нового функционала стала обрастать костылями для того, что бы «главная функция» не поперхнулась, то решили отказаться от нее. Постепенно она стала не то, что бы второстепенной — а придатком к 2-м стародавним модулям, которые были написаны еще на заре рождения веба, и никому не хотелось туда лезть и что-то править. Работали ведь как часы известной швейцарской марки.
                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                  0
                                                                                                  Проблема может лежать в разной плоскости. И не всегда это связанно с ростом проекта (количества разработчиков), нагрузок. Иногда проблема может лежать в плоскости оптимизаций по затратам — лично видел как один проект, пожирал время 12+ разработчиков. Видел доску этого проекта, где половина (отданная под задачи), была заполнена серыми карточками — техническим долгом.

                                                                                                  В итоге была создана команда с гордым названием RT (Refactoring Teem) которая должна была по сути заниматься рефракторным и устранением всех технических долгов. Она как достигла 4 человек, так и осталась со следующей версией продукта. Остальные разработчики стали не нужны, эти люди, после года своей работы (где-то переписали с нуля, где-то зарефакторили три раза до неузнаваемости), делали гораздо больше нежели старая команда со старым кодом.

                                                                                                  Как минимум в три раза сократить издержки по разработке — думаю это тоже неплохой результат.

                                                                                                  –11
                                                                                                  На самом деле, единственная причина для переписывания кода с нуля — это когда старый проект написан без объектно-ориентированного подхода и при этом язык программирования не поддерживает ООП.
                                                                                                    +3
                                                                                                    Аргументируйте
                                                                                                      –6
                                                                                                      Ну, это же элементарно — в ОО парадигме пишется для чего? Как раз для того, чтобы ЛЮБОЙ человек мог переписать ЛЮБОЙ код не с нуля, а базируясь на построенной раньше модели (применил бы рефакторинг). Когда код написан не в ООП модели — то код не имеет модели, то что там написано не соответствует предметной области, становится невозможно использовать повторно старый функции — код логически не разделен и соответственно он не понятен становится. А если еще и язык не дает возможности это постепенно улучшить — вот тогда и задумаешься о переписывании с нуля на другом более строгом ОО языке.
                                                                                                        +4
                                                                                                        А если это просто прекрасный код в процедурном или функциональном стиле. Или говнище, под маской ООП?
                                                                                                          –2
                                                                                                          С говнищем под маской ООП, но которой работает — можно бороться, есть методы и приемы, при этом не секрет, что называние говнищем это просто не понимание логики того кто это писал, в 80% случаев просто эмоции.

                                                                                                          Но прекрасный код в процедурном или функциональном стиле имеет точку не возврата, когда после внесения туда изменений код становится невозможно сопровождать. С таким кодом нужно поступить так: взять написать правильную ОО-модель, и использовать старые функции в ОО-оболочке. Если что-то не ложится, то тогда переписывать с нуля.
                                                                                                            –1
                                                                                                            Собственно, меня пригласили на фирму как раз для того, чтобы переписать ХОРОШИЙ код в процедурном стиле на ОО-код, по той простой причине, что этот ХОРОШИЙ код стало невозможно развивать дальше. Проект был порядка 50-100 тыс. строк.
                                                                                                              –3
                                                                                                              Ну и потом вы видели код в чистом функциональном стиле на 50-100 тыс. строк? Где? Очень хочется посмотреть.
                                                                                                                +1
                                                                                                                linux kernel
                                                                                                                  –1
                                                                                                                  :)

                                                                                                                  читаем

                                                                                                                  Linux — ядро операционной системы, соответствующее стандартам POSIX. В основном код написан на Си с некоторыми расширениями gcc и на ассемблере

                                                                                                                  И как на Си можно написать в чистом функциональном стиле? Не понимаю.
                                                                                                                    0
                                                                                                                    Стиль там, конечно, процедурный, но ООП как такового нет. А «чисто функциональное программирование» — сильно узкоспециализированная штука.
                                                                                                                      –1
                                                                                                                      Так я именно об этом и говорю. Но написав недавно статью «Существуют только структурная и объектная парадигмы программирования» там развели такой холивар, что пришлось закрыть. Но там всего лишь утверждалось как раз это: "«чисто функциональное программирование» — сильно узкоспециализированная штука". А в остальном статья была вообще про другое, но этого хватило для ужасного эмоционального холивара.

                                                                                                                      Вот и здесь смотрю массово минусуют, но без аргументов.

                                                                                                                      А про процедурное надо говорить отдельно, и никто не сомневается что там был потенциал больший, но не такой мощный как в ООП. (впрочем это тоже было написано в той проблемной статье)
                                                                                                                  +2
                                                                                                                  Мне тоже. Но вон Линукс написан (afaik) в процедурном стиле (очень хорошем) и никому это не мешает. А есть десятки вещей, которые написаны в ООП стиле — очень сложно поддерживать.

                                                                                                                  Я сам всегда пишу в ООП-стиле, но ваша категоричность — плоха.
                                                                                                                    –3
                                                                                                                    Про процедурный стиль никто не говорит. Такого много написали до ООП. Но это уже всем известно, что процедурный стиль имеет ограничения на размер кода.
                                                                                                                      +1
                                                                                                                      кому «всем»?
                                                                                                                        0
                                                                                                                        :) согласен многим видимо нет, но ничего подождем когда они столкнуться с этим на опыте. Впрочем вон их сколько — все рвутся переписать с нуля — это и есть потенциальные клиенты, кто это может быть поймет.
                                                                                                                        0
                                                                                                                        Не согласен, есть много промышленных и научных программ большого размера, написанных в процедурном стиле. Например, модели прогноза погоды. Авторам этих программ и в голову не приходит переписать их под ООП.
                                                                                                                          0
                                                                                                                          Это связано со спецификой, в такой сфере просто очень мало пользовательского интерфейса. А алгоритмы действительно в процедурном стиле пишутся нормально и справляются с задачей. Но как только они захотят предоставить нормальный GUI и главное и у них расширится предметная область — они будут вынуждены подумать о ООП. Кроме того, не к таким программа ограниченные требования — клиенты редко выдвигают им свои требования как они хотят, чтобы работала программа. Мат. модель — она есть мат. модель, пользователи редко разбираются что в ней надо менять, а вот «эта кнопочка стоит не тут, и по ней это засуньте сюда, а это посчитайте так» — стимулируют эволюционирование программы, и только в ООП это не превращается в «сущий ад»
                                                                                                                            0
                                                                                                                            Верно сказано, но к таким программам, как правило, GUI поставляется отдельно и является самостоятельной программой. Поэтому не возникает необходимость, переписать весь комплекс с ноля.
                                                                                                                              0
                                                                                                                              Это конечно выход, но ограниченный. Так как визуальная часть плотно общается с не визуальной. А если это в разных программах, то изменения в одной затрагивают изменения в другой — в итоге ничего кроме вырастания «бороды» не происходит. Конечно есть случаи не такой плотной связи — тогда такое решение годится.
                                                                                                                              0
                                                                                                                              GUI тоже не всегда требует ООП. Посмотрите, например, на openmotif или tk. Да и в том же GTK ООП чисто условное.
                                                                                                                                –3
                                                                                                                                То что-то такой код есть, еще совсем не говорит что он не требует ООП. Все требует ООП, только что-то быстрее сломается, а что-то медленнее.
                                                                                                                                  +1
                                                                                                                                  > Все требует ООП

                                                                                                                                  Нет. Если пихать ООП куда попало, получатся жуткие монстры.
                                                                                                                                    0
                                                                                                                                    Дело не в том куда пихать, а в том как пихать. А «жуткие монстры» мне кажется чаще в головах от непонимания роли ООП, чем на самом деле.
                                                                                                                        0
                                                                                                                        Я видел. работаю над проектом, где, есть выкинуть все вендорские тулзы, получится около 600.000 LOC. По надобности внедряю ООП, но у меня нет ООП головного мозга, поэтому я понимаю где нужен объект, а где — добавить функцию в библиотеку. Очень странно слышать про «переписывание кода полностью на ООП, потому что процедурный код — это плохо». Кажется, такое мнение навязывается популярными фреймверками (RoR, Yii, ZF, CI, Cake и т.д.), вот люди и страдают.
                                                                                                                      0
                                                                                                                      Построение модели предметной области, легкость рефакторинга, логическое разделение кода (а-ля слои/модули) и ООП — вещи ортогональные друг к другу (почти). Самый простой пример — предметная область моделируется не классами/объектами, а таблицами и полями БД.
                                                                                                                    0
                                                                                                                    Кому не нравится, хотя бы аргументировали бы :)
                                                                                                                      +1
                                                                                                                      1. Не во всех проектах нужна оо-парадигма.
                                                                                                                      2. Используя и ООП, и любую другую парадигму, «умельцы» могут наговнокодить такого, что вам и не снилось. Проблема тут не в инструменте.
                                                                                                                        –3
                                                                                                                        1. Это относится только к программированию железа, драйверов и т.п. — мы сейчас говорим не об этом
                                                                                                                        2. В ООП — все можно исправить. В этом ее и суть. В других парадигмах исправление будет практически не возможно без риска сделать не работающий код. + см. выше
                                                                                                                          +3
                                                                                                                          1. Простите, почему мы говорим не об этом, где это утверждалось?
                                                                                                                          2. Ага — всё. Особенно сильные связи между модулями, глубину наследования в 10..20, огромнейшие классы, которые делают всё, сложные методы с тысячами строк с sideeffect-ами. Непролазное, неизменяемое говнище можно сделать, используя любую технологию, и иногда его проще взять и выкинуть на помойку, чем распутывать и причёсывать.
                                                                                                                            0
                                                                                                                            2. Все то, что вы упомянули — как раз и делается рефакторингом. Выкинуть ума не надо — но сделать заново будет куда сложнее.
                                                                                                                              0
                                                                                                                              Вопрос состоит в сравнении стоимости рефакторинга и переписывания. Если код писали люди с анальной диспозицией верхних конечностей, и чтобы разобраться в нём, надо быть гением, не факт, что рефакторинг будет дешевле.
                                                                                                                                0
                                                                                                                                я говорю о проектах начиная с 50 тыс. строк. Там сомневаться не приходится, что рефакторинг всегда дешевле.
                                                                                                                                0
                                                                                                                                Процедуральный код точно так же можно рефакторить. Вообще, ООП — это хорошо, но даже близко не панацея от говноеода. Вы слишком догматично подходите к инструментам :)
                                                                                                                                  0
                                                                                                                                  Конечно можно, никто не сомневается. Просто в ООП — большая свобода действий, без ущерба качеству.
                                                                                                                          0
                                                                                                                          Я еще ни разу не слышал случая, когда кто-то переделывал проект только потому что там ООП нету) Что угодно может быть, но никак не эта причина
                                                                                                                            0
                                                                                                                              0
                                                                                                                              Это минус вашему менеджеру, если прям именно из-за ООП он переделывать продукт решил. Но скорее всего — это Вы неправильно поняли. Цель была не в ООП перевести, а сделать продукт лучше — добавить дополнительную функциональность, сделать более масштабируемым приложение, увеличить перфоманс и т.п.
                                                                                                                                0
                                                                                                                                Ну, конечно сделать продукт лучше, но из-за отсутствия ООП — этого нельзя было сделать.
                                                                                                                          0
                                                                                                                          Поддержка языками ООП — это большей частью «синтаксический сахар». Поэтому сложно говорить о том, что язык не поддерживает парадигму ООП: есть массивы/хэши/структуры (доступ к данным по индексу/имени), есть хоть какой-то механизм вызова функций/процедур динамически (указатели на функции, call_user_func, ФВП и т. п.) — язык де-факто поддерживает ООП, например, Ассемблер x86 его поддерживает.

                                                                                                                          Вывод: причин для переписывания с нуля вообще нет? :)

                                                                                                                          0
                                                                                                                          Автор, статья пропитана неопытностью. Вы, видимо, мало в интерпрайзе работали или не работали вообще. Да, в большинсве случаев согласен с доводами — действительно, чем крупнее проект — тем меньше шансов его переписать как нужно. НО! очень часто это необходимо. И то, что вы перечислили — далеко не все случаи. Бывает так, что система в будущем может потребовать большей нагрузки (Например, к 2015му году 500000 реквестов в день, вместо текущих 70) и основная архитектура — ни коим образом не уложится в такие требования. К тому же написана индусами и по-индусски. В этом случае — проще уговорить заказчика, предоставить ему пруф оф концепт, что наша версия работает быстрее, более масштабируема + добавить бантиков (типа, мы добавим еще админку, точнее некий бекофис) и сделаем всё более конфигурабильно. Тогда получается, и выигрывает кастомер, получая более быстрое и скалабильное решение, и выигрывает вендор, т.к. 1) объем работ больше, селовательно и кастомер заплатит больше и 2) И разработчикам так легче, чем рыться в индусском коде.
                                                                                                                          Другой случай (тоже из реальной жизни). Система писалась одним человеком на протяжении 10 лет. Жутко связана с другими системами (итеграции по средствам файлов, БД и прочего булшита). Кастомер принял решение — переписать заново, т.к. 1) В этом 10тилетнем хламе сложно разобраться 2) ЕГо сложно поддерживать и 3) Его архитектура — УГ и связывает все остальные системы. Чтобы развязаться — нужно полностью пересмотреть весь подход. Также есть 4я цель — т.к. писал систему 1 человек, то слишком велики риски.
                                                                                                                          Я пишу всё это к тому, что во-первых, не всегда девелопер определяет, переписывать заново или нет. И во-вторых, это комплексное решение, зависящее от многих факторов (перфоманс, скалабильность текущего решениея и т.п.
                                                                                                                            +7
                                                                                                                            Да вы пишите на английском сразу.
                                                                                                                              0
                                                                                                                              Сейчас вижу следующее — многие большие монолитные энтерпрайзные проекты разбиваются на несколько частей и уже являются друг для друга сервисами. Собственно к чему это ведет — да к тому, что за отдельный сервис отвечает уже небольшая команда из 3-10 человек. А не 40-50 девелоперов сидят в одном зале, одной командой и пишут-пишут-пишут код.

                                                                                                                              Ясное дело, что один разработчик, даже при таком подходе, не будет играть решающую роль. От его прихоти (хочу — не хочу), не будет складываться судьба проекта. Но то, что это будет гораздо гибче и удобнее в плане развития и, если потребуется, смены технологий — это факт.
                                                                                                                                0
                                                                                                                                >>Сейчас вижу следующее — многие большие монолитные энтерпрайзные проекты разбиваются на несколько частей и уже являются друг для друга сервисами.
                                                                                                                                Абсолютно верно. Те два примера, которые я привел — на самом деле модули одного большого проекта. Но я их назвал «системой» — из-за их независимости от общего проекта.
                                                                                                                              +1
                                                                                                                              Жду статьи — «Итак, этот проект придется переписывать с нуля». Только я уверен, что такой статьи не дождусь.
                                                                                                                                +1
                                                                                                                                Статья «Итак, этот проект придется переписывать с нуля»
                                                                                                                                Содержание: Удачи!
                                                                                                                                :)
                                                                                                                                0
                                                                                                                                Еще яркий пример проблемы: есть некоторый стандарт (например, клиент-серверный протокол). И есть исходники клиента. При их чтении волосы дыбом встают — кругом какие-то ифы, свичи, куча всяких ответвлений и частных случаев, отступлений от стандарта или разных (противоположных даже) его трактовок. Жуть! Надо всё переписать по стандарту!

                                                                                                                                Вот только оказывается потом, что это не говнокод вовсе, а попытка заставить клиент работать с разными серверами, которые блин, каждый реализуют стандарт по-своему. Т.е. можно было или написать красивый код, получив клиент, работающий по стандарту, по факту не совместимый ни с одним реальным сервером или написать противоречащий стандарту и логике говнокод, который будет реально работать.
                                                                                                                                  +2
                                                                                                                                  А почему бы не сделать абстракцию, которая скрывает недостатки разных платформ внутри себя и с ней работать?
                                                                                                                                    +1
                                                                                                                                    Потому что все абстракции дырявые. Каждый новый слой абстракции сковывает наши движения. После нескольких слоем уже начинаешь ощущать себя словно по горло в песке.

                                                                                                                                    Самый тяжелый случай который я видел фасад с именем Model, который поддерживал все рбд, несколько nosql-бд, три вида кэша и еще несколько приятных мелочей. Собственно методов там было мало — find, load, save, delete. Все.

                                                                                                                                    А у людей была проблема с ним — медленно работал, да и ни с чем, кроме как с постгресом они работать и не думали.
                                                                                                                                      0
                                                                                                                                      А у людей была проблема с ним — медленно работал, да и ни с чем, кроме как с постгресом они работать и не думали.

                                                                                                                                      Если так, то зачем тогда костыли для остальных версий?
                                                                                                                                      Вообще — не все. Посмотрите на JQuery. Она очень сильно сглаживает проблемы кроссбраузерности и при этом не уменьшает возможности программиста.
                                                                                                                                        0
                                                                                                                                        Зачем — сказать не могу. Видимо кто-то когда-то решил, что пригодиться.

                                                                                                                                        jquery это фреймворк, который по своей сложности не уступает голому js. То есть нам теперь не надо знать как именно работает какая-то фишка в каком-то конкретном браузере, но надо знать как она работает в jquery. Собственно поэтому он и не сковывает нам ничего.
                                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                    +2
                                                                                                                                    Переписывание с нуля это обычно куча времени и не факт, что новый код будет намного лучше.
                                                                                                                                    Правильнее, на мой взгляд, переписывать только то, что в данный момент мозолит глаз и раздражает сильнее всего. Так постепенно код придёт в норму.
                                                                                                                                      0
                                                                                                                                      > но и учесть все костыли, на которые наткнулся бывший говнокодер.
                                                                                                                                      Улыбнуло :).
                                                                                                                                        +2
                                                                                                                                        Я помню, когда-то давно, когда был еще наивен и глуп, переписывал один код, который мне казался лапшевидным. Я переписал эти 700 строк кода за один день. У меня вышло около 150 строчек, но потом, еще на протяжении месяца допиливал все то, что упустил. В итоге — около 800 строк.
                                                                                                                                          0
                                                                                                                                          Да нет же! С этим я абсолютно согласен. Прежде чем помножить на нолик десяток-другой «бесполезных» строк, нужно ой как крепко подумать о том, какая неведомая сила заставила их появиться. И очень часто «бесполезная» строка может оказаться недокументированным хаком.

                                                                                                                                          Я о том, что если костыль написал бывший говнокодер, то кто сейчас смотрит на этот костыль :)?
                                                                                                                                            0
                                                                                                                                            Один раз я видел такой код.

                                                                                                                                            Там было столько копипасты, что можно было выбрать любых 50 строк и ужать их до 5 строк функция + 10 строк кода.

                                                                                                                                            Потом выбрать 20 таких блоков по 15 строк и засунуть их в цикл. (2 строки на цикл, плюс 10 строк на две дополнительные функции и 15 строк тело цикла). Около часа бездумного выноса копипасты в функции и 50*20 = 1000 строк ужаты до 30 строк с полным сохранением функциональности. Автор утверждал, что так намного круче и удобнее разрабатывать.

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

                                                                                                                                              +2
                                                                                                                                              Меня улыбнуло то, что если на костыли наткнулся БЫВШИЙ говнокодер, то работает сейчас с этим костылём ТЕПЕРЕШНИЙ говнокодер. И не более… А вы мне тут про истории из жизни и прочее…
                                                                                                                                                0
                                                                                                                                                Не вижу логической связи. Вот было бы написано «прошлый говонокодер», тогда можно было бы сделать вывод, что и теперь говнокодер работает.
                                                                                                                                        0
                                                                                                                                        Полностью согласен с автором поста :)

                                                                                                                                        Нам очень часто попадались проекты от других программистов. И вот что мы заметили — есть люди, которые хотят всё переписать с нуля «по-нормальному» и, как оказалось, есть и те, которые просто продолжают в таком же стиле программировать.

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

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

                                                                                                                                        Если приходит проект, который был написан кем-то — прежде всего нужно понять, какой подход был у предыдущей команды к написанию программы и если неймётся — постараться придумать как этот подход можно немного улучшить.
                                                                                                                                          0
                                                                                                                                          Иногда бывает так, что разработчика ставят в рамки «модернизации системы», а при глубоком анализе выясняется, что тип работы «модернизация» переходит в тип «модернизация путем полного сноса».
                                                                                                                                          И тут лишь личная заинтересованность, опыт (не просто опыт, а опыт таких проектов) и желание оставить после себя проект «за который не стыдно» решают — будет ли это косметический рефакторинг или полное выпиливание родительского проекта.
                                                                                                                                            0
                                                                                                                                            Подозреваю, что есть большая разница между изменением каких-либо конкретных реализаций и изменением принципиальной структуры. Может статься так, что новый требуемый функционал просто вообще не реализуем без новой структуры — тогда придется разрабатывать заново и переписывать самую суть структуры проекта. Структуру нужно, подозреваю, разрабатывать с запасом, закладывая в нее то, что может потребоваться больше, чем указано в техзадании, как в количественных, так и в качественных смыслах, и учитывая что многое может поменяться.

                                                                                                                                            Про юнит-тесты и тестирование вообще — хочу спросить, а как же их реально применять? Как понять, куда их можно приткнуть? Особенно в тех случаях, когда код работает с чужими софтом/железом, когда неизвестны граничные условия и неизвестно достоверно, что и как должно быть.
                                                                                                                                              +1
                                                                                                                                              Насчёт железа не скажу, но достоверность даёт изучение кода. Надо заметить, что достоверность не того, как должно быть, а достоверность того, что есть. Основная задача автоматизированных тестов (юнит по крайней мере) не выявить ошибку, а зафиксировать поведение. При рефакторинге непокрытого тестами кода, сначала пишем тесты по результатам его анализа как «глазами», так и прогоном возможных или реальных значений (если есть возможность логировать вход и выход на большом потоке реальных данных), убеждаемся, что они проходят, то есть фиксируем поведение и лишь затем переписываем. Если вдруг пользователь рапортует, что «всё сломалось», то ищем, что мы не учли (например неявное использование переполнения или не очевидное привидение типа, например непустой строки к false, если эта строка '0'), пишем тест, который на старом коде работает, а на новом перестаёт, затем изменяем новый код так чтобы тест работал. Можно даже костылём изменить, если видно что обработка этого особого случая «по дзену» займёт много времени, а пользователь кричит «всё сломалось». Главное, что этот особый случай у нас зафиксирован, а будет время -перепишем без страха напороться на теже грабли.
                                                                                                                                                0
                                                                                                                                                Про фиксацию поведения да, подзабыл. Просто как-то мне в работе по большей части не приходилось возвращаться к старым методам, чтобы что — то изменить. Когда приходилось — например, это было изменение метода получения настроек с видеокамеры, чтобы считать новые настройки, появившиеся в новой прошивке или просто потребовавшиеся. И протестировать то, что он действительно возвращает все возможные значения без веб-интерфейса никак, нужно вручную менять их на камере и прогонять метод каждый раз. Ну, полагаю, здесь бы еще могли спасти mock-объекты, чтобы сымитировать поведение камеры, хотя анализировать поведение нескольких десятков моделей чтобы создать объект, который скорее всего нужен один раз, т.к. в каждой новой прошивке поведение может измениться радикально — это чересчур.

                                                                                                                                                Другой момент, когда приходилось возвращаться к старому, подразумевал переделку достаточно большой схемы работы как таковой. Каким методом автоматизированного тестирования можно охватить целый процесс, схему работы, состоящий из нескольких потоков, и охватывающий несколько классов? С отдельными методами проблем не возникало, сами по себе они работали прекрасно. Да в общем и со схемой тоже только пару раз обнаружились дедлоки — и установить ситуацию, в которой они возникали, так и не удалось — решили долгим и вдумчивым всматриванием в код и добавлением еще одной критической секции. Полагаю, юнит-тест можно было бы использовать, чтобы удостовериться что поведение не изменилось. Хотя проблем и так не возникло. Т.е. возможно они возникли, но обнаружить таковых не удалось и ситуаций, в которых они могли бы возникать, мы представить тоже не смогли. Затем остались проблемы с просадками производительности и утечкой памяти. Тут, я так понимаю, тесты тоже не использовать, т.к. фиксировать требуется поведение в достаточно сложном процессе, да и плюс к тому, всегда остаются неохваченные ситуации и неизвестные факторы.
                                                                                                                                                Вот когда в результате одного из обновлений камеры научились слать в заголовках пакетов видеопотока дополнительную информацию, и была мысль переписать парсер для поддержки этой возможности, тогда да, понимаю, как можно было бы использовать тесты — наловить несколько разных пакетов, и подсовывать их в тестах парсеру, затем расширить его, и проверить что старые пакеты парсятся так же. Но таких ситуаций было, ну, наверное, две за год с небольшим.
                                                                                                                                              0
                                                                                                                                              картинки красивые — зачет…
                                                                                                                                              что касается примера из жизни, то
                                                                                                                                              на заре расцвета Интернет, лет эдак 10 назад, может быть кто еще помнит:
                                                                                                                                              был очень перспективный проект Netscape Navigator,
                                                                                                                                              который давал несколько очков вперед бедному Ослику.
                                                                                                                                              И Вот бравые ребята из Netscape решили переписать весь код с ноля. Планировали все сделать за полгода, учитывая свои предыдущие наработки, в результате проект затянулся года на полтора, а за это время появился замечательный проект Mozilla, которая была по качеству лучше и удобнее.
                                                                                                                                              В результате Netscape влезло в долги, проект не пошел…
                                                                                                                                              в общем о такой фирме как Netscape уже мало кто помнит…
                                                                                                                                                0
                                                                                                                                                По отзывам знакомых, копавшихся в исходниках мозилы, там код тоже дале айс — запутанный так, без пол литра не разберешься, и хак на хаке сидит, и хаком погоняет
                                                                                                                                                  +8
                                                                                                                                                  Вы забыли упомянуть тот факт, что Mozilla Firefox и есть тот проект, который был переписан с нуля из Netscape Navigator.
                                                                                                                                                    0
                                                                                                                                                    нет…
                                                                                                                                                    тот проект стал Netscape 5.0
                                                                                                                                                    а  6.0 стала последней версией
                                                                                                                                                      0
                                                                                                                                                      Где доказательства?
                                                                                                                                                      Я специально сверялся с википедией:
                                                                                                                                                      "...Netscape приняла решение разрабатывать браузер в рамках проекта с открытым исходным кодом. Была создана неформальная группа Mozilla Organization, которая в основном финансировалась Netscape, оплачивавшей труд основной части программистов, работавших над проектом. Эта группа должна была координировать усилия по разработке Netscape 5, базировавшегося на исходном коде Communicator. Однако устаревший код создавал большие проблемы, и было принято решение написать программу заново. Новый исходный код был назван Mozilla, на основе которого с небольшими изменениями был создан Netscape 6."
                                                                                                                                                      ru.wikipedia.org/wiki/Netscape_Navigator
                                                                                                                                                      ru.wikipedia.org/wiki/Mozilla_Firefox
                                                                                                                                                        0
                                                                                                                                                        я про этот случай чиал в книге по управлению проектами,
                                                                                                                                                        но Википедия- тоже авторитетный источник, так что уложил на обе лопатки
                                                                                                                                                    0
                                                                                                                                                    Это вы Джоэля начитались.
                                                                                                                                                    Проблемы Нетскейпа были в первую очередь в бездарном руководстве, а потом уже в разрешении дать волю программистам и переписать всё.
                                                                                                                                                    0
                                                                                                                                                    Спасибо за статью, настроение поднялось :)!
                                                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                        0
                                                                                                                                                        а бывает проще переписать компилятор…
                                                                                                                                                          +1
                                                                                                                                                          расскажу об одном энтерпрайзном проекте
                                                                                                                                                          первая версия началась еще 1995 году, в 2006 было принято решение переписать с нуля, поскольку вендор старых средств разработки приказал долго жить еще 2003, и внесение изменений в систему стало слишком сложным.
                                                                                                                                                          до 2009 разработка велась в фоновом режиме, на фоне поддержки старой системы. в 2009 был внедрен первый этап, две системы работали в паре. И только сейчас, в 2012 внедеряется последний кусок.
                                                                                                                                                          Система бизнес кртитична, никаких перебоев в обслуживании не было, пользователи и руководство довольны.
                                                                                                                                                          Объем примерно 200к строк кода, команда 5 разработчиков + 3 тестера.
                                                                                                                                                          Но по времени вот как-то так получается.
                                                                                                                                                            +1
                                                                                                                                                            >… серьезные люди считают…
                                                                                                                                                            Можно конкретизировать? Какие, например?
                                                                                                                                                            Доводилось читать Макконнелла, Фаулера, Гласса, Мараско, Спинеллиса и др.
                                                                                                                                                            Авторы либо воздерживались от таких заявлений, либо, постараюсь процитировать:
                                                                                                                                                            — В жизни каждого проекта наступает момент, когда его надо написать с нуля.
                                                                                                                                                            — Первый вариант пишется на выброс и это надо принять, как должное.
                                                                                                                                                            Сам с нуля ни разу не переписывал ничего более чем на пару сотен строк в размере. Но рефачить приходиться постоянно.
                                                                                                                                                            Хотелось бы пополнить библиотеку работами других авторов. Заранее спасибо.
                                                                                                                                                              0
                                                                                                                                                              Возможно, я неправильно выразился в этом выражении.
                                                                                                                                                              Я тоже читал Макконнелла, может я додумал его таким образом.
                                                                                                                                                              Так же читал несколько различных статей, авторы которых придерживаются таких же мнений.
                                                                                                                                                              К сожалению, конкретизировать не могу)
                                                                                                                                                              +2
                                                                                                                                                              Надо признаться, я в данный момент (и не один, а с командой из 6 человек) переписываю старый проект.
                                                                                                                                                              Старый проект — САПР, разработан компанией Siemens в 70-80х гг под ОС HP-UX. Качественнейшая и современнейшая вещь для тех лет.
                                                                                                                                                              Получили лицензию, перенесли на платформу Linux из-за эмбарго США на поставки HP-машин.
                                                                                                                                                              Однако, последние 10 лет наблюдается страшная тенденция — система становится все хуже и хуже. Пересборка ряда модулей системы практически невозможна.
                                                                                                                                                              Под нее необходимо вести специальный дистрибутив ОС Linux. Обновление ядра Linux и glibc приводит к краху граф.редактора САПР.
                                                                                                                                                              + постоянные жалобы пользователей и желание внедрить кучу новых возможностей.

                                                                                                                                                              Пару лет убеждал руководство прекратить танцы с бубном, и начать разработку своей такой же системы.
                                                                                                                                                              В конце концов убедил. С тех пор прошло еще 2 года, пишем на Java и чуть-чуть на C. Через 2 месяца — проверка на вшивость — первое внедрение.
                                                                                                                                                                0
                                                                                                                                                                Желаю удачи!
                                                                                                                                                                Конечно же такие проекты должны переписываться, с тех лет появилось много более продвинутых средств как для разработки, так и для работы в принципе.
                                                                                                                                                                0
                                                                                                                                                                «Будьте готовы выбросить первую версию проэкта» — Ф. Брукс.
                                                                                                                                                                Переписывать можно по разному. От facebook первой версии наверное и строчки не осталось, и даже код двухлетней давности не всюду найдёшь. Код эволюционирует, в хорошо спроэктированом приложении одну подсистему, а иногда даже целый слой, меняют с минимальным влиянием на другие части.
                                                                                                                                                                А проэкты на 10 000 строк, у меня курсовая, компилятор языка Си имел около 10000 строк, о bison/yacc я тогда не знал.
                                                                                                                                                                15 000 для современного проєкта это достаточно мало. И помните хорошую пословицу «глаза боятся, а руки делают». Главное при изменении системы наличие плана, цели, чего мы этим изменением хотим достичь, улучшение для улучшения не имеет ценности для клиента. Для того придумали рефакторинг, TDD чтобы менять код с лучшей эфективностью.
                                                                                                                                                                  +1
                                                                                                                                                                  Проэкта? Проєкта?
                                                                                                                                                                    0
                                                                                                                                                                    Проекты бывают разные. Я специально уточнил, что статья применима к разработке одним программистом, или на крайний случай парой.
                                                                                                                                                                    Врядли бы Цукерберг стал с нуля один переписывать фейсбук, да?
                                                                                                                                                                    Тем более, вы говорите о частичном переписывании различных модулей, я же утверждаю, что весь проект переписывать с нуля чрезвычайно сложно, особенно при отсутствии адеватно сформированных требований и тестов.
                                                                                                                                                                    0
                                                                                                                                                                    По опыту, переписывание 15000 строк кода в попугаях — это год работы и соответственно годовой оклад одного программиста. Если заказчик готов платить — почему нет? Плюс к этому прокачка скилсов.
                                                                                                                                                                      0
                                                                                                                                                                      15000 строк кода бывают разными. Если это год работы нормального программиста, то, я не думаю что они так уж и плохи. Посмотрите на стандартные библиотеки, там те же тысячи строк историей в несколько десятков лет порой бывают.
                                                                                                                                                                        +1
                                                                                                                                                                        Тем не менее был как минимум в двух ситуациях.
                                                                                                                                                                        Первая — когда некую аналитическую систему переписал с нуля один человек за две недели переписал с нуля с учетом новых требований, в то время как «развернутую и работающую» пытались доработать 3 месяца.
                                                                                                                                                                        Вторая, когда переписаная с нуля система (семантическое ядро) в 5 раз обогнала на настольном компе рабочую у развернутую на мейнфрейме.

                                                                                                                                                                        Я НЕ утверждаю, что перписывать хорошо. Однако, работая аналитиком, привык к фактам и привык не доверять утверждениям «считаю, что так правильно».

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

                                                                                                                                                                        «Итак. Есть вариант дописывать к текущей — и каждая доработка будет стоит $100. И есть вариант переписать за $900 со внятной архитектурой и тогда каждая доработка будет стоить $10. И тогда если требуется < 10 доработок выгоднее дописывать старую, а если больше, то выгоднее переписать»

                                                                                                                                                                        И никаких вам «да в чо, он нормальный программист» и «да я вам как эксперт говорю» и прочих разрываний тельняшек.
                                                                                                                                                                          +1
                                                                                                                                                                          Спасибо за статью. Как раз сейчас назревает необходимость серьезного рефакторинга, даже почти полного переписывания, так что тема актуальна :)

                                                                                                                                                                          Статья не понравилась. Очень как-то все на голых утверждениях, и почти предвзято. По каждому пункту хотелось бы увидеть обоснования, примеры, доводы. Мне лично было бы гораздо интереснее читать обоснованные утверждения, чем просто список полезных советов. А моя практика (т.е. чтение с последующей проверкой материала) так вообще показывает, что такие советы часто неконструктивны, слишком поверхностны да и вообще бесполезны или даже вредны. Да и Вам могло бы быть полезным расписать свои мысли, это помогает глубже разобраться в теме.

                                                                                                                                                                          Вот, например, по первому пункту, который как раз практически мой случай.

                                                                                                                                                                          > проект – больше, чем лабораторная, но меньше, чем реальный коммерческий проект. Размер примерно 1000 строк кода.

                                                                                                                                                                          Ага, даже наверное меньше 800, если пустые строки поудалять :) Хотя, представьте себе, это реальный коммерческий проект (не в количестве строк дело, в общем).

                                                                                                                                                                          > Вы написали его и захотели улучшить.

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

                                                                                                                                                                          > Но вдруг обнаружили, что в архитектуре у вас ошибка, и исправление проблемно.

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

                                                                                                                                                                          > Переписали. Потом еще раз.

                                                                                                                                                                          На этом месте сразу возникает вопрос: почему «потом еще раз»? На чем основываются такие прогнозы? Или это просто догадки? Какие примеры из жизни вы можете привести, когда за первым переписыванием следовало второе и третье?

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

                                                                                                                                                                          > Станете ли вы переписывать его в четвертый раз? Возможно.

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

                                                                                                                                                                          > Небольшие проекты можно переписывать бесконечно, пока они не будут доведены до совершенства. Но вот проблема: где эта грань между совершенством и сумасшествием?

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

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

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

                                                                                                                                                                          > А время будет потеряно.

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

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

                                                                                                                                                                          Можем сдать. А можем и не сдать. Это вообще просто предположение, и страшилка для студента. А если посчитать выгоду, риски, то будет понятно, стоит этим заниматься или нет.

                                                                                                                                                                          Ну и так далее по всей статье.

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

                                                                                                                                                                          Еще переписывание может иметь хорошую практическую пользу в целях совершенствования навыков. Если хочется и можется — почему бы и не переписать? Будет как минимум возможность сравнить несколько подходов.

                                                                                                                                                                          Ссылка на «серьезных людей» порадовала — такие себе авторитеты в масках, сразу располагающие к доверию :)

                                                                                                                                                                          Пишите еще, больше, и интеснее!

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

                                                                                                                                                                          Самое читаемое