На самом деле подобный вопрос давно меня интересует, должен-ли программист быть в какой-то степени перфекционистом ? Ведь понятно, что сам по-себе спагетти код никуда не годиться, но в то-же время у меня часто бывают ситуации, когда мой код мне не нравиться, хотя он вполне читаем (с моей точки зрения), но в то-же время я ведь вижу, что можно что-то улучшить - тут выделить в отдельный метод, тут чуть подправить и переименовать итп. Ведь хочеться-же достигнуть своеобразного грааля программирования - что-бы каждый класс являл собой четкую и ясную сущность, без примеси "подозрительных" с точки зрения его интерфейса методов, каждый метод имел ясное название и делал-бы только то, что написано в его названии и ничего другого, и так далее (не один десяток таких-вот пожеланий) по стопам великих и ужастных Фаулера, Макконнела и прочих компьютерных умов нашего времени.
Но ведь у подобного вылизывания есть один недостаток - поглащаемое время, и так сложно иногда определиться, хватит тут рефакторить, или стоит еще немного улучшить ...

softwarer
Боюсь, внятной статистики на этот счет ни у кого нет, поэтому вопрос вкусов. Имхо - да.
...
Вообще говоря, понятие качества кода во всех его вариациях сводится ровно к противоположному - к экономии времени.

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

Николай1
Могу добавить еще одну сентенцию, от себя - "правильный и неправильный код пишется одинаковое время".

если-бы это было так, то мы-бы уже давно жили при коммунизме, еда в магазинах была-бы бесплатной, а работать надо было-бы только один час в неделю, да и в этот час нечего особо делать было-бы не надо ;)

softwarer
Не знаю, не знаю. Это утверждение и последующие исходят из предположения, что "пишем плохо, надо улучшать". А я предпочитаю сразу писать хорошо :) Конечно, через какое-то время можешь осознать ошибки, набрать практику применения или увидеть новую идею - ну так берешь и улучшаешь.

ну во-первых "хорошо" и "совершенно" - разные веши :) Или вы предпочитаете сразу писать совершенный код ? ;)

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

softwarer
Ошибаетесь. Во всяком случае, я куда более согласен с Николаем. Плохой код пишут не потому, что быстрее (хотя этим чаще всего оправдываются), а потому что для этого не требуется думать. Реально плохой код не сказать что быстрее в момент написания

хм, вы с Николаем тратите одинаковое время на придумывание имени метода DoSomeStuff() и CalculateTotalBalance() ? Вы с Николаем за пару мгновений выделяете общее из пары похожих методов в отдельное место ? Вы с Николаем в мгновение ока перемещаете методы между классами ?
Что-ж, вы с Николаем гении. Я вам завидую. А вот я не гений. Мне, что-бы что-то изменить в коде требуется некоторое время. Что-бы вместо одного здорового метода с уродским названием в левом классе, написать пару методов с ясными именами и вписывающимися в интерфейс своих классов мне тоже требуется время. Иногда оно не очень большое, иногда очень.

softwarer
резко медленнее в плане последующих затрат на исправление.

с этим не поспоришь

softwarer
Именно. Можно и нужно менять по ходу, и заметных затрат времени это не требует.

мне почему-то кажется, что это сильно зависит от того, что конкретно меняется ;)

softwarer
Более того, я абсолютно уверен в том, что если решение хорошо продумано, каждый участвующий в нем объект тривиально именуется. Затруднения в придумывании имени (а также желание иметь анонимные объекты, что возможно в некоторых языках) с моей точки зрения означают ровно одно: решение не продумано, программист не совсем понимает, что будет делать объект и зачем, поэтому и название под вопросом.

угу. А что-бы решение было хорошо продумано, времени-то случаем не надо тратить ? Вы-б еще сказали, что если решение продумано вплоть до названия каждой переменной, то набирание кода не отнимет много времени. Ну да, не отнимет, кто-бы спорил :)

softwarer
Лично я, собираясь написать несколько строк, и вспоминая, что "похожее я уже писал", не испытываю проблем с тем, чтобы вместо прискорбно типичного Ctrl-C Ctrl-V выделить метод. И времени на это тратится.... ну вот честно, по сравнению например с написанием хорошего набора юнит-тестов к тому же коду о таких тратах и говорить-то бредово.

в общем, затраты на рефакторинг у вас пренебрежительно малы. Что-ж, могу вас только поздравить с этим замечательным фактом. Но судя по всему, это не везде так, ибо зачем тогда тому-же Фаулеру вводить в свою книгу подглаву "Уменьшение стоимости рефакторинга" ?

softwarer
Хм. Скажем так, по моим представлениям работы пальцами здесь секунды.

в смысле секунды ? Напечатать в редакторе код ? А думать, в какие классы поместить методы и как они будут выглядеть и называться, будет сам редактор кода ? Мне-б такой редактор ;)

softwarer
Безусловно. Я говорю о случае "пишешь хороший код и по ходу дела соображаешь, что пару помарок таки допустил".

а если помарка большая ? Например осознал, что иерархия классов неверная ? Вы это тоже на пару минут переделаете ?

softwarer
Надо. И что самое удивительное - примерно столько же, сколько нужно, чтобы решение было плохо продумано.

действительно удивительно. Первый раз слышу подобную мысль. Всегда думал, что что-бы сделать что-то хорошее, надо приложить больше сил и времени.
Возможно вы имеете ввиду ситуацию, когда решаемая проблема знакома разработчику, и ему действительно не надо напрягаться для создания решения (либо сама задача тривиальна). Действительно, мозг подключать почти не надо, все сделается почти на автомате. Но часто-ли такое происходит ? Имхо нет. Хотя действительно, у кого как ...

softwarer
Уточню: на рефакторинг "прямо по ходу создания", о котором мы и говорим в смысле "совершенствовать можно до бесконечности". Разумеется, со временем меняются требования, появляются новые задачи и новые модули, появляется новый взгляд на систему - это уже порой требует рефакторинга вплоть до "все переписать".

теоретически, "все переписать" может случиться и без изменения требований вообще. Ну поняли, что выбрали кардинально не тот путь. И если есть желание совершенствовать - то ...

softwarer
Не понимаю я Вас, честно. Если я хочу разбить на части большую процедуру НарисоватьЧеловечка, у меня как-то не возникает вопроса с названиями процедур НарисоватьРуку, НарисоватьНогу и ГдеТоЗдесьДолжнаБытьГолова. Ну максимум сходить на мультитран за английским термином.

а если взять что-нибудь посложнее человечка ? Например моделирование полета сверхзвукового истребителя ? Тоже никаких вопросов не возникнет ?

Боюсь сказать банальную вешь, но при программировании приходиться принимать массу решений буквально на каждом шаге (собственно как и в любой инженерной науке, по сути программисты те-же конструктора истребителей или автомобилей). Если вы хотите, что-бы ваш истребитель быстро летал, метко стрелял и не разваливался в воздухе - будьте добры внимательно подумать над его конструкцией, а если в ходе проектирования выяснился промах - что-то в нем переделать.
Каким образом это может занять одинаковое время с проектированием чуда техники, у которого отвалятся крылья при попытке пилота завести двигатель ?