Отправляет email-рассылки с помощью сервиса Sendsay

Мастер программист

Подписаться Бесплатная новостная рассылка Подписчиков 18 RSS
  Октябрь 2008   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Открыта: 11-10-2008

Автор
Master Mind

Статистика

18 подписчиков
0 за неделю
←   Все выпуски   →

Мастер программист Рефакторинг


Статья 2.

Рефакторинг

 

Вернемся к мощному инструментарию, под общим названием - <Рефакторинг>. Применение этой методики напоминает мне создание скульптур. Сначала делаешь грубый набросок, главное, чтобы продвинуться вперед и что-то сделать. Потом меняешь и детализуешь часть за частью. Только в отличии от скульптуры материал у нас очень гибкий. Можно изменить реализацию целой системы, оставив интерфейсы и протоколы неизменными. И клиенты даже не узнают, что работают с другой системой.

Сущность рефакторинга в двух словах можно описать так: уменьшение сложности кода без изменения общего видимого поведения.

Как мы описывали в предыдущей статье: сложность - главная проблема программиста.

Рефакторинг состоит из набора методик. Основные - определяют направления применения изменений. Их часто называют "душком". Чем больше видимых проблем, тем больше надо менять код.

Но относиться к коду "с душком" нужно проще. Это всего лишь способ сделать какую-то вещь лучше.

Самый главный источник проблем - дублирование кода.

Как часто мы пишем прототип, и думаем: "Да, вот запущу его и удалю..."

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

Чтобы избежать этого надо <вынуть> повторяющийся код в отдельную процедуру. И если нужно переместить между классами.

Как мы сейчас увидели - рефакторинг - это довольно часто применяемы (часто неосознанно) механизм улучшения кода.

Кто из нас не любит, чтобы код был чище и красивее?

Но большинство из нас сталкиваются с тем, что менеджеры (и начальники считаются лишь с объемом кода и количеством функций) Туту все достаточно просто - если менеджер не принимает логичных доводов в пользу рефакторинга, то вам остается применять его самостоятельно, не ставя его в известность. Но инвестиции окупятся быстро.

Вы будете исправлять ошибки, и добавлять функции более быстро.

И, наконец - неопределенность пользователя со спецификацией обернется вам на руку.

Вы смело сможете сказать: <Все будет сделано в лучшем виде>. И после применения пары рефакторингов увидеть путь внедрения новой функции в систему.

А как рад будет ваш клиент, когда вы будете сдавать ему добавления быстрее, чем он ожидал.

 

Сделают одно отступление.

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

<х.х Работы по улучшению ПО будут проводиться по факту оплаты времени использования труда программиста>

Таким образом, можно построить хороший денежный поток.

 

Итак, вернемся <нашим баранам>

Рефакторинг - это революционный прорыв в разработке ПО. Да, не спорю, все его применяли много раз. Но основное отличие методики - ее надо применять до добавления и после добавления функций; до исправления ошибок и как способ увидеть путь расширения и масштабирования системы.

Как говорил одни мудрец: <Любая, самая простая вещи, становится сложной, если надо применять ее регулярно>

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

 

Пожелаю вам удачного программирования и счастливых моментов в работе и жизни.

 

С уважением, Владимир.
В избранное