Почему приходится постоянно переписывать программы?

← →
smu (2003-12-04 08:30) [0]

Я что один так криво пишу? От начального кода остается процентов 10...

← →
ИМХО (2003-12-04 08:37) [1]

Это нормально.

← →
Dmitriy O. (2003-12-04 08:38) [2]

Я пишу у меня остаетсяот начального кода только Application.Initialize;
Application.Title := "";
Application.CreateForm(TMyform, Myform);
Application.CreateForm(TData, Data);
Application.Run;

← →
mfender (2003-12-04 08:39) [3]

Это неизбежно. Не знаю про 10%, но больше половины иногда переписать приходится.

← →
smu (2003-12-04 08:43) [4]

Основные стадии:
1)Наваял что-то, что работает.
2)Оформил ввиде функции.
3)Завел объект
4)Убрал все в отдельный модуль...
Больше 10 процентов никак не получается...
(формулу не скажу :)) )

← →
AbrosimovA (2003-12-04 08:47) [5]

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

← →
Sergey13 (2003-12-04 08:56) [6]

Есть разные поводы для переписывания.
1. Сам напортачил и сделал все неоптимально, медленно, глупо.
2. То что нужно заказчику он и сам не знает. И узнает об этом только после начала опытной эксплуатации (т.е. после написания первого варианта проги).
По причинам переделок (для себя) я бы так распределил
1. 10-20%
2. 80-90%
Причем, часто получается так, что то, что было написано "нормально" для первоначальной постановки задачи, зачастую оказывается "неоптимально, медленно, глупо" для уточненного задания.

Нет предела совершенству. И глупости... 8-)

← →
ИдиотЪ (2003-12-04 09:10) [7]

хуже, когда переписываешь еще недоделанное

← →
Anatoly Podgoretsky (2003-12-04 09:12) [8]

ИМХО © (04.12.03 08:37) [1]
Это не нормально.

← →
ИМХО (2003-12-04 09:35) [9]

Удалено модератором
Примечание: Offtopic

← →
MVova (2003-12-04 10:14) [10]

Это происходит когда, получив задание, сначала пишут потом думают.
Когда-то тоже таким страдал.

Это те навыки, которые приходят со стажем.

← →
REA (2003-12-04 10:23) [11]

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

← →
ИдиотЪ (2003-12-04 10:23) [12]

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

← →
MVova (2003-12-04 10:37) [13]

> ИдиотЪ © (04.12.03 10:23) [12]

Всего не предвидишь.
Но, то насколько далеко ты можешь увидеть, зависит размер твоей зарплаты.

← →
Ru (2003-12-04 10:55) [14]

Великие художники (Рембрант, Пикасо, Ван-Гог) по многу раз переписывали свои картины и в результате получали совсем не то, что собирались рисовать, но именно поэтому они стали великим, а "мазилы" так и остались безизвестными.

Пишите Шура, пишите. В крайнем случае ума наберётесь.

← →
Empleado (2003-12-04 11:07) [15]

Может сначала задачу и ее решение стоит на бумаге набросать, в подробностях?
>От начального кода остается процентов 10...
90% "невостребованной" работы - это Очень(!) много ... ИМХО.

← →
Lola (2003-12-04 11:10) [16]

Мне чаще всего задачу ставят так: "Я еще сам не знаю, что я хочу, но примерно про это..." И сколько потом останется от первоначального "наброска"? Вот последний пример. Задача ставилась максимально конкретно (т.е. конкретные расчеты, репорты), срок - 2 недели. За две недели я это сделала. Теперь уже месяц переделываю. Уже не только я, но и сам заказчик запутался - "здесь играть, здесь не играть, здесь рыбу заворачивали". Не говоря уже об оптимизации, на неё вообще времени не хватает.

← →
smu (2003-12-04 11:13) [17]

> Empleado ©
ага и блок схему нарисовать.. :))

← →
Judith (2003-12-04 12:12) [18]

Lola © (04.12.03 11:10) [16]
Аналогично. Который раз зарекаюсь, сначала утверждаем ТЗ, потом стулья. Бесполезно...

← →
Юрий Зотов (2003-12-04 12:38) [19]

Тут не надо смешивать все в одну кучу. Одно дело - когда программа переписывается потому что изменились ТРЕБОВАНИЯ к ней, а совсем другое, когда она переписывается потому, была не написана, а "накодирована". Во втором случае виноват только сам ее автор, и никто другой.

← →
Sandman25 (2003-12-04 12:49) [20]

[11] REA © (04.12.03 10:23)

Я в таких случаях всегда пишу большой комментарий, в котором описываю, в чем состоит "неоптимальность" и зачем она на самом деле нужна. Одного раза оптимизации (через год после написания) и вынужденного восстановления неоптимальной версии хватило для выработки данной тактики :)

← →
euru (2003-12-04 13:58) [21]

ТЗ, конечно, нужно, но оно не панацея от неправильного написания программ. Это все-таки больше контракт между ЗАКАЗЧИКОМ (тот, кто делает постановку задания) и ИСПОЛНИТЕЛЕМ (тот, кто на основании этого задания программирует). Причем это ТЗ будет тогда полезно, когда ОБЕ стороны будут вынуждены (добровольно или принудительно) придерживаться его требований. В противном случае это просто формальность, которая никакой стороне не нужна и только приводит к пустой трате времени.

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

← →
SkyRanger (2003-12-05 02:19) [22]

>REA © (04.12.03 10:23)
ГЫЫЫ!!! Респект! %)

>Empleado © (04.12.03 11:07)
ИМХО писать прогу на бумаге увеличивать неэффективность на 200 процентов, не раз убеждался, на бумаге максимум что я разрабатываю это структура БД и структура классов, да и то, и то и другое в процессе изменяются до неузнаваемости, всего не предусмотришь, а хорошие идеи, ну или это так зачастую кажется, приходят только в процессе...

← →
Fantasist (2003-12-05 05:31) [23]

> да и то, и то и другое в процессе изменяются до неузнаваемости

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

← →
SkyRanger (2003-12-05 06:19) [24]

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

← →
Спрашивающий_ (2003-12-05 06:46) [25]

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

← →
SkyRanger (2003-12-05 06:53) [26]

>Спрашивающий_ (05.12.03 06:46) [25]
Такая же фигня :(

← →
Shirson (2003-12-05 07:36) [27]

От простого к сложному.
Сначала кусок кода, потом структуризация, потом хохоряшки.

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

IMHO.

← →
euru (2003-12-05 10:18) [28]

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

1. Наличие заказчика (тот, кому нужен результат этой работы) и исполнителя (тот, кто выполняет задание). Желательно (в идеале - обязательно) отсутствие подчинения какой-либо из сторон другой стороне, чтобы исключить фактор давления. Лучшим вариантом будет, если обе стороны абсолютно независимы друг от друга, чтобы областью их взаимодействия было бы только ТЗ. Худшим вариантом будет, если и заказчиком, и исполнителем будет одно лицо. В этом случае ТЗ будет эффективно только в том случае, если это лицо обладает достаточным самоконтролем, чтобы не нарушать ТЗ как в качестве заказчика, так и в качестве исполнителя. В противном случае ТЗ не нужно: все равно рано или поздно оно не будет соответствовать реальному состоянию.

2. Обязательное наличие мер штрафования, в случае нарушения одной из сторон условий ТЗ. Если таких мер не будет, то со временем какая-нибудь из сторон сможет его нарушить: заказчик может придумать новые условия, приводящие к переделыванию уже выполненной работы, а исполнитель изменить некоторые условия, которые, как он считает, смогут улучшить выполненную им работу (что чаще всего не соответствует действительности).

3. Приступать к выполнению работы нужно только после утверждения ТЗ лицами, имеющими право принимать такие решения и несущими за это ответственность.

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

← →
Anatoly Podgoretsky (2003-12-05 10:32) [29]

euru © (05.12.03 10:18) [28]
Существует более эффектиный метод, это когда TЗ и требования составляются третей стороной. Заказчик заказывает эту работу, затем выбирает исполнителя.

← →
euru (2003-12-05 11:16) [30]

>Anatoly Podgoretsky © (05.12.03 10:32) [29]
Я бы сказал, что это не более эффективный метод, это просто другой эффективный метод.
Это как и в обычной жизни: иногда эффективнее с поставщиком связываться через посредника, а иногда - и напрямую.

← →
Denis (2003-12-05 11:19) [31]

Немного не в тему, но по ней же.
Где-то полтора года назад мы начали разрабатывать программный комплекс, автоматизирующий и синхронизирующий работу основных служб завода (металургия). Разработали и утвердили проект, БД, начали писать клиентов. И тут - опаньки, выполз такой себе здоровый человеческий фактор. Логика отработана, программы работают прекрасно. Но оказалось, что та информация, которую собирали на этапе проектирования процентов на 30-40 не соответствует действительности. Потому что некий Дядя или Тетя перераспределяют, расщепляют финансовый или материальный "поток" в соответствии со СВОИМИ интересами, преследуя только им ведомые цели. Причем уследить за всеми вариациями этих "потоков" невозможно - каждый делает по своему..
Вот и получилось, что стройный изначально проект превратился в лоскутное одеяло. Получилось, что глобальная автоматизация предприятия невозможна в принципе, хотя сам завод - устойчивое, солидное предприятие.
Есть конечно и наши ошибки, но в общем и целом...

← →
euru (2003-12-05 11:31) [32]

>Denis © (05.12.03 11:19) [31]
Это больше административный фактор. Тут никакое ТЗ не поможет (если, конечно, изначально в нем не учесть все интересы этих Дядей и Тетей, но это нереально - интересы у них могут меняться по несколько раз в неделю).
Можно даже предсказать, чем все это закончится: рано или поздно наступит такое состояние, когда проще и надежнее будет считать вручную с минимальным привлечением вычислительной техники.

Почему приходится постоянно переписывать программы? Найти похожие ветки