Типичный сценарий из жизни программиста: свои пожелания пользователь излагает последовательно, по мере осваивания нового функционала. В стиле “…А еще бы хотелось…” и далее новый список “хотелок”. Это широко распространенная практика, когда требовать с пользователя техническое задание бесполезно.
В чем здесь проблема для программиста? Если каждый раз решать задачу строго в рамках пожеланий пользователя, последовательно, то очень быстро возможности текущей архитектуры программы исчерпаются. Ведь программист не знал, что заранее пользователь придумает, и не рассчитывал на это. Далее программист оказывается на развилке:
- “Латать” текущую архитектуру “заплатками”, да “подпирать костылями”, чтобы как можно быстрее выполнить задание. Это понравится пользователю, но код превратиться в “лапшу” и с ним станет невозможно работать.
- Переделать архитектуру, чтобы она соответствовала возросшим требованиям пользователя. Это хорошо для развития программы, но пользователь будет недоволен медленными темпами работ.
Другой вариант: заранее продумывать возможные направления развития программы и закладывать в архитектуру максимальные возможности. И тут тоже программист сталкивается с неприятностями:
- Если изначально делать “по уму”, то это долго и пользователь будет недоволен.
- Более того, окажется, что 90% возможностей, заложенных в новую архитектуру, останутся невостребованными.
Спасение есть! И оно под боком. Наверняка читатель слышал такое высказывание: “Думай глобально, действуй локально”. Соблюдение этого принципа помогает избежать описанных сложностей. Как это выглядит на практике?
- Надо описать задачу “максимум” и сделать набросок соответствующей идеальной архитектуры программы. Это то, к чему надо будет стремиться постоянно.
- При написании каждого класса, функции представлять себе какое место она займет в той “воображаемой” архитектуре программы.
Т.е., программируя для пользователя текущую небольшую задачу, надо структуру кода выстраивать так, чтобы он бесшовно лег на скелет вашей идеальной архитектуры. Одна функция за другой и вот у вас уже на скелет “наросло мясо кода”. Если все функции выполнены были “с прицелом” на будущую архитектуру, то заставить работать их вместе не составит труда.
В результате:
- Пользователь получает новый функционал быстро и остается доволен.
- Архитектура программы не рассыпается.
- Возникает синергетический эффект при стыковке различного функционала, изначально разрозненно разработанного. Т.е. открываются новые возможности использования программы.
- В любой момент времени программа остается работающей, т.к. в ней не требуется проводить глобальных переделок. Вы всегда можете быстро выдать пользователю новый функционал, а не оправдываться в том, что вы затеяли большие переделки.
Вот и получается: “Думай глобально, а действуй локально.”
