Основы проектирования приложения (программы)

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

Для примера возьмём системы управления контентом, так называемые CMS, Drupal, Joomla и им подобные. Проблема и преимущество таких систем управления в том, что они разрабатываются сообществом и как часто бывает, то, что набокопорил один, неразумное проектирование и пр., нельзя исправить в исходнике ибо от этого зависит вся система и дополнительные/сторонние модули и как следствие этот баг обходиться за счёт написания дополнительного куска кода.

И таким образом объём кода растёт вместе с требованиями к системным ресурсам, что в итоге неоправдывает результат получаемый на выходе, а также потраченные на него материальные и системные ресурсы.

Так например во многих многих CMS БД спроектирована далеко не самым лучшим образом, а именно подмечена манечка использовать в правах доступа не цыфры, а символы, напрмер "no" и "yes" и им подобные комбинации, вместо "1" и "0", что конечно же оказывает нагрузку как на БД так и на интерпретатор имхо цифровые значения обрабатываются быстрее нежели строковые + влияние длины строковых значений = глобальное потепление :))

Также не есть хорошо когда неоправдано присваиватся длинные имена SQL таблицам, полям, функциям, константам и переменным длина которых иногда растягивается чуть ли не на половину экрана!;( Например зачем разписывать имена полей типа "user_id", "group_id", "session_id" и т.д. если можно обойтись именованием "gid", "uid" и "sid" или зачем именовать поле "banned" (запрещенный) если можно обойтись простым "ban" (запрет), "activation" вместо "activate", "education" вместо "edu", "introtext" вместо "itext", "fulltext" вместо "ftext" и т.д.!?

Тоже самое относится к именам файлов и каталогов, что поможет сократить размеры скриптов и увеличить скорость их обработки. Нет надобности именовать каталог "include" если можно присвоить ему простое "inc" или "img" вместо "images".

Ещё одна существенная ошибка заключается в неоправданом хранении в БД тех данных которые с успехом могли бы хранится в файлах. Так например за что я не люблю CMS Drupal, так это за то, что она хранит в БД кеш и локализации, голая система с несколькими локализациями занимает около 5-ти МВ - просто "гениальное" решение! Не стоит плодить дополнительные запросы к БД для считывания основных настроек, которые можно с успехом вынести в глобальный файл конфигурации!

Как известно краткость мать таланта и всё гениальное должно быть просто! Чем больше и неоправдано наворочен код, тем больше расход системных ресурсов на его обработку и велика вероятность совершения ошибки! Поэтому лучше всего будет добавить комментарий к полю в БД, классу, функции, константе, переменной чем развозить их имена к которым постоянно будет происходить обращение/вызов! Меньше изобретать колёс и больше извлекать пользы из стандартных функций!

Некоторым это может показаться мелочью но, когда эти "мелочи" приумножаются многочисленными вызовами/обращениями, то для системы они становятся не такими уже и мелочами - это вопервых! А вовторых, зачем на эти "мелочи" тратить своё время нажимая лишние кнопки на клавиатуре!?

Так же важно при написании самого кода приложения придерживатся общепринятых стандартов "GNU Coding Standards" дабы его было удобно читать вам самим, а также другим людям которым прийдётся дорабатывать ваш код. Код написаный задним левым копытом плохо читается и как следствие замедляет разработку приложения - бывает вскроешь говно-код какого то программиста и думаешь: "А што б тебе руки повыкручивало" !;)

Существует мнение, что если ты не способен разобраться в чужом коде, то это значит, что ты плохой программист! А теперь представьте что вы водитель и вас сажают в жутко раздолбаное авто с загаженными стёклами, табуреткой вместо кресла, перепутанными педалями сцепления, тормоза и газа, веником вместо "дворников", разводным ключём вместо руля и без комментариев и вот значит вы садитесь и едете до первого столба..., хотя Вася (хозяин машины) успешно/мастерски их все обезжал - значит вы плохой водитель или всётаки это Вася мудак и машина его Гавно !?:)

Итак, схема проектирования:

  1. Сбор информации. Вам нужно знать все, что хотят пользователи, заказчик или ваше руководство от этой системы. В цивилизованном обществе принято давать разработчику техническое задание (ТЗ), как таковое, а также разделять программистов-аналитиков, проектирующих систему, от просто-программистов, пишущих код, и тем более различать администраторов и разработчиков Баз Данных. Однако нам до такого, как пешком до луны, поэтому отечественный программист обычно должен быть "все-в-одном-флаконе", а вместо ТЗ мы получаем сомнительные руководства типа: "Хочу чтоб она все делала сама, а я бы сидел в уютном кресле, чесал правую пятку, и отдавал мысленные приказания". Причем часто руководства письменные. Добро пожаловать новый пациент. На поиск приемлемого компромисса уходит определенное время. Также нелишним будет изучить конкурирующие системы, системы с похожей функциональностью, тут Google рулит.
  2. Выбор платформы. Включает в себя как выбор железа, в соответствии с планируемой нагрузкой на БД с учетом масштабируемости, так и выбор СУБД. Существует множество критериев, и для каждого они свои. Для кого-то важна цена/бесплатность продукта, для кого-то производительность.
  3. Грамотное проектирование структуры БД, с максимальным вынесением логики работы на уровень сервера БД. Ибо зачем делать лишнюю работу на клиенте, если она лучше и быстрее сделается на сервере. Плюс унифицированность системы. Чем грамотней и продуманней начальная структура БД, тем меньше геморроя мы получаем на следующих этапах. Да и расходы на поддержку существенно уменьшаются. Здесь необходим опыт. Если программист разбирается в Oracle не факт, что он также качественно и сходу разберется, например, в Interbase/Firebird. У всех свои особенности работы, а знание особенностей приходит с опытом работы. И неважно каким образом осуществляется проектирование, с использованием технических средств типа ErWin или на бумажке карандашиком, главное вcе равно в голове.
  4. Собственно проектирование и разработка интерфейса к БД. Ни один пользователь никогда не полезет в дебри утилит администрирования БД, а тем более не будет использовать SQL для получения или изменения каких-либо данных. Тут существует обратно-пропорциональная зависимость: чем универсальней программное средство, тем тяжелей оно в понимании и эксплуатации. Пользователю надо дать интерфейс, причем интерфейс довольно узкоспециализированный. Т.е. отрезать, разжевать и положить в рот необходимую ему информацию. Причем, в большинстве своем пользователи хотят чтобы все делалось при их минимальном участии, ну в крайнем случае согласны нажимать одну кнопку. Будучи главой компании, занимающейся разработкой такого программного обеспечения, или хотя бы начальником отдела кадров, я все-таки попытался бы совместить разработчика БД с программистом. Если в силу особой сложности проекта или иных технических причин это невозможно, то программист должен максимально тесно контактировать с разработчиком БД и ясно для себя представлять ее структуру. Не факт, что идеальная структура БД, которую с такой гордостью вчера представляли вам, не заставит программиста рвать и метать, поскольку будет чрезвычайно тяжело реализовываться в программе, поддерживаться и масштабироваться. При проектировании интерфейса также можно выделить несколько этапов:
    • Примерно представить как все это должно выглядеть и какую функциональность выдавать пользователям. Исходя из этого, определиться с минимально необходимым набором компонентов для реализации. Также полезно иметь наборы красивых картинок для кнопок, ибо ничто так не радует пользователей как красивые заставки и картинки.
    • Найти, скачать, купить данные компоненты.
    • Создать программу

Лично для меня в написании приложений БД есть несколько сложностей, решение которых я и хочу подсказать. Самое тяжелое это конечно рутина. Во всех пунктах нашей схемы есть элементы творчества: общение с пользователями-пациентами и с продвинутыми пользователями, поиск аналогов программы в сети, обдумывание различных функций и фишек будущей системы, анализ и подбор железа (чаще всего сводится к принципу "бери-что-есть, новое нини"), проектирование структуры БД и описание бизнес-логики, и наконец, само программирование.

Любая БД имеет много объектов внутри, таблиц, триггеров, процедур и другого барахла, о котором рядовому пользователю знать вовсе не обязательно. Исключим клинические случаи, которые недостойны гордого звания Базы данных, когда студент-недоучка делает на Access базу данных, содержащую одну таблицу со списком учащихся группы. Почти всегда в нормальной БД есть группа вспомогательных таблиц, созданных, например, для поддержания целостности данных, или для более полного охвата предметной области. Единственной функцией таких таблиц может быть просто подстановка значений в основную таблицу.

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

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

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

Из чего то универсального в области написания приложений можно выделить так называемые фреймворки (Framework), набор библиотек, в которых существует множество всяких заготовок (классов) и всяких там "хелперов", например:

  • Date Helper
  • Directory Helper
  • Download Helper
  • Email Helper
  • File Helper
  • Form Helper
  • HTML Helper

Фреймворки существуют для разных языков программирования, для C, C++, C# в Windows это .Net Framework, для РНР это Symfony и CodeIgniter, для Ruby это Ruby on Rails, для JavaScript это jQuery, Grid 960 для CSS и т.д. и т.п. но, когда у программиста кривые руки или работа идёт из-под палки, когда начальник (клиент-пациент) уже к вечеру хочет видет и требует в виде готового решения свою идею приснившуюся ему во время обеда, то ничего хорошего из этого не получится!

Главное помнить, что универсальных программистов (С + Pascal + Delphi + PHP + ...) не бывает, а также то, что программирование процесс творческий, а любое творчество требует уединения и душевного покоя, только в таких условиях можно получить качественный результат на выходе - вобщем всяческих вам баг, тьфу, тобишь благ :))

Автор: Олег Головский


Добавить комментарий


Защитный код
Обновить

6 megabytes