Перфекционизм в коде
 

Собственно сабж.

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

Бывает ли у вас такое, как боретесь и боретесь ли, как посоветуете бороться с этим ну и в таком духе:)

Я в принципе только начал более-менее серьезно работать, но от этой проблемы тоже страдаю, причем очень сильно.За сегодняшний день, например, один класс трижды переписывал, "тщательно обрабатывая напильником". Хотя, с другой стороны, при таком подходе из паровозов порой вертолеты получаются...

Эффективнее быть разным.

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

Я последнее время всегда ратую за то, что делать нужно под конкретную задачу.
3 уровня кода: полный реюз, частичный реюз, только под проект.
Полный реюз говорит о том, что эти классы могут перекочевать в проект вообще нетронутыми. Частичный - что в них надо будет внести правки. Конкретно под проект - то, что не будет перенесено никогда.

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

Если классы не превращать в свалку или склад, то вполне можно облегчить себе и окружающим жизнь.

Иногда бывает так, что функционал появляется\изменяется в процессе, и тут главное время реализации, поэтому бывают моменты когда приходится пренебрегать "красотой".

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

Ну много вариантов ведь в реальной жизни. Если бы всё было идеально то и темы подобные не начинались бы:)

Остается только мечтать об адекватной документации не меняющейся в ходе проекта и неограниченному времени на разработку:)

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

Лично для меня проблема - когда после многочасового кодинга начинаю терять концентрацию, понимание того что делаю, т.е. уже делаю как то подкоркой, не вполне осмысленно, вероятно это признак переутомления... Где-то даже читал про такие симптомы...

Недавно на Хабре обсуждалось.

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

Божественная статья!
Вообще добавить что-то тяжело, так, из менее важного.
Вы никогда не сможете верно оценить сроки разработки того, что вы ещё не разрабатывали.
Пока вы не закончили проект, вашего кода нет. Он хуже любого уже выпущенного.
Я, пожалуй, не страдаю совершенствованием кода, мне важен результат, код - это лишь средство.

Статья крутая. Очень.

Я как-то раз работал над проектом почти полгода, потом понял, что получилась хрень, и переписал все с нуля ) Причем потратил всего около месяца на то, чтобы догнать его до прежнего уровня, только с более красивой структуризацией и кодом =)

Статья да, в точку. Так что, товарищи, забьём коллективно на перфекционизм и будем *****кодить :D

Это потому, что за первые полгода в голове уже сложилось структура, видны ошибки, не надо придумывать новое.

На самом деле статья однобока.

Ни разу в жизни не переписывал код с нуля. Откуда у людей берется эта странная идея?
Всегда можно отрефакторить, поменять интерфейсы объектов и подправить структуру приложения. И это всегда будет и быстрее и надежнее, т.к. в любой момент работы над кодом - у нас "уровень готовности" кода не снижается.

На эту тему могу посоветовать статью одного из основателей stackoverflow.com Джоэля Спольски: http://www.joelonsoftware.com/articl...000000069.html
Никогда. Никогда не переписывайте код с нуля.

А про перфекционизм - у меня такая же фишка. Но знаете что? Это обычная лень. Лень потом разбираться с "плохим" кодом. И с этой ленью надо бороться. И с кодом в любом случае прийдется разбираться.

Переписывайте. Переписывайте, если это надо.

Далеко не всегда. Часто проще и быстрее переписать с нуля, чем переделывать существующее.
Это его личное мнение.
Перфекционизм == Лень O_o.
Совсем нет.
Мне просто не нравится, когда у меня бардак где-либо, хоть в коде, хоть на столе.

Определи слово "надо".

1. Ни разу в жизни не видел такого кода. Очень редко бывает проще написать что-то свое, чем разбираться с существующим чужим кодом, но если код твой - разбираться в нем не может быть настолько сложно, разве что у тебя раздвоение личности.
2. Конечно же это его личное мнение. Иначе не бывает. Но это мнение аргументировано, разжевано и положено на блюдечко.
3. Тут я спорить не буду, это мое мнение и его мне аргументировать лень. Да и смысла нет.

Вы код в темплатовских (или им подобных) флэшках когда-нибудь видели? :)

В смысле? Это каждый сам решает, когда проект стоит переписать с нуля или когда не стоит.
Это может быть чужой проект, который написан "боже, как это вообще может работать?"
Это может быть свой проект, у которого, по изначальному ТЗ, было четкий функционал, но в течении некого времени его расширили так, что теперь там заплатка на заплатке и каждая новая задача требует массу времени на интеграцию, и ты знаешь, что задач будет еще не один десяток. И тогда, зная уже текущие потребности можешь спроектировать проект так, что он будет гибок к новым задачам. И суммарно будет выигрыш по времени.
Если я писал проект 2 месяца + куча дополнений, которые пришлось вставить в обход архитекторы, а сейчас я смогу его переписать с нуля всего за неделю, я его перепишу.

А может быть так, что все что выше не будет аргументом, так как переписывание займет полгода-год.
Зависит от ситуации с проектом и времени.

Не верю. Ни единому слову )
Этого мог не видеть только:
1) Начинающий программист, который еще нифига не писал толком.
2) Человек, каким-то чудом сразу ставший продвинутым проггером, минуя все этапы развития )

Часто бывает так, что сама идея осталась прежней, а реализовать ее нужно подругому.

Ну, когда нужно сменить реализацию - это совсем из другой сказки. Плохой код тут не при чем.

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

Может у нас разное понимание слова "переписывать"? Вот не верю я, что через два месяца работы ты просто берешь и трешь папку с исходниками.
Скорее всего создаешь новую архитектуру и размазываешь по ней макро- и микрорешения изначального кода.
Тогда у нас просто разный подход. Я предпочитаю более локализированные изменения, чтобы не поламать нечаянно что-нибудь. За счет чего приходится гораздо меньше заниматься дебагом.

Если действительно весь изначальный код стирается, то... Даже не знаю. Странно.

Добавлено через 11 минут
Вот у меня тоже бывали подобные проекты. Но в итоге я:
а) разгребал все без удаления исходников и получал нормальную реализацию;
б) в особо злых случаях заворачивал весь спагетти-код в человеческий интерфейс, который позволял сделать все необходимые изменения.

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

Бывает и не через 2 месяца, а через полгода работы просто берешь и трешь папку с исходниками.

Да, и у меня бывает.

- Как там исходники?
- Тру!
:)

Подпишусь под каждым словом))

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

Перфекционизм это тру, если итераций по переписыванию не бывает больше одной.

Я думаю здоровый перфекционизм - это очень хорошо. Самое главное без фанатизма.
Такое было, ни капли не жалею.

Просто нерельно рефакторить, если пересмотрел саму архитектуру.

)))))