Как улучшить обучение студентов в отношении ремонтопригодности? [закрыто]

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

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

Недавно я столкнулся с этим вопросом , когда парень выглядит довольно удивленным, обнаружив, что его работа в основном связана с техническим обслуживанием. Затем я решил открыть дискуссию (по-французски) на главном сайте французского сообщества специалистов по разработке программного обеспечения ( http://www.developpez.com/ ). Дискуссия называется «Достаточно ли хорошо обучены студенты в реальности профессиональной разработки программного обеспечения?» и в основном о ремонтопригодности . Было отмечено, что, по крайней мере, во Франции люди недостаточно подготовлены для того, чтобы столкнуться с обслуживанием в обоих аспектах:

• поддерживать существующий код
• сделать обслуживаемый код

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

• Как мы можем научить ремонтопригодности?
• Какие упражнения вы бы предложили?
• Если вы хорошо подготовлены в отношении ремонтопригодности, какие конкретно курсы вы посещали?

[править] После некоторого недопонимания я думаю, что должен уточнить мой вопрос. Как руководитель проекта и разработчик программного обеспечения, я часто работаю со стажерами или студентами-выпускниками. Я когда-то был недавно закончил сам. Дело в том, что студенты обычно не знакомы с такими принципами, как SOLID, которые повышают удобство сопровождения проекта. Мы часто сталкиваемся с серьезными трудностями при разработке проектов (низкая ремонтопригодность). То, что я ищу здесь, является конкретным академическим примером успешного преподавания о важности ремонтопригодности и о том, как сделать лучший код относительно этой конкретной точки; или возможные предложения, чтобы улучшить способ обучения студентов.

Как мы можем научить ремонтопригодности?

Это вопрос практики.

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

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

Установите средство отслеживания ошибок и заполните его запросами, соответствующими конкретным нанесенным вами убыткам. Установите основные правила и практики для процесса разработки - коммиты VCS, обзоры кода, QA и т. Д. - подумайте о том, чтобы взять то, что вы можете, из контрольного списка, представленного в The Joel Test .

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

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

Отказ от ответственности: я только что получил степень бакалавра. Я не учитель.

Это может показаться очевидным, но я думаю, что лучший способ научить обслуживанию кода - это заставить студентов выполнять обслуживание кода. Вот что я бы сделал:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хороший код = меньше обслуживания и простота улучшения / добавления функций.

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

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

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

Упражнение:

1) Наличие заранее написанного плохого кода (например, дубликата кода), метод «рассчитать ипотечный платеж» написан в 9 местах проекта.

Попросите студента улучшить функцию, чтобы «добавить 1,2% надбавки ко всем ипотечным платежам».

Теперь студент увидит боль от поиска и исправления кода во всех 9 местах. Есть много шансов, что он не смог найти все 9 мест, где рассчитывается «ипотечный платеж».

2) Теперь покажите Хороший код, который имеет этот метод, который рассчитывает ипотечный платеж в одном-единственном месте . продемонстрируйте учащемуся, как легко улучшить хорошо написанный код, и объясните ему, как это повышает удобство сопровождения кода / проекта.

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

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

Во-первых, один ДОЛЖЕН определять «ремонтопригодность» - нет единого приемлемого для всех определения - аналогично определению архитектуры программного обеспечения. Поэтому выберите тот, который, по вашему мнению, является наиболее важным, охватывающим все аспекты, и укажите его в 3-4 строках максимум. Затем вы можете поговорить о некоторых показателях, таких как - время, чтобы вспомнить / понять ваш собственный код (или чей-то другой), количество WTF в минуту / час и т. Д. Держите его легким (юмористическим) - это сделает их более восприимчивыми к тому, что у вас есть сказать после этого.

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

Разделите класс на два - дайте одному разделу простое задание по кодированию, которое необходимо выполнить за 1-2 дня. Максимум. Жесткий срок. Они должны выполнять работу при любых обстоятельствах - руководящих принципах - «рабочем коде» по своему усмотрению. Для другой группы студентов то же самое задание, но со списком (именных) соглашений и некоторыми рекомендациями по дизайну и тому, как будут вычитаться баллы, если не будут выполняться. Это НЕ обман, даже если это звучит так;) Теперь попросите их поменять местами коды, т.е. группа 1 теперь работает над тем, что сделала группа 2, и наоборот. Теперь предложите модификацию исходного назначения кодирования и попросите их сделать это в тот же период времени. Соберитесь и спросите их, насколько это было легко / сложно, и предоставьте слово для дискуссий / мнений. Точка определенно достигнет цели - высокие шансы 50% учеников будут счастливы, и им будет легко, а 50% - трудно. Вы также можете попросить их заняться своими делами через 3 недели и посмотреть, смогут ли они сделать это за 1 день;)

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

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

Важно понимать разницу между разработкой с нуля и разработкой с нуля - не каждый проект или система были бы созданы с нуля (это довольно сложно найти или быть частью проектов «с нуля»). Объясняя, что поле «по своей сути» коричневое, и вы должны тратить время на его формирование по мере продвижения к возможному постепенному отказу, когда оно вырастает «из-под контроля» (возможно только тогда, когда дрейф слишком велик и «не поддерживается»). Чем скорее они это примут, тем лучше. Это сложно, так как программирование по своей сути креативно, но расширение чужого кода не воспринимается как таковое - искажайте его. Креативность - это способность понимать код, а затем применять «свой» креатив для его улучшения - если его лучше поддерживать, вы сможете более креативно его улучшить в будущем.

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