мысли вслух
- From
- Akzhan Abdulin (2:5040/55.46)
- To
- All ()
- Date
- 1998-07-21T11:12:06Z
- Area
- RU.TRADESOFT
Здравствуй, All!
Многие люди часто пытаются найти одну и ту же дорогу. Может быть, мою?
В процессе проектирования, исполнения и эксплуатации различных информационных систем (ИС) постепенно приходишь к выводу, что количество хороших вариаций достаточно мало, все делается из ограниченного числа давно известных функциональных блоков (идей, моделей, правил).
Здесь часть из моих стандартов:
0) Подумайте, не ихобретаете ли Вы новый велосипед? Часто лучше взять готовую расширяемую систему, и расширить ее необходимым образом. Пример - 1С: Торговля.
а) Проектируя ИС, сперва необходимо поставить тех. задание, и обязать заказчика к тому, что оно останется неизменным до выполнения (с соответствующим пени за изменение). Выбор платформы, выбор СУБД, выбор клиентской части - практически мало важны, если не делать грубых ошибок.
б) Проектируя ИС, не думайте о клиентском месте слишком много - не более 15-20% времени. Ибо это - самая гибкая часть, и по возможности - наиболее легкая. Нанимая программистов для выполнения клиентов, обычно абсолютно неважно, на чем они его делают, главное - что получится.
в) Проектируя модель данных, подумайте - возможно, что каждую строку информации необходимо сохранить для дальнейшей аналитики. Операция физического удаления инфромации обычно должна отсутствовать как класс.
г) Подумайте, насколько верно Вы выбрали первичные ключи. Обычно наилучшим выбором являются первичные ключи-суррогаты (искусственные ключи). Ни в коем случае не принимайте за первичный ключ имя, название, номер обьекта из внешнего мира. Они имеют тенденцию к изменению и к появлению дубликатов - real life.
д) Возможно, что операция модификации данных также должна отсутствовать как класс, вместо этого нужно закрывать период актуальности и текущей версии, и создавать новую версию, базирующуюся на старой.
е) Если количество пользователей больше одного, или выполняются сложные выборки, постарайтесь не использовать desktop databases.
ж) Операция SELECT 2+2 FROM MyTable является нетипичной для реляционной БД. Увидев такое, подумайте о создании промежуточного слоя бизнес-логики.
з) Многозвенные приложения в настоящее время (недоделанные среды разработки приложений) имеет смысл проектировать или для крупных организаций, или для Intranet/Internet/медленных линий связи, или в качестве коммерческой (не заказной) системы. Иначе это можно рассматривать как погоню за рюшечками.
и) Не беритесь доводить чужую систему до ума, если она не документирована. В этом случае обычно проще создать новую. Документируйте весь процесс - это помогает сдавать продукты точно в срок.
й) Если есть возможность, не проектируете систему на коленке. Используйте CASE-инструментарий. Не менее 30% всего времени на разработку ИС уходит именно на ее проектирование (бизнес-процессы / модель данных).
к) Наймите команду тестеров, не показывайте заказчику сырых продуктов. В этом случае на проблемные места надо ставить заглушки.
л) Заказчик не видит кухни, он оценивает продукт сперва по одежке.
Все выше сказанное - IMHO.
* Crossposted in RU.DELPHI.DB
* Crossposted in FE.SOFTWARE.DEVELOPMENT
* Crossposted in FE.DATABASE
* Crossposted in FE.DELPHI
* Crossposted in SU.DBMS
* Crossposted in RU.TRADESOFT
С уважением,
Akzhan
--- Раскpепощение ---
* Origin: <<<Citizen Job Center voice(7-421-2)35-43-47 ASU >>> (2:5040/55.46)