21 ошибка программиста PHP. Часть 3 - Отсутствие плана

Written on . Posted in PHP

ОГЛАВЛЕНИЕ

Страница 7 из 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже представлена очень несложная диаграмма, иллюстрирующая работу приложения. Диаграмма выполнена в Microsoft Visio(r) и идеально подходит для приложения по простой отправке сообщений.

Однако когда речь заходит о более сложных проектах, всегда полезно иметь под рукой специальный инструмент для построения диаграмм. Вот три, пользующиеся наибольшим успехом: 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 форум