В мозилле, опере и вебките есть событие DOMContentLoaded
А вообще во всех фреймворках есть событие, происходящие после загрузки DOM. Можете в исходном коде того же jQuery посмотреть. Правда для IE там тоже проверка через таймауты. Вот такой вот трюк: javascript.nwbox.com/IEContentLoaded/
Как альтернатива траку можно Redmine (http://www.redmine.org/) попробовать. Концептуально они близки (хотя редмайн пофункциональнее «out-of-box»), но редмайн мне удобнее кажется.
Ну немножко нечестно сравнивать скорость ООП и процедурного кода. 20% только выглядит серъёзной цифрой. В реальности основную нагрузку дадут тяжёлые вычисления (а они в веб проектах не часто бывают) и, конечно, внешние ресурсы (база данных и т.д.). Ну ещё инклуды зависимых пхп файлов дают самые значительные после БД тормоза (Zend Framework хороший пример). На фоне всего этого разница ООП и процедурного стиля само по себе не может много значить, чтобы оправдывать код, который сложнее поддерживать.
Правильно проводимый рефакторинг не может быть злом ни в одном проекте. Он может быть экономически невыгодым при определённых условиях, но пользу всё-равно приносит немалую.
Если рефакторинг проводится небольшими шагами, а проект покрыт тестами то рефаторинг
безопасен.
Ещё можно использовать какие-нибудь средства непрерывной интеграции, которые тоже косвенно могут улучшить качество, вернее облегчить контроль за ним. При автоматической сборке можно запускать автоматизированные тесты, вычислять метрики кода, проверять исходный текст на код стайл.
Есть, например, phpUnderControl облегчающий использование CruiseControl с php: www.phpundercontrol.org/about.html
Acceptance-тесты это по русски приёмочные тесты, ну и соотвественно они определяют удовлетворяет ли продукт критериям заказчика, и соответсвенно «примёт» он его или нет.
Да тут особенно не о чем читать :). Просто мне нравится термин. Его предложил Кент бек в своей книжки про лучшие практики в Smalltalk.
Это простой и короткий метод, состоящий из нескольких простых шагов (вызовы других методов или системных функций, простые циклы), находящихся на одном уровне детализации (то есть если метод начинается с вызова понятно названных функций, а потом вдруг появляется страшный цикл работающий с битами, то это неправильно, для него нужна отдельная функция).
В общем, смысл в том, что такой метод должен читаться легко и приятно, как книжка (потому что он короткий и состоит из вызовов других функций с понятными именами). Взглянув на него сразу должна быть понятна его логика работы. А все сложные моменты реализации должны быть в других функциях.
Это очень устаревший взгляд. Операторы break и continue считались «плохими» в 60-70 годах, поскольку они противоречили правилу структурного программирования об одной точке выхода из метода. В те времена в коде господствовали огромные функции и разобраться в них было сложно, особенно если у них было несколько точек выхода. В те времена это был хороший совет.
Сейчас высокоуровневый код изменился, господствует концепция Composed method, и соотвественно все функции небольшие. В таких условиях break и continue только улучшают код, поскольку помогают выделить особые граничные условия, облегчая чтение основного алгоритма. Без них проверка граничных условий пораждает кучу вложенных блоков, и код становится совсем некрасивым.
FirePHP вообще просто замечательная штука. Особенно удобно использовать, когда отлаживаешься в условиях Ajax запроса. После непродолжительного использования даже не знаю как жить без него.
Использование логических операторов вместо конструкций if — это ужасная практика.
Описанные конструкции только создают мнимую «элегантность», а на самом деле сильно снижают читаемость кода.
Никогда не понимал желания некторых программистов упаковать побольше комманд в одну строку кода.
Вам не нужно ждать шестой версии, объекты присваиваются и передаются как параметры по ссылкам уже с пятой версии. Если я, конечно, правильно понимаю и это присваение не имеет какого-то более сакраментального смысла.
Сама же его суть заключается в том, что мы гарантируем себе, что все методы интерфейса будут вести себя «правильно» независимо от того, какой конкретно производный класс используется.
Про непосредственно поведение вызываемого метода полиморфизм ничего не говорит. Полиморфизм связан только с интерфейсом. Он не дайт никаких гарантий, что, имплементируя один и тот же интерфейс, или, определяя абстрактные методы, программист не наплодит классов, функции которых имеют совершенно разное поведение, и соответсвенно объекты будут несовместимы между собой в рамках используемого интерфейса. То, что вы имеете в виду называется принцип подстановки Лисков, который и гооврит о построении концептуально правильных иерархий.
Javascript отнюдь не так прост, как многим кажется. Не стоит давать его как один из первых языков. Он серъёзно отличается от самых популярных языков (отсутсвие классов, замыкания, прототипы). Давать его вы будете, наверное, на уровне несложной манипуляции с DOM, поэтому у школьников сформируется превратное представление об этом красивом языке.
А вообще во всех фреймворках есть событие, происходящие после загрузки DOM. Можете в исходном коде того же jQuery посмотреть. Правда для IE там тоже проверка через таймауты. Вот такой вот трюк:
javascript.nwbox.com/IEContentLoaded/
www.ozon.ru/context/detail/id/2527057/
Если рефакторинг проводится небольшими шагами, а проект покрыт тестами то рефаторинг
безопасен.
sebastian-bergmann.de/archives/804-Quality-Assurance-in-PHP-Projects.html
Есть, например, phpUnderControl облегчающий использование CruiseControl с php:
www.phpundercontrol.org/about.html
Это простой и короткий метод, состоящий из нескольких простых шагов (вызовы других методов или системных функций, простые циклы), находящихся на одном уровне детализации (то есть если метод начинается с вызова понятно названных функций, а потом вдруг появляется страшный цикл работающий с битами, то это неправильно, для него нужна отдельная функция).
В общем, смысл в том, что такой метод должен читаться легко и приятно, как книжка (потому что он короткий и состоит из вызовов других функций с понятными именами). Взглянув на него сразу должна быть понятна его логика работы. А все сложные моменты реализации должны быть в других функциях.
Сейчас высокоуровневый код изменился, господствует концепция Composed method, и соотвественно все функции небольшие. В таких условиях break и continue только улучшают код, поскольку помогают выделить особые граничные условия, облегчая чтение основного алгоритма. Без них проверка граничных условий пораждает кучу вложенных блоков, и код становится совсем некрасивым.
Описанные конструкции только создают мнимую «элегантность», а на самом деле сильно снижают читаемость кода.
Никогда не понимал желания некторых программистов упаковать побольше комманд в одну строку кода.
А кстати избавить код от некрасивых проверок возвращаемого функциями значения также может паттерн Null object
en.wikipedia.org/wiki/Null_Object_pattern
А ещё можно добавить, что подобное решение известно под названием паттерна Type safe enum.
Вам не нужно ждать шестой версии, объекты присваиваются и передаются как параметры по ссылкам уже с пятой версии. Если я, конечно, правильно понимаю и это присваение не имеет какого-то более сакраментального смысла.
Про непосредственно поведение вызываемого метода полиморфизм ничего не говорит. Полиморфизм связан только с интерфейсом. Он не дайт никаких гарантий, что, имплементируя один и тот же интерфейс, или, определяя абстрактные методы, программист не наплодит классов, функции которых имеют совершенно разное поведение, и соответсвенно объекты будут несовместимы между собой в рамках используемого интерфейса. То, что вы имеете в виду называется принцип подстановки Лисков, который и гооврит о построении концептуально правильных иерархий.