|
Страница 4 из 10
5. Отсутствие экспертной оценки программыИдея добавить этот пункт появилась у меня во время подобной проверки, о которой попросил меня друг. Изучив его код, я был в состоянии сократить количество переменных на треть (что давало 400% увеличение скорости обращения к базе данных), количество строк в программе примерно вдвое, кроме того, внести ещё множество улучшений с общим результатом 1000% увеличение скорости (то есть в десять раз быстрее).
Мораль? Мораль в том, что качество, скорость и защищённость вашего кода возрастёт неимоверно, если у вас под рукой всегда есть другой опытный программист, который изучит ваш код. Другой человек заметит ошибки, о которых вы даже и не знали, найдёт более простые пути решения той или иной задачи. Кроме того, ему легче найти в вашем коде места, сильно замедляющие работу PHP или представляющие собой потенциальные "дыры".
Одна из причин небывалого успеха проекта PHP, языка с открытыми исходниками, - это то, что код видело множество людей. Тысячи людей бесплатно проверяли PHP на наличие ошибок, на потенциальные сбои, на несовместимость, на скорость работы и т. д. Таким образом, к появлению новой версии PHP, код просмотрело как минимум 2-3 очень опытных программиста.
В идеале, проекты среднего/крупного масштаба просматривают, по меньшей мере, два "приглашённых со стороны" программиста. Как и в любом другом виде творчества, свежий взгляд всегда очень кстати. Однако в большинстве случаев люд обходятся одним проверяющим.
Опытным экспертом считается тот, кто способен быстро дать оценку проделанной работе и внести конструктивные предложения как по содержанию кода, так и по реализации проекта в целом.
Нередко бывает полезно составить небольшой список вопросов к человеку, просматривающему код. Вот несколько возможных вопросов: - Какова цель кода XXX?
- Как файл XXX вписывается в остальную часть проекта?
- Каков алгоритм нейтрализации ошибок?
- Можем ли мы отследить действия среднего пользователя данной программы?
- Где пользователь программы может ошибиться?
|