Проведение презентации на тему «Стиль кода и шаблоны дизайна» [закрыто]

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

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

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

Некоторые вещи не так с нашим кодом (PHP) включают в себя:

• Минимальный ОО. В последнее время он улучшается, но все еще существуют тонны глобальных функций. Мне нужно время, чтобы найти вещи.
• Глобальный конфиг (мнение, я думаю). Вы можете найти $ GLOBALS ['blah'], разбросанный почти в каждом файле.
• Непоследовательный стиль скобок. Звучит минимально, но это фактически привело к тому, что синтаксическая ошибка была выдвинута пять дней назад, которая по-прежнему не исправлялась по состоянию на вчерашний день.
• Неэффективные конструкции. Я смог сделать некоторые базовые улучшения, которые сократили время работы в некоторых областях на 70%.

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

Будьте предельно осторожны, используя реальный код в презентации перед людьми, которые пишут этот код.

В лучшем случае вы расстроите свою команду, указав пальцем на них перед всеми. И вместо «Вы действительно открыли мне глаза» вы получите «WTF перед всеми? Вы даже смотрели на свой собственный код dumbA…».

Возьмите реальный пример, но измените его или убедитесь, что его нельзя отследить тому, кто его написал. Или берите реальный код от знакомых вам людей, но также берите немного своего ВАШЕГО старого кода и играйте в шутку и шутите с этими людьми в стиле standup :)

Чтобы ответить на ваши первоначальные вопросы: все, что касается читабельности: функции с как можно меньшим количеством аргументов, ООП, длинное и подробное имя переменной и комментарии.

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

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

"все еще тонны глобальных функций".

Сначала получите список. Полный идеал.

Во-вторых, разделите этот список на потенциальные классы. Подумайте об определениях классов.

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

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

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

Включите проектор.

Начните печатать.

Исправьте код. Перезапустите свои юнит-тесты.

Шаблоны проектирования, стиль кодирования и работа выполняются. Все в одной упаковке.

через 1 час у вас все получится, чтобы получить представление об основах.

Я предлагаю выбрать 3 вещи из каждой темы и сосредоточиться на них; ограничьте слайды 5-7 словами, чтобы люди слушали вас, а не читали слайды; используйте выдуманные примеры (чтобы не наступать на пальцы людей, как советуют другие); дать ссылки в конце (URL лучше книг) в качестве упражнения для тех, кто хочет узнать больше; опубликуйте свои слайды в интранете после презентации. (Что касается проблемы с фигурными скобками, используйте средство форматирования кода; это, вероятно, не стоит сражаться)

Предлагаемые темы:

• Стиль кодирования

  • Дзен ООП в PHP: кодирование со стилем!
  • 5 причин, почему глобальные функции вызывают рак кода
  • Что в имени? Соглашения и здравый смысл (или не заставляй меня думать!)

• Шаблоны проектирования

  • Некоторые паттерны GoF в нашем коде; введение
  • Шаблоны - это всего лишь инструменты, а не Евангелие
  • Лучшие и худшие: паттерны и анти-паттерны

примечание: глобальные конфиги иногда трудно избежать; Одно простое средство - поместить все ссылки на них в функцию init.

предостережение: я знаю только достаточно PHP, чтобы сломать WordPress и выполнить незначительные исправления веб-сайта

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

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

Покажите им плохой код, спросите, что в этом плохого. Дайте им подумать об этом на секунду, а затем дайте им «А-а-а-а-а!» момент, показывая им крайний случай (проблема Fencepost, возможно?) или случай, в котором их плохой дизайн разрушает все остальное.

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

Сделайте это забавным способом, чтобы привлечь их, вместо того, чтобы скучать или заставлять их занимать оборонительные позиции (кто этот парень, чтобы критиковать нас?); например, покажите им функцию, которая выполняет свою работу в два этапа (1 - введите имя жены) (2 - сохраните его в глобальном) (3 - введите имя мужа и перенесите имя жены из глобального, чтобы сохранить в базе данных) (4 - смеяться как плохая синхронизация приводит к тому, что у мужчин появляются «новые» жены), так как в шутку предлагают написать функцию статистики разводов.

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

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