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

[Dukobpa3]

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

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

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

[Silicium]

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

[Astraport]

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

[goodguy]

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

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

[Psycho Tiger]

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

[Dukobpa3]

3 уровня кода: полный реюз, частичный реюз, только под проект.

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

[i.o.]

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

[СлаваRa]

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

[Dukobpa3]

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

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

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

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

[fish_r]

Сообщение от Dukobpa3

Пару раз было такое что сам путался в своих "гениальных" схемах и приходилось всё переписывать с нуля.

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

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