Как преподавать Шаблоны разработки команде

Code review.

Forcing them to use design patterns will likely lead to overuse and anti-patterns.

1. Take a problem well known to them.

2. Identify the pattern that can solve the problem most effectively. And solve the problem with the pattern and also implement the solution and show them working.

3. Don't tell them yet about the Design Pattern. Repeat this for about 3-4 problems. Later tell them what you did was solved a problem with design pattern - Name each pattern and give them reference books or URL pointers for their further study and research.

I confess that I've never tried to do this, so I'm drawing on general observations about how teams can improve their skills and the quality of what they produce. How do people learn? Reading, experimenting, imitating, mentoring ... even listening to lectures! I think you'll need to apply several different approaches. I'd say that two things are critical: exposure to ideas and feedback.

Hence for a team I would do the following:

1). Design and code reviews. The reviews not to be conducted only by seniour people. Have juniors also read code and comment. Ideally they learn too.

2). Design wokrshops toss problems around and come up with alternative solutions.

In both cases I'm less concerned with Design Patterns (the book) than in inculcating a spirit of evaluation and consideration for design. What's good? What's bad? What forces and compromises lead to this particular solution. When is good enough enough?

Don't force them to read the book, this won't work.

Simply refactor their code using a design pattern, and show them why this is easier.

Also give them some time to learn the new way of working.

Получите пару копий «Шаблоны проектирования Head First» и попросите людей прочитать их. Это интересный способ узнать о шаблонах.

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

Я бы рекомендовал один или два раза в месяц устраивать часовой обед из коричневой корзины. Расскажите о концепции паттерна и покажите несколько примеров программирования.

На каждой лекции я говорю о Золотом Молоте - научитесь использовать каждый паттерн и ЗАБЛОКИРУЙТЕ их в своем наборе инструментов, пока они вам не понадобятся!

Моя любимая техника - это то, что я называю «Театром паттернов». Каждый из моих учеников исследует шаблон и пишет сценарий на 2-3 страницы, который использует шаблон в реальном мире. Например, я представляю театр о поездке Пола Ревира, чтобы описать Observer. (Роберт Ньюман видит британца и зажигает фонари; Пол Ревер видит фонари и начинает скакать и кричать; некоторые горожане слышат его и прячутся; некоторые горожане слышат его и берут оружие - отдельные пары стимул / реакция) Ничего в кинотеатрах не упоминается о программировании; все они о том, чтобы изложить концепции, прежде чем я начну программную часть лекции.

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

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

Reading the book only gives you 'insight' into Design Patterns and I believe that that light only clicks after having implemented some patterns. It may be advisable in your situation to set up a peer review and observe finished code to see where a pattern may have alleviated a particular problem.

Since you didn't mention a source, I will assume that you are talking about the GOF book and if so, I also assume that you are working in a statically typed language such as C++, Java, C#, etc.. If not, then many of the patterns may not even apply to your problem domain and will probably sideline your efforts for team adaptation. For example, Visitor (double dispatch) is not used in dynamically bound languages, Scala has Singleton baked in, etc..

Проповедь не работает. Подавать пример.

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

Когда кто-то задает вам вопрос о дизайне, не называйте его просто названием шаблона, возьмите книгу, откройте ее, укажите на соответствующую часть шаблона и скажите что-то вроде «О, послушайте это так, я не уверен, но я думаю, что это может быть полезно ".

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

Даже если вы запомнили все шаблоны, откройте книгу.

Когда кто-то задает вам вопрос о дизайне, не просто называйте им название шаблона, возьмите книгу, откройте ее на шаблоне, укажите на соответствующую часть шаблона и скажите что-то вроде «О, послушайте да, я не уверен, но думаю, что это может быть полезно ".

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

Даже если вы запомнили все шаблоны, откройте книгу.

Когда кто-то задает вам вопрос о дизайне, не просто называйте им название шаблона, возьмите книгу, откройте ее на шаблоне, укажите на соответствующую часть шаблона и скажите что-то вроде «О, послушайте да, я не уверен, но думаю, что это может быть полезно ".

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