Если вы заказываете приложения у сторонних разработчиков, то оценка их качества обязательна после того, как разработчик передаст вам код. Возможно вы гуру ПО, тогда эта статья не для вас, но если вам нужны несколько простых пунктов, оценок качества, то вот они: 1. Программа пытается заново изобрести объектную модель или «исправить» особенности языка.
Попробуйте найти класс под названием Object. Если вам это удалось, то это верный признак того, что автор пытается изобрести объектную модель (чаще всего это происходит из-за непонимания ее).
Можно с уверенностью предположить, что его «исправления» на этом не остановятся.
Наш совет при встрече с таким разработчиком: выключите телефон и смените адрес электронной почты.
2. В коде используются пользовательские глобальные переменные.
Поиск по словам «global» или «$GLOBALS» может выявить много интересного, например следующее: глобальная база данных $, $my, $mainframe; Если вы можете сказать мне, что содержится в двух последних переменных, то вы либо близко знакомы с автором строк программы, из которой взят этот пример, либо вы сумасшедший.
Вероятность второго варианта возрастает, если вы можете сказать, какое значение примет любая из этих переменных в разные периоды времени.
Короче говоря, верный признак того, что вы получили хреновый код — это глобальные переменные.
3. Смешанный HTML и SQL. Если вы можете найти HTML-код вместе с SQL в одном из файлов проекта, вы знаете, что это дрянной код. 4. Класс знает слишком много.
Найдите самый большой класс в проекте по размеру файла.
Посмотрите на его название.
Можете ли вы по нему четко определить, что он делает? Посмотрите на методы этого класса.
Связаны ли они общим смыслом? Если на оба вопроса вы ответили «нет», бегите с криком от такого застройщика.
5. Слишком много общедоступных или статических свойств.
Если вы обнаружите множество свойств, объявленных как «public static», умножьте свои выводы о дрянном коде на три.
6. Несколько уровней наследования.
Более двух уровней наследования в PHP-коде следует избегать как чумы.
Конечно, из любого правила может быть исключение.
Например, если вы не сомневаетесь, что ваши разработчики такие же профессионалы, как и разработчики ZendFramework. Если вы обнаружите правильное использование более двух уровней наследования в менее известных (неизвестных) продуктах, вам повезло.
7. Авторы стараются использовать шаблоны проектирования.
Чтобы узнать, было ли такое желание у авторов, выполните поиск по словам «фабрика», «декоратор», «стратегия».
Как только вы что-то нашли, задача усложняется: теперь вам нужен кто-то, кто действительно ЗНАЕТ, как следует реализовать шаблоны.
Если вам удалось найти такого человека и он сказал, что все в порядке, и авторы не просто «попробовали использовать», а использовали шаблоны.
Тогда вам очень повезло.
Это не дерьмовый код. 8. Изменение уровня ошибок приводит к повышению разговорчивости приложения.
Найдите в файлах «error_level».
В случае успеха замените значение на E_STRICT. Если после этого в приложении появится куча предупреждений и уведомлений, значит встречайте дерьмовый код. 9. В структуре каталогов есть папка «core».
Как правило, он содержит «общие» для приложения части.
Несмотря на это хорошее намерение, чаще всего это признак дрянного кода.
10. Приложение использует собственный шаблонизатор.
Осторожно, это действительно страшно.
Это ребята, которые будут изобретать велосипед снова и снова.
Вот дерьмовый код. Не обращайте внимания на это предупреждение, и вскоре для вас придумают цикл for. Статья представляет собой вольный перевод этот .
УПД.
Похоже, тон статьи показался присяжным заседателям «карма-минус» слишком резким.
Прошу прощения, мои дорогие (Регина Дубовицкая смеется за кадром).
УПД2. Возможно, имеет смысл прислушаться к рекомендациям и не быть категоричными.
Все слишком бурно на нее реагируют. Ну и добавьте к каждому пункту «потому что».
Теги: #php #дерьмовый код #Чулан
-
Встреча Startuppers В Вашем Городе
19 Oct, 24 -
Adobe Лайтрум 1.3
19 Oct, 24
