среда, 17 сентября 2008 г.

Кент Бек. Шаблоны реализации корпоративных приложений (Implementation Patterns)


Я решил, что несколько рассуждений, которые вырываются из моей души после прочтения этой книги, помогут вам избавиться от деревянных символов (рублей) и приобрести за бумажки что-то более важное. Читал я ещё английский вариант, поэтому рекомендую русский. Хотя ещё не ознакомился с качеством переводом.
Не секрет, что руководители и разработчики не против повышения качества кода. Например, руководители, чтобы уменьшить количество денег на дальнейшее развитие, а разработчики, чтобы просто гордиться результатами своей работы. Сколько бы мы не проектировали, не анализировали, не планировали, но последнюю жирную точку ставит разработчик. Он воплощает идеи многих людей в конечный код, конечный продукт. Крайне опрометчиво не замечать важности участия разработчика в процессе создания результата. А вы уверены, что жирная точка будет идеальной? А может быть это будет клякса? Я нет :)
Многие ведущие разработчики знают различные современные технологии, получают огромные зарплаты за свои знания (и это хорошо), но они создают такой код, в котором разобраться в здравом уме невозможно (а это плохо). Требуется погружать себя в медитативное состояние созерцания реализации мыслей творческого человека. Но не забывайте, каждая минута, час, сутки, которые я трачу на созерцание запутанного кода, выходит работодателю в огромные суммы. И простое исправление ошибочки становится грандиозным исследовательским трудом по лабиринтам спагетти кода и неограниченной фантазии автора исходного кода.
Почему мы вынуждены писать сложный код? Почему мы создаем код, цена которого увеличивается с каждой новой строчкой? Почему поддержка кода становится в порядки раз дороже его создания?
Ответ простой. Нас не учили писать качественный код. Мы прячемся за качественные собранные требования или детально проработанную архитектуру. А как же код? Это пустяк и не требует профессионального к себе отношения. Но были попытки многих авторов давать советы в области написания кода. Были попытки сделать уравниловку, предлагая оградить разработчика самопальной или скопированной с прошлого места работы "Конвенцией по наименованию".
Сообщество Agile-разработчиков стремилось решить эту диллему качественного кода. Ведущие эксперты максимально заостряли внимания на лучших практиках в мире программной инженерии. Они первые внедрили и продвигали идеи "Шаблонов проектирования", "Рефакторинга", TDD и др.. Постепенно гуру Agile мира приближались к тому, кто больше всего времени проводит над конечным продуктом. Конечного и настоящего создателя ПО - разработчика.
Книга "Шаблоны реализации корпоративных приложений" (Implementation Patterns) от Кента Бека заполняет самую важную нишу создания программного обеспечения. Теперь Agile покрывает весь цикл разработки и даёт отточенные мировым опытом самые современные практики. Эти практики начинаются с наименования переменной, до управления проектами разработки корпоративных приложений. Замечу, это не серебреная пуля, а всего лишь набор успешных практик и шаблонов, использование которых повышает ваш шанс на успех.
Я считаю, что книга "Шаблоны реализации" произведёт революцию в качестве кодирования. Она должна вытеснить неуклюжих бегемотов под названием "Coding and Naming Convention" (конвенции по наименованию и кодированию). Конечно, бегемотики не исчезнут полностью, но изменят масштабы, превратившись в настольные сувениры. Важность "Шаблонов реализации" в том, что качество кода определяется общим пониманием каждого разработчика единых ценностей и принципов высокопрофессионального кодирования, а не сухими структурными правилами (конвенцией) любителей излишней формализации.
Самый главный секрет создания качественного кода и проекта - это писать программы не для компьютера, а для людей. Это прописная истина, которая около сорока лет не имела реализации. Шаблоны реализации говорят как реализовать эту истину. Эта реализация состоит из трёх уровней: уровня ценностей качественного кода, уровня принципов и уровня паттернов.

Ценности качественного кода, которым мы должны следовать это:
- Коммуникация (communication) - разрабатываемый код должен явно отражать намерение создателя. Этот принцип подчёркивается и в рефакторинге.
- Простота (simplicity) - выбираются самые простые решения и алгоритмы. Не забывайте, мы пишем коммерческий код, где от нас зависит получение прибыли клиентам. И чем быстрее мы будем давать решения, тем довольней будет заказчик. И я гарантирую, что следующий проект он захочет реализовать снова с вашей командой.
- Гибкость (flexibility) - ценность, которая диктует нам выбор такого решения, которое будет самым простым, но в случае его развития наше решение с легкостью эволюционирует в нужную форму.

Эта книга будет достойным пополнением в коллекцию изданий для профессиональных разработчиков. Если вы хотите, чтобы каждый разработчик писал качественный код, то эта книга должна быть куплена из средств выделяемых на развитие персонала. Я работал в крупных компаниях, там всегда обещают, что компания гарантирует профессиональный рост своим работникам, но редко когда компании реализовывали свои обещания. Купив эту книгу каждому разработчику, вы сможете выполнить обещанное, а в отместку разработчики смогут улучшить архитектуру проекта, микродизайна и самое главное качество кода улучшится в порядки.
Материалы книги послужили мне хорошим источником для тренингов по качественному кодированию и сформировали багаж знаний, которым я делюсь во время проведения коуч-сессий.

Денис Миллер
Независимый Agile тренер и коуч.
Microsoft Certified Trainer
http://www.AgileConsulting.ru

2 комментария:

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

    ОтветитьУдалить
  2. Ну тебе тогда в сторону Agile нужно смотреть.

    Стиль разработки Agile меняет мировозрение разработчика с решения инженерных задач на бизнес value-ориентированную разработку.

    В течении тренингов этим и занимаемся :) Но требуется работа и с руководителями.

    denis miller

    ОтветитьУдалить