Вообще тема интересная. По крайней мере мне. Тем более у меня есть один успешный (на мой взгляд) опыт поэтапного рефакторинга проекта, начиная с ядра и заканчивая представлением. Сам статью написать не могу, так хоть в комментах своим опытом поделюсь.
Вы еще в код модулей не заглядывали, там иногда встречается ТАКООООЕЕЕЕ :)
А вот неприятия конструкции $var += 0; я если честно не понимаю. Имхо это довольно элегантный метод приведения переменной к числовому типу в языках с нестрогой типизацией. Я правда раньше умничал используя $var = (int)$var позабыв о максимальной длине переменной типа int, которая может быть в PHP… пока не нажёгся на это ограничение длинны.
Не шутка абсолютно. Знак «черепашка» — кружочек с двумя лапками в документации на ДВК и БК совершенно официально назывался «знак денежной единицы» и заменял собой доллар во всех портированных программах. Ннапример в Бейсике БК, где доллар обозначал строковую переменную, вместо него ставилась черепашка, аналогично в операционках ДВК (как классической RT-11 так и портированных РАФОС-ах).
Например в случае связывания двух и более таблиц по комбинации полей — составной индекс в каждой из связываемых таблиц по всем полям, участвующим в связке, существенно ускорит выполнение запроса (справедливо для MySQL 5.x). Другой вопрос что такое связывание не совсем нормально, но в некоторых случаях без него не обойтись.
Смотря какого индекса и смотря какой запрос. Пример из MySQL — сколько ты не добавляй индексы к строковому полю, но если поиск осуществляется REGEXP '...' или LIKE '%...%' (именно с процентом в начале needle) производительности это не прибавит.
Имхо решается административно — делить фичи на подфичи, не допускать коммитов в принципиально разные модули в один коммит. Имхо это проще, чем потом разбираться в адской простыне, где к каждому коммиту описание в виде «в методе ххххх добавлен параметр ууууу типа zzzzz, используется в строке nnnnn blah blah blah». Основная беда таких расширенных описаний — «за деревьями не увидишь леса». Если мне что то непонятно по коммиту — сразу же уточню у автора, если что попрошу откорректировать описание.
Мне, как руководителю, например, не очень хотелось бы видеть в SVN log очень уж расширенное описание к каждому коммиту. Достаточно указание на ишью id таска/фичи/бага и краткое словесное описание того что сделано, без тонкостей реализации. Расширенное описание допустимо в таск трекере (если конечно оный применяется).
Да уж, по NetCat это факт. У нас в компании куплено несколько лицензий 2.4 Extra и 3.0, некоторые модули (управление рекламой, статистика посещений) пришлось переписывать чуть ли не на 80%. Есть даже ошибки в контроллере, из за которых например неверно работают странцы, содержащие более чем 1 компонент, баги репортилсь, реакции — ноль. В итоге — исправляем сами.
В EditPlus 2 тоже немодальный поиск-замена. Ctrl-F вылез попап, но можно выделять все что хочешь на странице, тащить в клипборд, вставлять в поля поиска. Кроме того поиск с использованием perl compatible regex - это вообще тащ (ну для тех кто в теме конечно). Аналогично с поиском-заменой. Интерфейс - выше всяческих похвал.
Натуральный нерафинированный тростниковый сахар используется в ряде рецептов, где неприменим обычный, например в имбирном бездрожжевом эле. На обычном сахаре имбирь не забродит.
Согласитесь - разделять логику и представление надо, особенно в средних и крупных проектах, над которыми работает более одного разработчика. Для небольших проектов из десятка файлов и минимальными перспективами на масштабирование можно не использовать такое разделение, но речь щас не о таких проектах конечно же. Лично я считаю, что даже при использовании чистого php - в том наборе php файлов, которые отвечают за отображение, должен быть минимум программной логики, заточенной только на отображение (совсем без нее увы не обойтись, это приведет к раздуванию набора шаблонов и неоправданному усложнению системы в целом). Кроме того надо очень жёстко определять для себя механизм передачи параметров в шаблон - чтобы у разработчика не было соблазка "по быстрому" заюзать какую нибудь переменную, помимо передачи ее через формальный механизм. Ещё один соблазн - опять же "по быстрому" вставить где нибудь в программной части echo минуя шаблоны. От всех таких проблем избавляет smarty. Логику в smarty шаблонах использовать можно, его вполне хватает для нужд верстки. Переменные в шаблоне можно использовать только те, которые переданы assign-ом, это избавляет от возможных ошибок (понадеялись на то что переменная будет вечно, забыли, выкинули ее из логики но используем в шаблоне - типичный баг в случае просто php шаблонов). Echo в модуле тоже особо не попишешь - при грамотной организации иерархии шаблонов это бессмысленно. Но все же добавлю - большинство вышеупомянутых проблем решается руководством проекта и соответствующим уровнем разработчиков, знаю на собственном опыте руководителя.
В бытностью мою студентом все преподаватели различных математик (высшей, дискретной, спецглав) говорили "комплЕксный" (в отношении чисел), если кто нитт из студентов говорил "кОмплексный" то обычно в ответ следовало что то типа "кОмплексным может быть обед, молодой человек, а числа они комплЕксные".
Молодой человек, поведение операционной системы и прикладных программ ЕЩЁ как зависит от процессора. Об этом говорит хотя бы тот факт что hardware abstration layer для разных процессоров разный. Это во первых. Проблема AMD (да и остальных, Cyrix, Transmeta) что они фактически _эмулируют_ расширенный набор команд x86, т.к. они не знают как же именно они обрабатываются внутри Intel-овского эталона). Даже в примитивном 8086 где самые сложные команды были сравниния содержимого регистров и то были разные недокументированные side-effects в выполнении команд, что уж говорить про в несколько порядков более сложные. В принципе наш спор сейчас бессмысленен - у меня дома, на работе, у моих коллег не будет в обозримом будущем систем на AMD процессорах, потому что мы считаем что им нельзя доверять. Довольно краткий но неприятный опыт работы на AMD машине у меня был во время работы в gamedev отрасли, где компания была вынуждена их использовать для разработки и тестирования - это еще раз о поведении ПО на не-Intel системах. А фанатов у AMD много, причин этому много и это тема для отдельного разговора...
Я честно говоря рад что есть большое количество людей у которых решения на процессорах AMD работают. Хотя все таки склолен думать что любители "альтернативных" платформ настолько свыклись с "нестандартным" поведением их систем, что просто не считают его глючным. Можете минусовать дальше, я не скажу что мне это совсем уж безразлично, но я привык что все любители альтернативных решений как верные цепные псы не жалея минусов и кармы набрасываются на любого, кто посмел упрекнуть в чем то объект их вожделения и любования.
А вот неприятия конструкции $var += 0; я если честно не понимаю. Имхо это довольно элегантный метод приведения переменной к числовому типу в языках с нестрогой типизацией. Я правда раньше умничал используя $var = (int)$var позабыв о максимальной длине переменной типа int, которая может быть в PHP… пока не нажёгся на это ограничение длинны.
А я предпочитаю сидеть на стуле. А считать - на калькуляторе да. И думать головой.