Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

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

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

Очень важно выбрать тот реалистичный уровень организации процесса, которого вы и ваша группа сможете придерживаться. Даже если вы выполняете работу в индивидуальном порядке, желательно приучить себя к определенной самодисциплине. При работе над относительно небольшими проектами, каковыми обычно являются приложения для мобильных устройств, должен реализовываться подход, который будет привлекателен и удобен для всех участников группы. Чрезмерно детальное планирование лишает вас гибкости в тех случаях когда первоначальные планы приходится изменять. Излишне строгие пункты плана или негибкие спецификации будут просто игнорироваться. С другой стороны, отсутствие плана или слабая организация процесса проектирования приведут к неустойчивости определения продукта, который либо опустится в своем качестве до посредственного уровня, либо должен будет переделываться. Существует "золотая середина", зависящая от размера, сферы применения и степени завершения разрабатываемого продукта. Важно правильно оценить масштабы проекта и, исходя из этого, наметить реалистичную организацию работы, позволяющую достигнуть конечной цели.

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

■ Вооружитесь определенной методологией разработки. Методология — это план того, как вы будете проектировать и писать код. Оставшаяся часть настоящей главы посвящена разработке методологии для мобильных приложений.

■ Подготовьте план проекта в явном виде, оформив его в форме одного основного документа. Любой проект только выиграет, если у вас будет один основной документ, с требованиями которого согласны все участники проекта. Шаблон такого плана проекта определяется ниже.

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

Для всех проектов разработки программного обеспечения, кроме самых тривиальных, важно иметь единственный "руководящий документ", в котором определяются: 1) требования проекта и целевое назначение завершенного продукта; 2) философия проекта, 3) архитектура приложения; 4) текущее состояние работ в данном направлении; 5) план в соответствии с которым продукт будет переводиться из его текущего состояния в состояние успешного завершения. Для крупных проектов могут предусматриваться дополнительные документы, но всегда должен существовать один основной документ самого верхнего уровня, в котором определяются основные цели проекта, его нынешнее состояние и план работ. Этот документ должен быть реально действующим документом, который, по мнению всех участников группы, правильно определяет направления работы

Единственный руководящий документ, который управляет всем процессом разработки, должен включать несколько разделов:

■ Цели проекта. В этом разделе основного документа должно быть ясно указано, для чего предназначается завершенный продукт, и какая философия лежит в основе проекта.

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