Здравствуйте, AlexNek, Вы писали:
J>>нет, смотрим на старый код, анализируем его, понимаем что делает каждая строчка, превращаем старый код мысленно или на бумаге в алгоритм и аналогичный алгоритм реализуем для нового кода. AN>Какая вероятность того что эти два кода будут достаточно сильно отличаться?
причем здесь вероятность? В конкретный момент времени код уже есть, он или сильно отличается или слабо отличается
AN>J:Значит сначала рефакторим старый код — выделяем из него функцию обработки, AN>где будет физически находится этот "старый код" во время рефакторинга? J>>>>делаем ее виртуальной и в новом коде только лишь переопределяем эту функцию. AN>>>А откуда в новом возьмутся старые части? J>>так мы ж отрефакторили — общую часть выделили в базовый класс в котором теперь данные читаются, пихаются и сортируются и обрабатываются абстрактным обработчиком, который перекрывается в обоих методах. AN>То бишь делаем копию старого кода в которой его рефакторим и проверяем работоспособность.
еще раз. Допустим у нас есть файл А, в котором лежит класс ОбработчикФайловТипаА с единственной функцией Обработать() на 3 экрана, которая открывает файл, зачитывает из него данные, извлекает из данных некие важные числа, запихивает их в массив, тут же сортирует этот массив по возрастанию пузырьком и считает среднее арифметическое 5 максимальных чисел в качестве характеристики наших данных. Нам нужно написать обработчик файлов типа Б, который делает все абсолютно тоже самое, но считает среднее арифметическое 5 минимальных чисел.
При методе разработки копированием, мы заводим файл Б, копируем туда класс А, меняем имя класса на Б и начинаем анализировать функцию Б. Находим в ней кусок в котором в цикле складываются 5 последних элементов, меняем его на цикл для 5 первых элементов и, вуаля, задача решена.
При разработке с нуля мы сначала смотрим на код функции из класса А, анализируем его и понимаем что в новом классе будет отличаться только подсчет среднего арифметического. Выносим этот подсчет в отдельную функцию ПосчитатьХарактеристики() и прогоняем тесты, что бы убедиться что мы ничего не сломали. Заводим файл База, в нем заводим класс БазовыйОбработчик файлов и переносим в него функцию Обработать() целиком. Потом заводим абстрактную ПосчитатьХарактеристики(), делаем ПосчитатьХарактеристики() в классе ОбработчикФайловТипаА виртуальной и снова прогоняем тесты. И только после этого заводим файл Б, с классом ОбработчикФайловТипаБ в котором всего навсего пишем небольшую функцию ПосчитатьХарактеристики()
Человек, который будет писать ОбработчикФайловТипаС, в котором будет считаться среднее геометрическое, скажет нам офигенное спасибо
Но первый подход мне тоже приходилось использовать. Переделывать все потом было очень мучительно, поскольку кто-то решил схитрить и в одном из обработчиков вместо изменения индексов в цикле подсчета среднего арифметического поменял порядок сортировки. Поэтому выделение базового класса превратилось в ужас.
J>>Это дольше, чем скопировать и переименовать, но это надежнее и приятнее в программировании AN>А что мешает рефакторить старый код сразу на новом месте?
перегрузка мозга — нужно думать и что надо изменить и думать что надо отрефакторить и при этом еще надо добиться компиляции, потому как мы не все что нужно могли переименовать и при этом еще и тесты не работают, потому как старые тесты для нового класса не подходят
моя практика показывает что рефакторить нужно маленькими кусками, постоянно прогоняя тесты. Иначе можно внести на ровном месте ошибку и потом долго ее искать, проклиная себя за торопливость
J>>>>да и я не настаиваю на своей правоте — так, размышляю и делюсь своим опытом. AN>>>Я также не знаю правильного ответа, но что то мне подсказывает, что делать все с нуля не пользуя старый код будет далеко не оптимальным решением.
зависит исключительно от сложности кода и его способности быть поддерживаемым, то есть понимабельности и изменябельности (трудно русский перевод подобрать)
J>>зависит от старого кода, в примере который я рассказал написание с нуля вышло бы быстрее чем последующий поиск бага в скопированном AN>Так это же просто замечательно что нашли новый баг, его нужно и со старого кода вычистить.
не, в старом коде бага не было. Мы его внесли при превращении старого кода в новый
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, maxkar, Вы писали:
M>>А вот решение о том, как именно писать отдельные плагины, можно оставить разрабочтикам, ответственным за эти плагины. Они выберут ту методологию, с которой комфортнее работать лично им. AN>А вот этого не следует делать. Все плагины должны использовать один концепт и один скелет. Иначе, когда будет десяток плагинов никто в них не разберется, они все будут разными.
Я имел в виду методологию разработки "снизу вверх" или "сверху вниз". Архитектурные вопросы и вопросы стиля нужно проверять (ревью, например). А вот будет ли функциональность наращиваться "с нуля" или путем допиливания уже существующей здесь не важно до тех пор, пока результат соответствует всем требованиям. Хотя при этом возникает необходимость правильно отслеживать момент "завершения" работы над модулем. Например, в репозиторий не коммитится плагин "в разработке". Или коммитится, но где-то в трекере можно посмотреть статус всех функций (не реализовано, реализовано). Наличие такой поддержки позволяет и разрабатывать плагины "с нуля" (статус можно отобразить корректно). А вот отсутствие "статуса завершенности плагина" автоматически запрещает второй вариант, так как в снапшоте репозитория нельзя будет определить статус готовности плагина. "Работающий" плагин может только делать вид, что работает. А вот "недописанный" плагин явно не будет работать.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, AlexNek, Вы писали:
AN>>Здравствуйте, maxkar, Вы писали:
M>>>А вот решение о том, как именно писать отдельные плагины, можно оставить разрабочтикам, ответственным за эти плагины. Они выберут ту методологию, с которой комфортнее работать лично им. AN>>А вот этого не следует делать. Все плагины должны использовать один концепт и один скелет. Иначе, когда будет десяток плагинов никто в них не разберется, они все будут разными.
M>Я имел в виду методологию разработки "снизу вверх" или "сверху вниз". Архитектурные вопросы и вопросы стиля нужно проверять (ревью, например). А вот будет ли функциональность наращиваться "с нуля" или путем допиливания уже существующей здесь не важно до тех пор, пока результат соответствует всем требованиям.
Результат и так должен соответствовать, а путь к нему имеет самостятельную роль.
M>Хотя при этом возникает необходимость правильно отслеживать момент "завершения" работы над модулем.
Зачем, это и так известно. M>Например, в репозиторий не коммитится плагин "в разработке". Или коммитится, M>но где-то в трекере можно посмотреть статус всех функций (не реализовано, реализовано).
Кто будет заниматься этой ерундой (обновленим статуса) и для чего? Все кто имеет точки соприкосновения и так всё знают, а для отчетов есть план работ. А коммитить можно и в бранч, кому нужно тот возмет. M>Наличие такой поддержки позволяет и разрабатывать плагины "с нуля" (статус можно отобразить корректно).
Наличие такой поддержки никому не нужная работа. А если функции еше нет? Да и причем вообще функции, когда интересует функционал. M>А вот отсутствие "статуса завершенности плагина" автоматически запрещает второй вариант, так как в снапшоте репозитория нельзя будет определить статус готовности плагина.
Для чего нужен еще какой то статус? Или функционал полностью реализован или нет. Кому будет интересен этот статус и причем статус к типу разработки? M>"Работающий" плагин может только делать вид, что работает.
Если функционал не готов то и ежу понятно что не все работает правильно, но "база" обеспеченная старым скелетом резко минимизирует необходимость разработки заглушек для сопряженных заданий. M>А вот "недописанный" плагин явно не будет работать.
В любом случае плагин будет до определенного момента недописанным.
Здравствуйте, AlexNek, Вы писали:
AN>Для чего нужен еще какой то статус? Или функционал полностью реализован или нет. Кому будет интересен этот статус и причем статус к типу разработки?
Статус может быть интересен другому разработчику, который по какой-либо причине открыл этот код. Например, чтобы взять за основу для похожего плагина/устройства (оно может оказаться проще, чем брать "старый" плагин). Да и для тех же отчетов (которые план работ) проверить проще отсутствие меток TODO/FIXME/STUB, чем вспоминать, было оно до конца доделано или нет.
AN>Если функционал не готов то и ежу понятно что не все работает правильно, но "база" обеспеченная старым скелетом резко минимизирует необходимость разработки заглушек для сопряженных заданий.
Вот поэтому и будет работать только подход "писать заново". В нем по коду определить, "готов функционал или нет" обычно гораздо проще. "Заглушки" обычно хоть как-то помечаются (теми же TODO/FIXME в комментариях и другими подобными способами). А вот старый скелет такой информации не дает. Вот вы открыли файл, там какие-то методы. Вопрос — это уже полностью рабочий код или нет? Может быть, там старый скелет, еще не переписаный местами. А может, это уже полностью готовый модуль. Или придется искать другого разработчика и спрашивать его о состоянии дел? Или тестировать самому, работает оно до конца или нет? Все же в общем коде в репозитории если что-то не работает/не доделано, это хотелось бы определять практически сразу.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, AlexNek, Вы писали:
AN>>Для чего нужен еще какой то статус? Или функционал полностью реализован или нет. Кому будет интересен этот статус и причем статус к типу разработки?
M>Статус может быть интересен другому разработчику, который по какой-либо причине открыл этот код.
для чего другому разработчику лезть в незаконченный код? M>Например, чтобы взять за основу для похожего плагина/устройства (оно может оказаться проще, чем брать "старый" плагин).
звучит сильнее чем фантастика. Если такое и требуется, то не должно планироваться в параллель. А если уж и приспичило, то возмется копия старого плагина и попросятся нужные части от нового как временное решение. M> Да и для тех же отчетов (которые план работ) проверить проще отсутствие меток TODO/FIXME/STUB, чем вспоминать, было оно до конца доделано или нет.
Так по плану работ и видно доделано или нет. AN>>Если функционал не готов то и ежу понятно что не все работает правильно, но "база" обеспеченная старым скелетом резко минимизирует необходимость разработки заглушек для сопряженных заданий.
M>Вот поэтому и будет работать только подход "писать заново". В нем по коду определить, "готов функционал или нет" обычно гораздо проще. "Заглушки" обычно хоть как-то помечаются (теми же TODO/FIXME в комментариях и другими подобными способами). А вот старый скелет такой информации не дает. M>Вот вы открыли файл, там какие-то методы. Вопрос — это уже полностью рабочий код или нет?
Еще не попадалось случая когда команда не знает состояния дел в своем сегменте. Модуль или рабочий или в разработке. Для оперативности у разработчиков есть телефоны и почта. M>Может быть, там старый скелет, еще не переписаный местами. А может, это уже полностью готовый модуль. Или придется искать другого разработчика и спрашивать его о состоянии дел?
А для кого эти все вопросы? Модуль в разработке, по окончанию разработки начнется более углубленное тестирование. Всегда есть человек который в курсе актуального статуса проекта/модуля. M>Или тестировать самому, работает оно до конца или нет? Все же в общем коде в репозитории если что-то не работает/не доделано, это хотелось бы определять практически сразу.
Не нужно это определять это и так известно, иначе есть проблема коммуникации в команде.
