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