Як покращити підготовку студентів щодо ремонту? [зачинено]

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

Більше того, проекти, що знаходяться в обслуговуванні, становлять значну більшість загальної кількості проектів. За даними http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/ , частка проектів, що знаходяться в обслуговуванні, становить приблизно 2 / 3.

Нещодавно я натрапив на це питання , де хлопець виглядає досить здивовано, виявивши, що його робота в основному стосується обслуговування. Тоді я вирішив відкрити дискусію (французькою мовою) на головному веб-сайті французької спільноти фахівців з розробки програмного забезпечення ( http://www.developpez.com/ ). Дискусія має назву "Чи студенти достатньо навчені реальності професійного розвитку програмного забезпечення?" і в основному стосується ремонту . Було зазначено, що, принаймні у Франції, люди недостатньо готові до того, щоб зіткнутися з обслуговуванням в обох його аспектах:

• підтримувати існуючий код
• зробити реконструктивний код

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

• Як ми можемо навчити ремонту?
• Яку вправу ви б запропонували?
• Якщо ви добре пройшли навчання щодо ремонту, які саме курси ви проходили?

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

Як ми можемо навчити ремонту?

Це питання практики.

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

Отримайте якийсь проект ( проект A ), який добре виконаний, і введіть над ним декілька питань: введіть деякі помилки, добру дозу дубльованого та мертвого коду, киньте деякі функції, одиничні тести та документацію тут і там тощо. назва для цього, як Project A - пошкоджена версія .

Створіть інструмент відстеження проблем та заповніть його запитами, що відповідають певним збиткам. Встановіть основні правила та практики для процесу розробки - VCS виконує, огляди коду, QA і т.д. - розгляньте, що можна взяти з контрольного списку, що надається в тесті Joel .

• курсова робота 1.
  Виправте помилки, додайте відсутні тести, документацію та функції.
• курсова робота 2.
  Рефактор.
• курсова робота 3.
  Технічне обслуговування / вдосконалення оригінальних проектів для використання студентами наступного курсу
  - Проект А версії 2.0 та Проект А - пошкоджена версія 2.0 відповідно.
  _{Поліпшуючи пошкоджену версію, я маю на увазі нанесення кращої шкоди для неї. :)}

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

Відмова: Щойно я отримав ступінь CS. Я не вчитель.

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

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

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

Технічне обслуговування - це чеснота, а не вміння. Існує багато шляхів до створення рентабельних проектів, але немає жодної формули, яка б гарантувала їх створення.

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

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

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

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

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

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

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

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

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

Також є кілька чудових книг, які ви можете прочитати про написання чистого, бездоганного коду. Чистий код приходить на думку.

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

Хороший код = Менше технічного обслуговування та легко покращити / додати функції.

Поганий код = кошмар з обслуговування

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

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

Вправа:

1) Майте заздалегідь написаний неправильний код (наприклад) дублікат коду, метод, який говорить "обчислення іпотечного платежу", записаний у 9 місцях проекту.

Попросіть студента вдосконалити функцію "додати 1,2% доплати до всіх іпотечних платежів".

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

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

До речі, мені сподобався ваш підхід піддавати студентам ремонтопридатність програмного забезпечення.

@mattmattj: Оскільки є багато відповідей і посилання, яке я опублікував, має також кілька хороших вказівників, я додаю щось, що, сподіваюся, не є повторенням уже опублікованих відповідей.

По-перше, ОБОВ'ЯЗКОВО визначити "ремонтопридатність" - не існує жодного визначення, прийнятого всіма, - подібного до програмної архітектури. Отож виберіть той, який, на вашу думку, є найважливішим, який охоплює все, і викладіть його в 3-4 рядки максимум. Тоді ви можете поговорити про такі показники, як - час згадати / зрозуміти власний код (чи чужий), кількість WTF в хвилину / годину і т.д. сказати після цього.

Деякі вправи (це може здатися трохи збігаються з деякими відповідями, пробачте, будь ласка)

Розбийте клас на два - дайте одному розділу просте завдання кодування, яке потрібно виконати за 1-2 дні. Макс. Важкий термін. Вони повинні виконувати роботу за будь-яких обставин - керівництво - "робочий код", як вони вважають за потрібне. Для іншої групи студентів те саме завдання, але зі списком (іменування) умовних положень та деякими вказівками щодо дизайну та способів нарахування балів, якщо їх не дотримуватися. Це НЕ обман, навіть якщо це звучить так;) Тепер попросіть їх поміняти кодами, тобто група 1 зараз працює над тим, що робила група 2, і навпаки. Тепер запропонуйте змінити оригінальне призначення кодування та попросіть їх виконати в ті ж часові рамки. Зберітьсь і запитайте їх, як легко / важко це було, і відкрийте слово для дискусій / думок. Справа, безумовно, вдарить додому - великі шанси, що 50% класу були б щасливі, і це було легко, а 50% - важко. Ви можете також попросити їх попрацювати над власною справою через 3 тижні і побачити, чи зможуть вони це зробити за 1 день;)

(Хороший твіст - ви пишете той самий фрагмент коду зведеним способом і подаєте класу на модифікацію разом із їх власною)

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

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

Не соромтеся звернутися до аналогії спагеті у вищенаведеному посиланні ... сподіваюся, що це допоможе вразити деякі пункти додому. Інші відповіді допомагають заповнити прогалини і мають допомогти вам у навчанні! Удачі!