Советы о том, как распространять объектно-ориентированные практики [закрыто]

Я работаю в средней компании, которая имеет около 250 разработчиков. К сожалению, многие из них застряли в процедурном мышлении, и некоторые команды постоянно поставляют большие приложения Transactional Script , хотя на самом деле приложение содержит богатую логику. Они также не могут управлять проектными зависимостями и в конечном итоге получают сервисы, которые зависят от другого большого количества сервисов (чистый пример Big Ball of Mud ).

Мой вопрос: можете ли вы предложить, как распространять этот тип знаний?

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

Несколько вещей, которые я делаю, чтобы изменить это (но я либо терплю неудачу, либо изменение слишком мало)

• Проведение презентаций о принципах проектирования (SOLID, чистый код и т. Д.).
• Семинары о TDD и BDD.
• Тренерские команды (это включает использование sonar, findbugs, jdepend и других инструментов).
• IDE & Рефакторинг переговоров.

Несколько вещей, которые я думаю сделать в будущем (но я опасаюсь, что они могут быть не очень хорошими)

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

,

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

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

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

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

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

Что подводит меня к последнему пункту: ООП - отличная идея, и она хорошо работает для определенных видов проблем, но (и я говорю как из собственного опыта, так и перефразируя мнение некоторых великих умов здесь) для многих видов проблемы, это совершенно не подходит. Когда вы знакомы с ООП, а полупроцедурный код спагетти - единственная альтернатива, с которой вы знакомы, ООП, естественно, выглядит как дар небес (и в относительном смысле, это так), и вы, вероятно, приблизитесь все проблемы как гвозди для твоего ООП молотка. Это вполне естественно, и доведение ООП до (и за его пределами) своих ограничений - хороший способ развить свои навыки ООП, так что это не все отрицательно. Но, может быть (просто может быть) эта конкретная кодовая база не нуждается в ООП в конце концов. Может быть, это принесет гораздо больше пользы от процедурной архитектуры,

TL; DR: Если вы хотите что-то проповедовать, пусть это будет (платформо-независимая) хорошая практика кодирования, а не какая-то конкретная парадигма или методология.

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

Поэтому на самом деле ваш вопрос должен звучать так: «Как заставить разработчиков захотеть перейти на ОО-подходы?»

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

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

Затем начните демонстрировать, как методы ОО приведут к более легкому обслуживанию кода. Каждый в такой среде живет в страхе сделать « изменение », которое уничтожает треть производственного приложения. Инкапсуляция является ключом к предотвращению этого риска и позволяет каждому (будущему) уровню приложения поддерживать контракт с другими уровнями.

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

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

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

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

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

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

Я бы также предложил,

• Поскольку мотивация является ключом, мотивируйте их, подробно описывая, как ОО могут улучшить свою работу, особенно возможность сопровождения кода.
• Сделайте обзор кода и покажите, как провести рефакторинг, применяя композицию, наследование, полиморфизм и шаблоны.
• Представьте хороший процесс, такой как SCRUM, и привлекайте к нему разработчиков.
• Сделайте чтение книг типа «Рефакторинг» и «Рефакторинг по шаблонам» обязательным.

Я согласен с Шуво Насером. Это большое препятствие, поэтому относитесь к нему больше как к восхождению. Изучение того, как спроектировать целое приложение с использованием ООП, займет время.

1. Определите тех, кто понимает ООП, и приблизьте их к руководителям групп, тренерам, дизайнерам, рецензентам кода и т. Д.
2. Используйте существующий проект в качестве учебного пособия. Возможно, те, кто находился в # 1, были в этой команде.
3. Рефакторинг некоторых существующих проектов. Это может помочь некоторым людям построить мост между процедурным кодом и исходным кодом. Начните с основ. Они должны видеть, когда, где и почему вы используете эти принципы.
4. Вовлекайте их в занятия по дизайну с людьми, которые знают, что они делают.
5. Поместите их в команды разработчиков с кем-то, кто может предоставить руководство по проектированию, и убедитесь, что проект придерживается принципов OO (Предполагая, что причина, по которой вы хотите сделать это, в первую очередь, заключается в том, что это улучшит развитие.).

Принятие редко предшествует видению выгод. Мы говорим о сложном дизайне и не используем титульные листы отчетов TPS .

У вас уже есть хорошие идеи

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

Agile или объектно-ориентированный?

Вы упомянули некоторые Agile-технологии, такие как TDD, и некоторые более новые концепции, поэтому не будьте слишком резкими с людьми, чтобы не принять то, с чем все еще активно борются некоторые управленческие команды. Некоторые утверждают, что принимают Agile, но когда они говорят об этом, это означает, что они говорят, что означает. Организация характеризуется не командами, которые принимают решения и адаптируются, а жестким иерархическим контролем в стиле контракта.

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

Проблемы преодолеть?

Мост слишком далеко? Если вы попросите людей учиться одной мелочи в неделю, среди людей, которые участвуют в этом, произойдет много изменений. Если вы попросите их изменить все, что они знают, это будет приветствоваться немногими, трудно для многих и невозможно для других. Некоторые изменения, такие как контроль версий, локализованы. Вы переходите от того, что раньше не делали, у вас были тренировки, в которых не было ограничений памяти, кто-то проводил вас через это в первый раз, а затем повседневная работа была довольно легкой.

Другие изменения распространены. Например, выгрузка C и переключение на Java требуют значительного обучения, настройки и значительных изменений в повседневной жизни для принятия новой IDE, нового компилятора, нового языка, нового API, новой модели развертывания и т. Д. что происходит чаще всего в сочетании с пилотной программой или корпоративной реструктуризацией.

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

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

База поддержки слишком мала? Сделайте сортировку среди этих 250 человек и разделите их на три категории: готовые к объятиям, желающие учиться и не желающие учиться. У вас есть веские причины быть разочарованными людьми, которые не заинтересованы в переменах. С тем же успехом можно толкать веревку. Это напрасное усилие. Если вы чувствуете, кто поддерживает изменения, вы можете узнать, что их интересует.

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

В нем на длительный срок? До тех пор, пока вы не вырастите чемпиона, чтобы нести за собой вещи, вы должны ожидать, что вы потратите время на построение отношений. Возможно, вам придется остаться с командами, которых вы тренируете, на срок более одного месяца. Пока команда не владеет улучшенными методами для себя, вы просто полицейский технологии или методологии. Наставничество - это процесс, который может занять годы. Есть много вещей, которые ваши разработчики не хотят делать, которые вы считаете важными (я думаю, вы упомянули модульное тестирование). Это может занять некоторое время, чтобы построить общее видение ценности, которую это приносит. Я знаю это по своему опыту, потому что когда-то я выступал за инструмент покрытия кода в компании Fortune 500, которая имела отличную репутацию по качеству, но менеджеры и коллеги с осторожностью относились к этому.

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

Вы видите линию свободы? Часть внедрения «Best Practices» состоит в том, чтобы заставить людей отказаться от некоторой свободы делать вещи обычным способом. Отказ от усмотрения программиста будет более приемлемым, если вы будете искать возможности оставить много вариантов разработчикам. То, что они выбирают, определяется тем, что предписано разделением, которое мы можем назвать линией свободы. Может потребоваться аналогичное, хорошо обоснованное разделение по организационным, региональным / сайт-специфическим, групповым и личным практикам.

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

Самая важная вещь в подобных прорывах (будь то ООП или любая другая смена парадигмы, скажем, функциональное программирование или все, что выйдет в следующем году) - это ОБЗОРЫ КОДОВ И ПРОГРАММИРОВАНИЕ PEER . Сопровождайте их, приведите команды в другое русло, которое поможет им.

Мой личный путь к объектно-ориентированному программированию начался, когда какой-то случайный ассат, выполняющий обзоры кода, наказал меня за то, что я занимался модульным делом и поддерживал состояние без полного C ++ OO; думать код как

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(обратите внимание, что client_total может быть полностью избыточным, что является особенно плохо спланированным примером)

И я закончил тем, что делал это только тогда, когда более старший сотрудник просто указал на мой экран и сказал: «Посмотрите, если вы пишете одну и ту же вещь более одного раза, используйте процедуру или функцию и просто вызывайте ее снова и снова».

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

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