Можно ли написать программное обеспечение, которое не нужно постоянно модифицировать?

23

Я написал много программного обеспечения на разных языках, а также «написал» аппаратное обеспечение для использования с ПЛИС, использующими Verilog и VHDL.

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

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

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

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

Натан Фаррингтон
источник
8
Вы, кажется, описываете OCP
Одед
Этот материал принципа Открыто-Закрыто выглядит великолепно! Кто-нибудь использовал это успешно?
Натан Фаррингтон
2
@NathanFarrington: Большинство шаблонов проектирования (как описано GOF ) следуют OCP. Одним из примеров будет шаблон шаблонов .
Спойк
2
@NathanFarrington Принцип открытого-закрытого типа - это общий принцип, используемый разработчиками программного обеспечения при разработке программного обеспечения.
Джеспер
1
Я полагаю, что многие из программ, которые мы использовали сегодня, сделаны с использованием кусочков, которые являются точной копией кода, написанного 20 лет назад.
Мэллов

Ответы:

16

Может быть, это как-то связано с четко определенными интерфейсами и тестированием, например с аппаратным обеспечением?

Именно мои мысли!

Хорошо спроектированные модули с понятными интерфейсами, как правило, идеальны. Подумайте о чем-то вроде Stringкласса Java. Это компьютерная программа, но она имеет кристально чистый интерфейс. В нем нет известных ошибок. Он делает то, что должен, прекрасно. Конечно, он был тщательно протестирован за последние 15 лет, и, поскольку практически все программы используют Strings в качестве базовых строительных блоков, любая ошибка в нем будет быстро замечена. Любые «причуды» - не только ошибки, но и детали дизайна, о которых стоит знать - такие, как описанные здесь http://www.jwz.org/doc/java.html, уже хорошо известны и поэтому могут быть приняты во внимание. Счет.

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

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

Вероятно, нет серебряной пули, но хорошая комбинация лучших практик, включая, но не ограничиваясь:

  • Простые, автономные модули. Другими словами, низкая связь и высокая когезия.
  • Неизменность. Особенно важно с ростом параллелизма.

Стоит отметить, что оба пункта направлены на снижение сложности. Это ключевой момент. Энтропия всегда имеет тенденцию к увеличению, и если мы не будем бороться с этим, мы скоро утонем в сложности. Также интересно видеть, что за последние несколько лет языки программирования развивались в направлении поощрения или даже обеспечения соблюдения вышеупомянутых методов. В частности, рост функциональных языков заключается в следующем: чистые функции всегда возвращают одно и то же значение для одного и того же ввода, в них нет состояния . Тогда вы просто Compose чистые функции , которые принимают и возвращают неизменные значения , и ограничить неизбежную переменчивость для небольших четко определенных мест , вместо того , чтобы распространять его все вокруг. Проверьте это: http://clojure.org/state

Joonas Pulakka
источник
1
jwz не совсем согласен с тем, что класс String не содержит ошибок - jwz.org/doc/java.html
1
Он может работать так, как задумано, поэтому вопрос в том, не нарушен ли базовый дизайн. Я согласен, однако, что String - очень надежный класс.
1
Отличный ответ. Сейчас я пишу код почти исключительно на Python и пытаюсь воспользоваться функциональными конструкциями программирования. Да, я думаю, что вы правы, что неизменность является ключевым фактором. В первый раз, когда я создаю программный модуль, даже если я тестирую его, я, вероятно, испортил интерфейс, или, возможно, он имеет неправильную ответственность или слишком много. Поэтому я делаю второй модуль и оставляю первый в покое! Я все еще могу использовать первый модуль в будущем, если захочу, но никогда не изменю его, потому что, хотя он не идеален, он работает. Таким образом, функциональные языки с неизменяемостью могут помочь, как вы предлагаете.
Натан Фаррингтон
1
@JoonasPulakka: Да, если есть краткая сводка о программном обеспечении, это может быть «всегда есть другая ошибка». :-) И я думаю, что это один из моментов Натана.
Росс Паттерсон
1
Joonas, ты выиграл. Я начал изучать Clojure. Похоже, это лучший способ сделать программирование веселым.
Натан Фаррингтон
9

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

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

Вы должны обязательно проверить разработку через тестирование .

RCE
источник
Многие ответы на мой вопрос, кажется, содержат фольклор. Обязательно ли легче находить и исправлять программные ошибки, чем разрабатывать их с самого начала? Сколько действительно стоит модифицировать программное обеспечение? Наверное, никто не знает. Что касается разработки через тестирование, то имеет смысл тестировать программное обеспечение, которое можно использовать повторно. Программное обеспечение тогда становится фактическим строительным блоком, а не шаром грязи. Но нет смысла тестировать программное обеспечение, если оно просто изменится завтра. Я думаю, мне было интересно, можем ли мы на самом деле создавать программное обеспечение из строительных блоков, а не из грязи.
Натан Фаррингтон
1
@NathanFarrington: Я считаю, что существует огромная разница в том, как составляется спецификация и дизайн аппаратного и программного обеспечения. Большинство производителей аппаратного обеспечения, скорее всего, имеют более точные спецификации того, что они делают, чем разработчик программного обеспечения, чей клиент может сказать только «Я хочу программу, которая делает это!» Это в значительной степени гарантировано, чтобы получить новые функции, а что нет.
RCE
Конечно, если есть много изменений, некоторые тесты могут также нуждаться в изменении, но это не так, как программное обеспечение переключается с текстового процессора на веб-сервер. Ваша функция «новый документ» все равно создаст новую функцию, и ее тесты должны быть действительными.
RCE
Вы указали еще один ключевой принцип: чем лучше спецификации, тем меньше требуется изменений в будущем. Но это было не совсем то, к чему я стремился в моем вопросе, потому что вы можете добавить функции к оборудованию, прежде чем оно будет сделано, как программное обеспечение. Я думаю, что OCP был реальным ответом, но, к сожалению, это комментарий, поэтому я не могу пометить его как ответ. Другим моментом было постоянное продвижение вперед, и я думаю, что TDD может помочь в этом, предоставив регрессионные тесты.
Натан Фаррингтон
Смена программного обеспечения кажется проще и дешевле, чем аппаратная, но так ли это на самом деле? Да, я могу внести изменения и практически мгновенно сделать новую сборку одним нажатием пальца. Тем не менее, сборка все еще должна пройти проверку / QA. Какова была альтернативная стоимость? Что бы я делал вместо исправления этой ошибки. Что бы делал QA, если бы им не нужно было повторно проверять программное обеспечение. Были ли другие проекты перенесены, чтобы вывести это исправление на рынок? Есть много «скрытых» затрат, о которых люди не думают. Это может быть проще, но не обязательно дешевле.
Пемдас
6

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

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

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

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

Конечно, создание независимых модулей должно значительно уменьшить зависимость. Это необходимо учитывать при разработке программного обеспечения. Необходимо учитывать разделение задач, уровней, уровней, объектов контроллера, интерфейсов и т. Д.

«Как я могу получить больше удовольствия от написания программного обеспечения, не внося ошибок в работающий код и всегда продвигаясь вперед?»

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

2-Заставьте своего пользователя понять эту долгосрочную философию.

3-план реализации тщательно

4-Дизайн перед кодом.

5-Используйте общий дизайн, когда это уместно.

6-Использование прототипов в качестве инструмента подтверждения дизайна.

Без шансов
источник
Это все отличные советы. Подводя итог моим мыслям до этого момента: (1) сделайте релизы БОЛЬШИМ СДЕЛКОМ и сделайте много тестов и QA перед выпуском, (2) сделайте модули БОЛЬШИМ СДЕЛКОМ и убедитесь, что у них есть четко определенные документированные интерфейсы с тестами для этих интерфейсы и утверждения, чтобы видеть, нарушен ли интерфейс, и как только модуль "выпущен", он никогда не изменяется (OCP).
Натан Фаррингтон
4

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

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

Вернуться к вопросу ОП. Не могли бы вы определить систему строительных блоков, из которых можно извлечь все ваше программное обеспечение? Возможно. Будет ли это очень экономически эффективным? Вероятно, нет, потому что к тому времени, когда вы приступите к разработке достаточно надежной системы компонентов, тестов и других принадлежностей, чтобы поддержать этот идеалСистема программирования, вы обнаружите, что ваши конкуренты уже опередили бы вас на рынке, и, что еще хуже, с точки зрения среднего программиста, вы, вероятно, нашли бы, что стиль программирования в стиле "резака печенья" очень ограничивающий и, скорее всего, очень скучно. Я лично работаю над API, где основная часть кода модуля была настолько доработана и стандартизирована, что все, что я сейчас делаю, - это генерирую шаблон кода и заполняю пробелы. Большую часть моего времени я могу потратить на написание простого кода соединителя и максимально быстрое извлечение модулей. Это серьезно ошеломляет. Существует очень мало возможностей делать больше, чем просто кодировать одни и те же вещи снова и снова, поэтому, когда появляется другая возможность проекта, я не упускаю шанс сделать НИЧЕГО еще.

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

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

S.Robins
источник
Мне любопытно, вы пишете, что тестирование важно, но и ошеломляет.
Натан Фаррингтон
@NathanFarrington Спасибо за указание на это. Моя цель состояла в том, чтобы положительно поговорить о тестировании, но я думал об этом, когда печатал что-то другое, так что в этом абзаце все вышло совершенно неправильно! Я исправил, чтобы соответствовать фактической точке, которую я пытался осветить!
С.Робинс
3

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

Если это вас расстраивает, подумайте о другой карьере. Шутки в сторону.

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

Часто при добавлении функции в другом месте появляется ошибка, которая раньше работала просто отлично.

Это проблема обеспечения качества.

Это не происходит в оборудовании, пока интерфейсы не нарушены.

Это также верно в отношении программного обеспечения.

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

Да. Вы должны практиковать обеспечение качества.

С. Лотт
источник
1
Кстати, я не пытаюсь троллить, и да, может быть, я не интересуюсь программным обеспечением. Но вы говорите, что «смысл программного обеспечения в том, чтобы иметь возможность добавлять функции». Это правда? Фон Нейман изобрел программное обеспечение, позволяющее создать компьютер, который мог бы вычислять более одной математической функции, не перемонтируя ее логические и арифметические единицы. Мне любопытно, откуда эта философия функциональности программного обеспечения. Аппаратное обеспечение имеет функции, но цель аппаратного обеспечения - не добавлять функции.
Натан Фаррингтон
Я предполагаю, что под контролем качества вы подразумеваете тестирование. Да, моя интуиция говорит, что для производства качественного программного обеспечения требуется обширное тестирование. Но я думаю, что это выходит за рамки этого. В аппаратном обеспечении модуль может содержать ошибку. Но когда вы добавляете новое оборудование, оно не вносит новых ошибок в существующий аппаратный модуль. В конце концов все ошибки во всех модулях могут быть найдены и исправлены. Но в программном обеспечении часто код изменяется (модули меняются), а не добавляется, что может привести к ошибкам. Думаю, я искал методологию разработки программного обеспечения, которая была бы чисто аддитивной.
Натан Фаррингтон
Теперь у меня есть более разумный комментарий к вашему ответу. Причина, по которой я высказал недовольство по поводу того, что программное обеспечение никогда не было «сделано», заключается, вероятно, в том, что я всегда использовал очень рыхлый подход к релизам. Одна новая функция соответствует следующему выпуску, без регрессионного тестирования и очень небольшого контроля качества. Если бы выпуски были БОЛЬШИМ, то держу пари, что мои жалобы о том, что программное обеспечение никогда не будет сделано, исчезнут.
Натан Фаррингтон
@NathanFarrington: Тьюринг изобрел программное обеспечение для взлома постоянно меняющихся кодов Enigma. «Под гарантией качества вы подразумеваете тестирование». Ложь. Я имею в виду обеспечение качества - каждый аспект развития должен иметь стандарты качества, которые должны соблюдаться. Тестирование - это один (ограниченный) способ оценки качества одного вида артефакта. msgstr "код изменён ... что может привести к ошибкам". Правильный. Это провал качества, а не неотъемлемая черта программного обеспечения.
S.Lott
Мы определенно отвлекаемся от темы. Согласно этой ссылке , Колосс Тьюринга не был универсальным (в вычислительном смысле) и не использовал хранимые программы (программное обеспечение).
Натан Фаррингтон
2

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

Я рекомендую вам изучить « формальные методы » для проверки правильности конструкций и программного обеспечения. Инструменты симулятора, которые вы используете для проектирования оборудования, пытаются сделать что-то близкое. Я не верю, что инструменты для формальных методов где-то близки к тому, чтобы быть полезными в промышленности в настоящее время, и единственные отрасли, которые имеют сильные стимулы для отсутствия дефектов, это авионика и медицина (достаточно интересно, что FDA ясно говорит, что «программное обеспечение отличается от оборудования "по этой ссылке). Кроме того, если вы разрабатываете с Verilog / VHDL, то вы придерживаетесь бинарной логики. Это резко снижает сложность. Не будет аппаратного эквивалента проблеме 2000 года.

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

Tangurena
источник
1

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

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

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

Фигня. Возможно, вы лично лучше, чем многие другие «аппаратные» люди, не занимающиеся паяльником, но я видел множество неудачных схем, неисправных микросхем ( например , знаменитая проблема Intel «f00f»), но это не так говорить с полем в целом. И по мере того как изделия из искусственных материалов становятся «мягче», проблемы становятся все труднее предотвратить.

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

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

И последнее замечание: у программного обеспечения финансовая модель отличается от аппаратной, даже программируемой. Большая часть непотребительского программного обеспечения, а также некоторые потребительские программы продаются таким образом, чтобы это стимулировало изменения. Когда вы можете сказать бизнесу: «Платите нам 10 000 долларов сейчас плюс 18% в год», вы можете перепродавать продукт каждые несколько лет. Но чтобы оправдать эту плату, вы должны предоставить клиенту изменения, которые они хотят. Хм ... если подумать о кривой устаревания оборудования Apple, возможно, в конце концов, это не имеет значения - аппаратные средства просто заставляют вас по- настоящему их покупать!

Росс Паттерсон
источник
Никогда не говорил, что я лучше всех. ;-) Когда в железе есть ошибка, это становится новостью. Когда программное обеспечение имеет ошибку, ммм, программное обеспечение ожидания всегда имеет ошибки. Какие методологии мы не используем, потому что они слишком дорогие и не веселые?
Натан Фаррингтон
0

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

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

http://en.wikipedia.org/wiki/Extreme_Programming

Когда вы взаимодействуете с аппаратным обеспечением, аппаратное обеспечение нуждается в значении х, и это все (теоретически), но когда вы взаимодействуете с людьми сегодня, они нуждаются в х, а завтра они могут нуждаться в у и т. Д. Это так, как меняются требования бизнеса и людей. , Поскольку люди! = Машины, поэтому код, который НИКОГДА не меняется в большинстве случаев, невозможен.

Также, как я сказал в моем предыдущем / удаленном ответе, постарайтесь избежать изменений, которые не важны, заставляя людей думать, прежде чем начать писать код. Больше вовлекайте пользователей в процесс принятия решений и т. Д. Уточняйте затраты на изменения, планируйте больше и т. Д. Это не «способы кодирования», а «не кодирование», потому что с большим количеством требований будет меньше изменений и больше веселья.

H27studio
источник
1
Хороший ответ. Я занимался экстремальным программированием. Кажется, это полная противоположность тому, что я искал, когда все направление проекта может меняться еженедельно в зависимости от прихоти клиента. Я не против повторяющихся выпусков, я просто не хочу, чтобы во 2-й версии были ошибки, которых не было в 1-й версии. И вы правы, что предварительный дизайн может сэкономить усилия в долгосрочной перспективе.
Натан Фаррингтон
Как я всегда говорю, лучший код - это не код. :-)
H27studio
0

Можно ли написать программное обеспечение подобным образом?

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

кстати, разве вы не слышали об ошибках HW? Гораздо страшнее любой ошибки программного обеспечения и ее сложнее исправить (а не просто обновить программное обеспечение)

BЈовић
источник
1
Да, в оборудовании тоже есть ошибки, даже зрелые, хорошо протестированные, такие как процессоры. Хорошее оборудование разработано так, чтобы аппаратные ошибки могли быть исправлены в программном обеспечении! Причина моего первоначального вопроса заключается в том, что я написал много программного обеспечения, но меня всегда тревожило то, насколько легко вводить ошибки и насколько грязной была система в целом. Я чистый человек, поэтому методология разработки аппаратного обеспечения всегда казалась мне более естественной. Это также может быть связано с областью действия.
Натан Фаррингтон
1
@NathanFarrington Программное обеспечение обычно более сложное, чем HW. HW проверяется более тщательно. SW может меняться легче, поэтому люди, как правило, не уделяют так много внимания.
BЈовић
0

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

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

HLGEM
источник
У вас есть действительная точка. Типы вещей, которые мы традиционно делаем на аппаратном уровне, хорошо понятны: процессоры, контроллеры USB, конечные точки PCI Express, контроллеры памяти и т. Д. Затем мы внедряем всю бизнес-логику этого приложения в программное обеспечение. Может быть, по мере того, как мы будем продвигаться вверх, программный стек становится все более запутанным и менее понятным?
Натан Фаррингтон
-1

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

AndSoYouCode
источник