Как избавиться от стремления к идеализации ?

[login999]

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

[GreenBear]

нужно ли избавляться?

[Rebz]

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

[login999]

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

[login999]

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

[gold-goblin]

Логин, твои бэтки это супер проги, кодишь ты идеально и поэтому от этой привычки из бавлятся не надо =)

[Rebz]

login999, для этого есть ТЗ.
Формализуй требования и выполняй только их. Если возникнет какая-то идея - то предложи её заказчику. Далее установи себе сроки. Если понадобится внедрять что-то новое, согласуй их (сроки) с заказчиком.

[login999]

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

login999, для этого есть ТЗ.
Формализуй требования и выполняй только их. Если возникнет какая-то идея - то предложи её заказчику.
Не выходит, не могу сдать заказчику то что мне не нравится, а нравится понятное дело только идеальный вариант, в чем и трабл :(. П.С. ТЗ как такового нету, то что я ему пишу оно его в принципе и не требует, давным давно уже и так уговорились что нужно

[login999]

Вообще заказ должен был бы уложиться максимум в 500-600 строк =/, а сейчас там уже в районе 1.2 к строк, где юзаются уже и свои собственные обертки к модулям, и куча всяких разных наворотов, придумано пару велосипедов, которые мне удобнее, чем стандартное...

[Rebz]

login999, ну вот в этом и причина. Потому что нет четких требований, регламентации и технического задания как такового. Все-таки, не просто так их придумали ;).

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

[login999]

login999, ну вот в этом и причина. Потому что нет четких требований, регламентации и технического задания как такового. Все-таки, не просто так их придумали ;).

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

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

Дело не в количестве строк, я приблизительно написал, насколько я оценил обьем работы, и сколько оно получилось

[Rebz]

Изучи методологии, которые есть при разработке ПО.
Ты не должен переписывать все с 0.
Изначально продумай как должно быть, а потом пиши.. чтобы потом с 0 не переписывать. Лучше потрать больше времени на проработку, чем потом на исправление.

[login999]

Изучи методологии, которые есть при разработке ПО.
Ты не должен переписывать все с 0.
Изначально продумай как должно быть, а потом пиши.. чтобы потом с 0 не переписывать. Лучше потрать больше времени на проработку, чем потом на исправление.
Понимаешь в чем проблема, сначала продумываю, исходя из имеющихся средств, после того как дописываю, набор средств уже увеличивается.
Исходя из набора средств на конец, вижу что нужно переписывать с нуля, так как улучшать слишком много, количество патчей/улучшений тоже не самым лучшим образом влияет, я перестаю понимать, как оно действует, стабильность системы в целом тоже падает, в результате я либо недоволен своим кодом, либо(что еще хуже) перестаю прослеживать всю логическую цепочку того как он должен действовать, в результате выходит индусский код, вспомнить на утро (даже по комментам) чего я там наворотил весьма проблематично, так как сплю мало, и в башке постоянная каша

[Rebz]

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

[login999]

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

[Rebz]

Ознакомься:
http://www.cmcons.com/articles/obshhie_stati_rup/rup_i_drugie_metodologii_razrabotki_po/
:)

[login999]

Ознакомься:
http://www.cmcons.com/articles/obshhie_stati_rup/rup_i_drugie_metodologii_razrabotki_po/
:)
Спасибо, нырнул читать :)

[Дикс]

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

[[n]-c0der]

Стремление к идеализации.. хм не считаю, что это плохо, и вообще это даже хорошо, у меня немного другая проблема, при написании чего то, если встречается, что то интересное, я перескакиваю с задачи на свой интерес, изучаю уже что то другое, при изучении чего то, встречается еще что то интересное и ппц, перескакиваешь с одного на другое, учишь там тут, там тут и кажется, что жизни моей не хватит выучить все необходимое...
А от своего стремления к идеализации не отрекайся, благодаря данному фактору, заметно растет твой уровень знаний, соответственно и опыт... правда это сугубое ИМХО...

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