Как принято в вашей команде: устаревшие строки закомментировать и оставить на некоторое время или сразу выпилить? И почему так? --- Добавлено --- Можно также обсудить миграции. Допустим вы решаете заменить одно поле на другое. Старое останется (временно) или будет сразу удалено в той же миграции?
Для старого кода git, просто оставляем его в другой ветке. По поводу миграций - никаких правок старых миграций. Только новые (потому что трудновато вручную отслеживать состояние БД, состояние миграций. Проще запускать их, зная что не нарушена целостность БД).
В моей нынешней команде из одного человека)) обычно каменчу код до момента пока не пойму что новое работает как надо. Потом просто легкий рефакторинг делаю (или не делаю, если вломы)))))))) и убираю старое массово. Миграциями почти не пользуюсь. ууупс.... ))) понимаю что не айс, но поскольку один - никакого смысла в них сейчас не вижу.
старый код вовсе отделял от контента, смотрел по конкретной логике, что нужно преобразовывать/переписывать. По окончанию последовательной переписи с тестами, немедленно удалял. После за другой кусок берусь. Почему отделяю ? 75% начальных действий по свежему коду идут наброски, а после уже оптимизация и разделение на составные. --- Добавлено --- Дамп файлов всегда сохраняю - на всякий косяк.
Пришёл, поудалял --- Добавлено --- За последние месяцы несколько кадров сменилось и теперь почти все так делают.
есть пример PHP: /* - ищем нейрон/пиксель по вертикальной оси */ private function axis_y( int $x ): bool { $im = $this -> setImageCrop( [ 'x' => $x, 'y' => 0, 'width' => 1, 'height' => imagesy ( $this -> im ) ], true ); imagetruecolortopalette ( $im, false, 2 ); $bool = imagecolorstotal ( $im ) > 1; imagedestroy ( $im ); return $bool; /* $y = 0; while ( $y < imagesy ( $this -> im ) ) { if ( imagecolorat ( $this -> im, $x, $y ) ? $this -> neuron : ( int ) ! $this -> neuron ) { return true; } $y++; } return false; */ }
Мои соображения на счёт выпиливания либо закомментирования. * по хорошему код должен документировать сам себя, т.е. быть достаточно читабелен чтобы объяснять что происходит. поэтому если мы видим одновременно две версии — старую и новую — мы видим причину изменений. я считаю это важно. * да, история в git может показывает что на что изменилось, но только в том случае, если мы целенаправленно сравниваем версию А с версией Б. пока мы того не затребовали, мы не знаем почему код пришёл к тому, к чему он пришёл. На самом деле в конкретном проекте я уже вынужден был согласиться с выпиливанием. Стандарт выше, чем личные соображения. Но соображения есть