Личные ощущения как симптом?

[Котяра]

Здесь нужно учесть 2 подхода в проектировании и разработке.
Это waterfall и XP( iteration,refactoring,proto etc).
"Водопад" это система разразботки для которой пишется детальный план. От начала до конца.
"Разработка через итерации" - это часть экстремального программирования.
Я предпочитаю смешанную схему работы. Т.е. для определённой итерации в меру возможности составляется полный план и выполняется от и до без отступлений. Если находится какой-то тупик или ответвление от плана - замораживаем, но вносим его на следующей итерации (учитываем при составлении подробного плана).
Такая разработка позволяет иметь рабочий продукт в конце каждой интерации (как сказал бы Лебедев - система прогрессивного джипега)
Минусы тоже есть. Обычно код приходиться переписывать по множеству раз, поэтому нужно привыкать к написанию кода с учётом разработки через рефакторинг, прототипировании и/или постоянной детализацией прототипа.
Подробнее можно почитать у Макконнелла и Фаулера, но собственные грабли - лучший опыт.

[etc]

Мыслить надо шире.

[dark256]

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

10 января пришло ТЗ и где-то треть графики по локациям и интерфейсу. В течении месяца постоянные добавления и уточнения. Срок сдачи - 10-го марта. Код - на GWBasic оно выглядело бы лучше.
Постоянный рефакторинг блоков по 100-300 строк кода. Перекрестные вызовы процедур с передачей данных уже через черт его знает что и как. Кидает в дрож от этого зрелища. В пятницу пришла графика по ОКОНЧАТЕЛЬНОМУ виду интерфейсов. Надо ли говорить, что.....

А сроки поджимают!.... Вот таким вот калом оно и останется... В дворники уйти хочется....

[fish_r]

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

Мыслить надо шире.

Объясни...

[Zebestov]

fish_r красава точненько как вложил

[mooncar]

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

Кидает в дрож от этого зрелища... Надо ли говорить, что.....
А сроки поджимают!....

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

[fish_r]

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

трачу значительную часть времени на комментарии ...

Вот. У кого-то из адептов программирования (это кажется по поводу UML): "Код должен быть настолько очевиден, чтобы не было необходимости его комментировать.". А у меня он уже не становится настолько очевиден.
И ещё: "Если строка кода нуждается в комментарии значит для этой строки необходимо создание функции.."

Может быть и спорные изречения. Не помню кто, да и где написал. Но мне именно такой код доставляет удовольствие. А "затуманивающий мусор" раздражает. Поэтому и тему создал: Может быть это не просто эстетские ощущения, а объективное свидетельство кривизны?

[expl]

http://agilepod.ru/?p=187
Здесь вот рассказывают по "Развитие эмоционального интеллекта", так что кое-кто использует эмоции как руководство к действию.

Но это все изотерика.
А истинный критерий кривости кода - тестопригодность.

[wvxvw]

Так будет случаться всегда, нo нужно быть к этому всегда готовым. Не далее чем недели две назад менеджер решил меня нагрузить новым проектом, и вдруг ему пришло в голову, что он может не написать тех задание... С воплями, слезами и уговорами, какое-то подобие тех задания появилось. Его естесственно тут же в нескольких местах поменяли до неузнаваемости, но, его наличие обеспечило мне по крайней мере несколько дней спокойной работы. Т.е. если бы его не было, и менеджер не напряг бы думательную мышцу головы, то было бы хуже.
Сам факт того, что план будет нарушен и даже очень часто не отменяет его полезности. Хотя, почему-то многим начинает казаться наоборот... Чтобы многих остановить, это можно сравнить со светофорами, которые не предотвращают все ДТП, но если бы их не было...
А что до переделок - всякая работа имеет свою цену, и... на самом деле, программист, который может переделать чужой код, не просто залепив дырки чем под руку попалось, а так, чтобы еще и улучшить, удалить ненужные части, оптимизировать, если есть что - таких мало, и если програма вообще жива, и ее нужно поддерживать - таких трудно найти... хотя, обычно такая работа считается менее квалифицированной, изза чего поддержка поручается начинающим / ленивым. Изза чего программы становятся хуже и хуже с каждым релизом

[etc]

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

Объясни...

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