Ремонтопригодность - главная задача профессиональной разработки программного обеспечения. В действительности, обслуживание - это почти всегда самая длинная часть жизненного цикла программного обеспечения, поскольку оно длится с момента выпуска проекта и заканчивается практически до конца времен.
Более того, проекты, находящиеся в эксплуатации, составляют подавляющее большинство от общего числа проектов. Согласно 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 .
Исправить ошибки, добавить недостающие юнит-тесты, документацию и функции.
Рефакторинг.
Поддержание / улучшение оригинальных проектов для использования студентами следующего года
- Project A версии 2.0 и Project A - поврежденная версия 2.0 , соответственно.
Под улучшением повреждённой версии я имею в виду нанесение ей лучшего образовательного урона. :)
Из практики, упомянутой выше, уделите особое внимание обзорам кода . Вероятно, это наиболее эффективный способ обеспечить простоту обслуживания кода, на что указывает, например, верхний ответ в связанном вопросе .
источник
Отказ от ответственности: я только что получил степень бакалавра. Я не учитель.
Это может показаться очевидным, но я думаю, что лучший способ научить обслуживанию кода - это заставить студентов выполнять обслуживание кода. Вот что я бы сделал:
Идея состоит в том, чтобы студенты не только работали с чужим кодом, но и научили их ценить поддерживаемый код, который, надеюсь, улучшит их навыки проектирования.
источник
Ремонтопригодность - это достоинство, а не умение. Существует множество путей создания поддерживаемых проектов, но нет единой формулы, которая гарантировала бы их создание.
Если вы цените добродетели, такие как доброта и щедрость, вы ищете способы практиковать то же самое в своей повседневной жизни. То же самое и с ремонтопригодностью: если вы и ваша организация цените ремонтопригодность, вы будете помнить об этом при разработке и реализации проекта. Это будет законной причиной потратить немного больше времени на создание чего-либо, потому что вы знаете, что ремонтопригодность ценится. И наоборот, тратить дополнительное время на ремонтопригодность в организации, которая не ценит его, не рекомендуется.
Если вы хотите научить людей делать вещи ремонтопригодными, вам следует начать с разъяснения, что ваша организация ценит ремонтопригодность. Укажите это в требованиях к вашим проектам. Сделайте это одним из критериев успешной проверки кода. Короче говоря, сделайте ремонтопригодность частью вашей культуры .
Далее, будьте готовы посвятить некоторые ресурсы улучшению обслуживания в ваших существующих проектах. Определите те части проекта, где ошибки появляются, или где исправление ошибок или внесение изменений очень сложно и занимает много времени, а также перепроектируйте или реорганизуйте, чтобы облегчить обслуживание.
Наконец, познакомьте новых разработчиков с вашей культурой обслуживания , назначив их командам, которые уже практикуют это ежедневно. Нет лучшего способа помочь кому-то принять ценность, чем дать им множество хороших примеров и рекомендаций.
источник
Мне, например, не нравится термин Maintainable в отношении разработки программного обеспечения. Реальность такова, что все программное обеспечение является обслуживаемым в том смысле, что оно может быть предметом работ по техническому обслуживанию, поэтому реальная проблема заключается в том, является ли программное обеспечение дорогим или недорогим в обслуживании, условно говоря. Я знаю, что это звучит как очень педантичное заявление в начале ответа, однако моя точка зрения прояснится через мгновение.
Проблема со степенями IT, которые являются основными в разработке программного обеспечения, состоит в том, что они действительно обучают студентов только минимальному уровню, который студенты должны знать о написании программного обеспечения. Профессиональные навыки и знания приобретаются благодаря обучению, которое проводится в первые несколько лет послеквалификация для получения степени. Это когда выпускник начинает работать над проектами, которые действительно важны для клиента, в среде, где существует большое давление для выполнения, и ожидается, что он создаст продукт по профессиональному стандарту. К сожалению, многие компании не поощряют культуру, в которой поддерживаются профессиональные стандарты в области программного обеспечения, и в результате они получают проекты, которые в результате оказываются дорогостоящими в разработке и поддержке. К сожалению для наших выпускников, они изучают много вредных привычек в таких условиях в первые годы своей карьеры, и может пройти много времени, прежде чем они научатся преодолевать эти привычки ... если вообще.
Вы бы лучше научили студентов писать чистый код и выявлять проблемы в программном обеспечении, которые обычно влекут за собой технические долги . Изучите книги о чистом коде , рефакторинге и разработке бережливого программного обеспечения в качестве отправной точки в качестве отправной точки и научите студентов писать модульные тесты перед кодом реализации, чтобы обеспечить высокий уровень охвата тестами. Научите студентов распознавать повторяющиеся и повторяющиеся шаблоны в своем коде и как реорганизовать код для устранения такого дублирования. Помогите студентам понять и применять такие принципы, как SOLID и DRY, Самое главное, покончить с этой идеей, что способность поддерживать код - это то, что делается исключительно на основе проектирования и реализации кода, и вместо этого прививать чувство мастерства и качества при производстве программного обеспечения с самого начала, стремясь доработать код в том виде, в котором он реализован, чтобы минимизировать влияние технической задолженности и тем самым свести к минимуму затраты на поддержание программного обеспечения.
источник
Я думаю, что лучший способ выучить такие навыки - это делать обзоры кода и парное программирование. Во время анализа кода опытные сотрудники могут указать, как сделать код более понятным (как правило, делая его более читабельным), и обосновать, почему определенные варианты могут создавать более поддерживаемый код.
Парное программирование - еще лучший способ научить такого рода вещам, потому что оно дает менее опытному персоналу непосредственный опыт поддержки кода с тем, кто уже знает, как это сделать хорошо.
Есть также несколько замечательных книг о написании чистого, поддерживаемого кода. Чистый код приходит на ум.
Трудно получить этот опыт в академических кругах, поскольку студенты редко модифицируют большие базы кода. Большая часть этих навыков будет получена из обучения на работе, и обзоры кода и парное программирование могут действительно облегчить это обучение.
источник
Хороший код = меньше обслуживания и простота улучшения / добавления функций.
Плохой код = кошмар обслуживания
По сути, мы должны донести до учащихся: «всякий раз, когда в проекте есть дрянной код, новый разработчик, который собирается присоединиться к компании, потому что первоначальный автор кода будет страдать, и как это повлияет на программное обеспечение». «.
Таким образом, один из лучших способов научить студента обслуживанию программного обеспечения - показать пример как хорошего кода, так и плохого кода, попросить их добавить функцию, а затем научить их, что написание хорошего кода не только для самоудовлетворения, но и для Это легко для людей, которые собираются поддерживать код.
Упражнение:
1) Наличие заранее написанного плохого кода (например, дубликата кода), метод «рассчитать ипотечный платеж» написан в 9 местах проекта.
Попросите студента улучшить функцию, чтобы «добавить 1,2% надбавки ко всем ипотечным платежам».
Теперь студент увидит боль от поиска и исправления кода во всех 9 местах. Есть много шансов, что он не смог найти все 9 мест, где рассчитывается «ипотечный платеж».
2) Теперь покажите Хороший код, который имеет этот метод, который рассчитывает ипотечный платеж в одном-единственном месте . продемонстрируйте учащемуся, как легко улучшить хорошо написанный код, и объясните ему, как это повышает удобство сопровождения кода / проекта.
Кстати, мне понравился твой подход, заключающийся в том, чтобы показать студентам возможность сопровождения программного обеспечения.
источник
@mattmattj: Так как там очень много ответов, и ссылка, которую я разместил, содержит несколько хороших указателей, я добавлю кое-что, что, надеюсь, не повторение уже опубликованных ответов.
Во-первых, один ДОЛЖЕН определять «ремонтопригодность» - нет единого приемлемого для всех определения - аналогично определению архитектуры программного обеспечения. Поэтому выберите тот, который, по вашему мнению, является наиболее важным, охватывающим все аспекты, и укажите его в 3-4 строках максимум. Затем вы можете поговорить о некоторых показателях, таких как - время, чтобы вспомнить / понять ваш собственный код (или чей-то другой), количество WTF в минуту / час и т. Д. Держите его легким (юмористическим) - это сделает их более восприимчивыми к тому, что у вас есть сказать после этого.
Некоторые упражнения (может показаться, что они частично совпадают с некоторыми ответами, пожалуйста, прости это)
Вот где вы закладываете основу удобства обслуживания - каждая строка кода, измененная / обновленная, стоит компании денег. Чем проще читать и вспоминать код, тем лучше / быстрее модификация, которая поможет сократить время выхода на рынок. Очень важно в современном быстро меняющемся технологическом пространстве. Ремонтопригодность является ключом к эффективной эволюции систем.
Важно понимать разницу между разработкой с нуля и разработкой с нуля - не каждый проект или система были бы созданы с нуля (это довольно сложно найти или быть частью проектов «с нуля»). Объясняя, что поле «по своей сути» коричневое, и вы должны тратить время на его формирование по мере продвижения к возможному постепенному отказу, когда оно вырастает «из-под контроля» (возможно только тогда, когда дрейф слишком велик и «не поддерживается»). Чем скорее они это примут, тем лучше. Это сложно, так как программирование по своей сути креативно, но расширение чужого кода не воспринимается как таковое - искажайте его. Креативность - это способность понимать код, а затем применять «свой» креатив для его улучшения - если его лучше поддерживать, вы сможете более креативно его улучшить в будущем.
Не стесняйтесь ссылаться на аналогию со спагетти в приведенной выше ссылке ... надеюсь, что это поможет достичь определенных результатов. Другие ответы помогут заполнить пробелы и должны помочь вам с обучением! Удачи!
источник