Здравствуйте, FR, Вы писали:
AVK>>Это все разговор ни о чем. Давай конкретно — что именно будет препятствовать рефакторингу?
FR>Только цена.
Цена ппереписывания с нуля не может быть маленькой по определению.
FR>Рефакторинг может оказаться дороже, а иногда и существенно дороже чем написание с нуля.
Существенно дороже — ну очень вряд ли. Слегка дороже — возможно, но это с лихвой окупится выпуском промежуточных версий.
Не, я конечно понимаю, что намного приятнее писать с чистого листа, но с коммерческой точки зрения эта практика крайне сомнительна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, metaprogrammer, Вы писали:
M> А в эту практику входили продукты, которым тридцать лет или больше? Мешанину из Фортрана, Си и PL/I рефакторить злейшему врагу не пожелаю.
А как ты думаешь с такими системами поступают? Их переписать — нереально. Поэтому фортранокобол до сих пор эксплуатируется в совсем немаленьких объемах.
M> В плохом древнем коде разбираться я очень даже умею. И в большинстве случаев цикл "понять логику — придумать лучше — переписать заново" занимал в несколько раз меньше времени, чем "понять логику — понять все косяки и незадокументированные грязные хаки — инкрементально изменять до приличного состояния".
Не не не. Я же ведь не против переписывания кусочков итерационно. Мне крайне сомнительно переписывание продукта целиком.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А в реальности дело , конечно, обстоит так, как об этом думаешь ты. Это, впрочем, давно понятно.
По делу есть что сказать?
AVK>>Это все разговор ни о чем. Давай конкретно — что именно будет препятствовать рефакторингу?
PD>Пожалуйста.
PD>1. Отсутствие продуманной модели ядра. Ядро было сделано в 16-битном варианте исходно, причем для реального режима. После этого последовательно добавляли DPMI (переход к стандартному режиму), потом переводили вызовы int 21H (да-да, именно их, а еще int 2FH) в соответствующий код для 32-битного режима, потом добавляли то, что имеется в Win32 (объекты ядра)
Делаем микроядро в 32-битном варианте, старый объемный код обвязываем стабами.
PD>2. Отсутствие системы безопасности ВООБЩЕ.
Добавляем. API то эту безопасность уже содержало, нужна была только реализация.
PD>3. user и gdi в основном так и остались 16-битными и нереентерабельными.
На первом этапе можно оставить. Потом портануть из NT.
PD>4. Кооперативная модель многозадачности, в которую было в качестве заплаты добавлена вытесняющая
Выкинуть заплату, сделать полностью вытесняющей.
PD>5. Загрузка из реального режима, при том, что уже могли загрузиться драйверы реального режима (config.sys), которые приходилось кривым способом дизейблить.
Ну, это вообще не проблема. Загрузчик штука весьма обособленная.
PD>6. Совершенно кривой способ реализации VM86. Общая память для всех DOS-окон.
Не проблема, опять же — VM86 штука тоже отдельная.
PD>Это то, что я написал, не думая.
Плохо, что не думая.
PD> Если начну вспоминать или почитаю того же Питрека — я еще с десяток пунктов напишу.
Лучше не надо. Все, что ты перечислил, прекрасно рефакторится без переписывания всего и вся.
AVK>>Всего.
PD>Например, MS-DOS в Windows 7 ?
Это просто разные продукты, абсолютно невзаимозаменяемые.
PD>Ясно. В общем, можно из всего сделать все.
Передергивание.
PD>Ответь тогда на один простой вопрос — почему же MS начала линию NT вместо того, чтобы рефакторить эту 9x ?
Линия NT уже давно существовала на момент появления 9Х, о чем тебе уже здесь писали. Продукт уже был. При таком раскладе, конечно же, дешевле просто выкинуть 9Х.
PD>Не знаю, чем ты именно занимаешься, это твое дело.
PD> Может, в этой области твое утверждение и верно. В общем случае — нет, что и показывает практика (9x->NT).
Ну сколько можно повторять одну и ту же глупость — NT это не переписывание 9Х, это параллельный продукт.
PD> И чтение книжек тут как раз очень даже помогает понять. где и когда стоит переделывать, а когда — начать с чистого листа.
Давай формальный критерий — когда нужно переписывать все?
AVK>>В разработчиках.
PD>Для одного из своих основных продуктов
Какой он нафик основной? Основные продукты у МС — Винда и Офис, все остальное шелуха для продажи первых двух.
PD>, более того, продукта, который во многом определяет лицо MS перед массовым юзером (MS SQL, VS и т.д. пользуются немногие, Office — гораздо больше, но далеко не все, а вот в Интернет ходят все) MS не смогла сформировать хорошую команду разработчиков ? Что-то странно это...
Ничего странного. Такое происходит сплощь и рядом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
M> В плохом древнем коде разбираться я очень даже умею. И в большинстве случаев цикл "понять логику — придумать лучше — переписать заново" занимал в несколько раз меньше времени, чем "понять логику — понять все косяки и незадокументированные грязные хаки — инкрементально изменять до приличного состояния".
Иногда "понять логику" должно пройти через "понять все косяки и незадокументированные грязные хаки".
Как поступать в таком случае.
На позапрошлом проекте мне пришлось-таки "инкрементально изменять до приличного состояния". И только после этого я смог "придумать лучше — переписать заново".
Такое бывает, когда всё погрязло в связности и старательно обмотано спагетти.
Здравствуйте, AndrewVK, Вы писали:
M>> А в эту практику входили продукты, которым тридцать лет или больше? Мешанину из Фортрана, Си и PL/I рефакторить злейшему врагу не пожелаю.
AVK>А как ты думаешь с такими системами поступают?
Я знаю, как с ними поступают. Одну такую переписывали целиком с нуля, с совсем новой архитектурой, другая такая уже лет десять переписывается по частям, модуль за модулем. А что делать то? Поддерживать то этот кошмар невозможно.
AVK> Их переписать — нереально. Поэтому фортранокобол до сих пор эксплуатируется в совсем немаленьких объемах.
Эксплуатируется — да, и ещё лет сорок эксплуатироваться будет как минимум. Но не рефакторится. Когда возникает такая необходимость — просто переписывают большую часть системы с нуля. Когда у владельцев хватает авантюризма и средств — переписывают всё с нуля. Как правило о подобных решениях не жалеют.
AVK>Не не не. Я же ведь не против переписывания кусочков итерационно.
Особой разницы обычно нет, кусочки могут быть при этом очень большими, и представлять собой вполне полноценные продукты сами по себе. При таком переписывании архитектура может меняться весьма существенно. А так — можно и этот разнесчастный переход 9x->NT назвать инкрементальным. А что — всего-то ядро поменяли, потом библиотеки одну за другой переписывали...
AVK> Мне крайне сомнительно переписывание продукта целиком.
Иногда и это бывает необходимым, когда заложенный в архитектуру предел роста уже достигнут.
AVK>Цена ппереписывания с нуля не может быть маленькой по определению.
Но она всё-равно не высока, потому что большинство требований и подводных камней аналитики должны быть уже известно.
AVK>Существенно дороже — ну очень вряд ли. Слегка дороже — возможно, но это с лихвой окупится выпуском промежуточных версий. AVK>Не, я конечно понимаю, что намного приятнее писать с чистого листа, но с коммерческой точки зрения эта практика крайне сомнительна.
Тут влияет квалификация разработчиков.
Если квалификация низкая — проще переписать. Получится тоже говно, но уже другое и быстро
А вообщее конечно обсуждается сферический конь в вакууме. Надо смотреть по месту.
Здравствуйте, FR, Вы писали:
FR>Иллюстрация очень простая, наш проект можно представить как двухмерную фигуру, ну скажем для начала круг, мы его равиваем расширяя его границы, но по мере развития границы начинают принимать форму фрактала, то есть их длина (соответствующая сложности и эквивалентная приложенным усилиям) очень быстро растет, при этом рост площади фигуры (а площадь это функциональность программы) стремится к нулю.
Аналогия хорошая, я сам как-то пришел к похожей. Но тут все определяется тем, как проект развивается. Никто не мешает, условно говоря превратить круг в овал или любую другую выпуклую фигуру, главное правильно расставлять приоритеты и не пытаться прыгнуть выше головы. Если же точки роста, грубо говоря, задаются без учета текущего состояния системы — заказчиком, или отделом маркетинга, или еще кем-то внешним, типа хочу, чтобы здесь была красивая красная кнопка, а как вы это сделаете, меня не интересует, то тогда действительно в итоге получим фрактал.
Здравствуйте, AndrewVK, Вы писали:
AVK>Бывает относительно хороший код, который рефакторить тяжело, бывает плохой код, который рефакторить легко. Догадываешься, в чем разница?
А что за критерий по которому код хороший, а рефакторится плохо?
Можно пару подробностей или примеров?
Здравствуйте, VGn, Вы писали:
VGn>Но она всё-равно не высока
AVK>>Не, я конечно понимаю, что намного приятнее писать с чистого листа, но с коммерческой точки зрения эта практика крайне сомнительна.
VGn>Тут влияет квалификация разработчиков.
Конечно. Чем выше квалификация, тем меньше разработчика тянет переписать все нафик.
VGn>Если квалификация низкая — проще переписать. Получится тоже говно, но уже другое и быстро
Не проще, потому что получится такое же гавно неизвестно когда и намного более глючное, потому что про доведение кода до production state обычно переписывальщиков не заботит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, metaprogrammer, Вы писали:
M> Я знаю, как с ними поступают. Одну такую переписывали целиком с нуля, с совсем новой архитектурой
И как, переписали?
M>, другая такая уже лет десять переписывается по частям, модуль за модулем
О!
M>. А что делать то? Поддерживать то этот кошмар невозможно.
Рефакторить.
M> Эксплуатируется — да, и ещё лет сорок эксплуатироваться будет как минимум. Но не рефакторится.
Конечно. Потому что дешевле переписать на современных языках. Но это крайности.
M> Когда возникает такая необходимость — просто переписывают большую часть системы с нуля.
Да нет, обычно ее переписывают потихоньку с запуском в работу кучи промежуточных состояний.
M> Особой разницы обычно нет
С точки зрения технической — почти нет. С точки зрения коммерческой — есть и еще какая.
M> Иногда и это бывает необходимым, когда заложенный в архитектуру предел роста уже достигнут.
Нет никаких таких пределов в реальности. Есть лишь способность кода и архитектуры меняться в той или иной степени. Чем выше эта способность, тем дешевле обходится рефакторинг. А рассчитывать на то, что раз созданная архитектура без серьезных изменений способна прожить долго — ну, каждый сам себе злобный буратина.
От переписофилии хорошо, кстати, лечит более менее частый и стабильный график релизов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, FR, Вы писали:
FR>Иллюстрация очень простая, наш проект можно представить как двухмерную фигуру, ну скажем для начала круг, мы его равиваем расширяя его границы, но по мере развития границы начинают принимать форму фрактала, то есть их длина (соответствующая сложности и эквивалентная приложенным усилиям) очень быстро растет, при этом рост площади фигуры (а площадь это функциональность программы) стремится к нулю.
С какого бодуна ей стремиться к нулю???
Посмотри на множество Мандельброта с фрактальной границей — его площадь разве стремится к нулю с ростом детализации границы?
Применительно к софту — если софт умеет что-то делать (скажем, копировать файл), то после добавления 84-х новых фич она окажется неспособной сделать то, что умела делать изначально (копировать файл)?
Здравствуйте, jazzer, Вы писали:
J>С какого бодуна ей стремиться к нулю??? J>Посмотри на множество Мандельброта с фрактальной границей — его площадь разве стремится к нулю с ростом детализации границы?
Здравствуйте, metaprogrammer, Вы писали:
M> Справедливости ради — NT всё же гораздо раньше чем 9x начали делать.
Справедливости ради — 9x есть продолжение 3.x 16 битной, которая в свое время есть продолжение в конечном счете 1.0, которую делать начали намного раньше
Здравствуйте, AndrewVK, Вы писали:
AVK>По делу есть что сказать?
Это у вас с IT фирменное блюдо, что ли ? Если говорят то, что вам не нравится — значит, не по делу.
AVK>>>Это все разговор ни о чем. Давай конкретно — что именно будет препятствовать рефакторингу?
PD>>Пожалуйста.
PD>>1. Отсутствие продуманной модели ядра. Ядро было сделано в 16-битном варианте исходно, причем для реального режима. После этого последовательно добавляли DPMI (переход к стандартному режиму), потом переводили вызовы int 21H (да-да, именно их, а еще int 2FH) в соответствующий код для 32-битного режима, потом добавляли то, что имеется в Win32 (объекты ядра)
AVK>Делаем микроядро в 32-битном варианте, старый объемный код обвязываем стабами.
То-то веселая производительность будет.
PD>>2. Отсутствие системы безопасности ВООБЩЕ.
AVK>Добавляем. API то эту безопасность уже содержало, нужна была только реализация.
М-да...Это к коду, который частично выполняется в реальном режиме, ты собираешься безопасность добавить ? . Причем в реальном режиме там выполняется не какой-то кусок explorer, а самая что ни на есть часть ядра...
PD>>3. user и gdi в основном так и остались 16-битными и нереентерабельными.
AVK>На первом этапе можно оставить. Потом портануть из NT.
Двигатель от Боинга поставить на Запорожец.
PD>>4. Кооперативная модель многозадачности, в которую было в качестве заплаты добавлена вытесняющая
AVK>Выкинуть заплату, сделать полностью вытесняющей.
Да ну ? Можно поподробнее, как ты себе это представляешь ? Как это понравится 16-битным приложениям, которые про вытесняющую и слыхом не слыхали ? Как это понравится тем же user/gdi , которые тоже не слыхали. И т.д.
PD>>5. Загрузка из реального режима, при том, что уже могли загрузиться драйверы реального режима (config.sys), которые приходилось кривым способом дизейблить.
AVK>Ну, это вообще не проблема. Загрузчик штука весьма обособленная.
Если бы ты знал архитектуру 9x, то не говорил бы такое. Он там никак не обособленный, потому что он вообще не загрузчик в нынешнем понимании слова. Это просто встроенный запуск программы DOS. Да-да, именно так. В Windows 3.11 загружали сначала MS-DOS, а потом набирали в командной строке C:>win. А в 9x... в общем, то же самое, только набирается автоматически. И при этом все загруженные драйверы и TSR должны быть на месте, и работать, если только их 9x не подменит своим кодом.
PD>>6. Совершенно кривой способ реализации VM86. Общая память для всех DOS-окон.
AVK>Не проблема, опять же — VM86 штука тоже отдельная.
Ох...
PD>>Это то, что я написал, не думая.
AVK>Плохо, что не думая.
Глупо пытаться придать фразе иной смысл, чем тот, который был в нее заложен.
PD>> Если начну вспоминать или почитаю того же Питрека — я еще с десяток пунктов напишу.
AVK>Лучше не надо. Все, что ты перечислил, прекрасно рефакторится без переписывания всего и вся.
В общем, все, с меня хватит. То, что ты со внутренней структурой 9x не знаком — для меня ясно. Это, впрочем, беда небольшая. Но вот то, что ты, не зная о ней практически ничего, решаешься делать широковещательные выводы — вот это действительно плохо. Не для меня (мне-то что ?) , а для тебя. Потому что и в практической деятельности ты (и если бы только ты!) начнешь рефакторить то, что подлежит просто списанию, а в итоге устроишь такой монстр, о котором впоследствиии можно будет одно сказать — работать-то он работает, а вот почему и как — это уже никому не понятно. Ну и скорость работы будет... что и говорить.
PD>>Ответь тогда на один простой вопрос — почему же MS начала линию NT вместо того, чтобы рефакторить эту 9x ?
AVK>Линия NT уже давно существовала на момент появления 9Х, о чем тебе уже здесь писали.
В последний раз объясняю — 9x есть следующая версия 3.x 16. Историю знать не мешает все же.
>Продукт уже был. При таком раскладе, конечно же, дешевле просто выкинуть 9Х.
Слава богу, что MS твоим советам не следовало, а все же сообразила начать с нуля.
PD>> Может, в этой области твое утверждение и верно. В общем случае — нет, что и показывает практика (9x->NT).
AVK>Ну сколько можно повторять одну и ту же глупость — NT это не переписывание 9Х, это параллельный продукт.
А можно ссылку, где я говорил , что NT это именно переписывание 9x ? Из предыдущей фразы это отнюдь не следует, там идет речь о переходе, а отнюдь не о переписывании. Это именно ты утверждал, что можно было путем рефакторинга из 9x сделать что-то приличное. А я именно утверждал, что единственное решение здесь — начать с чистого листа. Что MS и сделала.
Приписывать оппоненту прямо противоположное тому, что он утверждает и объявить это глупостью — да, конечно, достойный способ дискутирования .
PD>> И чтение книжек тут как раз очень даже помогает понять. где и когда стоит переделывать, а когда — начать с чистого листа.
AVK>Давай формальный критерий — когда нужно переписывать все?
Ну ты даешь! Дай мне немедленно формальный критерий, приемлемый везде и всюду, при этом даже не зная, о каком продукте речь идет и как он сделан! Не дам. Истина конкретна. Надо изучить продукт, разобраться в его архитектуре и реализации, посмотреть, насколько его текущее состояние соответсвует новым требованиям, а тогда уж и решать. Не спеша и с умом.
Вот у нас сейчас как раз ситуация. когда предстоит переписывание продукта, проработавшего более 10 лет, из которых последние 5 лет мы его не поддерживали. Заказчика он вполне устраивал, да и сейчас работает как часы, но время идет... Так что если выиграем тендер — будем переписывать с нуля, а не выиграем — это будет делать кто-то иной . Жалко мне, конечно, тот код, на который я не один год потратил, но что поделаешь. Кстати, я своему менеджеру заикнулся было насчет использования прежнего кода хоть бы в части. Ответ был четкий и недвусмысленный — все будет делаться заново. А заказчик, поверь, очень уж серьезный
AVK>>>В разработчиках.
PD>>Для одного из своих основных продуктов
AVK>Какой он нафик основной? Основные продукты у МС — Винда и Офис, все остальное шелуха для продажи первых двух.
Здравствуйте, AndrewVK, Вы писали:
M>> Я знаю, как с ними поступают. Одну такую переписывали целиком с нуля, с совсем новой архитектурой
AVK>И как, переписали?
Да, конечно же. На период переписывания обе системы работали параллельно, и самым первым делом была налажена конвертация данных между новым и старым форматом. Потом старую систему просто отключили. Переход был совершенно гладким.
Просто, переписывать с нуля — тоже уметь надо.
M>>, другая такая уже лет десять переписывается по частям, модуль за модулем
AVK>О!
И за это время куча релизов вышла, кстати.
M>>. А что делать то? Поддерживать то этот кошмар невозможно.
AVK>Рефакторить.
Нет. Не понимаю я этой веры в рефакторинг. Плохой код очень часто дешевле переписать чем исправить.
M>> Эксплуатируется — да, и ещё лет сорок эксплуатироваться будет как минимум. Но не рефакторится.
AVK>Конечно. Потому что дешевле переписать на современных языках. Но это крайности.
Эти "крайности" почему-то мне постоянно попадаются на пути. Собственно, практически только подобным переписыванием я всю жизнь и занимаюсь.
AVK>С точки зрения технической — почти нет. С точки зрения коммерческой — есть и еще какая.
Не вижу и коммерческой разницы тем более.
AVK>Нет никаких таких пределов в реальности.
Есть-есть. Например, код на Fortran 77, полностью завязанный на глобальные состояния, распараллелить и сделать thread safe нереально вообще. Только переписать с нуля, и на более адекватном языке.
AVK> Есть лишь способность кода и архитектуры меняться в той или иной степени. Чем выше эта способность, тем дешевле обходится рефакторинг.
Человеческая фантазия безгранична на идиотские и нелепые архитектуры.
AVK> А рассчитывать на то, что раз созданная архитектура без серьезных изменений способна прожить долго — ну, каждый сам себе злобный буратина.
Да кто ж тридцать лет назад так далеко вперёд заглядывал? Они не буратины, просто индустрия тогда вся молодая и неопытная была.
AVK>От переписофилии хорошо, кстати, лечит более менее частый и стабильный график релизов.
См. выше — нисколько не лечит, а наоборот неплохо помогает.
Здравствуйте, COFF, Вы писали:
COF>Аналогия хорошая, я сам как-то пришел к похожей. Но тут все определяется тем, как проект развивается. Никто не мешает, условно говоря превратить круг в овал или любую другую выпуклую фигуру
И даже в прямоугольник, по крайней мере в дискретном пространстве дисплея. Только стоит ли ?
>главное правильно расставлять приоритеты и не пытаться прыгнуть выше головы.
