Предотвращает ли повторное использование программного обеспечения повторяемость процесса

Повторное использование кода как проблема

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

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

Некоторые сравнения с другими дисциплинами

строительство

Напротив, строительство физических систем (зданий, мостов) далеко не так многоразово. Это правда, что проект дома может многократно использоваться для создания одной и той же копии дома, но строительство должно выполняться каждый раз. Cut & paste не работает так в аналоговом мире. Чертежи мостов менее пригодны для повторного использования, чем дома, потому что условия на месте будут отличаться.

Мастера-строители - это эксперты, признанные за то, что спроектировали и / или построили десятки, сотни или тысячи вещей в своей области. Например, Фрэнк Ллойд Райт , всемирно известный архитектор и дизайнер designed more than 1,000 structures and completed 532 works. Сравните это с Андерсом Хейлсбергом, который разработал «всего» пять языков (Turbo Pascal; Delphi; J ++; C #; Typescript). Во многих отношениях это несправедливое сравнение, потому что домены разные. Но на широком уровне измеряемая продукция двух очень умных людей сильно отличается.

Боевые искусства

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

деревообрабатывающий

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

Итак, мешает ли повторное использование программного обеспечения разработчикам программного обеспечения стать более опытными?

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

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

Возможность повторного использования программного обеспечения не препятствует улучшению процесса.

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

В одном крайнем случае мы можем предположить, что надежная линейка программных продуктов, С другой стороны, вы можете предположить, что с нуля. Все еще необходимо выполнять все эти процессы в различной степени, хотя они могут происходить с разной скоростью или, возможно, даже в разных последовательностях. Например, при большом количестве повторного использования больший процент выделенного времени может быть потрачен на действия по интеграции и проверке / валидации на системном уровне (требования V & V, интеграционные тесты, системные тесты, приемочные тесты). С новыми усилиями по разработке может потребоваться больший процент времени при проектировании и реализации. Пока вы выполняете процесс хотя бы один раз в течение проекта, вы можете измерить его (количественно и качественно). Как только вы внесете коррективы и увидите, как эти корректировки влияют на некоторую меру или области процесса, или общей возможности поставки программного обеспечения,

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

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

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

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

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

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

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

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

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

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

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

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

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

Но для вашего краткого и краткого вопроса: из моего опыта я бы сказал и да, и нет.

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

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

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

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

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

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

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

Ах, черт, опять отвлекся ... Я извиняюсь за то, что я не спал 32 часа, так что мои способности к фокусировке немного ... что я говорил?

Если кто-то еще читает, мой вывод таков:

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

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

Как указано в принятом ответе в другом вопросе для программистов, аналогии со строительством следует соблюдать осторожность:

рекомендуемое чтение для этого является аналогом построения программного обеспечения

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

Что я заметил, так это то, что хорошие программные проекты «превращают» большую повторяемость в обеспечение качества.

Когда я был тестером в 1,5-летнем проекте, мы запускали циклы тестирования в еженедельных выпусках «контрольных точек», примерно в 70 раз больше, чем в проекте. Это было ... вполне повторяемо, мягко говоря (за неделю мало что меняется). Тестирование ночных сборок было, естественно, еще более повторяемым - около 500 раз в течение всего проекта (лишь немногие развлекательные ошибки, связанные с showtopper, были слишком редки, чтобы что-то изменить).

Теперь, следуя этой «подозрительной» аналогии, расскажите мне строительную компанию, которая построила 500 мостов - все с одной командой.

• Далее, расскажите мне компанию, которая использовала в основном одинаковые кирпичи и железо на каждом из своих новых мостов (здесь я имею в виду тот факт, что тестируемые нами выпуски имели в основном одни и те же фрагменты кода день за днем, неделю за днем. неделя - "не так много вещей меняется").
  

Мастера-строители - это эксперты, признанные за то, что спроектировали и / или построили десятки, сотни или тысячи вещей в своей области.

Хорошо, после вашего объяснения повторяемости, приведенного выше, я могу сказать, что? Тогда наша маленькая, не очень особенная группа тестировщиков проверила, см. Выше («около 500») сотни вещей в нашей области.

Что касается разработчиков проектов, они буквально построили («ночные сборки») - видите, слово то же самое, и смысл в этом контексте правильный - сотни вещей в своей области.

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

• В качестве примера, еще один из моих прошлых проектов (опять же, ничего особенного, довольно обычный), на этот раз в роли разработчика, продолжается уже более 5 лет (8 основных релизов, несколько десятков второстепенных). Были аналогичные еженедельные контрольные точки ( 5x52~=250из них), аналогичные ночные выпуски ( 5x365~=1800из них) и аналогичные команды разработчиков / QA, работающие над ними. День за днем, неделя за неделей, месяц за месяцем, в основном повторяющиеся вещи (между двумя ночными сборками не так много изменений) - как и было обещано, в диапазоне тысяч раз (1800).

Проекты с более долгим сроком службы, такие как Windows, Java или AutoCAD, могут длиться 10, 20, 30 лет, что позволяет легко повторять столько «тысяч» ночных сборок и ночных тестов, сколько они получают.

Концепция непрерывности перехода к QA становится еще более заметной с непрерывной интеграцией ...

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

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

Повторяемость? это прямо там, столько, сколько можно подумать.

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

упражнение в программировании, которое помогает программисту отточить свои навыки посредством практики и повторения ...

То, что вы говорите, верно: например, библиотеки решают функции, не решаемые языками высокого уровня, которые решают проблемы, не решаемые сборкой, которые решают проблемы, не решаемые машинным кодом. Когда вы вызываете System.out.println () в Java, вы теряете из виду, как процессор выводит на устройство.

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

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

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

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

Это все о ресурсах. Несколько лет назад, если вы разрабатывали программные проекты для больших мэйнфреймов, они могли бы существовать в течение 15 лет или около того с использованием в основном статической среды разработки. Программа FORTRAN, написанная для расчета заработной платы, или программа COBOL были усовершенствованы за десятилетия, потому что она постоянно использовалась. Были ресурсы, чтобы увидеть, как это можно улучшить. У нас больше нет такой медленной среды для точной настройки и оттачивания навыков для конкретного проекта. Но мы берем эти навыки и адаптируем их к возможностям следующего проекта. Но в конце концов становится выбор денег, потраченных на новый проект, чтобы сделать работу, или сделать новую работу с большим количеством золотого покрытия. Позолота проекта означает улучшение его до n-й степени и добавление тонны наворотов, даже если пользователь этого не сделал

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