Проведення презентації про "стиль коду та моделі дизайну" [закрито]

Моя компанія (невелика, приблизно 40 людей у ​​трьох офісах) періодично проводить "майстер-класи для розробників" в Інтернеті, де один із розробників проводить презентацію з якоїсь технічної теми. Це не обов'язково стосується нашої роботи, а просто допомогти кожному вдосконалити свої вміння та розуміння.

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

Моя перша ідея - використовувати власний код як приклад, щоб привести додому пункт "будь ласка, застосуйте це до своєї роботи". Але тема настільки широка.

Деякі речі, неправильні з нашим кодом (PHP), включають:

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

Я хочу, щоб ця річ була максимально корисною, не звучаючи поблажливих моїх колег. Тож на які аспекти "стилю" варто звернути увагу, і які дизайнерські моделі можуть бути найбільш корисними для пояснення?

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

У кращому випадку ви збираєтесь засмутити свою команду, вказуючи пальцем на них перед усіма. І те, що ви отримаєте замість "Ви дійсно відкрили мені очі", це "WTF перед усіма? Ви навіть подивилися на власний код dumbA .."

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

Щоб відповісти на початкові запитання: Все, що стосується читаності: функції з якомога меншими аргументами, OOP, довга і детальна назва змінної та коментарі.

Я здогадуюсь, що у вас є система відстеження помилок у вашій організації. Вийміть декілька найневісніших помилок із сховища, перегляньте звіт про виправлення причин цього (глобальні змінні зіпсувались, функції робили речі, які вони не призначалися тощо), а потім обговоріть стилі кодування та шаблони дизайну, які могли б допомогти уникнути цієї проблеми. .

Це трохи важкої роботи, щоб зробити цю частину досліджень, але це найсильніший спосіб загнати додому те, що ви представляєте, справді працює .

"досі тонни глобальних функцій".

Спочатку отримайте список. Повний ідеал.

По-друге, розділіть цей список на потенційні класи. Подумайте про визначення класів.

Під час фактичної презентації виберіть найбільший, найбільш очевидний, найяскравіший, найменш спірний потенційний клас, який би поглинув купу цих глобальних функцій.

Як тема дискусії. У вас є ідея. Вам потрібно досягти консенсусу. І відповідати на питання по дорозі. І допоможіть їм зрозуміти, чому це єдиний клас об’єктів, а не купа випадкових функцій, що діляться глобальними.

Потім, обговоривши це до того моменту, коли вони розуміють саме цей клас і як ви дійшли до вмісту….

Увімкніть проектор.

Почніть вводити текст.

Зафіксуйте код. Перезапустіть свої тести.

Дизайн шаблонів та стиль кодування та робота. Все в одному пакеті.

за 1 годину ви будете робити добре, щоб переконатися в мінімальному розумінні основ.

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

Пропоновані теми:

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

  • Дзен OOP в PHP: Кодування зі стилем!
  • 5 причин, чому глобальні функції викликають рак коду
  • Що в імені? Конвенції та здоровий глузд (або не змушуйте мене думати!)

• Шаблони дизайну

  • Деякі зразки GoF у нашому кодексі; Вступ
  • Візерунки - це просто інструменти, а не Євангеліє
  • Найкраще і найгірше: візерунки та анти-візерунки

зауважте: глобальних конфігурацій іноді важко уникнути; один простий засіб - поставити всі посилання на них у функції init

застереження: Я знаю лише PHP, щоб зламати Wordpress і виконувати незначні виправлення веб-сайтів

Про використання реального коду у презентації - якщо він використовується, використовуйте його лише для добрих прикладів, НІКОЛИ не поганих прикладів. Для поганого складіть свій власний або знайдіть його в Інтернеті. Це дозволяє вашим колегам пишатися своєю роботою та отримувати визнання за неї. Це також уникає сценарію, коли вони можуть бути злі / збентежені за те, що вони виділяються як поганий розробник.

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

Покажіть їм поганий код, запитайте, що в ньому поганого. Нехай вони подумають про це на секунду, а потім дайте їм "Аааааа!" моменту, показуючи їм крайовий кейс (проблема Fencepost, можливо?) або випадок, коли їхній поганий дизайн руйнує все інше.

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

Зробіть це смішним способом залучати їх, а не нудьгувати або змушувати їх займати оборонні позиції (хто цей хлопець, щоб нас критикувати?); наприклад, покажіть їм функцію, яка виконує свою роботу в два кроки (1- введіть ім'я дружини) (2 - збережіть його у глобальному масштабі) (3-введіть ім'я чоловіка та візьміть ім'я дружини з глобального для зберігання в базі даних) (4- сміх як погана синхронізація призводить до того, що у чоловіків є "нові" дружини), як жарт пропонують написати функцію статистики розлучень.

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

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