Существует несколько секретов быстрой клиент-серверной разработки. Здесь приведено несколько уловок сообразительных менеджеров для поддержания разумных темпов разработки
Время не на стороне большинства разработчиков клиент-серверных систем.
Быстрая разработка и внедрение - вот два самых существенных преимущества клиент-серверных систем, рекламируемые сторонниками этой среды. Возможности быстро приспосабливаться к меняющейся бизнес-среде, "на лету" добавлять функции к приложениям непрерывного действия и сокращать время, требующееся для полной подготовки приложения к выпуску, показались миллионам растревоженных разработчиков и менеджеров слишком хорошими, чтобы быть правдой. И они не ошиблись.
По мнению аналитиков и умудренных опытом пользователей клиент-серверных систем, правда состоит в том, что не существует никакой "врожденной" экономии или волшебных секретов, когда речь идет о сокращении времени внедрения этой среды. Просто с годами находчивые руководители проектов и менеджеры информационных технологий усвоили несколько основных правил, уроков и хитростей своего ремесла, помогающих сэкономить одну вещь, которой, кажется, никогда не бывает достаточно: время.
"Существует несколько грозящих напрасной тратой времени ловушек, в которые могут попасть люди", - говорит Санжив Пурба, менеджер Deloitte & Touche Consulting Group (Торонто). Наиболее распространенные ошибки: попытка разрабатывать все приложения - и большие, и маленькие - одинаково, отсутствие четкого пути перехода и интегрирование в среду слишком большого числа "кусочков".
"Стремление идти в ногу с наилучшими решениями в этой области может быть самой настоящей ловушкой из-за времени, которое потребуется для проверки того, что все будет работать друг с другом", - добавляет Джон Левис, старший менеджер Deloitte & Touche.
Более разумным решением будет выбрать самые важные сегменты своей среды, например структуру СУБД или связующий компонент, и затем найти продукты, которые лучше всего дополнят их.
Разработка с нуля
Тех, кто стремится сократить время разработки, Левис и другие предупреждают об опасной тенденции пытаться повторно изобретать велосипед в каждом проекте разработки. Вместо того чтобы самим строить нестратегические части приложения, например верификацию базовых адресов или модуль планирования, Левис рекомендует купить их. Срок разработки также можно сократить, повторно использовав код, созданный при выполнении предыдущих проектов.
"Если это доступно и соответствует вашим нуждам, то будет разумнее потратить свое время на разработку стратегически важных частей приложения", - пояснил Левис. Другим моментом, провоцирующим неприятности, является попытка собрать из кусочков бо/льшую часть приложения, это наверняка породит массу проблем с интеграцией.
Билл Гэннон, вице-президент по разработкам фирмы Sentry Market Research (Уэстборо, шт. Массачусетс), добавляет, что помимо прочего следует заранее на стадии планирования разработки обсудить жизненный цикл приложения. Совет разработчикам: подумайте о росте и масштабируемости.
Гэннон рекомендует разработчикам уделить пристальное внимание архитектуре, чтобы в дальнейшем приложение можно было масштабировать, затрачивая минимальные усилия. Иначе весьма вероятно, что в будущем придется основательно перестроить приложение. "Хорошее планирование проекта нельзя заменить ничем, - говорит Левис. - Если вы не уделите этому некоторое время с самого начала, то вы будете вынуждены потратить время на то, чтобы вернуться назад и устранить все проблемы".
Умные разработчики, усвоившие эти уроки, смогут значительно сэкономить время, даже столкнувшись с иной средой разработки. Читайте следующий материал, чтобы узнать, как некоторые из ваших коллег пытаются повернуть время вспять.
Эйлин Кроули
