Ключевые принципы проектирования кода

05 Октября 2012 Программирование
5 0

Сегодня хочу поговорить о дизайне кода. То, что он должен быть красивым - это понятно, но для этого не обязательно звать Артемия Лебедева, потому что в случае с кодом он просто не поможет. Когда начинаете новый проект и начинаете задумываться о том, какие классы вам нужны и как все должно работать, нужно всегда держать в голове мысль о том, что код и требования к нему могут меняться.

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

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

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

Я прекрасно понимаю, что гибкость далеко не всегда то же самое, что и скорость и если забыть о гибкости, то больше раздора для оптимизации и создания более быстрого кода. Но в большинстве случаев все же гибкость побеждает над скоростью. Если у вас проект, в котором скорость важнее всего, тогда другое дело.

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

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

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

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

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

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

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым