Разное

>Как вы находите золотую середину между объемом факторов, который учесть надо, и факторами, которые, по крайней мере, на первых парах, можно не учитывать?

все приходит с опытом.
представляете как бы было просто жить, если бы можно было знать все наперед?

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

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

А если серьезно - думай о том что будет меняться 100% или неизвестно как оно будет работать. Эти куски делай по желанию - либо нарочито примитивно, либо наоборот - очень просто, но очень гибко.

Например последний сайт, который я делал, содержит хлебные крошки. Я чуял программистским органом, что хлебные крошки на этом сайте не везде будут отражать структуру сайта. Поэтому решил не генерировать их из БД и не строить структуру сайта вообще. Просто плоская структура страниц. А хлебные крошки хранил... в виде структуры языка.

$BREAD = {     'Page-key'=>[         'urlpage'  => 'Страничка',         'urlpage2' => 'Страничка2'     ] }

Я брал ключ страницы и получал массив хэшей "урл-имя ссылки" и получал хлебные крошки вида:

<a href="urlpage">Страничка</a> - <a href="urlpage2">Страничка2</a>

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

И вот это сработало. Недели не прошло, как потребовалось убрать один уровень из хлебных крошек, но оставить его в структуре сайта.

Еще вот пример из того же сайта. Неизвестно было на какой странице что отображать в левой панели. Был один вариант - меню. Но какое? Возможно было, что для разных страниц будет отображаться разное меню. Ну и что? Я не стал заморачиваться написанием модуля для генерации меню и прочего. Я просто сделал 1 html файл с меню и включаю его туда везде, где не указано что нужно включать другой. И это очень гибко и удобно. Потому что туда я могу наверстать что угодно. Хоть каждый пукнт меню оформлять по-своему. А реализация элементарная.

Короче, нужно вычленять моменты которые не будут меняться вообще и реализовать их смело и жестко. А другие нужно делать либо очень гибко (если есть известные пределы гибкости), либо очень топорно и от того, совсем гибко.

Мое мнение.

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

Привет. Меня зовут Сергей.

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

Да, возможно: при хорошей архитектуре некоторые проблемы решаются как бы сами собой - и их уже не придется оптимизировать :)

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

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

> Проблеме лет уже 50, преждевременную оптимизацию не даром называют бичом программирования.
Вот думал, стоит относить это к преждевременной оптимизации или нет :)

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

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

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