Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Прислали на работе проект на доработку, мало того предыдущий программер не знает про разделение логики и представления, дак еще и такие штуки на каждом шагу встречаются
Дорогой дневничок:
Это пиздец полный //простите вырвалось
Вчера попросили тоже помочь с выводом иерархического дерева и построение урлов, код обалденный: sql и html в одной функции и между ними php. На вопрос почему это не выкинуто: "Так работает же, почти как надо". И ведь не объяснить, что цена (читай время) поддержки очень дорога.
Спс, выговорился.
пхп-шники думают иначе:
"если оно работает - лучше его не трогать" ->
"оптимизировать стоит только тот скрипт, который тормозит"
даже в мануалах пхп такое встречалось...
так что для них: "почти работает" == "работает", а если "работает" - лучше не трогать...
экономить ресурсы надо по мере написания кода, и не в ущерб понятности. А то давайте тогда вообще не применять ООП, не отделять логику от представления - ведь это сбережет пару наносекунд!
об оптимизации надо думать и при проектировании(а хороший ли это подход?) и при написании кода(а не делаю ли я тут лишнюю работу?) и собственно при решении проблем(почему тут так страшно тормозит?) - а не как советуют, что якобы можно сначала писать левой ногой, а уж потом кидаться оптимизировать.
при этом на том самом последнем этапе нужно В ПЕРВУЮ очередь оптимизировать узкие места, а уж ПОТОМ подумать, а не рефакторнуть ли и остальное и еще улучшить и читаемость и производительность )
Почти все известные мне сайты на PHP тормозили из за базы данных. Один заход на сайт -- 50 запросов к бд.
Джойнят шесть таблиц внешним объединением по полю varchar(255). Отсюда и тормоза.
Надо бить по рукам, приговаривая "нормальная форма".
Тогда и тормозов не будет.
Я не говорю о фейсбуках, я говорю о обычном говносайте на обычной говноцмс типа umi.
wordpress mu + штук 10 плагинов + кастомная тема... как то делал по 1000 запросов к базе на страницу.
проект не мой, просто коллега дизайнер бегал с воплями "тормозииит сайт"
зачем там 1000 запросов? даже 50 зачастую это много
"тормозииит сайт" - и это при одном запросе у него кончается терпелка? ) ггг, значит 100 юзеров просто положат его ) а я уж молчу про 1000, 10 000....
не с абсолютного. Если менять алгоритм - то да, большую часть придется переделать заново. Но даже когда пишешь код "с нуля", стоит держать перед глазами старый код - некоторые фрагменты, если они не плохи, можно не стыдять скопипастить в новую реализацию - это сэкономит время и силы, и уменьшит шансы наделать еще больше бугов
как ни странно, но в большей части пхп проектов достаточно чуть ли не полуавтоматически заменить быдлокод на нормальный, потому что уже программируем -сколько, лет 40,да? - а грабли все те же. Если не помогает - то скорей всего ошибка уже этапа проектирования, и нужно уже переделывать саму идеологию - обычно это помогает.
ну это скорей рекомендация, правила хорошего тона - что бы замена не слишком отличалась от таймса.
и кстати, это не такой уж редкий шрифт, что бы его не было, это же не какой нить century gothic
Это пиздец полный //простите вырвалось
Вчера попросили тоже помочь с выводом иерархического дерева и построение урлов, код обалденный: sql и html в одной функции и между ними php. На вопрос почему это не выкинуто: "Так работает же, почти как надо". И ведь не объяснить, что цена (читай время) поддержки очень дорога.
Спс, выговорился.
"если оно работает - лучше его не трогать" ->
"оптимизировать стоит только тот скрипт, который тормозит"
даже в мануалах пхп такое встречалось...
так что для них: "почти работает" == "работает", а если "работает" - лучше не трогать...
"оптимизировать стоит только тот скрипт, который тормозит" - ну на спичках, как говорится, экономить точно не стоит
- почему бы не экономить ресурсы, которые и так тратятся беспощадно ?(
об оптимизации надо думать и при проектировании(а хороший ли это подход?) и при написании кода(а не делаю ли я тут лишнюю работу?) и собственно при решении проблем(почему тут так страшно тормозит?) - а не как советуют, что якобы можно сначала писать левой ногой, а уж потом кидаться оптимизировать.
при этом на том самом последнем этапе нужно В ПЕРВУЮ очередь оптимизировать узкие места, а уж ПОТОМ подумать, а не рефакторнуть ли и остальное и еще улучшить и читаемость и производительность )
как то так
Джойнят шесть таблиц внешним объединением по полю varchar(255). Отсюда и тормоза.
Надо бить по рукам, приговаривая "нормальная форма".
Тогда и тормозов не будет.
Я не говорю о фейсбуках, я говорю о обычном говносайте на обычной говноцмс типа umi.
проект не мой, просто коллега дизайнер бегал с воплями "тормозииит сайт"
"тормозииит сайт" - и это при одном запросе у него кончается терпелка? ) ггг, значит 100 юзеров просто положат его ) а я уж молчу про 1000, 10 000....
семантичко
не факт, что на компе у человека будет times new roman.
и кстати, это не такой уж редкий шрифт, что бы его не было, это же не какой нить century gothic
но мы вообще-то о семантике