Большой Воронежский Форум Mobile

Можно по-разному писать программы.

С одной стороны важен результат. Т.е. за конкретный срок сделать то, что задумано. При этом внутренности как бы роли не играют. Можно там все сделать так, как знаешь, как легче и удобнее тебе.

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

Не совсем из той оперы, но может станет понятно о чем я. Есть HTML. Есть его стандарт. Там везде твердят, что нужно избегать тэгов физического форматирования, типа <b>, <font> и делать все на стилях. Также советуют привыкать писать значения атрибутов в кавычках. Тем не менее, большинство дизайнеров (или как их там, кодеров html) пишут и <b> и <font color=xyz> и тому подобное.

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

Кроме как чисто экономические соображения, что еще может заставить поступать так, а не иначе?

Ссылки в почти в тему:
http://www.joelonsoftware.com/items/2004/04/22.html
http://www.joelonsoftware.com/articl...000000014.html
http://www.thenoodleincident.com/tut...esson/why.html [Ответ]

С. Королев говорил:
"Лучше делать медленно и хорошо, чем быстро и плохо. Потом будут помнить только то, хорошо ли было сделано, или нет, и никто не вспомнит, быстро или медленно". [Ответ]

"Правильно" нужно писать прогу если ты потом собираешься ее развивать. А если "бери и проваливай", то можно как бог на душу положит. [Ответ]

В общем-то большинство "правильных" советов - паттернов таких как MVC, Layered application, Session Facade, Business Delegate, различных рекомендаций по стилям кодирования, по структуре кода направлены на то, чтобы облегчить последующие изменения. Ибо изменения в ПО есть объективная реальность.
Проблему облегчения внесения изменений предлагается решать проверенным способом (да и наверное единственно возможным) - "разделяй и властвую". Это значит следующее:

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

Представь такую ситуацию - ты сделал сайт на 100 страниц без использования css. И тебе требуется (жесткое требование заказчика) изменить шрифт и его цвет на всем сайте. Сколько времени (дней!) займет эта замена у тебя? Сколько ошибок в верстку ты внесешь дополнительно?
А если у тебя все на css то поменяешь пару значений в css файле и все.

Alex__G добавил [date]1091186715[/date]:
Вся "правильность" как правило окупается. Чем больше проект - тем больше окупается и приносит прибыль. Руководства не дураки пишут, и модные технологии как правило есть ответ на требования разработчиков. [Ответ]

Писате прогу надо так, и только так, как того требуют душа, вдохновение и умение... [Ответ]

А ты пробовал разобраться в БОЛЬШОЙ проге, которую писал пол-года назад??! Пока ты ее пишешь вроде все понимаешь, что к чему и зачем...а проходит пол-годика и все - хрен разберешься...

Поэтому любую прогу даже в 10 строчек надо писать не как захотелось, а правильно. Если так писать оно и получается удобнее и быстрее... [Ответ]

Правильно, граждане. Прогу надо писать по правилам. Только очень сложно заметить грань, за которой 90% времени уделяешь поддержанию собственных правил, а не эффективному программированию и решению поставленных задач. [Ответ]

Писать программы надо так, чтобы ты сам понимал что же ты пишешь. Лучше написать одну качественную и удобную программу чем десяток с плохим кодом и глючно работающих. [Ответ]

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