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

25

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

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

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


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

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

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

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

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

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

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

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


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

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

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

Сообщество
источник
Если вы написали кусок кода, вы по существу решили проблему. Если вы хороши в этом, эта часть решает КЛАСС проблем. Если вы действительно хороши, это расширяется до метакласса проблем. И тогда вы теряете интерес: нет необходимости совершенствовать один велосипед, если вокруг нерешенные проблемы дизайна. Удовольствие от решения проблем исходит от блестящего нового материала, а не от полировки старых проблем до совершенства.
Охотник на оленей
2
Хорошие программные проекты "переносят" много повторяемости в QA. Когда я был тестером в 1,5-летнем проекте, мы запускали циклы тестирования в еженедельных выпусках «контрольных точек», примерно в 70 раз больше, чем в проекте. Это было ... вполне повторяемо, мягко говоря (за неделю мало что меняется). Тестирование ночных сборок было, естественно, еще более повторяемым - около 500 раз в течение всего проекта (лишь немногие развлекательные ошибки, связанные с showtopper, были слишком редки, чтобы что-то изменить). Теперь, скажите мне строительную компанию, которая построила 500 мостов - все с одной командой
комнат
@gnat - это отличное понимание и перспектива, о которой я еще не задумывался. Другие аспекты SDLC становятся намного более эффективными благодаря этому повторению.
1
@ GlenH7 расширил его в ответ , в основном, чтобы включить фотографии мостов :)
комнат
Сколько проблем пришлось решить Фрэнку Ллойду Райту в его 1000 структурах против Андерса Хейсберга в определении его простых 5 языков? Райт должен был принимать решения по указу, Андерсу приходилось оправдывать решения для многих людей, таких же умных и знающих, как он. Могу поспорить, что Андерсу пришлось решать много-много других вопросов. Таким образом, ваши метательные числа в миксе зависят только от того, что вы выбрали для подсчета, а не от каких-либо реальных количественно сопоставимых чисел. Поэтому мне нравится вопрос, мне просто не нравятся рассуждения / примеры, вдохновляющие вопрос. Эффективность ПО значительно улучшилась за эти годы.
Данк

Ответы:

10

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

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

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

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

Томас Оуэнс
источник
зависит от того, что на самом деле используется повторно, оно может даже попасть в CMMI Acquisition, то есть не в разработку.
imel96
1
Но CMMI не удалось каким-либо значимым образом. Ни одно из «убийственных приложений» 21-го века не было создано людьми, заинтересованными в матрице зрелости CMMI. Некоторые блестящие люди имели идею и реализовали ее, а затем наняли более блестящих людей, чтобы увеличить масштаб решения. Наоборот, проекты, которые, вероятно, по крайней мере платили за услугу стандартам, подобным CMMI, потерпели неудачу, например, попытка Министерства обороны США создать новое приложение для расчета заработной платы.
Кевин Клайн
1
@kevincline Не имеет значения, что CMMI удалось или не удалось. Сидя в аэрокосмической / оборонной промышленности, я вижу CMMI в своей организации и в компаниях, с которыми мы работаем, с которыми мы являемся субподрядчиками и с которыми мы заключаем субподряд. Однако я хочу сказать, что для улучшения процессов вам необходимо идентифицировать свои процессы. CMMI - это единственный инструмент для этого. Есть и другие, и вы можете определить свои собственные. Когда у вас есть процессы, вы можете определить их, измерить и улучшить их.
Томас Оуэнс
1
@Kevin: «Приложения-убийцы» по своей природе «вне мейнстрима». Поэтому неудивительно, что большая часть новой и инновационной работы была создана экспериментами и взломом, а не каким-то дисциплинированным процессом. Хотя «приложение-убийца» зависит от определения. Является ли приложение, которое превращается в увлечение, действительно «приложением-убийцей», или представляет собой программу DoD, которая позволяет реактивным истребителям безопасно летать и не дает им сбивать своих союзников с «приложения-убийцы». Причуды часто не требуют никаких навыков / инноваций вообще (например, домашний рок, хула-хуп) ......
Данк
... включая многие действительно популярные "причудливые" прикладные программы. Принимая во внимание, что крупные проекты типа DoD почти всегда требуют огромного количества навыков и процессов. Кроме того, ваше представление о сбое CMMI, вероятно, больше говорит о вашем опыте (или его отсутствии) в отраслях, где используется CMMI, чем сама CMMI. CMMI не идеален и, вероятно, даже не хорош, но как минимум заставляет компании, по крайней мере, попытаться записать и следовать процессу и даже попытаться улучшить его. Если это все, что CMMI выполняет, то это успех.
Данк
5

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

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

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

Euphoric
источник
Дело не в том, что другие дисциплины не используют повторно дизайн, разница в количестве повторного использования. Все объекты, которые вы упомянули, должны быть физически сконструированы для каждого экземпляра. Я не могу просто скопировать и вставить дверь, например. Повторение, которое приходит из конструкции, приводит к выявлению эффективности и улучшений, которые не очевидны с самого начала. Постройте набор кухонных шкафов, и вы обнаружите новые вещи между 1-м и последним. Вы понимаете общую сложность, поскольку виртуальная природа программного обеспечения позволяет нам неосознанно накапливать сложности.
1
@ GlenH7 Дело в том, что разработка программного обеспечения не строит. Его проектирование. Строя вещи, вы делаете одно и то же снова и снова. Но с дизайном у вас всегда разные цели и проблемы. Не стоит сравнивать его со строительством здания, а с созданием его плана.
Эйфорическая
2
Я не уверен, что полностью согласен с вашей точкой зрения на разработку программного обеспечения. Разработка SW - это и дизайн, и строительство. Конструкция должна обеспечивать обратную связь с дизайном. И в аналоговой, и в цифровой сфере хорошие архитекторы «пачкают руки» и строят, чтобы завершить цикл обратной связи. Даже если мы сосредоточимся только на дизайне, я думаю, что повторение дизайна определяет эффективность, которая ведет к лучшему дизайну. SW не повторяется, как другие поля. Каждый мост требует модификации общего подхода, адаптирующего его к месту, на котором он собирается.
SW dev не так сложен по сравнению с дизайном, который разработает архитектор. Просто мы думаем, что это трудно, потому что мы не относимся к программному обеспечению как к надлежащей инженерной дисциплине, и потому что мы продолжаем изобретать вещи. Если бы вы только знали, что входит в дизайн других вещей, вы бы увидели, что большая часть программного обеспечения должна быть тривиальной, но мы
усложняем
Если сравнивать с мостом - вы правы, мосты - это решенная проблема. Вам нужен новый мост, отряхните старые конструкции и сделайте несколько изменений, и у вас будет новый мост (я, конечно, преувеличиваю простоту). Так почему же веб-сервис не сконструирован подобным образом в программном обеспечении? Вот почему программное обеспечение не является разработкой ИМХО, мы относимся к нему больше как к ремеслу (или искусству), где каждый проект - индивидуальная работа.
gbjbaanb
2

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

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

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

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

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

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

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

PSR
источник
2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бойсе
источник
Разве тот факт, что большинство разработчиков программного обеспечения могут обойтись без знания внутренней работы системы, не является сильным показателем широкого повторного использования? Я также нахожу забавным, как истории из правительственных проектов звучат просто ужасно, но если бы у вас были какие-либо знания о правительственной работе, вы бы поняли, насколько невежественен автор. Молоты за 1500 долларов и т. Д. ... Все становится понятным, когда вы понимаете, что правительственные процессы требовали 10 человек для проверки и получения конкурентоспособных котировок перед покупкой, ИЛИ просто не перемещали средства между бухтами учета.
Данк
Я не утешаюсь, зная, что инженер-программист, работающий над «самой сложной» компьютерной системой в самолете , не спал в течение 32 часов. =)
RubberDuck
2

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

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

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

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

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

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

  • Далее, расскажите мне компанию, которая использовала в основном одинаковые кирпичи и железо на каждом из своих новых мостов (здесь я имею в виду тот факт, что тестируемые нами выпуски имели в основном одни и те же фрагменты кода день за днем, неделю за днем. неделя - "не так много вещей меняется").
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

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

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

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

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

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

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


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

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

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

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

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

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

комар
источник
1
Отличные очки, и я думаю, что побеги, которые затем были возвращены в автоматизированный набор тестов, отражают некоторые из тех впечатлений, на которые я намекаю. Что касается претензий "той же команды", я возвращаюсь к опыту Райта. С более чем 500 построенных зданий он был общим элементом для всех тех. Но суть сделана, и я согласен с некоторыми предпосылками.
@ GlenH7 да, влияние повторения было действительно глубоким, и оно выходило далеко за рамки тестовых наборов. Знания накапливались повсюду, где происходили повторения - вы знаете, все стремится к оптимальному результату после 20 ... 30 ... 50 раз. Подготовка к контрольным точкам / ночная подготовка, отправка сообщений об ошибках (и вообще вся "ошибка в жизни"), связь с dev / QA / mgmt / sysadmins, документирование и т. Д. Я сосредоточился только на повторяемости, потому что погружение в вопросы накопления знаний, которые естественно следовали бы, иметь эффект пожарного шланга при изложении моей точки зрения
комнат
-1

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

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

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

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

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

Amot
источник
1
Я думаю, что вы затрагиваете некоторые потенциально обоснованные моменты, но я не вижу, чтобы они связывали друг друга, чтобы ответить на вопрос. И я не согласен с вашим соотношением 99: 1 для повторного использования. Я думаю, что это сильно переоценивает количество повторного использования. Даже в среде разработчиков программного обеспечения показатели повторного использования далеко не так высоки.
-2

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

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

Эдвард
источник
3
Я понимаю некоторые моменты, которые вы пытаетесь высказать, но они основаны на презумпции и незнании. Я имел обыкновение разрабатывать для мэйнфреймов, и я могу заверить вас, что скорость разработки была такой же быстрой, как на открытых системах. Процесс был другим, но темп был таким же. Ваш ответ будет более сильным, если сосредоточиться на компоненте переносимых навыков и подробно остановиться на потенциальной эффективности, полученной таким образом.
Вы должны взглянуть на историю, например, не было новых технологий, выпускаемых ежегодно или около того, в системах мэйнфреймов для ОС CDC 6600 Kronos, например. Это было в основном статичным в течение 15 лет. Сейчас дела идут гораздо быстрее, и нет времени, чтобы получить глубокие знания, полученные за 15 лет. Например, нет программистов на Flash с 15-летним опытом работы с Flash. Перечитав мой пост, я остаюсь на своем оригинальном посте.
Эдвард