Если вы заказываете приложения сторонним разработчикам, обязательным условием является оценка его качества после того, как разработчик передал код вам. Вы можете быть гуру в программном обеспечении, тогда эта статья не для вас, но если вам нужно несколько простых пунктов, оценки качества, то вот они:
1. Программа пытается заново изобретать объектную модель или «исправить» языковые особенности.
Попробуйте поискать класс под названием Object. Если Вам это удалось, то это верный признак того, что автор пытается изобрести объектную модель (чаще всего это происходит от отсутствия ее понимания). Можно смело предположить, что его «исправления» не остановятся на достигнутом. Наш совет при встрече с таким разработчиком: отключайте телефон и меняйте почтовый адрес.
2. Код использует пользовательские глобальные переменные.
Поиск по коду слов «global» или "$GLOBALS" может открыть Вам много интересного, например такого:
global $database, $my, $mainframe;
Если вы сможете мне сказать, что содержится в последних двух переменных, вы либо близко знакомы с автором строк программы, откуда взят этот пример, либо псих. Вероятность второго варианта увеличивается, если вы сможете сказать, какое значение примет любая из этих переменных в разные периоды времени. Короче, верный признак того, что к вам попал дерьмокод — глобальные переменные.
3. Смешанный html и SQL.
Если вы сможете найти в одном из файлов проекта HTML-код вместе с SQL, знайте — перед вами дерьмовый код.
4. Класс слишком много знает.
Найдите по размеру файла самый большой класс в проекте. Посмотрите на его название. Можете вы по нему однозначно определить, что он делает? Посмотрите на методы этого класса. Связаны они общим смыслом? Если вы на оба вопроса однозначно ответили «нет» убегайте с криками от такого разработчика.
5. Слишком много публичных или статичных свойств.
Если вы находите много свойств, объявленных как «public static», умножьте свои выводы о дерьмокодовости на три.
6. Несколько уровней наследования.
От более чем двух уровней наследования в PHP-коде следует бежать, как от чумы. Конечно, на любое правило может быть исключение. Например, если вы не сомневаетесь, что ваши разработчики так же профессиональны, как разработчики ZendFramework. Если вы найдете правильное использование больше чем двух уровней наследования в менее известных (никому не известных) продуктах — вам крупно повезло.
7. Авторы пытаются использовать патерны проектирования.
Чтобы выяснить, было ли у авторов такое желание — поищите по словам «factory», «decorator», «strategy». Если вы что-то нашли, задача усложняется: теперь вам нужен кто-то, кто действительно ЗНАЕТ, как должны быть реализованы шаблоны. Если вам удалось найти такого человека и он сказал, что все в порядке, и авторы не просто «пытались использовать», а использовали патерны. То вам очень повезло. Перед вами — не дерьмокод.
8. Смена error-level приводит к повышенной разговорчивости приложения.
Поищите по файлам «error_level». При удаче, замените значение на E_STRICT. Если в приложении после этого появилось куча ворнингов (warning) и нотайсов (notice), то знакомьтесь — дерьмокод.
9. В структуре директорий есть папка под названием «core».
В ней, как правило, собраны «общие» для приложения части. Несмотря на такое благое намерение, чаще всего оно является признаком дерьмокода.
10. Приложение использует свой собственный шаблонизатор.
Опасайтесь, это действительно страшно. Вот эти ребята, которые снова и снова будут изобретать колесо. Перед вами дерьмокод. Проигнорируйте это предупреждение и вскоре они изобретут для вас цикл for.
Статья является вольным переводом этой.
UPD. Похоже тон статьи показался слишком резким присяжным заседателям, минусующим в карму. Прошу прошения, дорогие мои (за кадром смех Регины Дубовицкой).
UPD2. Пожалуй, имеет смысл прислушаться к рекомендации и уйти от категоричности. Слишком бурно на нее все реагируют. Ну и добавить «потому что» к каждому пункту.
1. Программа пытается заново изобретать объектную модель или «исправить» языковые особенности.
Попробуйте поискать класс под названием Object. Если Вам это удалось, то это верный признак того, что автор пытается изобрести объектную модель (чаще всего это происходит от отсутствия ее понимания). Можно смело предположить, что его «исправления» не остановятся на достигнутом. Наш совет при встрече с таким разработчиком: отключайте телефон и меняйте почтовый адрес.
2. Код использует пользовательские глобальные переменные.
Поиск по коду слов «global» или "$GLOBALS" может открыть Вам много интересного, например такого:
global $database, $my, $mainframe;
Если вы сможете мне сказать, что содержится в последних двух переменных, вы либо близко знакомы с автором строк программы, откуда взят этот пример, либо псих. Вероятность второго варианта увеличивается, если вы сможете сказать, какое значение примет любая из этих переменных в разные периоды времени. Короче, верный признак того, что к вам попал дерьмокод — глобальные переменные.
3. Смешанный html и SQL.
Если вы сможете найти в одном из файлов проекта HTML-код вместе с SQL, знайте — перед вами дерьмовый код.
4. Класс слишком много знает.
Найдите по размеру файла самый большой класс в проекте. Посмотрите на его название. Можете вы по нему однозначно определить, что он делает? Посмотрите на методы этого класса. Связаны они общим смыслом? Если вы на оба вопроса однозначно ответили «нет» убегайте с криками от такого разработчика.
5. Слишком много публичных или статичных свойств.
Если вы находите много свойств, объявленных как «public static», умножьте свои выводы о дерьмокодовости на три.
6. Несколько уровней наследования.
От более чем двух уровней наследования в PHP-коде следует бежать, как от чумы. Конечно, на любое правило может быть исключение. Например, если вы не сомневаетесь, что ваши разработчики так же профессиональны, как разработчики ZendFramework. Если вы найдете правильное использование больше чем двух уровней наследования в менее известных (никому не известных) продуктах — вам крупно повезло.
7. Авторы пытаются использовать патерны проектирования.
Чтобы выяснить, было ли у авторов такое желание — поищите по словам «factory», «decorator», «strategy». Если вы что-то нашли, задача усложняется: теперь вам нужен кто-то, кто действительно ЗНАЕТ, как должны быть реализованы шаблоны. Если вам удалось найти такого человека и он сказал, что все в порядке, и авторы не просто «пытались использовать», а использовали патерны. То вам очень повезло. Перед вами — не дерьмокод.
8. Смена error-level приводит к повышенной разговорчивости приложения.
Поищите по файлам «error_level». При удаче, замените значение на E_STRICT. Если в приложении после этого появилось куча ворнингов (warning) и нотайсов (notice), то знакомьтесь — дерьмокод.
9. В структуре директорий есть папка под названием «core».
В ней, как правило, собраны «общие» для приложения части. Несмотря на такое благое намерение, чаще всего оно является признаком дерьмокода.
10. Приложение использует свой собственный шаблонизатор.
Опасайтесь, это действительно страшно. Вот эти ребята, которые снова и снова будут изобретать колесо. Перед вами дерьмокод. Проигнорируйте это предупреждение и вскоре они изобретут для вас цикл for.
Статья является вольным переводом этой.
UPD. Похоже тон статьи показался слишком резким присяжным заседателям, минусующим в карму. Прошу прошения, дорогие мои (за кадром смех Регины Дубовицкой).
UPD2. Пожалуй, имеет смысл прислушаться к рекомендации и уйти от категоричности. Слишком бурно на нее все реагируют. Ну и добавить «потому что» к каждому пункту.
