Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 182
Можно еще тесты написать. Получится быстрее, чем «все с нуля», и можно будет потихоньку по частям рефакторить.
Покрытие юнит-тестами незнакомого кода — это безусловно хорошая практика. Но далеко не всякий код хорошо тестируем (более того, если он хорошо тестируем, возможно он не так уж и плох) и зачастую приходится провести некислый такой рефакторинг, чтобы этой самой тестируемости добиться =)
Не на всякий лапшекод можно написать тесты, так, что бы быстрее. К примеру, недавно, мне попался один замечательный год-обжект (там где он мне попался, еще с пару десятков таких): 2 публичных метода и 12 (или 13 уже не припомню) тысяч строк кода, около 40 приватных методов и вызов еще трех таких вот год обжектов.
По сути то интеграционный тест накатить можно — вполне понятно что будет после вызова и первого, и второго методов. Собственно так и поступили. Но полноценно растащить все у меня получилось только через полтора дня (рефакторинг от идеи очень облегчил работу). Но и тут для тестирования были проблемы, состояние многих объектов было «нестабильным», в лучшем случае — неполным. Они прокидывались через 10-20-30 методов, перед тем как улететь в очередной внешний объект забивались левыми данными, потом подчищались (благо в комментариях люди поясняли зачем это было сделано). Где-то зачем-то копировались.
В общей сложности там, при каждом последующем рефакторинге, хорошо так и тесты переписывались. Переделывание этого всего заняло уже 8 дней, и это примерно треть от того, что необходимо сделать.
Переписали бы с нуля гораздо быстрее было бы — уже бы закончили, пару таких вот модулей переписали уже. Но, к сожалению, старый код тоже надо активно сопровождать (хотя там сопровождения на 10-20 минут в день — тут поменять, там запилить, тут что бы вместо ААА было ААА + БББ). Поэтому такой вот компромисс — часть времени за задачу, несравнимая часть на рефакторинг.
По сути то интеграционный тест накатить можно — вполне понятно что будет после вызова и первого, и второго методов. Собственно так и поступили. Но полноценно растащить все у меня получилось только через полтора дня (рефакторинг от идеи очень облегчил работу). Но и тут для тестирования были проблемы, состояние многих объектов было «нестабильным», в лучшем случае — неполным. Они прокидывались через 10-20-30 методов, перед тем как улететь в очередной внешний объект забивались левыми данными, потом подчищались (благо в комментариях люди поясняли зачем это было сделано). Где-то зачем-то копировались.
В общей сложности там, при каждом последующем рефакторинге, хорошо так и тесты переписывались. Переделывание этого всего заняло уже 8 дней, и это примерно треть от того, что необходимо сделать.
Переписали бы с нуля гораздо быстрее было бы — уже бы закончили, пару таких вот модулей переписали уже. Но, к сожалению, старый код тоже надо активно сопровождать (хотя там сопровождения на 10-20 минут в день — тут поменять, там запилить, тут что бы вместо ААА было ААА + БББ). Поэтому такой вот компромисс — часть времени за задачу, несравнимая часть на рефакторинг.
Когда стоит переписывать проект- когда вы говнокодер и хотите набраться опыта…
Я стараюсь предерживаться правила, достаточно четко сформулированного в старом-добром анекдоте:
- Папа, а почему солнце всегда встает на восходе, а заходит на западе?
папа поворачивает голову с красно-воспаленными глазами к сыну
- Всегда восходит на востоке?
сын: - Всегда
папа: - заходит всегда на западе?
сын: - Да
папа: - ничего не глючит? все работает нормально?
сын: - да, все нормально
папа: - Ну так и не трогай там нихрена!
Хороший анекдот, тоже его люблю)
Вот это верно. Работает — не трогай.
Главное — не распространять этот принцип на утюги, чайники и т.д.
не работает — меняй.
нафига возиться со старым умершим чайникм, когда можно купить новый.
в общем-то.
нафига возиться со старым умершим чайникм, когда можно купить новый.
в общем-то.
Если можно купить — хорошо, а если самому сделать чайник, вместо того, чтобы подпаять…
Если денег совсем некуда девать.
В стиральной машине автомате за почти 15 лет работы четырежды поменял прокладку-сальник в выпускном насосе. Первый раз она стОила около рубля, последний раз — рублей 40. Общая сумма меньше меньше сотни. Четыре стиральных машины это тоже несколько меньше сотни. Только тысяч.
ЗЫ. Кстати, у коллеги случилась как-то такая же проблема. Вызвал он сертифицированного мастера. Тот ему поменял насос. Старый вручил в руки со словами — он годный, только прокладка износилась, а мы прокладки менять не сертифицированы. Сумма ремонта — 6 тыс руб. Патамушта Бош и его не чинят. Его меняют.
В стиральной машине автомате за почти 15 лет работы четырежды поменял прокладку-сальник в выпускном насосе. Первый раз она стОила около рубля, последний раз — рублей 40. Общая сумма меньше меньше сотни. Четыре стиральных машины это тоже несколько меньше сотни. Только тысяч.
ЗЫ. Кстати, у коллеги случилась как-то такая же проблема. Вызвал он сертифицированного мастера. Тот ему поменял насос. Старый вручил в руки со словами — он годный, только прокладка износилась, а мы прокладки менять не сертифицированы. Сумма ремонта — 6 тыс руб. Патамушта Бош и его не чинят. Его меняют.
ну вот если кто-то из топовых производителей тупо меняет книго читалки — киндлы кажется…
в моей конторе, например тоже модемы если пересыхает, грет и не работает тоже меняют
в моей конторе, например тоже модемы если пересыхает, грет и не работает тоже меняют
В конторе — это хорошо. Можно попросить заменённый прибор забрать себе для опытов и, если повезёт и починка лёгкая, получить +1 к опыту и +1 прибор за бесценок :).
то, что забирается на замену — выкидывается как неремонтопригодное еще сервиниками ))
нет смысла возиться.
нет смысла возиться.
Не очень понял кто на ком стоял… Наверное, в больших забюрократизированных конторах всё сложно — я тоже встречался со всякими актами на списание и специальной службой, принимающей сгоревшую технику для последующей сдачи на драгметаллы… Но в небольших таки попроще.
Ну, и к слову… Вот совсем недавно у одного некта сдох блок питания в компуктере. Нект вызвал мастера. Мастер заменил БП. Сгоревшая деталь всегда оставляется клиенту. Ну, я у некта взял умертвие для опытов. Вздулся конденсатор (заводской дефект этой модели) и выгорели защитные варисторы на входе. Общая цена ремонта — где-то на 10 рублей комплектухи, 10 минут гугленья, 20 минут на распаковывание паяла-кусачек-отвёрток, сборку-разборку, впайку-выпайку, демонстрацию детишкам кишок БП, процесса пайки, торжественного включения и поддержания образа немерянной папиной круторы :). Дополнительный бонус — вновьобретённый прибор оказался мощнее и совершеннее моего домашнего, был вставлен в домашний контупер, а старый блок пошёл на другие опыты по мастыренью из него зарядного устройства для автомобильного аккумулятора, севшего по причине «внезапных» для сибири холодов ниже -35 (зимой ещё было дело).
Было бы желание и, главное, интерес поколупаться.
Ну, и к слову… Вот совсем недавно у одного некта сдох блок питания в компуктере. Нект вызвал мастера. Мастер заменил БП. Сгоревшая деталь всегда оставляется клиенту. Ну, я у некта взял умертвие для опытов. Вздулся конденсатор (заводской дефект этой модели) и выгорели защитные варисторы на входе. Общая цена ремонта — где-то на 10 рублей комплектухи, 10 минут гугленья, 20 минут на распаковывание паяла-кусачек-отвёрток, сборку-разборку, впайку-выпайку, демонстрацию детишкам кишок БП, процесса пайки, торжественного включения и поддержания образа немерянной папиной круторы :). Дополнительный бонус — вновьобретённый прибор оказался мощнее и совершеннее моего домашнего, был вставлен в домашний контупер, а старый блок пошёл на другие опыты по мастыренью из него зарядного устройства для автомобильного аккумулятора, севшего по причине «внезапных» для сибири холодов ниже -35 (зимой ещё было дело).
Было бы желание и, главное, интерес поколупаться.
Обычно дохнет подшипник на барабане, а не сальник… И его смена — многочасовой геморрой с фиговым результатом.
Иногда люди готовы платить деньги за то, чтобы ты ничего не переделывал, но смог, в случае чего, подставить костыль. Им спокойней так живётся, т.к. проверенное старое легче поддаётся управлению (читай – планированию).
Прибегает молодой сын-юрист к старому отцу-юристу и кричит:
- Отец, поздравь меня! Я выиграл дело, которое ты не мог выиграть всю свою жизнь!
А тот ему в ответ:
- Дурак, я с него кормился всю свою жизнь!..
у вас какой то до чет :) в первой строчке.
на третий строке возвращался три раза и понял, что наверное «встает на востоке», а не «встает на восходе»
:) или все таки я не прав?
на третий строке возвращался три раза и понял, что наверное «встает на востоке», а не «встает на восходе»
:) или все таки я не прав?
Как раз столкнулся недавно с такой ситуацией: дали мне с коллегой для тестирования ПЗС-камеру, в комплекте — только виндовые драйверы. Их установили, но оказалось, что без дорогущей проприетарной поделки ни кадра мы с этой камеры не получим (а поделка не имеет CLI, т.е. работать с ней бессмысленно).
Благо, нашелся линуксовый софт. Однако, при компиляции он не заработал. Модуль ядра был допилен до современного, однако клиентский софт постоянно падал. Внутри — уйма страшного кода без проверок значений, возвращаемых функциями, поддержка уймы матриц, кроме конкретно нашей.
Вот и думай, что здесь делать: переписывать с нуля («выдрав» лишь то, что нужно для работы с конкретной камерой), или же пытаться «допилить» имеющееся (~28 тысяч строк) до рабочего состояния (а там еще проблема в том, что оно не на С, а на C++)…
Благо, нашелся линуксовый софт. Однако, при компиляции он не заработал. Модуль ядра был допилен до современного, однако клиентский софт постоянно падал. Внутри — уйма страшного кода без проверок значений, возвращаемых функциями, поддержка уймы матриц, кроме конкретно нашей.
Вот и думай, что здесь делать: переписывать с нуля («выдрав» лишь то, что нужно для работы с конкретной камерой), или же пытаться «допилить» имеющееся (~28 тысяч строк) до рабочего состояния (а там еще проблема в том, что оно не на С, а на C++)…
Не рассматривайте камеру и софт отдельно друг от друга, относитесь к ним вместе как к продукту. Тогда возможно поставить вопрос, а не проще ли сменить продукт?
Согласен. Однако, во-первых, меня никто не спрашивал, покупать ли эту камеру; во-вторых, продукция сильно специфическая и узнать о ней подробную информацию до покупки часто просто невозможно (т.е. пишет, например, продавец, что у него все ОК, а на деле — ничего не работает, или работает совершенно не так, как было заявлено).
Согласен с автором!
Кроме того, переписывание с нуля может привести к тому, что команде придется сопровождать два совершенно разных решения для одной и той же задачи. Эта ситуация происходит в том случае, если «старое» решение уже внедрено у нескольких клиентов, и обновлять его клиенты не собираются.
Кроме того, переписывание с нуля может привести к тому, что команде придется сопровождать два совершенно разных решения для одной и той же задачи. Эта ситуация происходит в том случае, если «старое» решение уже внедрено у нескольких клиентов, и обновлять его клиенты не собираются.
Когда я купил свой первый велосипед (китайон), решил улучшить в нём в се узлы по мере возможностей. Начал с замены подшипников. Однако по неопытности поставил их не той стороной и как следует испоганил оси. С тех пор я твёрдо держусь правила: не сломалось — не чини.
Очень хорошее правило, но слабо применимое к активной разработке ПО. Поясню на примере. Сейчас имею дело с одной очень старой системой где очень так хорошо следовали этому правилу. В итоге такого 3.14%$!@#а, я не встречал давно. Тут можно весь день искать то место куда бы влепить костыль и навсегда забыть про это место. Это будет самое лучшее решение, ну или по крайней мере оно не будет выделяться из общей массы кода.
За то недолгое время, которое мне пришлось поработать с этим кодом, я могу сказать следующее: в моих руках находиться история. Я вижу слои программного кода, которые отчетливо показывают как же все таки развивалась java в последние 10 лет, начиная с третьей, и думаю скоро появиться, седьмой версией. Я вижу что поиск и отладка занимают до 90% моего времени.
В сравнении с тем новым кодом, который я пишу, где поиск занимает жалкие 5% времени, а отладка… тут все сложно — тесты пишутся вместе с кодом, поэтому на тыканье этого всего ручками тоже не больше 10% времени, по большей части что бы убедиться, что действительно все так прекрасно.
И да, мой код уже пару раз за последние несколько месяцев хорошо так отрефакторен, что бы не появился еще один пласт истории — уж лучше сейчас потратить 30 минут и допилить до актуальных требований, пусть даже они чисто косметические, нежели потом, через год рвать на себе волосы и громко кричать что приходиться копаться в говне.
За то недолгое время, которое мне пришлось поработать с этим кодом, я могу сказать следующее: в моих руках находиться история. Я вижу слои программного кода, которые отчетливо показывают как же все таки развивалась java в последние 10 лет, начиная с третьей, и думаю скоро появиться, седьмой версией. Я вижу что поиск и отладка занимают до 90% моего времени.
В сравнении с тем новым кодом, который я пишу, где поиск занимает жалкие 5% времени, а отладка… тут все сложно — тесты пишутся вместе с кодом, поэтому на тыканье этого всего ручками тоже не больше 10% времени, по большей части что бы убедиться, что действительно все так прекрасно.
И да, мой код уже пару раз за последние несколько месяцев хорошо так отрефакторен, что бы не появился еще один пласт истории — уж лучше сейчас потратить 30 минут и допилить до актуальных требований, пусть даже они чисто косметические, нежели потом, через год рвать на себе волосы и громко кричать что приходиться копаться в говне.
Правило применимо к любой сфере и не имеет ограничений. Суть его, как видно, может показаться не явной.
От велосипеда требуется только езда. Если он едет и ездока это устраивает, нет смысла в нём что-то чинить.
В вашем случае есть необходимость делать рефакторинг, дабы облегчить дальнейшую вашу работу.
От велосипеда требуется только езда. Если он едет и ездока это устраивает, нет смысла в нём что-то чинить.
В вашем случае есть необходимость делать рефакторинг, дабы облегчить дальнейшую вашу работу.
Ситуаций когда от кода требуется только что бы он работал — мало. Очень мало. ПО — это, зачастую, живые и развивающиеся системы, которые должны адаптироваться под существующие реалии. Наш мир очень изменчив и если ПО из за своей архитектуры невозможно в приемлемые сроки переделать под текущие реалии, то такое по превращается в зомби.
По поводу велосипедов, тут тоже не все так просто. Когда-то давно, когда я начинал заниматься стритом и очень активно общался с другими велосипедистами, которые триалили или, например, занимались дертом, я понял насколько велосипед для них живой организм. Не было и недели, что бы там что-то не правилось, не подпиливалось, не
Без этого они погибают, ну или как
И правильно говорят, что код пишется не для компилятора, а для человека. По другому никак.
По поводу велосипедов, тут тоже не все так просто. Когда-то давно, когда я начинал заниматься стритом и очень активно общался с другими велосипедистами, которые триалили или, например, занимались дертом, я понял насколько велосипед для них живой организм. Не было и недели, что бы там что-то не правилось, не подпиливалось, не
Без этого они погибают, ну или как
И правильно говорят, что код пишется не для компилятора, а для человека. По другому никак.
Текс, продолжаем:
Не было и недели, что бы там что-то не правилось, не подпиливалось, не покупалось, не менялось. Потому что, если перестал следить за велосипедом то все, это верный путь к быдлотриалу — когда ты сидишь с пивом на лавке, а твой байк валяется рядом.
И опять же, сейчас, если я достану свой велосипед с балкона, а мне придется это сделать — через 2 недели буду собаку гонять по лесу, для того, что бы в форму привести. То мне придется неплохо так вложиться, потому что, например, в тех же тормозах я не уверен. В вилке — ну, прыгать с ней бы не решился :)
Так же и программы, если его дне подпиливать, не подтачивать, не переделывать — то без этого они погибают, ну или как зомби становятся — вроде они и есть, что-то делают, но лучше не трогать, что бы мозг был в целости и сохранности. Посмотрите сейчас на то, что не правилось в последние несколько лет, но исправно выполняет свои обязанности — сразу поймете о чем я.
Не было и недели, что бы там что-то не правилось, не подпиливалось, не покупалось, не менялось. Потому что, если перестал следить за велосипедом то все, это верный путь к быдлотриалу — когда ты сидишь с пивом на лавке, а твой байк валяется рядом.
И опять же, сейчас, если я достану свой велосипед с балкона, а мне придется это сделать — через 2 недели буду собаку гонять по лесу, для того, что бы в форму привести. То мне придется неплохо так вложиться, потому что, например, в тех же тормозах я не уверен. В вилке — ну, прыгать с ней бы не решился :)
Так же и программы, если его дне подпиливать, не подтачивать, не переделывать — то без этого они погибают, ну или как зомби становятся — вроде они и есть, что-то делают, но лучше не трогать, что бы мозг был в целости и сохранности. Посмотрите сейчас на то, что не правилось в последние несколько лет, но исправно выполняет свои обязанности — сразу поймете о чем я.
Мой опыт показал, что если есть архитектурные просчеты, блокирующие развитие — то лучше сразу переписать, чем навешивать гроздья костылей.
А по поводу старого, но хорошего или незаменимого кода — если его грамотно «обернуть» и задокументировать, то он прослужит очень и очень долго.
А по поводу старого, но хорошего или незаменимого кода — если его грамотно «обернуть» и задокументировать, то он прослужит очень и очень долго.
Код вообще, сам по себе, очень живуч. В конце прошлого года зашел на один из тех сайтов, которые я поддерживал, в начале своей карьеры. Смотрю — тот же девелоперский бекдор, залез, посмотрел историю в svn — 5 лет без обновления, та система виджетов которую запиливал. Из документации — только комментарий. Количество виджетов за это время выросло с 10 до около 80 (80 разных наследников класса Widget). Зачем так много — кто его знает, посмотрел на несколько, можно было бы удалить вообще, если немного подправить сам базовый класс. Но его почему-то никто не трогает.
Стараюсь если и переписывать, то по частям, и покрывать код тестами.
Вопрос к автору: как вы относитесь к рефакторингу?
К рефакторингу я отношусь замечательно, если его делаю не я)
К сожалению, лишь в немногих фирмах выделяется время на рефакторинг, а когда он проводится во время внесения доработок – это совсем зло.
К сожалению, лишь в немногих фирмах выделяется время на рефакторинг, а когда он проводится во время внесения доработок – это совсем зло.
А почему рефакторинг во время внесения доработок — это зло?
Потому что можно в нем случайно утонуть.
Допустим, вам дали доработку и вы ее оценили. В процессе вы поняли, что неплохо бы эту часть улучшить, код не читается, алгоритм неоптимален. Вы переработали часть + внесли доработку за время, отведенное только на доработку (либо за большее время, т.е. не уложились в срок), и не успели адекватно протестировать. В лучшем случае, можно будет просто откатиться. В худшем, не дай кодобог, ошибка попадет в продакшн.
Допустим, вам дали доработку и вы ее оценили. В процессе вы поняли, что неплохо бы эту часть улучшить, код не читается, алгоритм неоптимален. Вы переработали часть + внесли доработку за время, отведенное только на доработку (либо за большее время, т.е. не уложились в срок), и не успели адекватно протестировать. В лучшем случае, можно будет просто откатиться. В худшем, не дай кодобог, ошибка попадет в продакшн.
Согласен, спасибо.
Проблема не в рефакторинге, а в неправильном планировании и управлении проектом. Некоторые доработки трудно встроить в существующую архитектуру проекта. В таком случае принимается решение к доработке архитектуры под новые изменения. На это необходимо запланировать соответствующее время. Данная техника рефакторинга освещается в книге Фаулера (ниже я уже оставил ссылку)
Рефакторинг должен влючаться в оценку в таком случае. Если вы достаточно давно в проекте, вы должны знать все топкие места, и либо сразу понимать, сколько там понадобится на рефакторинг, либо взять немного времени для того, чтобы посмотреть и дать оценку.
Поэтому тесты должны быть до рефакторинга и внесения изменений. «Зажимаете» тестами «окрестности» кусков, которые предполагаете доработать, пишите тест на доработку, пишите саму доработку.
Я вот очень плохо отношусь к тому времени, которое выделяют на рефакторинг. Сейчас попытаюсь объяснить почему.
Потому что многие разработчики считают это время временем для того, что бы все переписать. Так и получалось у нас несколько раз (разные разработчики, разный уровень, разные языки) — два дня в конце спринта на рефакторинг, в начале следующего кричат о том что не хватило времени, нужен еще один день. Смотришь что сделали — половину отрефакторили, половину переписали все с нуля, а так как спешили — то сейчас то, что переписали не менее «кривое» и бажное, так что в первую очередь пойдет на следующий рефакторинг.
Знаю людей которые постоянно выбирают второй вариант. В итоге через какое-то время недоумевают почему даже подправить одну маленькую делать выливается в несколько часов.
Другое дело когда человек начинает допиливать что-либо и понимает, что надо бы немного подправить код, что бы было проще. Тогда и рефакторинг действительно рефакторинг, а не «сейчас мы напряжемся и за день выдадим коду на всю неделю вперед».
Но это не касается тех ситуаций, когда необходим архитектурный рефакторинг — или 2-3 дня только им заниматься, а уже потом новый код (иначе никак) или десяток костылей за те же 2-3 дня но на текущей архитектуре.
Потому что многие разработчики считают это время временем для того, что бы все переписать. Так и получалось у нас несколько раз (разные разработчики, разный уровень, разные языки) — два дня в конце спринта на рефакторинг, в начале следующего кричат о том что не хватило времени, нужен еще один день. Смотришь что сделали — половину отрефакторили, половину переписали все с нуля, а так как спешили — то сейчас то, что переписали не менее «кривое» и бажное, так что в первую очередь пойдет на следующий рефакторинг.
Знаю людей которые постоянно выбирают второй вариант. В итоге через какое-то время недоумевают почему даже подправить одну маленькую делать выливается в несколько часов.
Другое дело когда человек начинает допиливать что-либо и понимает, что надо бы немного подправить код, что бы было проще. Тогда и рефакторинг действительно рефакторинг, а не «сейчас мы напряжемся и за день выдадим коду на всю неделю вперед».
Но это не касается тех ситуаций, когда необходим архитектурный рефакторинг — или 2-3 дня только им заниматься, а уже потом новый код (иначе никак) или десяток костылей за те же 2-3 дня но на текущей архитектуре.
В одной из книг натыкался на интересное предложение. Если изменения кода модуля (компонента, класса и т.п.) затрагивают больше его четверти — то дешевле будет переписать его полностью. На самом деле, наверное, не стоит относится к величине 25% как к какому magic number. Но, совершенно точно, нужно понимать, что всегда есть порог, которые разделяет две крайности — переписывание и рефакторинг. И любое принятое решение — это компромисс.
Иногда очень трудно решиться на то, чтобы оставить в продукте какой-то старинный модуль, особенно после того как в него посмотришь… Но у него есть важное преимущество — он уже есть и он уже давно работает. Но если есть понимание, что требования изменились настолько сильно, что этот старый модуль придется изрядно переделать/доделать — почти наверняка проще сделать его заново. Потому что как себя поведет старый код в новых условиях, на которые он не был изначально рассчитан — большая загадка.
Иногда очень трудно решиться на то, чтобы оставить в продукте какой-то старинный модуль, особенно после того как в него посмотришь… Но у него есть важное преимущество — он уже есть и он уже давно работает. Но если есть понимание, что требования изменились настолько сильно, что этот старый модуль придется изрядно переделать/доделать — почти наверняка проще сделать его заново. Потому что как себя поведет старый код в новых условиях, на которые он не был изначально рассчитан — большая загадка.
Если изменения кода модуля (компонента, класса и т.п.) затрагивают больше его четверти — то дешевле будет переписать его полностью
От кода все зависит. Если так посчитать то мой последний «перепишем все с нуля» был от того, что необходимо было поправить около 1% кода т.е. чуть более 50 строчек кода. Правда это были основные строчки. В итоге оказалось так, что либо переписываем все и забываем обо всем на свете. Либо эти 20 строчек выделяем в стратегию и используем либо старую (которая работает для всего-всего), либо новую которая работает только для достаточно малой части тех модулей которые имеются в обвесе, но зато так, как необходимо на текущий момент.
Первым шагом был второй вариант, а там в течении той же недели и остальное под новый вариант перепилили. Как водиться — с нуля.
От кода все зависит. Если так посчитать то мой последний «перепишем все с нуля» был от того, что необходимо было поправить около 1% кода т.е. чуть более 50 строчек кода. Правда это были основные строчки. В итоге оказалось так, что либо переписываем все и забываем обо всем на свете. Либо эти 20 строчек выделяем в стратегию и используем либо старую (которая работает для всего-всего), либо новую которая работает только для достаточно малой части тех модулей которые имеются в обвесе, но зато так, как необходимо на текущий момент.
Первым шагом был второй вариант, а там в течении той же недели и остальное под новый вариант перепилили. Как водиться — с нуля.
Зависит от обстоятельств. Я видел один отчетик, который постоянно «апгрейдили» методом копипаста. Там можно вместо сотен нефти кода прописать парочку функций и сделать все гораздо проще и удобнее, но разработчик свято следовал правилу «работает? — пусть работает». И ведь работает…
Вы сами ответили на свой вопрос — оно работает! Для практических задач это часто перевешивает все внутренние недостатки.
Могу привести не то чтобы контрпример. Жила была система, ей было лет 15, технологии устарели, разработчики сменились, количество заплаток и вставок превысило все разумные пределы.
Наконец-то было принято решение все переписать заново. Была сделана система, которая гораздо надежнее, масштабируемее, функциональнее. По крайней мере теоретически. Дело за малым — реализовать это на практике. Программа большая, писало её много народу и все немножко ошибались (куда без этого). Наверное еще года 3 — и система станет почти такой, какой должна стать…
Могу привести не то чтобы контрпример. Жила была система, ей было лет 15, технологии устарели, разработчики сменились, количество заплаток и вставок превысило все разумные пределы.
Наконец-то было принято решение все переписать заново. Была сделана система, которая гораздо надежнее, масштабируемее, функциональнее. По крайней мере теоретически. Дело за малым — реализовать это на практике. Программа большая, писало её много народу и все немножко ошибались (куда без этого). Наверное еще года 3 — и система станет почти такой, какой должна стать…
Говорю же, от обстоятельств зависит. Лично я многие вещи каждый раз с нуля делаю, и достиг в этом определенного мастерства. После такого стыдно смотреть в свой же старый код. И чужой код не гнушаюсь в порядок приводить, очень помогает в дальнейшем. А то, что работает — это еще не значит, что хорошо работает.
Но при этом я не агитирую за однозначное переписывание всего и вся. Для этого опыт нужен, знание как лучше сделать.
Но при этом я не агитирую за однозначное переписывание всего и вся. Для этого опыт нужен, знание как лучше сделать.
Что я нового прочитал в этой статье студента-фрилансера?
Вроде, я не указывал, и не претендовал на новизну.
И почему интересно вы решили, что я – студент-фрилансер?
И почему интересно вы решили, что я – студент-фрилансер?
Посмотрел профиль, 22 года — студент, или вы решили не учиться?)
Понимаете, проблема даже не в том, что статья не интересна. Перед тем как кого-то учить, постарайтесь объяснить во введении, почему вы знаете про это лучше других, каков ваш опыт, иначе доверия к вашим советам не будет.
Понимаете, проблема даже не в том, что статья не интересна. Перед тем как кого-то учить, постарайтесь объяснить во введении, почему вы знаете про это лучше других, каков ваш опыт, иначе доверия к вашим советам не будет.
Не судите людей по каким-то внешним признакам. Я мог написать, что мне 35 лет, я живу в штатах и работаю в Google. При этом было бы больше доверия?
Хорошо, я учту пожелания)
К слову, я получаю диплом, и имею опыт коммерческой разработки 3 года. Это не очень много, согласен, но я считаю, что мне есть, чем поделиться.
Хорошо, я учту пожелания)
К слову, я получаю диплом, и имею опыт коммерческой разработки 3 года. Это не очень много, согласен, но я считаю, что мне есть, чем поделиться.
реальность состоит не только из студентов которым трудно разобраться в том что есть но и из профессионалов которые переписывают проект т.к. его принято и оценено решение его сделать заново.
Примеры полностью переписанных систем
MS Windows 3.11 -> MS Windows 95
MacOS — > MacOS X
Внутрикорпоративные системы также нередко полностью переписываются. Главное чтоб решение об этом принималось обоснованно.
Основная причина полной переделки — архитектура на момент создания не учитывала появившиеся со временем изменения в рабочем процессе т.к. заранее всё учесть невозможно.
Примеры полностью переписанных систем
MS Windows 3.11 -> MS Windows 95
MacOS — > MacOS X
Внутрикорпоративные системы также нередко полностью переписываются. Главное чтоб решение об этом принималось обоснованно.
Основная причина полной переделки — архитектура на момент создания не учитывала появившиеся со временем изменения в рабочем процессе т.к. заранее всё учесть невозможно.
«И еще помните, что серьезные люди считают, что переписывание проектов с нуля – это признак непрофессионализма.»
Чьего непрофессионализма, того кто изначально написал какашку или менеджера, который допускает экономически невыгодные действия (рефакторинг, зачем если и так работает)?
Был у меня случай когда предложили поработать с проектом (на ведущей роли) который разрабатывался более двух лет, командой из 4-5 человек. Сам проект еле шевелится на нагрузках, переписать сами понимаете нереально, дорабатывать как бы тоже (структура БД не позволит).
А вот допустим фрилансю для себя в целях не столько заработать, сколько получить некоторый реальный опыт работы с интересующими инструментами и библиотеками, то есть работаю с не совсем привычными технологиями. Изначально делаю не совсем оптимально (ввиду недостатка опыты в данном направлении, сроков первой демонстрации, изначально не лучших выбранных библиотек и тд), но аккуратно и осмысленно, сразу ставлю TODO где видны сомнительные места, весь проект веду один — поэтому рефарактор проще. Заказчик заранее оповещен что планируется стадия рефаторинга, и вполне это допускает. Почему бы в таком случае и не порефакторить, и самому полезно (вообще когда тебя не гонят желание сделать лучше возникает чаще), и проекту, и оплачивается. А вот многие местные конторы уверен вообще не знакомы с таким понятием как рефакторинг, ну разве что только в свое свободное время :)
Особенно сложно рефакторить «динамические языки» (вроде JS), и крайне сложно когда нет единой структуры использования этих языков (куча разнородного JS кода раскидано по страницам, никаких классов, никаких неймспейсов). Все нужно загрузить в голову (язык ведь не компилируемый), чтобы найти общую часть, отследить связи, построить иерархию и тд.
Чьего непрофессионализма, того кто изначально написал какашку или менеджера, который допускает экономически невыгодные действия (рефакторинг, зачем если и так работает)?
Был у меня случай когда предложили поработать с проектом (на ведущей роли) который разрабатывался более двух лет, командой из 4-5 человек. Сам проект еле шевелится на нагрузках, переписать сами понимаете нереально, дорабатывать как бы тоже (структура БД не позволит).
А вот допустим фрилансю для себя в целях не столько заработать, сколько получить некоторый реальный опыт работы с интересующими инструментами и библиотеками, то есть работаю с не совсем привычными технологиями. Изначально делаю не совсем оптимально (ввиду недостатка опыты в данном направлении, сроков первой демонстрации, изначально не лучших выбранных библиотек и тд), но аккуратно и осмысленно, сразу ставлю TODO где видны сомнительные места, весь проект веду один — поэтому рефарактор проще. Заказчик заранее оповещен что планируется стадия рефаторинга, и вполне это допускает. Почему бы в таком случае и не порефакторить, и самому полезно (вообще когда тебя не гонят желание сделать лучше возникает чаще), и проекту, и оплачивается. А вот многие местные конторы уверен вообще не знакомы с таким понятием как рефакторинг, ну разве что только в свое свободное время :)
Особенно сложно рефакторить «динамические языки» (вроде JS), и крайне сложно когда нет единой структуры использования этих языков (куча разнородного JS кода раскидано по страницам, никаких классов, никаких неймспейсов). Все нужно загрузить в голову (язык ведь не компилируемый), чтобы найти общую часть, отследить связи, построить иерархию и тд.
Треш
Лучше дорабатывать переписывая, eсли проект это позволяет.
Для быстрорастущих проектов очень часто переписывание с нуля — это единственный шанс остаться на плаву.
Когда у вас есть 1000 пользователей, вы справляетесь, но когда появляется 100.000 пользователей, то становится очевидным, что текущая архитектура не позволяет держать такую нагрузку.
А дальше у вас 2 пути: либо переписать всё с нуля, либо тратиться на более дорогое железо до тех пор, пока стоимость обслуживания каждого следующего пользователя не станет выше того дохода, который он приносит. А потом всё равно переписывать всё с нуля.
Я это видел уже в двух компаниях, когда проекты вдруг становились очень высоконагруженными и приходилось всё переписывать.
Когда у вас есть 1000 пользователей, вы справляетесь, но когда появляется 100.000 пользователей, то становится очевидным, что текущая архитектура не позволяет держать такую нагрузку.
А дальше у вас 2 пути: либо переписать всё с нуля, либо тратиться на более дорогое железо до тех пор, пока стоимость обслуживания каждого следующего пользователя не станет выше того дохода, который он приносит. А потом всё равно переписывать всё с нуля.
Я это видел уже в двух компаниях, когда проекты вдруг становились очень высоконагруженными и приходилось всё переписывать.
>Размер проекта превышает 10000 кода
это как 100 нефти?
это как 100 нефти?
Первый комикс переведён неправильно. «OH MY. I've done it again, haven't I?» — это совсем не «Я ведь сделал всё правильно?..», от этого теряется половина смысла.
Бывает берешься за чужой проект и начинаешь его допиливать, думаешь, так ведь быстрее получится, чем заново на грабли наступать, а потом увязаешь в этом говнокоде и через полгода осознаешь что за эти полгода можно было запросто проект с нуля написать и через все грабли пройти.
Выводы спорные. Блестящий аналог проекта — жена. Нет универсального решения, что быстрее и лучше — перевоспитать текущую жену или развестись и завести себе новую.
Серьезные люди считают, ага. Я посмотрел бы на этих серьезных людей если бы им внезапно пришлось поддерживать код в котором встречалась javascript-переменная isIE4
Рефакторинг — наше все.
Советую прочитать книгу:
Мартин Фаулер — Рефакторинг. Улучшение существующего кода.
www.ozon.ru/context/detail/id/1308678/
Советую прочитать книгу:
Мартин Фаулер — Рефакторинг. Улучшение существующего кода.
www.ozon.ru/context/detail/id/1308678/
6) Размер проекта превышает 10000 кода, без учета инструментов и фреймворков. Даже этого будет много чтобы оценить, стоит ли овчинка выделки.
Когда файл старой версии класса занимает 114кб вообще без комментов, а новая версия с минимальными комментами — 14 кб и делает тоже самое, но без багов + ещё чуть-чуть — начинаешь очень сильно задумываться о необходимости переписывания всего, что попадает под руку в этом проекте…
Когда файл старой версии класса занимает 114кб вообще без комментов, а новая версия с минимальными комментами — 14 кб и делает тоже самое, но без багов + ещё чуть-чуть — начинаешь очень сильно задумываться о необходимости переписывания всего, что попадает под руку в этом проекте…
>Когда файл старой версии класса занимает 114кб
Вот на этом этапе уже нужно задумываться о том, чтобы переписывать. Задумываться, не значит переписывать.
Вот на этом этапе уже нужно задумываться о том, чтобы переписывать. Задумываться, не значит переписывать.
7) размер проекта превышает 500 000 кода без учета инструментов и фреймворков — их там просто нет.
Переписывать однозначно, но надо сохранять совместимость — все равно не сможешь переписать всё.
В итоге получаем еще один уровень наслоений на этом говне мамонта. Но может 500 000 кода превратятся в 400 000 кода и последователям будет попроще.
Переписывать однозначно, но надо сохранять совместимость — все равно не сможешь переписать всё.
В итоге получаем еще один уровень наслоений на этом говне мамонта. Но может 500 000 кода превратятся в 400 000 кода и последователям будет попроще.
Переписать пол-миллиона строк? Вы трудозатраты себе представляете?
Ещё стоит учесть, что при переписывании с нуля неизбежно будут внесены новые баги.
Не говоря уже о том, что в коммерческом продукте это действо просто экономически нецелесообразно.
Не нравится код — для тебя придумали рефакторинг.
Ещё стоит учесть, что при переписывании с нуля неизбежно будут внесены новые баги.
Не говоря уже о том, что в коммерческом продукте это действо просто экономически нецелесообразно.
Не нравится код — для тебя придумали рефакторинг.
серьезные люди считают, что переписывание проектов с нуля – это признак непрофессионализма
самый правильный вывод во всей статье
самый правильный вывод во всей статье
Как то в одном веб приложении переписывал «Главную» функцию, которая обсчитывала всё что можно и которая использовалась везде где только можно, т.к. на больших объёмах данных всё ложилось. На входе — что то около 7 параметров. На выходе — 31 массив. Около 2000 строк кода. Недели 2 разбирал что как устроено. Еще столько же переписывал. И месяц ушел на то, чтобы при различном наполнении БД и различных входных параметрах выход старого и нового экземпляров был идентичным.
С тех пор с большой опаской отношусь к оптимизациям :) Хотя и без нее было нельзя, и «рабочее время» на нее было выделено.
С тех пор с большой опаской отношусь к оптимизациям :) Хотя и без нее было нельзя, и «рабочее время» на нее было выделено.
Интересно почему у Вас сложилось отрицательное впечатление, Вас не устроил результат?
Доводилось ли Вам после этого длительно сопровождать этот проект?
Что получилось вместо вышеприведенной функции с 7 параметрами?
Использовались ли юнит-тесты при проведении рефакторинга?
Доводилось ли Вам после этого длительно сопровождать этот проект?
Что получилось вместо вышеприведенной функции с 7 параметрами?
Использовались ли юнит-тесты при проведении рефакторинга?
Я не сказал, что негативное. Просто столько «души» вынула эта переработка, что прежде чем браться за подобное — 100 раз подумаю. Сам результат меня устроил в том плане, что именно с этим моментом, меня больше не напрягали.
В общей сложности проект я 2 года сопровождал. Изначально было много народу, когда я туда пришел. Потом, буквально за пол года на этом проекте я один остался.
А получился такой же «ящик» с идентичным входом и выходом, только другой начинкой + в последствие было кеширование навешано. Т.к. обновление автоматически накатывалось порядка 60 клиентам, то переписывать кардинально было чревато. Да и «добро» на это не дали.
Юнит тесты не использовались. Не до того было.
В общей сложности проект я 2 года сопровождал. Изначально было много народу, когда я туда пришел. Потом, буквально за пол года на этом проекте я один остался.
А получился такой же «ящик» с идентичным входом и выходом, только другой начинкой + в последствие было кеширование навешано. Т.к. обновление автоматически накатывалось порядка 60 клиентам, то переписывать кардинально было чревато. Да и «добро» на это не дали.
Юнит тесты не использовались. Не до того было.
Думаю вся проблема была в том, что это была «главная функция». Я такое тоже встречал и мне говорили о таких местах кода так: делай что хочешь — а вот это не трогай, даже не смотри туда. Один раз посмотрел. Функция которая делает по сути все и ничего одновременно. Когда критическая масса нового функционала стала обрастать костылями для того, что бы «главная функция» не поперхнулась, то решили отказаться от нее. Постепенно она стала не то, что бы второстепенной — а придатком к 2-м стародавним модулям, которые были написаны еще на заре рождения веба, и никому не хотелось туда лезть и что-то править. Работали ведь как часы известной швейцарской марки.
Проблема может лежать в разной плоскости. И не всегда это связанно с ростом проекта (количества разработчиков), нагрузок. Иногда проблема может лежать в плоскости оптимизаций по затратам — лично видел как один проект, пожирал время 12+ разработчиков. Видел доску этого проекта, где половина (отданная под задачи), была заполнена серыми карточками — техническим долгом.
В итоге была создана команда с гордым названием RT (Refactoring Teem) которая должна была по сути заниматься рефракторным и устранением всех технических долгов. Она как достигла 4 человек, так и осталась со следующей версией продукта. Остальные разработчики стали не нужны, эти люди, после года своей работы (где-то переписали с нуля, где-то зарефакторили три раза до неузнаваемости), делали гораздо больше нежели старая команда со старым кодом.
Как минимум в три раза сократить издержки по разработке — думаю это тоже неплохой результат.
В итоге была создана команда с гордым названием RT (Refactoring Teem) которая должна была по сути заниматься рефракторным и устранением всех технических долгов. Она как достигла 4 человек, так и осталась со следующей версией продукта. Остальные разработчики стали не нужны, эти люди, после года своей работы (где-то переписали с нуля, где-то зарефакторили три раза до неузнаваемости), делали гораздо больше нежели старая команда со старым кодом.
Как минимум в три раза сократить издержки по разработке — думаю это тоже неплохой результат.
На самом деле, единственная причина для переписывания кода с нуля — это когда старый проект написан без объектно-ориентированного подхода и при этом язык программирования не поддерживает ООП.
Аргументируйте
Ну, это же элементарно — в ОО парадигме пишется для чего? Как раз для того, чтобы ЛЮБОЙ человек мог переписать ЛЮБОЙ код не с нуля, а базируясь на построенной раньше модели (применил бы рефакторинг). Когда код написан не в ООП модели — то код не имеет модели, то что там написано не соответствует предметной области, становится невозможно использовать повторно старый функции — код логически не разделен и соответственно он не понятен становится. А если еще и язык не дает возможности это постепенно улучшить — вот тогда и задумаешься о переписывании с нуля на другом более строгом ОО языке.
А если это просто прекрасный код в процедурном или функциональном стиле. Или говнище, под маской ООП?
С говнищем под маской ООП, но которой работает — можно бороться, есть методы и приемы, при этом не секрет, что называние говнищем это просто не понимание логики того кто это писал, в 80% случаев просто эмоции.
Но прекрасный код в процедурном или функциональном стиле имеет точку не возврата, когда после внесения туда изменений код становится невозможно сопровождать. С таким кодом нужно поступить так: взять написать правильную ОО-модель, и использовать старые функции в ОО-оболочке. Если что-то не ложится, то тогда переписывать с нуля.
Но прекрасный код в процедурном или функциональном стиле имеет точку не возврата, когда после внесения туда изменений код становится невозможно сопровождать. С таким кодом нужно поступить так: взять написать правильную ОО-модель, и использовать старые функции в ОО-оболочке. Если что-то не ложится, то тогда переписывать с нуля.
Собственно, меня пригласили на фирму как раз для того, чтобы переписать ХОРОШИЙ код в процедурном стиле на ОО-код, по той простой причине, что этот ХОРОШИЙ код стало невозможно развивать дальше. Проект был порядка 50-100 тыс. строк.
Ну и потом вы видели код в чистом функциональном стиле на 50-100 тыс. строк? Где? Очень хочется посмотреть.
linux kernel
:)
читаем
Linux — ядро операционной системы, соответствующее стандартам POSIX. В основном код написан на Си с некоторыми расширениями gcc и на ассемблере
И как на Си можно написать в чистом функциональном стиле? Не понимаю.
читаем
Linux — ядро операционной системы, соответствующее стандартам POSIX. В основном код написан на Си с некоторыми расширениями gcc и на ассемблере
И как на Си можно написать в чистом функциональном стиле? Не понимаю.
Стиль там, конечно, процедурный, но ООП как такового нет. А «чисто функциональное программирование» — сильно узкоспециализированная штука.
Так я именно об этом и говорю. Но написав недавно статью «Существуют только структурная и объектная парадигмы программирования» там развели такой холивар, что пришлось закрыть. Но там всего лишь утверждалось как раз это: "«чисто функциональное программирование» — сильно узкоспециализированная штука". А в остальном статья была вообще про другое, но этого хватило для ужасного эмоционального холивара.
Вот и здесь смотрю массово минусуют, но без аргументов.
А про процедурное надо говорить отдельно, и никто не сомневается что там был потенциал больший, но не такой мощный как в ООП. (впрочем это тоже было написано в той проблемной статье)
Вот и здесь смотрю массово минусуют, но без аргументов.
А про процедурное надо говорить отдельно, и никто не сомневается что там был потенциал больший, но не такой мощный как в ООП. (впрочем это тоже было написано в той проблемной статье)
Мне тоже. Но вон Линукс написан (afaik) в процедурном стиле (очень хорошем) и никому это не мешает. А есть десятки вещей, которые написаны в ООП стиле — очень сложно поддерживать.
Я сам всегда пишу в ООП-стиле, но ваша категоричность — плоха.
Я сам всегда пишу в ООП-стиле, но ваша категоричность — плоха.
Про процедурный стиль никто не говорит. Такого много написали до ООП. Но это уже всем известно, что процедурный стиль имеет ограничения на размер кода.
кому «всем»?
Не согласен, есть много промышленных и научных программ большого размера, написанных в процедурном стиле. Например, модели прогноза погоды. Авторам этих программ и в голову не приходит переписать их под ООП.
Это связано со спецификой, в такой сфере просто очень мало пользовательского интерфейса. А алгоритмы действительно в процедурном стиле пишутся нормально и справляются с задачей. Но как только они захотят предоставить нормальный GUI и главное и у них расширится предметная область — они будут вынуждены подумать о ООП. Кроме того, не к таким программа ограниченные требования — клиенты редко выдвигают им свои требования как они хотят, чтобы работала программа. Мат. модель — она есть мат. модель, пользователи редко разбираются что в ней надо менять, а вот «эта кнопочка стоит не тут, и по ней это засуньте сюда, а это посчитайте так» — стимулируют эволюционирование программы, и только в ООП это не превращается в «сущий ад»
Верно сказано, но к таким программам, как правило, GUI поставляется отдельно и является самостоятельной программой. Поэтому не возникает необходимость, переписать весь комплекс с ноля.
Это конечно выход, но ограниченный. Так как визуальная часть плотно общается с не визуальной. А если это в разных программах, то изменения в одной затрагивают изменения в другой — в итоге ничего кроме вырастания «бороды» не происходит. Конечно есть случаи не такой плотной связи — тогда такое решение годится.
GUI тоже не всегда требует ООП. Посмотрите, например, на openmotif или tk. Да и в том же GTK ООП чисто условное.
Я видел. работаю над проектом, где, есть выкинуть все вендорские тулзы, получится около 600.000 LOC. По надобности внедряю ООП, но у меня нет ООП головного мозга, поэтому я понимаю где нужен объект, а где — добавить функцию в библиотеку. Очень странно слышать про «переписывание кода полностью на ООП, потому что процедурный код — это плохо». Кажется, такое мнение навязывается популярными фреймверками (RoR, Yii, ZF, CI, Cake и т.д.), вот люди и страдают.
Построение модели предметной области, легкость рефакторинга, логическое разделение кода (а-ля слои/модули) и ООП — вещи ортогональные друг к другу (почти). Самый простой пример — предметная область моделируется не классами/объектами, а таблицами и полями БД.
Кому не нравится, хотя бы аргументировали бы :)
1. Это относится только к программированию железа, драйверов и т.п. — мы сейчас говорим не об этом
2. В ООП — все можно исправить. В этом ее и суть. В других парадигмах исправление будет практически не возможно без риска сделать не работающий код. + см. выше
2. В ООП — все можно исправить. В этом ее и суть. В других парадигмах исправление будет практически не возможно без риска сделать не работающий код. + см. выше
2. Все то, что вы упомянули — как раз и делается рефакторингом. Выкинуть ума не надо — но сделать заново будет куда сложнее.
Я еще ни разу не слышал случая, когда кто-то переделывал проект только потому что там ООП нету) Что угодно может быть, но никак не эта причина
см. коммент выше
Поддержка языками ООП — это большей частью «синтаксический сахар». Поэтому сложно говорить о том, что язык не поддерживает парадигму ООП: есть массивы/хэши/структуры (доступ к данным по индексу/имени), есть хоть какой-то механизм вызова функций/процедур динамически (указатели на функции, call_user_func, ФВП и т. п.) — язык де-факто поддерживает ООП, например, Ассемблер x86 его поддерживает.
Вывод: причин для переписывания с нуля вообще нет? :)
Вывод: причин для переписывания с нуля вообще нет? :)
Автор, статья пропитана неопытностью. Вы, видимо, мало в интерпрайзе работали или не работали вообще. Да, в большинсве случаев согласен с доводами — действительно, чем крупнее проект — тем меньше шансов его переписать как нужно. НО! очень часто это необходимо. И то, что вы перечислили — далеко не все случаи. Бывает так, что система в будущем может потребовать большей нагрузки (Например, к 2015му году 500000 реквестов в день, вместо текущих 70) и основная архитектура — ни коим образом не уложится в такие требования. К тому же написана индусами и по-индусски. В этом случае — проще уговорить заказчика, предоставить ему пруф оф концепт, что наша версия работает быстрее, более масштабируема + добавить бантиков (типа, мы добавим еще админку, точнее некий бекофис) и сделаем всё более конфигурабильно. Тогда получается, и выигрывает кастомер, получая более быстрое и скалабильное решение, и выигрывает вендор, т.к. 1) объем работ больше, селовательно и кастомер заплатит больше и 2) И разработчикам так легче, чем рыться в индусском коде.
Другой случай (тоже из реальной жизни). Система писалась одним человеком на протяжении 10 лет. Жутко связана с другими системами (итеграции по средствам файлов, БД и прочего булшита). Кастомер принял решение — переписать заново, т.к. 1) В этом 10тилетнем хламе сложно разобраться 2) ЕГо сложно поддерживать и 3) Его архитектура — УГ и связывает все остальные системы. Чтобы развязаться — нужно полностью пересмотреть весь подход. Также есть 4я цель — т.к. писал систему 1 человек, то слишком велики риски.
Я пишу всё это к тому, что во-первых, не всегда девелопер определяет, переписывать заново или нет. И во-вторых, это комплексное решение, зависящее от многих факторов (перфоманс, скалабильность текущего решениея и т.п.
Другой случай (тоже из реальной жизни). Система писалась одним человеком на протяжении 10 лет. Жутко связана с другими системами (итеграции по средствам файлов, БД и прочего булшита). Кастомер принял решение — переписать заново, т.к. 1) В этом 10тилетнем хламе сложно разобраться 2) ЕГо сложно поддерживать и 3) Его архитектура — УГ и связывает все остальные системы. Чтобы развязаться — нужно полностью пересмотреть весь подход. Также есть 4я цель — т.к. писал систему 1 человек, то слишком велики риски.
Я пишу всё это к тому, что во-первых, не всегда девелопер определяет, переписывать заново или нет. И во-вторых, это комплексное решение, зависящее от многих факторов (перфоманс, скалабильность текущего решениея и т.п.
Да вы пишите на английском сразу.
Сейчас вижу следующее — многие большие монолитные энтерпрайзные проекты разбиваются на несколько частей и уже являются друг для друга сервисами. Собственно к чему это ведет — да к тому, что за отдельный сервис отвечает уже небольшая команда из 3-10 человек. А не 40-50 девелоперов сидят в одном зале, одной командой и пишут-пишут-пишут код.
Ясное дело, что один разработчик, даже при таком подходе, не будет играть решающую роль. От его прихоти (хочу — не хочу), не будет складываться судьба проекта. Но то, что это будет гораздо гибче и удобнее в плане развития и, если потребуется, смены технологий — это факт.
Ясное дело, что один разработчик, даже при таком подходе, не будет играть решающую роль. От его прихоти (хочу — не хочу), не будет складываться судьба проекта. Но то, что это будет гораздо гибче и удобнее в плане развития и, если потребуется, смены технологий — это факт.
>>Сейчас вижу следующее — многие большие монолитные энтерпрайзные проекты разбиваются на несколько частей и уже являются друг для друга сервисами.
Абсолютно верно. Те два примера, которые я привел — на самом деле модули одного большого проекта. Но я их назвал «системой» — из-за их независимости от общего проекта.
Абсолютно верно. Те два примера, которые я привел — на самом деле модули одного большого проекта. Но я их назвал «системой» — из-за их независимости от общего проекта.
Жду статьи — «Итак, этот проект придется переписывать с нуля». Только я уверен, что такой статьи не дождусь.
Еще яркий пример проблемы: есть некоторый стандарт (например, клиент-серверный протокол). И есть исходники клиента. При их чтении волосы дыбом встают — кругом какие-то ифы, свичи, куча всяких ответвлений и частных случаев, отступлений от стандарта или разных (противоположных даже) его трактовок. Жуть! Надо всё переписать по стандарту!
Вот только оказывается потом, что это не говнокод вовсе, а попытка заставить клиент работать с разными серверами, которые блин, каждый реализуют стандарт по-своему. Т.е. можно было или написать красивый код, получив клиент, работающий по стандарту, по факту не совместимый ни с одним реальным сервером или написать противоречащий стандарту и логике говнокод, который будет реально работать.
Вот только оказывается потом, что это не говнокод вовсе, а попытка заставить клиент работать с разными серверами, которые блин, каждый реализуют стандарт по-своему. Т.е. можно было или написать красивый код, получив клиент, работающий по стандарту, по факту не совместимый ни с одним реальным сервером или написать противоречащий стандарту и логике говнокод, который будет реально работать.
А почему бы не сделать абстракцию, которая скрывает недостатки разных платформ внутри себя и с ней работать?
Потому что все абстракции дырявые. Каждый новый слой абстракции сковывает наши движения. После нескольких слоем уже начинаешь ощущать себя словно по горло в песке.
Самый тяжелый случай который я видел фасад с именем Model, который поддерживал все рбд, несколько nosql-бд, три вида кэша и еще несколько приятных мелочей. Собственно методов там было мало — find, load, save, delete. Все.
А у людей была проблема с ним — медленно работал, да и ни с чем, кроме как с постгресом они работать и не думали.
Самый тяжелый случай который я видел фасад с именем Model, который поддерживал все рбд, несколько nosql-бд, три вида кэша и еще несколько приятных мелочей. Собственно методов там было мало — find, load, save, delete. Все.
А у людей была проблема с ним — медленно работал, да и ни с чем, кроме как с постгресом они работать и не думали.
А у людей была проблема с ним — медленно работал, да и ни с чем, кроме как с постгресом они работать и не думали.
Если так, то зачем тогда костыли для остальных версий?
Вообще — не все. Посмотрите на JQuery. Она очень сильно сглаживает проблемы кроссбраузерности и при этом не уменьшает возможности программиста.
Зачем — сказать не могу. Видимо кто-то когда-то решил, что пригодиться.
jquery это фреймворк, который по своей сложности не уступает голому js. То есть нам теперь не надо знать как именно работает какая-то фишка в каком-то конкретном браузере, но надо знать как она работает в jquery. Собственно поэтому он и не сковывает нам ничего.
jquery это фреймворк, который по своей сложности не уступает голому js. То есть нам теперь не надо знать как именно работает какая-то фишка в каком-то конкретном браузере, но надо знать как она работает в jquery. Собственно поэтому он и не сковывает нам ничего.
Переписывание с нуля это обычно куча времени и не факт, что новый код будет намного лучше.
Правильнее, на мой взгляд, переписывать только то, что в данный момент мозолит глаз и раздражает сильнее всего. Так постепенно код придёт в норму.
Правильнее, на мой взгляд, переписывать только то, что в данный момент мозолит глаз и раздражает сильнее всего. Так постепенно код придёт в норму.
> но и учесть все костыли, на которые наткнулся бывший говнокодер.
Улыбнуло :).
Улыбнуло :).
Я помню, когда-то давно, когда был еще наивен и глуп, переписывал один код, который мне казался лапшевидным. Я переписал эти 700 строк кода за один день. У меня вышло около 150 строчек, но потом, еще на протяжении месяца допиливал все то, что упустил. В итоге — около 800 строк.
Да нет же! С этим я абсолютно согласен. Прежде чем помножить на нолик десяток-другой «бесполезных» строк, нужно ой как крепко подумать о том, какая неведомая сила заставила их появиться. И очень часто «бесполезная» строка может оказаться недокументированным хаком.
Я о том, что если костыль написал бывший говнокодер, то кто сейчас смотрит на этот костыль :)?
Я о том, что если костыль написал бывший говнокодер, то кто сейчас смотрит на этот костыль :)?
Один раз я видел такой код.
Там было столько копипасты, что можно было выбрать любых 50 строк и ужать их до 5 строк функция + 10 строк кода.
Потом выбрать 20 таких блоков по 15 строк и засунуть их в цикл. (2 строки на цикл, плюс 10 строк на две дополнительные функции и 15 строк тело цикла). Около часа бездумного выноса копипасты в функции и 50*20 = 1000 строк ужаты до 30 строк с полным сохранением функциональности. Автор утверждал, что так намного круче и удобнее разрабатывать.
Но в целом этому коду помогло бы только полное удаление, что мы, в принципе, и сделали.
Там было столько копипасты, что можно было выбрать любых 50 строк и ужать их до 5 строк функция + 10 строк кода.
Потом выбрать 20 таких блоков по 15 строк и засунуть их в цикл. (2 строки на цикл, плюс 10 строк на две дополнительные функции и 15 строк тело цикла). Около часа бездумного выноса копипасты в функции и 50*20 = 1000 строк ужаты до 30 строк с полным сохранением функциональности. Автор утверждал, что так намного круче и удобнее разрабатывать.
Но в целом этому коду помогло бы только полное удаление, что мы, в принципе, и сделали.
Полностью согласен с автором поста :)
Нам очень часто попадались проекты от других программистов. И вот что мы заметили — есть люди, которые хотят всё переписать с нуля «по-нормальному» и, как оказалось, есть и те, которые просто продолжают в таком же стиле программировать.
Т.к. я отношусь к тем, кто хочет всё с нуля переписывать — то мы так пробовали делать. И очень сильно обломались, т.к. тупо не учли, что проект до нас 4 года разрабатывался и там столько функционала, который переписать просто нереально. Месяц работы — коту под хвост (просто удалили, что успели за это время написать).
Если клиент настаивает на том, что нужно всё переписать с нуля — делаем ему оценку план как на новый проект — и нет никаких проблем. Но если это наша инициатива — лучше 3 раза перекреститься.
Если приходит проект, который был написан кем-то — прежде всего нужно понять, какой подход был у предыдущей команды к написанию программы и если неймётся — постараться придумать как этот подход можно немного улучшить.
Нам очень часто попадались проекты от других программистов. И вот что мы заметили — есть люди, которые хотят всё переписать с нуля «по-нормальному» и, как оказалось, есть и те, которые просто продолжают в таком же стиле программировать.
Т.к. я отношусь к тем, кто хочет всё с нуля переписывать — то мы так пробовали делать. И очень сильно обломались, т.к. тупо не учли, что проект до нас 4 года разрабатывался и там столько функционала, который переписать просто нереально. Месяц работы — коту под хвост (просто удалили, что успели за это время написать).
Если клиент настаивает на том, что нужно всё переписать с нуля — делаем ему оценку план как на новый проект — и нет никаких проблем. Но если это наша инициатива — лучше 3 раза перекреститься.
Если приходит проект, который был написан кем-то — прежде всего нужно понять, какой подход был у предыдущей команды к написанию программы и если неймётся — постараться придумать как этот подход можно немного улучшить.
Иногда бывает так, что разработчика ставят в рамки «модернизации системы», а при глубоком анализе выясняется, что тип работы «модернизация» переходит в тип «модернизация путем полного сноса».
И тут лишь личная заинтересованность, опыт (не просто опыт, а опыт таких проектов) и желание оставить после себя проект «за который не стыдно» решают — будет ли это косметический рефакторинг или полное выпиливание родительского проекта.
И тут лишь личная заинтересованность, опыт (не просто опыт, а опыт таких проектов) и желание оставить после себя проект «за который не стыдно» решают — будет ли это косметический рефакторинг или полное выпиливание родительского проекта.
Подозреваю, что есть большая разница между изменением каких-либо конкретных реализаций и изменением принципиальной структуры. Может статься так, что новый требуемый функционал просто вообще не реализуем без новой структуры — тогда придется разрабатывать заново и переписывать самую суть структуры проекта. Структуру нужно, подозреваю, разрабатывать с запасом, закладывая в нее то, что может потребоваться больше, чем указано в техзадании, как в количественных, так и в качественных смыслах, и учитывая что многое может поменяться.
Про юнит-тесты и тестирование вообще — хочу спросить, а как же их реально применять? Как понять, куда их можно приткнуть? Особенно в тех случаях, когда код работает с чужими софтом/железом, когда неизвестны граничные условия и неизвестно достоверно, что и как должно быть.
Про юнит-тесты и тестирование вообще — хочу спросить, а как же их реально применять? Как понять, куда их можно приткнуть? Особенно в тех случаях, когда код работает с чужими софтом/железом, когда неизвестны граничные условия и неизвестно достоверно, что и как должно быть.
Насчёт железа не скажу, но достоверность даёт изучение кода. Надо заметить, что достоверность не того, как должно быть, а достоверность того, что есть. Основная задача автоматизированных тестов (юнит по крайней мере) не выявить ошибку, а зафиксировать поведение. При рефакторинге непокрытого тестами кода, сначала пишем тесты по результатам его анализа как «глазами», так и прогоном возможных или реальных значений (если есть возможность логировать вход и выход на большом потоке реальных данных), убеждаемся, что они проходят, то есть фиксируем поведение и лишь затем переписываем. Если вдруг пользователь рапортует, что «всё сломалось», то ищем, что мы не учли (например неявное использование переполнения или не очевидное привидение типа, например непустой строки к false, если эта строка '0'), пишем тест, который на старом коде работает, а на новом перестаёт, затем изменяем новый код так чтобы тест работал. Можно даже костылём изменить, если видно что обработка этого особого случая «по дзену» займёт много времени, а пользователь кричит «всё сломалось». Главное, что этот особый случай у нас зафиксирован, а будет время -перепишем без страха напороться на теже грабли.
Про фиксацию поведения да, подзабыл. Просто как-то мне в работе по большей части не приходилось возвращаться к старым методам, чтобы что — то изменить. Когда приходилось — например, это было изменение метода получения настроек с видеокамеры, чтобы считать новые настройки, появившиеся в новой прошивке или просто потребовавшиеся. И протестировать то, что он действительно возвращает все возможные значения без веб-интерфейса никак, нужно вручную менять их на камере и прогонять метод каждый раз. Ну, полагаю, здесь бы еще могли спасти mock-объекты, чтобы сымитировать поведение камеры, хотя анализировать поведение нескольких десятков моделей чтобы создать объект, который скорее всего нужен один раз, т.к. в каждой новой прошивке поведение может измениться радикально — это чересчур.
Другой момент, когда приходилось возвращаться к старому, подразумевал переделку достаточно большой схемы работы как таковой. Каким методом автоматизированного тестирования можно охватить целый процесс, схему работы, состоящий из нескольких потоков, и охватывающий несколько классов? С отдельными методами проблем не возникало, сами по себе они работали прекрасно. Да в общем и со схемой тоже только пару раз обнаружились дедлоки — и установить ситуацию, в которой они возникали, так и не удалось — решили долгим и вдумчивым всматриванием в код и добавлением еще одной критической секции. Полагаю, юнит-тест можно было бы использовать, чтобы удостовериться что поведение не изменилось. Хотя проблем и так не возникло. Т.е. возможно они возникли, но обнаружить таковых не удалось и ситуаций, в которых они могли бы возникать, мы представить тоже не смогли. Затем остались проблемы с просадками производительности и утечкой памяти. Тут, я так понимаю, тесты тоже не использовать, т.к. фиксировать требуется поведение в достаточно сложном процессе, да и плюс к тому, всегда остаются неохваченные ситуации и неизвестные факторы.
Вот когда в результате одного из обновлений камеры научились слать в заголовках пакетов видеопотока дополнительную информацию, и была мысль переписать парсер для поддержки этой возможности, тогда да, понимаю, как можно было бы использовать тесты — наловить несколько разных пакетов, и подсовывать их в тестах парсеру, затем расширить его, и проверить что старые пакеты парсятся так же. Но таких ситуаций было, ну, наверное, две за год с небольшим.
Другой момент, когда приходилось возвращаться к старому, подразумевал переделку достаточно большой схемы работы как таковой. Каким методом автоматизированного тестирования можно охватить целый процесс, схему работы, состоящий из нескольких потоков, и охватывающий несколько классов? С отдельными методами проблем не возникало, сами по себе они работали прекрасно. Да в общем и со схемой тоже только пару раз обнаружились дедлоки — и установить ситуацию, в которой они возникали, так и не удалось — решили долгим и вдумчивым всматриванием в код и добавлением еще одной критической секции. Полагаю, юнит-тест можно было бы использовать, чтобы удостовериться что поведение не изменилось. Хотя проблем и так не возникло. Т.е. возможно они возникли, но обнаружить таковых не удалось и ситуаций, в которых они могли бы возникать, мы представить тоже не смогли. Затем остались проблемы с просадками производительности и утечкой памяти. Тут, я так понимаю, тесты тоже не использовать, т.к. фиксировать требуется поведение в достаточно сложном процессе, да и плюс к тому, всегда остаются неохваченные ситуации и неизвестные факторы.
Вот когда в результате одного из обновлений камеры научились слать в заголовках пакетов видеопотока дополнительную информацию, и была мысль переписать парсер для поддержки этой возможности, тогда да, понимаю, как можно было бы использовать тесты — наловить несколько разных пакетов, и подсовывать их в тестах парсеру, затем расширить его, и проверить что старые пакеты парсятся так же. Но таких ситуаций было, ну, наверное, две за год с небольшим.
картинки красивые — зачет…
что касается примера из жизни, то
на заре расцвета Интернет, лет эдак 10 назад, может быть кто еще помнит:
был очень перспективный проект Netscape Navigator,
который давал несколько очков вперед бедному Ослику.
И Вот бравые ребята из Netscape решили переписать весь код с ноля. Планировали все сделать за полгода, учитывая свои предыдущие наработки, в результате проект затянулся года на полтора, а за это время появился замечательный проект Mozilla, которая была по качеству лучше и удобнее.
В результате Netscape влезло в долги, проект не пошел…
в общем о такой фирме как Netscape уже мало кто помнит…
что касается примера из жизни, то
на заре расцвета Интернет, лет эдак 10 назад, может быть кто еще помнит:
был очень перспективный проект Netscape Navigator,
который давал несколько очков вперед бедному Ослику.
И Вот бравые ребята из Netscape решили переписать весь код с ноля. Планировали все сделать за полгода, учитывая свои предыдущие наработки, в результате проект затянулся года на полтора, а за это время появился замечательный проект Mozilla, которая была по качеству лучше и удобнее.
В результате Netscape влезло в долги, проект не пошел…
в общем о такой фирме как Netscape уже мало кто помнит…
По отзывам знакомых, копавшихся в исходниках мозилы, там код тоже дале айс — запутанный так, без пол литра не разберешься, и хак на хаке сидит, и хаком погоняет
Вы забыли упомянуть тот факт, что Mozilla Firefox и есть тот проект, который был переписан с нуля из Netscape Navigator.
нет…
тот проект стал Netscape 5.0
а 6.0 стала последней версией
тот проект стал Netscape 5.0
а 6.0 стала последней версией
Где доказательства?
Я специально сверялся с википедией:
"...Netscape приняла решение разрабатывать браузер в рамках проекта с открытым исходным кодом. Была создана неформальная группа Mozilla Organization, которая в основном финансировалась Netscape, оплачивавшей труд основной части программистов, работавших над проектом. Эта группа должна была координировать усилия по разработке Netscape 5, базировавшегося на исходном коде Communicator. Однако устаревший код создавал большие проблемы, и было принято решение написать программу заново. Новый исходный код был назван Mozilla, на основе которого с небольшими изменениями был создан Netscape 6."
ru.wikipedia.org/wiki/Netscape_Navigator
ru.wikipedia.org/wiki/Mozilla_Firefox
Я специально сверялся с википедией:
"...Netscape приняла решение разрабатывать браузер в рамках проекта с открытым исходным кодом. Была создана неформальная группа Mozilla Organization, которая в основном финансировалась Netscape, оплачивавшей труд основной части программистов, работавших над проектом. Эта группа должна была координировать усилия по разработке Netscape 5, базировавшегося на исходном коде Communicator. Однако устаревший код создавал большие проблемы, и было принято решение написать программу заново. Новый исходный код был назван Mozilla, на основе которого с небольшими изменениями был создан Netscape 6."
ru.wikipedia.org/wiki/Netscape_Navigator
ru.wikipedia.org/wiki/Mozilla_Firefox
Это вы Джоэля начитались.
Проблемы Нетскейпа были в первую очередь в бездарном руководстве, а потом уже в разрешении дать волю программистам и переписать всё.
Проблемы Нетскейпа были в первую очередь в бездарном руководстве, а потом уже в разрешении дать волю программистам и переписать всё.
Спасибо за статью, настроение поднялось :)!
а бывает проще переписать компилятор…
расскажу об одном энтерпрайзном проекте
первая версия началась еще 1995 году, в 2006 было принято решение переписать с нуля, поскольку вендор старых средств разработки приказал долго жить еще 2003, и внесение изменений в систему стало слишком сложным.
до 2009 разработка велась в фоновом режиме, на фоне поддержки старой системы. в 2009 был внедрен первый этап, две системы работали в паре. И только сейчас, в 2012 внедеряется последний кусок.
Система бизнес кртитична, никаких перебоев в обслуживании не было, пользователи и руководство довольны.
Объем примерно 200к строк кода, команда 5 разработчиков + 3 тестера.
Но по времени вот как-то так получается.
первая версия началась еще 1995 году, в 2006 было принято решение переписать с нуля, поскольку вендор старых средств разработки приказал долго жить еще 2003, и внесение изменений в систему стало слишком сложным.
до 2009 разработка велась в фоновом режиме, на фоне поддержки старой системы. в 2009 был внедрен первый этап, две системы работали в паре. И только сейчас, в 2012 внедеряется последний кусок.
Система бизнес кртитична, никаких перебоев в обслуживании не было, пользователи и руководство довольны.
Объем примерно 200к строк кода, команда 5 разработчиков + 3 тестера.
Но по времени вот как-то так получается.
>… серьезные люди считают…
Можно конкретизировать? Какие, например?
Доводилось читать Макконнелла, Фаулера, Гласса, Мараско, Спинеллиса и др.
Авторы либо воздерживались от таких заявлений, либо, постараюсь процитировать:
— В жизни каждого проекта наступает момент, когда его надо написать с нуля.
— Первый вариант пишется на выброс и это надо принять, как должное.
Сам с нуля ни разу не переписывал ничего более чем на пару сотен строк в размере. Но рефачить приходиться постоянно.
Хотелось бы пополнить библиотеку работами других авторов. Заранее спасибо.
Можно конкретизировать? Какие, например?
Доводилось читать Макконнелла, Фаулера, Гласса, Мараско, Спинеллиса и др.
Авторы либо воздерживались от таких заявлений, либо, постараюсь процитировать:
— В жизни каждого проекта наступает момент, когда его надо написать с нуля.
— Первый вариант пишется на выброс и это надо принять, как должное.
Сам с нуля ни разу не переписывал ничего более чем на пару сотен строк в размере. Но рефачить приходиться постоянно.
Хотелось бы пополнить библиотеку работами других авторов. Заранее спасибо.
Надо признаться, я в данный момент (и не один, а с командой из 6 человек) переписываю старый проект.
Старый проект — САПР, разработан компанией Siemens в 70-80х гг под ОС HP-UX. Качественнейшая и современнейшая вещь для тех лет.
Получили лицензию, перенесли на платформу Linux из-за эмбарго США на поставки HP-машин.
Однако, последние 10 лет наблюдается страшная тенденция — система становится все хуже и хуже. Пересборка ряда модулей системы практически невозможна.
Под нее необходимо вести специальный дистрибутив ОС Linux. Обновление ядра Linux и glibc приводит к краху граф.редактора САПР.
+ постоянные жалобы пользователей и желание внедрить кучу новых возможностей.
Пару лет убеждал руководство прекратить танцы с бубном, и начать разработку своей такой же системы.
В конце концов убедил. С тех пор прошло еще 2 года, пишем на Java и чуть-чуть на C. Через 2 месяца — проверка на вшивость — первое внедрение.
Старый проект — САПР, разработан компанией Siemens в 70-80х гг под ОС HP-UX. Качественнейшая и современнейшая вещь для тех лет.
Получили лицензию, перенесли на платформу Linux из-за эмбарго США на поставки HP-машин.
Однако, последние 10 лет наблюдается страшная тенденция — система становится все хуже и хуже. Пересборка ряда модулей системы практически невозможна.
Под нее необходимо вести специальный дистрибутив ОС Linux. Обновление ядра Linux и glibc приводит к краху граф.редактора САПР.
+ постоянные жалобы пользователей и желание внедрить кучу новых возможностей.
Пару лет убеждал руководство прекратить танцы с бубном, и начать разработку своей такой же системы.
В конце концов убедил. С тех пор прошло еще 2 года, пишем на Java и чуть-чуть на C. Через 2 месяца — проверка на вшивость — первое внедрение.
«Будьте готовы выбросить первую версию проэкта» — Ф. Брукс.
Переписывать можно по разному. От facebook первой версии наверное и строчки не осталось, и даже код двухлетней давности не всюду найдёшь. Код эволюционирует, в хорошо спроэктированом приложении одну подсистему, а иногда даже целый слой, меняют с минимальным влиянием на другие части.
А проэкты на 10 000 строк, у меня курсовая, компилятор языка Си имел около 10000 строк, о bison/yacc я тогда не знал.
15 000 для современного проєкта это достаточно мало. И помните хорошую пословицу «глаза боятся, а руки делают». Главное при изменении системы наличие плана, цели, чего мы этим изменением хотим достичь, улучшение для улучшения не имеет ценности для клиента. Для того придумали рефакторинг, TDD чтобы менять код с лучшей эфективностью.
Переписывать можно по разному. От facebook первой версии наверное и строчки не осталось, и даже код двухлетней давности не всюду найдёшь. Код эволюционирует, в хорошо спроэктированом приложении одну подсистему, а иногда даже целый слой, меняют с минимальным влиянием на другие части.
А проэкты на 10 000 строк, у меня курсовая, компилятор языка Си имел около 10000 строк, о bison/yacc я тогда не знал.
15 000 для современного проєкта это достаточно мало. И помните хорошую пословицу «глаза боятся, а руки делают». Главное при изменении системы наличие плана, цели, чего мы этим изменением хотим достичь, улучшение для улучшения не имеет ценности для клиента. Для того придумали рефакторинг, TDD чтобы менять код с лучшей эфективностью.
Проэкта? Проєкта?
Проекты бывают разные. Я специально уточнил, что статья применима к разработке одним программистом, или на крайний случай парой.
Врядли бы Цукерберг стал с нуля один переписывать фейсбук, да?
Тем более, вы говорите о частичном переписывании различных модулей, я же утверждаю, что весь проект переписывать с нуля чрезвычайно сложно, особенно при отсутствии адеватно сформированных требований и тестов.
Врядли бы Цукерберг стал с нуля один переписывать фейсбук, да?
Тем более, вы говорите о частичном переписывании различных модулей, я же утверждаю, что весь проект переписывать с нуля чрезвычайно сложно, особенно при отсутствии адеватно сформированных требований и тестов.
По опыту, переписывание 15000 строк кода в попугаях — это год работы и соответственно годовой оклад одного программиста. Если заказчик готов платить — почему нет? Плюс к этому прокачка скилсов.
15000 строк кода бывают разными. Если это год работы нормального программиста, то, я не думаю что они так уж и плохи. Посмотрите на стандартные библиотеки, там те же тысячи строк историей в несколько десятков лет порой бывают.
Тем не менее был как минимум в двух ситуациях.
Первая — когда некую аналитическую систему переписал с нуля один человек за две недели переписал с нуля с учетом новых требований, в то время как «развернутую и работающую» пытались доработать 3 месяца.
Вторая, когда переписаная с нуля система (семантическое ядро) в 5 раз обогнала на настольном компе рабочую у развернутую на мейнфрейме.
Я НЕ утверждаю, что перписывать хорошо. Однако, работая аналитиком, привык к фактам и привык не доверять утверждениям «считаю, что так правильно».
На мой взгляд требуется внятная методика оценки поддержки системы, что бы манипулировать такими примерно цифрами:
«Итак. Есть вариант дописывать к текущей — и каждая доработка будет стоит $100. И есть вариант переписать за $900 со внятной архитектурой и тогда каждая доработка будет стоить $10. И тогда если требуется < 10 доработок выгоднее дописывать старую, а если больше, то выгоднее переписать»
И никаких вам «да в чо, он нормальный программист» и «да я вам как эксперт говорю» и прочих разрываний тельняшек.
Первая — когда некую аналитическую систему переписал с нуля один человек за две недели переписал с нуля с учетом новых требований, в то время как «развернутую и работающую» пытались доработать 3 месяца.
Вторая, когда переписаная с нуля система (семантическое ядро) в 5 раз обогнала на настольном компе рабочую у развернутую на мейнфрейме.
Я НЕ утверждаю, что перписывать хорошо. Однако, работая аналитиком, привык к фактам и привык не доверять утверждениям «считаю, что так правильно».
На мой взгляд требуется внятная методика оценки поддержки системы, что бы манипулировать такими примерно цифрами:
«Итак. Есть вариант дописывать к текущей — и каждая доработка будет стоит $100. И есть вариант переписать за $900 со внятной архитектурой и тогда каждая доработка будет стоить $10. И тогда если требуется < 10 доработок выгоднее дописывать старую, а если больше, то выгоднее переписать»
И никаких вам «да в чо, он нормальный программист» и «да я вам как эксперт говорю» и прочих разрываний тельняшек.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дорабатывать или переписывать