Сабж, все знают пословицу "Лучшее-враг хорошего", у мну проблема в том что я стараюсь сделать лучше, в результате хорошего не выходит. Увлекаюсь кодингом, поэтому трабла я думаю понятна, в результате получаются беты, причем постоянно, слишком дохера пытаюсь улучшить
Хм. Ты имеешь в виду кодинг на работе? Ну если ты исправляешь заявленные баги, дописываешь новый функционал и у тебя остается время - оптимизируй, почему нет).
у меня получается замкнутый круг - заказ уже я хз сколько пытаюсь сдать, написал, тестим вместе с заказчиком, баги выловили, поправил, его пожелания учел, подкрутил, смотрю на результат - ублюдочно, переписываю с нуля, пока переписываю, улучшаю одно, улучшил одно, потом вижу что другое можно сделать лучше, доделал это, переделал то, и так замкнутый круг блин, как белка в колесе, постоянный апгрейд, все доходит максимум до беты.
Нет, работаю я не кодером) В IT, но не кодер мну, на досуге просто подрабатываю кодингом оптимизация не получается по одной причине - до нее не доходит, переписываю софт практически с нуля
Логин, твои бэтки это супер проги, кодишь ты идеально и поэтому от этой привычки из бавлятся не надо =)
login999, для этого есть ТЗ. Формализуй требования и выполняй только их. Если возникнет какая-то идея - то предложи её заказчику. Далее установи себе сроки. Если понадобится внедрять что-то новое, согласуй их (сроки) с заказчиком.
Не, далеко не идеально я кодю, спасибо за поддержку, но далеко не идеально. Не выходит, не могу сдать заказчику то что мне не нравится, а нравится понятное дело только идеальный вариант, в чем и трабл . П.С. ТЗ как такового нету, то что я ему пишу оно его в принципе и не требует, давным давно уже и так уговорились что нужно
Вообще заказ должен был бы уложиться максимум в 500-600 строк =/, а сейчас там уже в районе 1.2 к строк, где юзаются уже и свои собственные обертки к модулям, и куча всяких разных наворотов, придумано пару велосипедов, которые мне удобнее, чем стандартное...
login999, ну вот в этом и причина. Потому что нет четких требований, регламентации и технического задания как такового. Все-таки, не просто так их придумали . В требованиях может быть примерно записано следующее: производительность, функциональность, сроки разработки, демонстрация заказчику и т.д. Если заказчику важно кол-во строк, а не производительность, то уделяй этому внимание. Никаких своих апгрейтов.
Гхм, наверное ты прав, но трабл в том что и с другими цацками которые для себя пишу тоже подобные траблы, если берусь что-то улучшать, то как минимум один раз с нуля переписываю, стремлюсь идеализировать и предусмотреть абсолютно все, вплоть до того, что тот кому в руки попадет есть редкий тормоз, сделать так чтою предусмотреть все баги, но они чаще всего вылазят именно из-за того что их и пытаешься предусмотреть Дело не в количестве строк, я приблизительно написал, насколько я оценил обьем работы, и сколько оно получилось
Изучи методологии, которые есть при разработке ПО. Ты не должен переписывать все с 0. Изначально продумай как должно быть, а потом пиши.. чтобы потом с 0 не переписывать. Лучше потрать больше времени на проработку, чем потом на исправление.
Понимаешь в чем проблема, сначала продумываю, исходя из имеющихся средств, после того как дописываю, набор средств уже увеличивается. Исходя из набора средств на конец, вижу что нужно переписывать с нуля, так как улучшать слишком много, количество патчей/улучшений тоже не самым лучшим образом влияет, я перестаю понимать, как оно действует, стабильность системы в целом тоже падает, в результате я либо недоволен своим кодом, либо(что еще хуже) перестаю прослеживать всю логическую цепочку того как он должен действовать, в результате выходит индусский код, вспомнить на утро (даже по комментам) чего я там наворотил весьма проблематично, так как сплю мало, и в башке постоянная каша
Ну это понятно . Проект сначала должен быть полностью готов на бумаге. Что, сколько, чего используется. Дальнейшие перспективы, утилизация и т.д. Только тогда можно приступать к нему. Посмотри методологии..
Ты прав, ушел в гугл искать, сам хотел чего-то подобное почитать, но блин терминов не знал, что не айс( мну доморощеный быдлокодер, и с терминологией не знаком )
знакомая проблема надо подавлять в разумных пределах, если речь идёт о скорости выполнения одёргивать себя почаще со временем всё сбалансируется
Стремление к идеализации.. хм не считаю, что это плохо, и вообще это даже хорошо, у меня немного другая проблема, при написании чего то, если встречается, что то интересное, я перескакиваю с задачи на свой интерес, изучаю уже что то другое, при изучении чего то, встречается еще что то интересное и ппц, перескакиваешь с одного на другое, учишь там тут, там тут и кажется, что жизни моей не хватит выучить все необходимое... А от своего стремления к идеализации не отрекайся, благодаря данному фактору, заметно растет твой уровень знаний, соответственно и опыт... правда это сугубое ИМХО... Забыл сказать о том, что если ты выполняешь ТЗ, твое стремление не должно быть препятствием, сроку сдачи данной задачи...