понедельник, 26 августа 2013 г.

Планирование разработки

Типичный сценарий из жизни программиста: свои пожелания пользователь излагает последовательно, по мере осваивания нового функционала. В стиле “…А еще бы хотелось…” и далее новый список “хотелок”. Это широко распространенная практика, когда требовать с пользователя техническое задание бесполезно.

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

  • “Латать” текущую архитектуру “заплатками”, да “подпирать костылями”, чтобы как можно быстрее выполнить задание. Это понравится пользователю, но код превратиться в “лапшу” и с ним станет невозможно работать.
  • Переделать архитектуру, чтобы она соответствовала возросшим требованиям пользователя. Это хорошо для развития программы, но пользователь будет недоволен медленными темпами работ.

Другой вариант: заранее продумывать возможные направления развития программы и  закладывать в архитектуру максимальные возможности. И тут тоже программист сталкивается с неприятностями:

  • Если изначально делать “по уму”, то это долго и пользователь будет недоволен.
  • Более того, окажется, что 90% возможностей, заложенных в новую архитектуру, останутся невостребованными.

Спасение есть! И оно под боком. Наверняка читатель слышал такое высказывание: “Думай глобально, действуй локально”. Соблюдение этого принципа помогает избежать описанных сложностей. Как это выглядит на практике?

  1. Надо описать задачу “максимум” и сделать набросок соответствующей идеальной архитектуры программы. Это то, к чему надо будет стремиться постоянно.
  2. При написании каждого класса, функции представлять себе какое место она займет в той “воображаемой” архитектуре программы.

Т.е., программируя для пользователя текущую небольшую задачу, надо структуру кода выстраивать так, чтобы он бесшовно лег на скелет вашей идеальной архитектуры. Одна функция за другой и вот у вас уже на скелет “наросло мясо кода”. Если все функции выполнены были “с прицелом” на будущую архитектуру, то заставить работать их вместе не составит труда.

В результате:

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

Вот и получается: “Думай глобально, а действуй локально.”