Dimdim SoftWare
Мастерская Dr.dimdim
ГлавнаяПоискНаписать письмо
ГлавнаяМоделированиеПроектированиеТЗРазработкаИнтерфейсСтатьиСсылкиАвтор
Главная > Управление качеством

Отсутствие плана


Из серии 21 ошибка программиста

В наше время многие проекты пишутся по принципу "главное начать, дальше само пойдёт". Например, один из моих первых проектов я написал, основываясь на 40-минутном разговоре по телефону. И хотя всё работало, риск того, что оно могло "упасть", был очень велик. Естественно, если бы я всё продумал и распланировал до того, как сел кодировать, риск появления сбоев в работе был бы намного меньше.

Например, абстракция в проекте была почти нулевая. То есть, если бы заказчик пожелал вместо MSSQL использовать MySQL, пришлось бы переписывать весь проект целиком. Кроме того, вся система защиты была сделана кое-как. Все данные хранились в "куке". Была ещё парочка недочётов, слишком незначительных, чтобы описывать их подробно...

В своей работе "The Mythical Man Month", посвящённой процессу разработки программного обеспечения, Фред Брукс описал оптимальный план работы над приложением следующим образом:

1/3 Проектирование: вы разрабатываете концепцию функционирования. Что включают в себя разные модули приложения (или части этих модулей)? Как они взаимодействуют? Что должно делать приложение в целом? Ответы на эти вопросы служат основой для всей разработки системы.

    • 1/6 Кодирование: это то, что мы все просто обожаем делать. Проводим концепцию в жизнь.
    • 1/4 Тестирование отдельных модулей и общее тестирование на ранней стадии разработки. При создании больших систем наступает такой момент: приложение ещё не готово, но уже доведено до той стадии, когда можно уже тестировать его основную функциональность.
    • 1/4 Тестирование всей системы: это последняя стадия, где мы уже имеем на руках готовое приложение: теперь его надо проверять и перепроверять, чтобы оставить в нём как можно меньше "багов".

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

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

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

Этапы разработки проекта

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

Итак, образцовый план проекта включает в себя:

    • этап изучения требований
    • этап разработки
    • этап тестирования

тап изучения требований

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

Определение пользовательских требований

Так как же выяснить, что именно ваш заказчик хочет от приложения? Станьте на время консультантом по определению потребностей заказчика и, в частности, постарайтесь получше узнать, что он собой представляет. Например, вас должно интересовать следующее:

    • Чем они занимаются?
    • Что делает их продукт лучше других (или уникальным)?
    • Как они хотели бы представить себя целевой аудитории?
    • Какие особенности/свойства их сайта помогут им достичь своего рынка?

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

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

Определение технологических требований

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

Этап разработки

Итак, спецификации готовы. На данном этапе вы должны решить, как будет реализовано приложение, что когда в нём будет происходить. Можете сделать даже несколько набросков в псевдокоде, если какие-либо места покажутся вам слишком запутанными. Другими словами, вам будет нужно:

    • смоделировать приложение
    • проиллюстрировать его
    • сделать наброски в псевдокоде

Смоделировать

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

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

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

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

Проиллюстрировать

Ниже представлена очень несложная диаграмма, иллюстрирующая работу приложения. Диаграмма выполнена в Microsoft Visio(r) и идеально подходит для приложения по простой отправке сообщений.
figure 1
Однако когда речь заходит о более сложных проектах, всегда полезно иметь под рукой специальный инструмент для построения диаграмм. Вот три, пользующиеся наибольшим успехом: Dia, Visio и UML.

Псевдокод

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

Для примера вернёмся к нашему скрипту для отправки сообщений:

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 (хотя и мог бы им быть). Миссия псевдокода - определить задачи и, возможно, подвести под них теоретическую основу. Уровень абстракции псевдокода зависит только от вас. Лично я склоняюсь в сторону менее абстрактного кода. Всё зависит от того, насколько комфортно вы чувствуете себя в программировании.

Наконец, когда вы распланировали всё приложение, вы можете начать кодировать: вам уже известны все шаги, которые будет нужно предпринять; известно и то, что в конечном счёте нужно получить.

Этап тестирования

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

Скажем честно: программисты ненавидят тестирование. Это, наверное, самое нудное и раздражающее занятие в программировании. Тестирование - это часы и дни погони за неизвестными багами, отладка, проверка всех возможных комбинаций и ситуаций, - и всё для того, чтобы убедиться, что программа в большинстве случаев работает правильно. И в довершение всего, код без багов вы всё равно НЕ ПОЛУЧИТЕ! Всё равно, что-нибудь да ускользнёт от вашего внимания. И вещи, которые (вы уверены!) не должны случиться, обязательно случаются.

Регрессивные испытания

Редко кто ограничивается одной версией приложения: большинство из них находятся на постоянном, бесконечном обновлении. Убедитесь, что при добавлении новых функций не искажается работа старых функций: функций, от которых пользователи в некоторой степени зависят. Для этого вам необходимо узнать о таком понятии как Цикл Регрессивных Испытаний. Так называют тесты, которые подтверждают, что функциональность настоящей версии продукта не будет нарушена в следующем релизе. Каждая новая версия самого проекта PHP проходит серию регрессивных испытаний и поэтому при добавлении нововведений прежняя функциональность полностью сохраняется. Таким образом, достигается не только обратная совместимость всех версий PHP (т.е. новые возможности добавляются, но старые скрипты продолжают корректно работать), но и подтверждается то, что нововведения не нарушают работу всех остальных функций (и даже никак не изменяют их поведение).

Нагрузочные испытания

Ура, ваше приложение отлично работает с одним пользователем: все вроде бы получается и происходит с огромной скоростью. А что будет, если с приложением одновременно заработают 20 пользователей? А 30? Или даже 100? Насколько быстро работает ваш проект теперь? Не стал ли выдавать странные ошибки?

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

Но это не означает, что всю работу по тестированию можно отфутболить пользователям (просто выложить всё на сайт и ждать отзывов и писем о найденных ошибках, ну вы знаете...). Проведите бета-тестирование (как описано в предыдущей главе). Кроме того, существуют специальные сервисные программы, эмулирующие большой наплыв пользователей. На ум сразу приходит AB от Apache. AB или Apache Benchmark (Анализатор Производительности Apache) делает заданное количество запросов к странице и выдаёт количество успешных запросов, количество неудавшихся запросов, среднюю скорость и т.д.

Настоятельно рекомендуется проверять ваши web-проекты с помощью AB (если, конечно, вы приняли бесконечно верное решение использовать Apache-сервер). Так вы сможете обнаружить и оптимизировать страницы, "съедающие" память, или загружающиеся слишком долго. (Также, подумайте о приобретении замечательной утилиты по кэшированию от Zend - The Zend Cache).

 

Вверх

<<Назад

Главная| ИС.. | Моделирование | Проектирование |ТД | Разработка | Интерфейс | Статьи | Ссылки | Автор
DimDim SoftWare Мастерская Dr. dimdim Copyright 2003-2004
Администратор info-system@mail.ru
Последнее обновление 26-Дек-2003