Последняя третья часть описывает самые недопустимые ошибки програмирования. Последние 7 "смертельных" ошибок концептуальны в своей природе и могут являться первопричиной ошибок, описанных в части 1 и 2. Они включают грубые промахи, такие как малое время, отведенное на разработку и не просматривание полученного кода.

7. Программирование методом "Вырезал и Вставил": Неправильный Способ
Я видел, как программисты-новички копируют код, который, к примеру, проверяет верность адреса e-mail, добавляют функцию, посылающую письмо и строки, использующие значения формы для создания почтового сообщения. Они вставляют его целиком с свою программу, что приводит к работающей смеси функций, которая ненадежно отправляет форму. Хотя код будет работать в оптимальных условиях, он не пройдет никакой реальной проверки на качественность. Эта мешанина не будет:

Дорабатываемой: Код будет выглядеть, как множество отрывков, слепленных вместе. Попросите опытного программиста изменить скрипт и он предпочтет все переписать с нуля. Нечитаемый код это недорабатываемый код.
Безопасной: Вы будете помещать код других людей, не понимая полностью, что он делает. Подумайте об этом. Что, если бы в этом коде был бы фиктивный системный вызов, который бы снес все файлы с вашего диска? Более того, тот же самый код не всегда окажется одинаково безопасным на разных системах и конфигурациях. В заключение, в вашей системе будут глюки, унаследованные из чужой программы.
Быстрой: Когда код слепляют вместе, он, вероятно, окажется не особо быстрым, поскольку он не последователен - а это самая важная вещь, когда доходит до создания быстрых скриптов.
Делайте Правильно: Сначала изучите, Потом Копируйте

Внимательно изучите код другого программиста перед его копированием. Проанализируйте, что было сделано. Только если код читабелен, согласуется с логикой вашей программы и в нем нет ошибок, его можно рассматривать, как кандидат на копирование. Интегрирование кода таким образом позволит легче совместить его с остатками своего кода.

Библиотеки - это хорошо

Используйте библиотеки PHP лишь из проверенных источников, таких как PEAR, или PHP Classes Repository. Для предварительно запакованных API, хорошо использовать дополнительную функциональность, которую эти API предоставляют вашей программе. На самом деле, если вы можете найти написанные библиотеки в источниках, вызывающих доверие, обычно лучше использовать их в своем коде.

6. Нет принципов написания кода
Раньше, когда я только начал программировать, я работал над простым проектом (на Perl'е) с тремя другими программистами. Поскольку я был молодом (и не был ведущим разработчиком), мы не договорились о принципах написания кода. Каждому из нас была поручена часть проекта, мы разошлись и стали работать раздельно друг от друга. Когда мы наконец собрались, чтобы собрать законченный продукт (связать все части вместе), каждый кусок работал по разному. К примеру, один из программистов предпочитал studlyCaps стиль именования функций и переменных. Я, например, предпочитал использовать подчеркивания для выделения названий функций и переменных. У главы проекта был еще более интересный стиль программирования. По настроению он пользовался то одним, то другим способом (что привело к некоторым конфликтам названий и головной боли). Если коротко, получилась фигня. Нам понадобилось где-то на 20 часов больше, чем пришлось бы потратить, если бы мы обо все договорились заранее и договорились о принципах написания кода.

Эти принципы - способ определения структуры и внешнего вида вашего кода, они описывают методы и стиль, который вы должны использовать при разработке проекта.
Каждый проект должен следовать набору таким принципов. Они должны включать все, начиная от глобальных моментов, например, как разделить исходный код (например, файловая структура), до более специфических, таких как правила именования переменных (например, префиксы и суффиксы, написание глобальных переменных заглавными буквами). Принципы определяют общепризнанные стандарты, которым следуют все участники проекта независимо от собственного стиля программирования. Они могут служить для определения всех спорных моментов, таких как:

Какие переменные глобальные и как они обозначаются, как глобальные.
Структура документа, обозначающая какой файл должен быть помещен в lib, а какой в src каталоги.

Стиль комментариев и их написание.
Написание документации.
Длина строки.
Принципы написания кода должны быть оформлены, как официальный документ их должен придерживаться каждый программист, задействованный в проекте. Когда проект завершен, документация сохраняется на будущее, как справочная информация.

Пример Документа по принципам написания кода

Давайте создадим очень короткий документ по принципам написания кода. Мы не будем углубляться в детали, просто напишем каркас. Настоящий документ обычно достигает размера в 10-40 листов. Обратите внимание, что вам не понадобиться каждый раз писать его заново. Старый вариант всегда можно изменить по необходимости и использовать в новом проекте.

Основные параметры стиля DesignMultimedia.com

Вот пример такого документа. Как только он завершен, вы можете в одиночку сосредоточится на его реализации и не беспокоиться о несовместимости исходного кода, метода именования переменных или структуре сайта.

Вступление
Этот документ содержит следующую инфомацию:

Файловая Структура
Заголовки и Подвалы
Документация по коду
Стиль комментирования, назначение и определение комментариев
Основные моменты разработки
Именование переменных
Файловая Структура
Приложение DesignMultimedia.com имеет следующую структуру:
<Описание, как будут храниться файлы вашего приложения (например, что куда разместить), также как правила именования каждого файла.>

Объяснение структуры:
<Объясните каждый момент, чтобы не было разночтений, что именно вы имели ввиду>

Заголовки и Подвалы
Каждая страница программы должна содержать следующий заголовок:
<Здесь описывается заголовок. Он может быть чем угодно, от куска кода до простого copyright'а>
К примеру, все файлы .c и .h PHP4 имеют следующий стандартный заголовок:

<?php
/*
+------------------------------------------------------------------------+
| PHP version 4.0 |
+------------------------------------------------------------------------+
| Copyright (c) 1997, 1998, 1999, 2000 The PHP Group |
+------------------------------------------------------------------------+
| This source file is subject to version 2.02 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is |
| available at through the world-wide-web at |
| http://www.php.net/license/2_02.txt. |
| If you did not receive a copy of the PHP license and are unable |
| obtain it through the world-wide-web, please send a note to |
| Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script so we can mail you a copy immediately. |
+------------------------------------------------------------------------+
| Authors: Sterling Hughes |
+------------------------------------------------------------------------+
*/
?>

И следующий подвал:
<Здесь вы описываете стандартный подвал вашего сайта, к примеру, это можно найти в завершении всех .c и .h файлов PHP:>

<?php
/*
* Local variables:
* tab-width: 4
* c-basic-offset: 4
* End:
*/
?>

Объяснения если необходимы:
<Расскажите про размещение заголовков и подвалов, а также объясните, зачем они нужны (в зависимости от их содержания) >

Документация по Коду
<Здесь вы описываете специфику представления кода в приложении, где он пишется по стилю документации javadoc, а где по документации к XML с использованием таблиц стилей Docbook.>

Стиль комментирования
<Здесь описываются различные типы комментариев, в дополнении к описанию значений любых используемых аббревиатур или "фраз".>

Основные моменты разработки
<Здесь описывается, что можно и что нельзя делать. К примеру, не собирайте разные классы в один файл или помещайте каждый класс в отдельный файл.>

Именование Переменных
<К примеру, вы можете написать следующее:>
Этот сайт следует следующим принципам присвоения имен:
[1] Названия все классов любыми буквами.
[2] Названия всех функции строчными буквами со словами, разделенными подчеркиванием (_).
[3] Дополнительные специфические правила.

5. Не Проверяется Код
Я понял, что этот пункт надо включить в эту статью, когда провел проверку кода для моего друга. Кода я читал его код, я смог сократить число переменных на одну треть, что дало прирост скорости в 400% при обращениях к базе данных. Более того, я сократил число строк кода наполовину, что привело к ускорению на 1000% (в 10 раз). Какова мораль сей басни? Если другой опытный программист пройдется по вашему коду мелкой гребенкой, качество, скорость и безопасность кода значительно возрастет. Он сможет найти глюки, о существовании которых вы даже нег догадывались и предложит сделать что-то более простым способом. Более того, он сможет определить места, которые замедляют PHP или приводят к появлению серьезных дыр в системе безопасности.

Одна из причин, по которой PHP, как система с открытым исходным кодом, занимает значительную долю рынка, заключается в том, что другие разработчики могут изучить исходный код, пишущийся для PHP. Тысячи людей участвуют в поиске ляпов, глюков, утечек памяти, ошибок совместимости и неоптимальности. К моменту выпуска новой версии PHP, по меньшей мере 2 или 3 программиста-эксперта просмотрели исходный код.

В идеале, скрипты для средне- или крупноразмерного проекта должны проверять два разных программиста, не участвовавших в написании исходного кода. Во время написания, комментарии постороннего человека также могут оказаться полезными. Впрочем, в большинстве случаев вам должно хватить одного программиста-эксперта, проверяющего код. Квалифицированный проверяющий - это тот, кто может быстро понять работу кода и предложить конструктивные советы и по его содержанию и по исполнению.

Часто, оказывается полезным сделать небольшой вопросник для проверяющего. Вот некоторые примеры, которые я счел полезными:

Каково назначение XXX кода?
Какая связь файла XXX с остальным проектом?
Каков стандартный механизм обработки ошибок в программе?
Можем мы ли мы отследить действия стандартного пользователя, работающего с программой?
Где пользователь может столкнуться с ошибками?

4. Затыкание дыр в проекте
Вы создаете приложение и затем понимаете, что некоторые вещи были сделаны не так, как их надо было сделать. Затыкание дыр в проекте - это создание временных заплаток вместо устранения основной, более серьезной проблемы. Когда вы совершаете эту ошибку, она может привести к работающему коду с серьезными заплатками, что приведет к снижению скорости и надежности приложения.

Показатели Упущений в Проекте

Обычно, когда вы первоначально планируете свой проект, вы думаете, что выполняете все в нужном порядке. Вы можете не осознать, что идете по неправильному пути, пока не получите специфику структуры приложения (или его частей).

Вот показатели, что план проекта сбился с пути:

Чрезмерное Затыкание дыр: Вы "затыкаете дыры" в коде. "Затыкание дыр" - это решение, которое заставляет код работать, но не подходит к структуре программы. Аналогично, это может быть не оптимальным решением, но единственным, применимой в текущей структуре.
Слишком-Сложные Решения. Вы можете обнаружить, что делать сложные операции для выполнения простых действий. Посмотрите на следующий пример, использующий цикл for для вывода строки:
<?php
$GeorgeBush = "If you look at the trends, I think you'll see that most of our
imports come from other countries";

for ($idx = 0; $idx < strlen($GeorgeBush); $idx++)
{
print $GeorgeBush[$idx];
}
?>

Код сверху написан хорошо; он пробегает по строке и выводит цитату Джорджа Буша. Он правильно написан и внешне и по синтаксису. Тем не менее, той же цели можно было достичь, применив функцию print на всю строку целиком.

Исправление Упущений Проекта

Когда вы понимаете, что ваша программа была написана с ошибками или не-оптимальной структурой, шаги, необходимые для исправления этого, могут быть различными, от оставления программы такой, какая она есть, изменения частей структуры программы, или полной переработки всего приложения. В большинстве случаев, лучшим вариантом будет, если кто-нибудь не участвующий в процессе разработки программы осмотрит ее и прикинет, что нужно сделать.

Давайте рассмотрим три категории ошибок:

Мелкие упущения местного масштаба: Иногда упущения в проекте программ могут быть не критичными и могут не стоить времени и денег, которые понадобятся на переработку структуры.
Исправление: В этом случае, вы должны записать информацию о недостатке на будущее. Если в будущем будет производиться реструтуризация, вы сможет заодно произвести любые необходимые изменения. Примером такого может быть использование неверного типа структуры данных для определенной части программы (обычный массив, где больше бы подошел ассоциативный, или стека, где больше бы подошло дерево).

Значительное упущение местного масштаба: В других случаях выясняется, что нужно переделать лишь часть приложения. Например, вы пишите Операционную Систему и есть недостатки в построении окон, но весь предшествующий код вполне хорош.
Исправление: Все, что на самое деле нужно переделать - это Менеджер Окон (а не вся ОС). Это, пожалуй, самый распространенный случай, в котором часть структуры неверна, а общая структура правильна.

ЗНАЧИТЕЛЬНОЕ, глобальное упущение в проекте: В большинстве таких случаях, вся инфраструктура приложения нарушена.
Исправление: Когда инфраструктура нарушена, обычно требуется полная реорганизация кода и взаимодействия различных частей программы. Это наиболее сложный и долгий случай, и редкий проект доходит до такого состояния. Примером может быть хранение всей информации поисковой системы типа Яndex'а в текстовых файлах.

3. Исключение Пользователя из Разработки Дизайна
С вами когда-нибудь случалось такое? Вас назначили разработать и произвести корпоративное приложение для внутреннего пользования именно вашей организацией. Вы провели часы, находя и документируя требования. Вы рассчитали проект, назначили задания и сделали его. Три месяца спустя вы представляется работающую модель лишь для того, чтобы получить следующие ответы пользователей:

"Это не то, что мы хотели"
"Требования изменились"
"Хорошо, но:"
"Э: какое приложение?" (первоначальный пользователь уволился!!!!)
Финальным судьей качества приложения будут пользователи. По определению, они будут использовать ваше приложение (и пытаться обругать его разными способами). Многие программисты создают очень крутые приложения, и все равно ожидания пользователей не оправдываются. Обычно это связано с одним или более "непониманиями".

Непонимания возникают, когда вы отстраняется пользователя от разработки структуры. Когда создается приложения, всегда думайте о них. Всегда держите в голове, чего хотят они и как приложение должно достичь поставленной цели. Наиболее важно, впрочем, уделять время на общение с ними:

Постоянный опрос мнения пользователей
Создание Прототипов
Бета Тестирование
Постоянный Опрос Мнения Пользователей

Как написал Бенджамин Франклин в альманахе Бедного Ричарда "Стежок, сделанный вовремя, спасает девятерых." (Прим.пер.- Не силен я в американской истории) Тоже верно и для приложений. Если вы хотите поберечь свое время, постоянно спрашивайте их мнения. Чего они хотят? Чего нет? Что улучшит приложение?

Создание Прототипов

Создание Прототипов - это структурированный процесс тестирования и требования мнения пользователя по мере разработки приложения. Тестирование веб-приложения во время его разработки также важно. Начните с определение тестеров.

Проверяйте, насколько приложение соответствует требованиям пользователей, но также требуйте и прямых личных мнений. Многие программисты совершают ошибку - тестирует приложение только, когда оно завершено. Это рецепт провала, поскольку то, чего хочет пользователь, и то, чего сделает вы, скорее всего, будет различаться. Более того, пользователи лучше поймут, чего они хотят, когда увидят ясный пример. В кратце, нельзя заставить пользователя сразу четко сформулировать свои требования, хотя каждый программист и хочет этого.

Я предлагаю, чтобы вы определили путевые столбы по ходу разработки приложения. В конце каждого такого отрезка обдумайте следующие моменты:

Приносит пользу пользователю работа, которую вы проделали?
Чтобы они хотели видеть в приложении того, что еще не реализовано?
Будут ли они использовать добавленную вами функциональность?
Что дает приложение?
Ваши улучшения сделали все лучше или хуже?
Когда нужно размещать путевые столбы?

Обычно грамотно размещать путевые столбы в те моменты, когда завершена очередная значительная часть пользовательского интерфейса. К примеру, я часто размещаю первый столб когда завершается работа над интерфейсом приложения. Это момент, когда дизайнеры примерно представляют, как будет выглядеть сайт. Следующую проверку нужно будет провести, когда будет готова простейшая демо-версия, демонстрирующая функциональность приложения.

Таким образом, я проверю пользовательский интерфейс по завершению каждого модуля или компонента приложения. Модуль или компонент может быть, например, системы управления пользователями приложения, или, возможно, поисковой системой сайта. В эти моменты я возьму мою первоначальную группу тестеров (а также тех новых, которые имеют особое отношение к объекту тестирования) и предложу ответить на поставленные вопросы. Это позволяет увидеть "общий" эффект изменений, которые вы только что сделали. Вы можете определить дополнительные наборы вопрос на каждый "путевой столб" или использовать стандартный набор.

Бета Тестирование

Это обычная форма тестирования, которая похожа на создание прототипов, но обычно оставляется на время окончания работ. Выбранные клиенты получают возможность проверить приложение и сообщить свои комментарии и отчеты об ошибках. Оно не такое интерактивное, как создание прототипов, и должно быть произведено как можно раньше. Тем не менее, это необходимый шаг, который разработчики обязательно должны произвести перед выпуском приложения.

2. Отступление от Технического Задания
Во многие проектах сейчас все заканчиваются тем, что ТЗ пишется по мере работы. К примеру, в одном из моих первых проектов, я создал приложение, основанное на 40-минутном телефонном разговоре. Хотя все получилось нормально, риск провала был намного больше, чем если бы я потратил время на то, чтобы спланировать и представить себе приложение до начала его разработки. К примеру, когда я сделал проект, ничего не было абстрактным. Это означает, что если бы пользователь захотел использовать MySQL вместо MSSQL, приложение пришлось бы переписывать. Более того, там была туча ляпов безопасности. Я хранил все данные приложения в cookie. Было еще несколько недостатков - некоторые слишком обидные, чтобы их упоминать.

Когда Фред Брукс описал процесс разработки приложения в Месяце Мифического Человека (The Mythical Man Month), он определил следующее оптимальное расписание:

1/3 Планирование: Здесь вы описываете, как ваше приложение будет работать, каковы различные компоненты (и компоненты компонентов) приложения и как они будут связаны. Что должно делать приложение? Ответив на эти фундаментальные вопросы вы положите базис планирования приложения.
1/6 Кодирование: То, что мы любим делать. Превращать дизайн в реальность.
1/4 Тестирование компонентов и раннее тестирование системы: При разработке больших приложений наступает момент, когда, хотя приложение еще не готово, но базовую функциональность уже можно проверить.
1/4 Тестирование всех компонентов вместе: Это заключительная стадия, когда у нас уже есть законченное приложение, теперь его нужно проверять и перепроверять, чтобы убедиться, что оно настолько избавлено от глюков, насколько возможно.
Сегодня нам повезет, если хотя бы 1/6 времени, отведенного на разработку проекта, уйдет на планирование. Программисты начнут работать прямо сейчас, вообще не представляя, какие требования у задачи, в чем суть проблемы, и как ее решить. Этот сценарий аналогичен написанию статьи без плана.
Кодирование должно быть процессом размещения того, что уже было спланировано. Множество программистов (и я один из них) пишут все приложение (или наиболее сложные моменты приложения) перед тем, как начать непосредственное написание на настоящем языке программирования, таком, как PHP.

Обратите внимание: Процесс планирования внешнего вида, особенностей и функциональных требований приложения известен, как информационная архитектура.

Стадии Проекта

О стадиях проектного плана может быть сказано много. К примеру, можно упомянуть отладку, моделирование, разработку проекта и планирование времени. Тем не менее, я только набросаю простенький план. Обычный План Проекта включает:

Стадия Анализа Требований
Стадия разработки Дизайна Программы
Стадия Тестирования
Стадия Анализа Требований

Первая часть планирования проекта - создание анализа требований: здесь вы точно определяет, что требуется. Вы точно решает, что должна делать программа и как она будет работать. Это одна из важнейших стадий в разработке веб-приложения.

Определение Требований Пользователя
Так каким же образом вы определяете, что именно пользователь хочет от приложения? Возьмите на себя роль консультанта, чтобы определить их потребности, а также получше узнать своих клиентов. К примеру:

Что они делают?
Что делает их продукт лучшим (или уникальным)?
Как они представляют себя потребителям?
Как особенности сайта позволят им выйти на рынок?
Последнее, как я выяснил, отличный способ сделать проект больше. Можете ли вы найти, что можно добавить к функциональности сайта, чтобы помочь им? Если да, вы получить довольного заказчика, а заодно и больший (и высокоопличиваемый) проект.

Методы исследования могут варьироваться от обзора рынка или вопросников до разговора с ключевыми людьми компании. Каким бы способом вы не воспользовались для сбора нужно информации, крайне важно подумать о вышеупомянутых пунктах.

Определение Технологических Требований
Здесь вы решаете, какие технологии будут нужны вашему приложению и как вы будете использовать их. Первостепенный вопрос, есть ли у нас возможности и знаем ли мы, как выполнить требования пользователя? Технологии может включать, к примеру, языки программирования (в дополнение к PHP), ОС, скорость сервера, скорость коннекта, и т.д.

Стадия разработки Дизайна Программы
У вас есть спецификация. Теперь вы решаете, как написать приложение, что когда произходи; может даже пишите какой-то псевдо-код если встретите сложные для выполнения места. Вкратце, вам понадобиться:

Смоделировать
Проиллюстрировать
Набросать псевдо-код
Смоделировать. Перед написанием приложения, поймите, как разные части приложения будут взаимодействовать друг с другом.

К примеру, давайте разработаем простую форму. Мы разрабатываем возможные действия, которые может произвести пользовать при обращении к простому скрпиту, рассылающему почту. При самом абстрактом подходе, возможны два варианта. Они отослали данные формы, или нет. Если они не отослали данные формы, мы должны показать первую страницу формы. В противном случае, мы должны (еще раз) сделать одну из следующих двух вещей.

Если посланные данные верны (подразумевается, что они удовлетворяют всем критериям истинных данных), то отослать письмо пользователю и выдать сообщение с благодарностью.
В противном случае выдать сообщение об ошибки и дать возможность исправить ошибку.
Проиллюстрировать Их . Очень простая диаграмма показывает работу диаграммы, описанную выше. Она была сделана в Microsoft Visio и прекрасно подходит для простого приложения, отсылающего письмо.

Впрочем, когда доходить до более сложных приложений, часто используется специализированный инструмент, который позволит создать диаграмму ваших приложений. Чтобы получить информацию об этих популярных инструментах, посетите Dia, Visio, и UML.

Набросать Псевдо Код. Написание псевдо кода, реального кода, описывающего работу приложения, но не работающего - распространенная практика, используемая многими разработчиками. Обычно к ней прибегают, когда они упираются во что-то сложное или не могут полностью понять как впишется в систему какой-то определенный аспект приложения. Я также обнаружил, что псевдо код полезен при описании интерфейса приложения, когда его будут использовать другие программисты. Это помогает понять, что нужно сделать, и какой для этого самый простой способ.

К примеру, псевдо код снизу может быть набросан при разработке нашего простого приложения, отсылающего письмо.

<?php
if (formSubmitted)
{
valid_name(name) or error() and output_form();
valid_email(email) or error() and output_form();
valid_message(message) or error() and output_form();

message = name & email;

send_mail(email, message);

print "Thank you for your feedback";
}
else
{
print "Send us feedback";
formelement(name);
formelement(email);
formelement(message);
}
?>

Псевдо код выше определяет общую структуру скрипта и показывает все требуемые специфические элементы. Код не должен быть верным работающим PHP кодом (хотя и может быть). Что должен делать псевдо код - это определять различные задачи приложения и, возможно, теорию за этими задачами. Уровень абстракции вашего псевдо кода зависит только от вам. Лично я предпочитаю писать менее абстрактный вид псевдо кода, чем большинство людей. Все зависит от того, насколько вы знакомы с программированием. Наконец, когда вы спланировали все приложение, вы можете начать кодировать ваше приложение зная все шаги, которые нужно будет предпринять, и представляя, что именно вы будете создавать.

Стадия Тестирования

Одна из важнейших стадии разработки приложения, про которую часто забывают это стадия (заключительного) тестирования. Часто из-за за давления по времени и/или со стороны менеджеров, эту стадию сокращают или пропускают, а приложение считают завершенным.

Будем честны, программисты ненавидят тестирование. Это, пожалуй, одна из наиболее скучных и раздражающих стадий разработки приложения. Часто она состоит из погонь за диким гусем (? - wild goose chases), часов обезглючивания, и тестирования различных вариантов, чтобы понять, будет ли код работать в различных условиях. Если вы пропустите это, у вас никогда не будет обезглюченного кода! Вы всегда можете быть уверены, что что-то пропустили. Знаете, то, про что вы думаете, что оно никогда не случится, все равно произойдет.

Тестирование на Возвращение к предыдущему Состоянию. Приложения бесконечно дорабатываются. Важно быть уверенным, что когда вы добавляете новые функции, вы не сломаете то, что было раньше и то, на что рассчитывают пользователи. Такми образом, вы должны проделать Тестирование на Возвращение к предыдущему Состоянию. Это набор тестов, который дает уверенность, что имеющаяся функциональность не сломается с учетом произведенных изменений.

PHP сам по себе тестируется таким образом, чтобы убедиться что все функции и процессы, верно работающие в нем, когда вы проведете изменения в нем, не затронут другую часть PHP. Это помогает PHP не только поддерживать обратную совместимость (например, когда добавляются новые функции, старые скрипты продолжают работать). Но также это способ убедиться, что ни одно из совершенных изменений не испортит функции (не просто изменит их поведение).

Стресс-Тесты. ОК, значит ваше приложение отлично работает с 1 пользователем - все идет прекрасно и с огромной скоростью. Но что, если ваше приложение начнут использовать 20 пользователей? 30 пользователей? Или даже 100 пользователей одновременно? Как быстро тогда оно будет работать? Не начнет ли оно внезапно выдавать непонятные ошибки? Когда вы тестируете приложение вы обязательно провести стресс-тест, чтобы убедиться, что приложение выдержит большие нагрузки и будет нормально работать в различных условиях.

Это не означает, что не нужно отдать программу на тестирование пользователю. Выдайте ему ее и ждите отчетов об ошибках и мнений. Проведите бета тест (как упоминается в предыдущей ошибке). Более того, если специальные автоматические инструменты, эмулирующие тестирование толпой пользователей. Первый приходящий в голову, это Apache's ab tool. AB, или Apache Benchmark произведет определенное число запросов к вашей Web-странице и вернет число удачных, неудачных, среднее время ожидания и т.д. Я советую использовать AB на всех ваших веб-страницах (в случае, если вы примите бесконечно мудрое решение пользоваться апачем). Так вы сможете обнаружить и оптимизировать страницы, которые требуют уйму памяти или просто очень долго грузятся. (Также, подумайте о покупке мощной утилиты кэширования скриптов - The Zend's Cache).

1. Потеря Во Времени
Ошибка номер один, с которой сталкиваются все программисты - это потеряться во времени. Посмотрите правде в глаза, мы все оптимисты. Для нас нормально предполагать, что проект займет ровно столько времени, сколько он должен. Мы не учитываем все, что может пойти наперекосяк. К примеру, нам не приходит в голову, что выполнение чего-то может вызвать у нас проблемы.

Так, мы должны пресекать свои чувства и подредактировать цифры. Как правило, каждый раз, когда я беру проект, я учитываю каждый фактор, который приходит мне в голову и рассчитываю требуемое время, а затем удваиваю его. Компании редко бывают недовольны, когда вы завершаете проект раньше времени (и совсем наоборот обстоят дела, когда вы не укладываетесь в сроки). Такой метод позволяет получить достаточно времени, чтобы сделать работу качественно и не опоздать. Но, честно говоря, он зависит от точности моего первоначального расчета.

Каждый программист недооценивает (или в редких случаях, переоценивает) время, необходимое для завершения проекта на определенную величину, для меня в два раза, для кого-то в полтора, для третьего в три. Задача в том, чтобы выяснить среднюю ошибку в расчете требуемого времени и потом постоянно вносить эту поправку во все проекты.

Недостаточно время на разработку проекта приводит к следующим эффектам (которые я слишком хорошо знаю):

Вы забудете о своей личной жизни до тех пор, пока не сдадите проект. Все дни и ночи будут посвящены программированию, оставляя мало времени на отдых (не то, чтобы было неинтересно программировать, но программировать без остановки - это ужасно).
Вас будут торопить, что означает, что вы потратите меньше времени на создание надежного, читабельного и быстрого кода. Вместо этого, вы сосредоточитесь лишь на том, чтобы успеть ко времени сдачи проекта.
Вы можете пропустить важнейшие шаги, такие как проверка или отладка кода, которые, в свою очередь, рассердят клиентов и приведут к еще большей работе.
Вам придется бросать на проект больше людей, что будет стоить больших денег, а может и не помочь (по законам Брука, особенно на больших проектах).
Всегда уделяйте достаточно времени для долгого процесса отладки (такого же долгого, или даже более длинного, чем процесс разработки сам по себе), и 1/3 всего времени проекта на планирование. Это две важнейшие стадии производственного процесса.

SterlingWonderfulToyland.com: Пример

Давайте рассмотрим пример сайта, SterlingWonderfulToyland.com. Этот простой электронный магазин предназначен для продажи ограниченного выбора Playstation 2 и Видео Игр по демпинговым ценам. Владелец Джон Гиусепп также хочет убедить клиентов зайти в настоящий магазин и купить товары в нем. Таким образом, в сайте есть два основных раздела:

Интернет-магазин.
Обычная часть сайта - указывает, где находится магазин и что он собой представляет.
Во время планирования, я придумаю несколько вариантов каждого раздела веб-сайта. Я затем совмещу время на разработку той и другой, добавлю неделю на то, чтобы страстить их, а затем сообщу клиенту время на разработку всего сайта (словно он бы состоял из одного объединенного раздела).

Обычная часть сайта

Для простой, не-динамической части сайта, я прикину, сколько времени понадобиться на разработку каждой страницы в таком редакторе, как Macromedia Dreamweaver. Поскольку ничего динамического там нет, я умножу полученное время на количество страниц (с учетом того, что дизайн уже разработан). Затем я удвою результат (моя ошибка обычно 2x). Для этого раздела не нужно составлять никаких серьезных планов (как только пришла диаграмма, как должна выглядеть страница, все, что останется - слепить ее в Dreamweaver).

Обратите Внимание: Учтите дополнительные 1/3 времени от разработки приложения на планирование. К примеру, если вы ожидаете, что на разработку системы проверки кредитной карты понадобиться 9 дней, добавьте дополнительные 2-3 дня.

Интернет-Магазин

Для Интернет-магазина расчет времени произвести сложнее. Проще всего разбить задачу на меньшие подзадачи (такие, как транзакцией кредитных карточек, заказ через один клик, информация о продуктах, управление продуктами и т.д.), и рассчитать различные компоненты не учитывая поправку на ошибку. Я затем совмещу их, умножу результат на величину ошибки. После этого я добавлю дополнительные 1/3 времени, которое мне понадобиться на завершение проекта, на тестирование и исправление глюков, чтобы быть уверенным, что клиент получит работающий продукт.

Обратите Внимание: Положите дополнительные 1/3 времени на планирование, как в статической части сайта.

Продажа времени сдачи проекта

Даже если вы можете примерно установить время сдачи проекта, ваш босс или клиент может не быть так доволен этим, как вы. Иногда слишком оттянутое время сдачи может сорвать сделку. Конкуренты предложат сделать все быстрее за время, за которое они это сделать не смогут, и просто опоздают со сдачей проекта. Так как можно установить время сдачи такое, чтобы босс/клиент были бы довольны и в которое вы бы уложились?

Вот здесь вам предстоит продать себя и время сдачи проекта. Что вы можете предложить клиенту? Почему требуемое вам время правдоподобное и такое, какое оно есть? Представьте себе, что вы - клиент, и подумайте, чего вы ожидаете от потенциального программиста?