За последние 24 часа нас посетили 20063 программиста и 1081 робот. Сейчас ищут 685 программистов ...

Закомментировать или удалить?

Тема в разделе "Прочее", создана пользователем artoodetoo, 27 сен 2019.

Метки:
  1. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.068
    Симпатии:
    1.231
    Адрес:
    там-сям
    Как принято в вашей команде: устаревшие строки закомментировать и оставить на некоторое время или сразу выпилить? И почему так?
    --- Добавлено ---
    Можно также обсудить миграции. Допустим вы решаете заменить одно поле на другое. Старое останется (временно) или будет сразу удалено в той же миграции?
     
  2. kazadai90

    kazadai90 Активный пользователь

    С нами с:
    6 фев 2013
    Сообщения:
    103
    Симпатии:
    19
    Для старого кода git, просто оставляем его в другой ветке.

    По поводу миграций - никаких правок старых миграций. Только новые (потому что трудновато вручную отслеживать состояние БД, состояние миграций. Проще запускать их, зная что не нарушена целостность БД).
     
  3. Roman __construct

    Roman __construct Активный пользователь

    С нами с:
    27 апр 2019
    Сообщения:
    1.270
    Симпатии:
    112
    В моей нынешней команде из одного человека)) обычно каменчу код до момента пока не пойму что новое работает как надо. Потом просто легкий рефакторинг делаю (или не делаю, если вломы)))))))) и убираю старое массово.

    Миграциями почти не пользуюсь. ууупс.... ))) понимаю что не айс, но поскольку один - никакого смысла в них сейчас не вижу.
     
  4. MouseZver

    MouseZver Суперстар

    С нами с:
    1 апр 2013
    Сообщения:
    7.734
    Симпатии:
    1.315
    Адрес:
    Лень
    старый код вовсе отделял от контента, смотрел по конкретной логике, что нужно преобразовывать/переписывать. По окончанию последовательной переписи с тестами, немедленно удалял. После за другой кусок берусь.

    Почему отделяю ? 75% начальных действий по свежему коду идут наброски, а после уже оптимизация и разделение на составные.
    --- Добавлено ---
    Дамп файлов всегда сохраняю - на всякий косяк.
     
  5. [vs]

    [vs] Суперстар
    Команда форума Модератор

    С нами с:
    27 сен 2007
    Сообщения:
    10.553
    Симпатии:
    631
    Пришёл, поудалял
    --- Добавлено ---
    За последние месяцы несколько кадров сменилось и теперь почти все так делают.
     
  6. Алекс8

    Алекс8 Активный пользователь

    С нами с:
    18 май 2017
    Сообщения:
    1.730
    Симпатии:
    359
    удаляю сразу все нафик)) и из БД тоже)
     
  7. MouseZver

    MouseZver Суперстар

    С нами с:
    1 апр 2013
    Сообщения:
    7.734
    Симпатии:
    1.315
    Адрес:
    Лень
    есть пример
    PHP:
    1.     /*
    2.         - ищем нейрон/пиксель по вертикальной оси
    3.     */
    4.     private function axis_y( int $x ): bool
    5.     {
    6.         $im = $this -> setImageCrop( [ 'x' => $x, 'y' => 0, 'width' => 1, 'height' => imagesy ( $this -> im ) ], true );
    7.        
    8.         imagetruecolortopalette ( $im, false, 2 );
    9.        
    10.         $bool = imagecolorstotal ( $im ) > 1;
    11.        
    12.         imagedestroy ( $im );
    13.        
    14.         return $bool;
    15.        
    16.         /* $y = 0;
    17.        
    18.         while ( $y < imagesy ( $this -> im ) )
    19.         {
    20.             if ( imagecolorat ( $this -> im, $x, $y ) ? $this -> neuron : ( int ) ! $this -> neuron )
    21.             {
    22.                 return true;
    23.             }
    24.            
    25.             $y++;
    26.         }
    27.        
    28.         return false; */
    29.     }
     
  8. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.068
    Симпатии:
    1.231
    Адрес:
    там-сям
    Мои соображения на счёт выпиливания либо закомментирования.
    * по хорошему код должен документировать сам себя, т.е. быть достаточно читабелен чтобы объяснять что происходит. поэтому если мы видим одновременно две версии — старую и новую — мы видим причину изменений. я считаю это важно.
    * да, история в git может показывает что на что изменилось, но только в том случае, если мы целенаправленно сравниваем версию А с версией Б. пока мы того не затребовали, мы не знаем почему код пришёл к тому, к чему он пришёл.

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