Исправить или переписать. Ловушки нашего подсознания

Солнышко уже скрылось, а я все "пилю" один и тот же кусок кода. А хотел-то всего лишь исправить мелкую ошибку. Однако, исправив одно, обнаружил, что отвалилось другое, а там, в свою очередь, уже и так куча "костылей-распорок", так как код этот правится не в первый раз. Вот в такие моменты и начинаешь думать "а не переписать ли весь этот блок с нуля - так, что бы без распорок, без костылей...". На что пессимист в глубине сознания начинает возражать "А сколько на это времени уйдет? Код-то не маленький. А, может, проще-таки еще одну заплаточку?". Так как же поступить? Переписывать или править дальше? Как правильно оценить время? На самом деле, оценивать объем кода по базовым факторам мы все умеем - смотрим на количество строк, прикидываем сложность, сопоставляем с тем, сколько обычно времени уходит на такой код. Все это понятно, но есть факторы, сильно искажающие нашу оценку - факторы, действующие на подсознательном уровне и приводящие к неадекватным решениям.

Свой или чужой код

Пожалуй, это один из сильнейших факторов, искажающих нашу оценку временных затрат. И, если вы в сомнениях - переписать или добавить заплатку, то подавляющем большинстве случаев вы примете правильное решение, следуя простой формуле:

Свой код переписывайте смело.

Чужой лучше не трогать - сделайте заплатку

Дело в том, что в процессе написания кода вы так или иначе натыкаетесь на множество непредвиденных моментов, сложностей, которые вы не предусмотрели заранее. И это нормально - опытный программист всегда прибавляет к изначальной оценке небольшой резерв именно на эти сложности, при чем делает он это автоматически. При этом, если данную задачу вы уже решали, то все "подводные камни" вами уже пройдены. Кроме того, вы уже продумали весь алгоритм целиком и, по сути, вам останется продумать только те структурные моменты, из которых задача переделывается. Однако, при оценки времени, в нашем подсознании возникает задача целиком и мы оцениваем ее примерно в то же время, как и новую задачу. Конечно, сознательно мы понимаем, что сложные части уже продуманы и даже пытаемся вычесть затраченное на них время из общей оценки. Но, при этом, результирующая прикидка все равно получается завышенной. Если же мы собираемся переписать чужую задачу, то, как правило, просматриваем общую структуру кода, не вникая в рутинные и, на первый взгляд достаточно понятные куски кода. В следствии чего, наше подсознание формирует несколько заниженную оценку и, как правило, мы ее даже не корректируем.

Упрощаем код и пишем красиво

Работая в команде, мне часто приходится читать чужой код. И, периодически я вижу простые вещи написанные весьма громоздко и совершенно нечитаемо. Например, много повторяющихся блоков или, еще хуже, лишние операции. Такой код хорош, если ваша цель сделать так, что бы никто не разобрался, однако, в большинстве случаев, такая цель перед нами не стоит.

bool a = SomeCondition();
/* Как упростить следующий код? */
bool b;
if( a.ToString().Length == 5 )
{
   b = true;
} else
{
   b = false;
}

Этот небольшой отрывок я привел отчасти ради шутки, а отчасти для того, что бы показать о чем идет речь. Разумеется, я не думаю, что кто-то реально так пишет. Но, в реальности наши задачи несколько сложнее и, по мере поступления новых вводных, мы часто перестаем видеть знакомые шаблоны и, как следствие, начинаем писать в стиле приведенного выше шуточного примера.