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

Некоторые из проблем, с которыми приходится сталкиваться разработчикам программного обеспечения, можно с полными основаниями охарактеризовать как "временные трудности". С появлением более совершенных инструментальных средств разработки острота этих проблем может снизиться. Хорошим примером временных трудностей могут служить проблемы отладки. За многие годы был достигнут огромный прогресс в предоставлении разработчикам средств отладки приложений в процессе их выполнения. Это привело к кардинальным изменениям самого процесса отладки, благодаря чему эта ранее трудоемкая задача, которая решалась при помощи столь разнородного инструментария, как карандаш и бумага, низкоуровневые средства наподобие дизассемблеров или отладочная печать, и требовала немалой доли интуиции, в настоящее время превратилась в весьма естественную интерактивную составную часть любого набора современных средств разработки. Среди разработчиков, пользующихся современным инструментарием, сегодня вряд ли найдутся такие, кто считает отладку отдельным видом деятельности, отличным от проектирования и написания кода. Сейчас все это объединено в рамках одного естественного процесса разработки программного обеспечения, и разработчики плавно переключаются с одного вида деятельности на другой. Еще не так давно наблюдалась явно иная картина, и, по крайней мере, в отношении программного обеспечения, выполняющегося на устройствах, об этом можно говорить со всей определенностью. Представляя собой когда-то сложнейшую проблему, отладка кода в наши дни значительно упростилась. То были временные трудности, и улучшение технологий позволило с ними справиться

Ко второй категории проблем разработки программного обеспечения относятся те, которые лучше всего описываются выражением "неотъемлемые трудности". Проблемы этого рода уходят корнями в саму сердцевину процесса разработки программ.

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

Неплохим примером ситуаций, которым свойственны неизбежные сложности, является проектирование алгоритмов. Современные объектно-ориентированные языки разработки значительно облегчили инкапсуляцию и организацию кода, но они не в состоянии упростить или автоматизировать собственно проектирование алгоритмов. Несомненно, наличие богатого набора базовых классов, предлагаемых современными программными средами, способствует написанию эффективных алгоритмов, однако проектирование принципиально новых алгоритмов по-прежнему является нелегкой задачей, которая, по всей вероятности, будет оставаться таковой и в ближайшем обозримом будущем. Это имеет место по той простой причине, что алгоритмам, в силу самой их природы, свойственна специфичность, обусловленная конкретикой задачи, и не существует никаких известных общих способов, позволяющих преобразовать ваши намерения в алгоритм, который наилучшим образом соответствовал бы намеченным целям; в подобных случаях автоматизация возможна лишь при условии значительного сужения масштаба задачи и создания специального инструментария для ее решения. То же самое можно сказать и о написании многопоточного кода. Применение усовершенствованных инструментальных средств, языков программирования и библиотек, несомненно, облегчает эту работу и позволяет решать задачи во многих случаях, допускающих строгое описание; вместе с тем, создать универсальную машину, способную разрезáть общие задачи на параллельные ломтики, нам никак не удается. Подобные проблемы являются неизбежными, и их решение требует тщательного проектирования и применения подходящей методологии.

Современные языки программирования и средства графического проектирования позволяют разработчикам полнее реализовывать свои намерения, но не устраняют необходимости в приобретении устойчивых навыков конструирования алгоритмов. Без таких навыков невозможно обойтись при построении критических систем, определяющих поведение и эффективность программного обеспечения. Лучшее, что смогла предложить современная технология программирования, — это упаковка сложных алгоритмов в повторно используемые компоненты и каркасы, и предоставление возможности моделирования взаимодействия компонентов между собой. При таком подходе проектирование критических систем, представляющих общий интерес, могут осуществлять высококлассные специалисты, а остальные разработчики получают возможность повторно использовать эти системы. Проектирование компонентов может быть упрощено, а взаимодействие между авторами компонентов и клиентами сделано более прозрачным за счет применения таких технологий моделирования, как UML (Unified Modeling Language — унифицированный язык моделирования) и панели графического проектирования, но эти технологии не в состоянии снять проблемы внутренней сложности, свойственные процессу проектирования эффективных алгоритмов. Постоянное совершенствование инструментальных средств будет способствовать преодолению временных трудностей, однако трудности постоянного характера, обусловленные самой природой алгоритмов, будут всегда оставаться.

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

Сначала выделяются критические компоненты и алгоритмы, требующие проектирования, кодирования и тестирования на самом высоком профессиональном уровне. Вся основная функциональность предоставляется разрабатываемым приложениям высокоуровневым и, как правило, менее строго тестируемым кодом, который использует эти компоненты. Причина успеха компонентов как методологии заключается в том, что она дает возможность разложить приложение на отдельные части. Это позволяет инженерам-программистам, специалистам в области архитектуры систем и руководителям идентифицировать наиболее трудные моменты алгоритмизации и сосредоточить на них внимание. Как и в случае любой другой методологии, при разбиении приложения на компоненты необходимо действовать осмотрительно, стараясь не переусердствовать в этом. Если выделять в отдельные компоненты все, что только возможно, исходя из того ложного допущения, что увеличение количества компонент, на которые разбивается проект, приводит к лучшему техническому решению, то в результате этого чрезмерно усложнятся интерфейсы между многочисленными компонентами различно] о рода. Средства моделирования могут оказать вам помощь в визуализации этих взаимодействий, но от сложной картины вам все равно не избавиться. Чрезмерное обилие необязательных компонентов размывает тот острый фокус, который, в соответствии с самим ее назначением, должна обеспечивать разбивка на компоненты для достижения высоких эксплуатационных характеристик критических элементов. Любая методология должна применяться осмотрительно и с отчетливым пониманием тех целей, которые при этом преследуются. Методология полезна лишь тогда, когда можно измерить ее эффективность при решении данной задачи, ибо только в этом случае вы будете уверены в том, что реализуются все ее преимущества.