Я написал много программного обеспечения на разных языках, а также «написал» аппаратное обеспечение для использования с ПЛИС, использующими Verilog и VHDL.
Мне нравится писать аппаратные средства больше, чем программные, и я думаю, что одна из основных причин заключается в том, что можно написать аппаратное обеспечение, которое «сделано» и не нуждается в модификации: вы определяете интерфейсы и функциональность, пишете тестовый стенд , внедрите аппаратный модуль, затем протестируйте его, используя симулятор. Тогда вы можете положиться на этот аппаратный модуль как на строительный блок для создания чего-то большего и лучшего: если вам нужно добавить функцию в этот модуль, вы создадите второй модуль и добавите туда функциональность. Вы никогда не выбрасываете оригинальный модуль, так как он работает просто отлично и все еще может быть полезен.
Одно из моих главных разочарований в программном обеспечении - это то, что оно никогда не «делается». Всегда есть другая особенность, чтобы добавить. Часто при добавлении функции в другом месте появляется ошибка, которая раньше работала просто отлично. Это не происходит в оборудовании, пока интерфейсы не нарушены.
Чтобы быть ясным, я не сторонник создания одной версии чего-либо со списком функций, и это все навсегда: я за итераций и несколько выпусков с течением времени, чтобы добавить новые функции. Я просто не хочу совать код слева и найти ошибку справа, и это, кажется, происходит после добавления новой функции.
Можно ли написать программное обеспечение аналогичным образом, на котором аппаратное обеспечение «написано»? Существует ли хорошая методология разработки программного обеспечения, которая позволяет всегда продвигаться вперед и позволяет добавлять новые функциональные возможности без необходимости переписывать существующий код и вводить новые ошибки?
источник
Ответы:
Именно мои мысли!
Хорошо спроектированные модули с понятными интерфейсами, как правило, идеальны. Подумайте о чем-то вроде
Stringкласса Java. Это компьютерная программа, но она имеет кристально чистый интерфейс. В нем нет известных ошибок. Он делает то, что должен, прекрасно. Конечно, он был тщательно протестирован за последние 15 лет, и, поскольку практически все программы используютStrings в качестве базовых строительных блоков, любая ошибка в нем будет быстро замечена. Любые «причуды» - не только ошибки, но и детали дизайна, о которых стоит знать - такие, как описанные здесь http://www.jwz.org/doc/java.html, уже хорошо известны и поэтому могут быть приняты во внимание. Счет.Глючное программное обеспечение отчасти является культурной проблемой: люди привыкли глючить программное обеспечение, и, в отличие от аппаратного обеспечения, программное обеспечение обычно может быть легко исправлено впоследствии, поэтому его не нужно улучшать изначально (или когда-либо, потому что, эй, мы должны отправить сейчас, давайте исправим это в следующей версии). Но в значительной степени это проблема реальной сложности: сложность программного обеспечения неуклонно возрастала в течение последних 50 лет, но человеческий мозг остается тем же. Когда растущая сложность достижения совершенства и растущая простота исправления проблем в будущем (быстрая автоматическая сборка, распространение через Интернет) сочетаются с напряжением графика и отсутствием дисциплины, результатом является то, что это такое.
Вероятно, нет серебряной пули, но хорошая комбинация лучших практик, включая, но не ограничиваясь:
Стоит отметить, что оба пункта направлены на снижение сложности. Это ключевой момент. Энтропия всегда имеет тенденцию к увеличению, и если мы не будем бороться с этим, мы скоро утонем в сложности. Также интересно видеть, что за последние несколько лет языки программирования развивались в направлении поощрения или даже обеспечения соблюдения вышеупомянутых методов. В частности, рост функциональных языков заключается в следующем: чистые функции всегда возвращают одно и то же значение для одного и того же ввода, в них нет состояния . Тогда вы просто Compose чистые функции , которые принимают и возвращают неизменные значения , и ограничить неизбежную переменчивость для небольших четко определенных мест , вместо того , чтобы распространять его все вокруг. Проверьте это: http://clojure.org/state
источник
Разница лишь в том, насколько проще и дешевле модифицировать программное обеспечение по сравнению с аппаратным обеспечением. Если бы аппаратное обеспечение было легко и дешево модифицировать и доставлять клиентам, они бы это сделали.
Вы должны обязательно проверить разработку через тестирование .
источник
Я прокомментирую некоторые ваши замечания, надеясь, что вы получите ответ из этих комментариев.
Это связано с тем, что спецификация решения является неполной или потому, что план предоставления улучшений не является точным. Это может произойти с любым программным, аппаратным или любым другим проектом.
Конечно, создание независимых модулей должно значительно уменьшить зависимость. Это необходимо учитывать при разработке программного обеспечения. Необходимо учитывать разделение задач, уровней, уровней, объектов контроллера, интерфейсов и т. Д.
1-Понимать требования внимательно. Может быть, вам нужно рассмотреть вопрос о закрытии требований до проектирования. Если вы делаете итеративную разработку, у вас нет шансов сделать это. Некоторые методологии поощряют это, но лично я думаю, что это не хорошо для всех типов проектов. Создание программного обеспечения на основе жестких требований позволяет улучшить дизайн.
2-Заставьте своего пользователя понять эту долгосрочную философию.
3-план реализации тщательно
4-Дизайн перед кодом.
5-Используйте общий дизайн, когда это уместно.
6-Использование прототипов в качестве инструмента подтверждения дизайна.
источник
Поскольку люди обычно очень быстро указывают на это, одним из преимуществ программного обеспечения является то, что его легко и относительно дешево менять по сравнению с аппаратным обеспечением. Это особенно важно, когда вы поздно понимаете, что у вас что-то в корне неправильно. Сделайте то же самое с аппаратным обеспечением, и вы потеряете миллион долларов, так что, как вы сказали, вы используете свои симуляторы и т. Д., И вы тестируете базинг из этого. Я думаю, что именно здесь парадигма терпит неудачу, когда вы переходите на программное обеспечение.
Получить в голову среднего разработчика программного обеспечения, и что у вас есть очень занятой человек с невероятно сжатым сроком. Его менеджер говорит, что можно оставить несколько ошибок, потому что вы всегда можете исправить это позже. Тесты часто являются запоздалой мыслью, но даже в сценарии, основанном на тестах, тесты сохраняются минимальными, а код записывается в минимум тестов, и часто используются короткие пути, так что многие из граничных случаев могут быть пропущены. Система может быть тщательно протестирована на единицу, но редко подвергается тщательному испытанию в целом и столь же редко подвергается стресс-тестированию в любой степени. Добавьте к этому то, что вы пишете программное обеспечение с нуля, и у вас мало возможностей для симуляции программного обеспечения, прежде чем приступить к его написанию, в первую очередь потому, что мы редко пишем программное обеспечение из того же рода детализированных строительных блоков, которые вы найдете в аппаратном обеспечении.
Вернуться к вопросу ОП. Не могли бы вы определить систему строительных блоков, из которых можно извлечь все ваше программное обеспечение? Возможно. Будет ли это очень экономически эффективным? Вероятно, нет, потому что к тому времени, когда вы приступите к разработке достаточно надежной системы компонентов, тестов и других принадлежностей, чтобы поддержать этот идеалСистема программирования, вы обнаружите, что ваши конкуренты уже опередили бы вас на рынке, и, что еще хуже, с точки зрения среднего программиста, вы, вероятно, нашли бы, что стиль программирования в стиле "резака печенья" очень ограничивающий и, скорее всего, очень скучно. Я лично работаю над API, где основная часть кода модуля была настолько доработана и стандартизирована, что все, что я сейчас делаю, - это генерирую шаблон кода и заполняю пробелы. Большую часть моего времени я могу потратить на написание простого кода соединителя и максимально быстрое извлечение модулей. Это серьезно ошеломляет. Существует очень мало возможностей делать больше, чем просто кодировать одни и те же вещи снова и снова, поэтому, когда появляется другая возможность проекта, я не упускаю шанс сделать НИЧЕГО еще.
Так как же получить качественное и хорошо продуманное программное обеспечение, и в то же время получать удовольствие от этого? Я считаю, что это зависит от вашего выбора инструментов и методологии. Для меня ответом было использование хорошего BDD API, потому что он позволил мне создать очень легкий для чтения, но очень детализированный код. Я могу построить набор тестов из минимального количества повторно используемых методов и описать свои тесты на языке спецификаций. Таким образом, я приближаюсь к более компонентному подходу к разработке, за исключением того факта, что я отвечаю за проектирование и проверку строительных блоков. Кроме того, выходные данные теста точно определяют ту часть теста, где происходит сбой, так что мне не нужно гадать, есть ли сбой в настройке или утверждении.
Настройка вашей методологии также помогает. Я большой сторонник применения принципов бережливого развития и объединения их со многими другими приемами и принципами, которыми на протяжении многих лет боролось движение Agile. Устранение большинства расточительных методов, которые я использовал, чтобы найти такие разочарования, очень помогло сделать разработку более приятным занятием. Я все еще остаюсь с проблемой, что иногда - но, надеюсь, не слишком часто - ошибки будут появляться в моем коде, однако теперь у меня больше времени и стимулов тратить больше времени на написание более надежных тестов и стремление к 100 % теста покрытия. Более того, очень приятно видеть, что все эти зеленые огни появляются в конце моего дня,
источник
Если это вас расстраивает, подумайте о другой карьере. Шутки в сторону.
Точка программного обеспечения, чтобы иметь возможность добавлять новые функции. Во-первых, вся причина изобретения «программного обеспечения» заключалась в том, чтобы мы могли добавлять новые функции.
Это проблема обеспечения качества.
Это также верно в отношении программного обеспечения.
Да. Вы должны практиковать обеспечение качества.
источник
Я рекомендую вам изучить « формальные методы » для проверки правильности конструкций и программного обеспечения. Инструменты симулятора, которые вы используете для проектирования оборудования, пытаются сделать что-то близкое. Я не верю, что инструменты для формальных методов где-то близки к тому, чтобы быть полезными в промышленности в настоящее время, и единственные отрасли, которые имеют сильные стимулы для отсутствия дефектов, это авионика и медицина (достаточно интересно, что FDA ясно говорит, что «программное обеспечение отличается от оборудования "по этой ссылке). Кроме того, если вы разрабатываете с Verilog / VHDL, то вы придерживаетесь бинарной логики. Это резко снижает сложность. Не будет аппаратного эквивалента проблеме 2000 года.
Большая проблема в том, что все сложно. И вы не можете устранить сложность, вы можете только переместить ее.
источник
В мире программного обеспечения мы называем этот «модуль» библиотекой и используем его точно так же. Многие библиотеки построены так, что они функционируют хорошо, а затем довольны, выполняя свою работу без изменений, пока что-то важное не приведет к следующей ревизии. Думайте о них как о программном обеспечении, которое было залито эпоксидной смолой :-)
Фигня. Возможно, вы лично лучше, чем многие другие «аппаратные» люди, не занимающиеся паяльником, но я видел множество неудачных схем, неисправных микросхем ( например , знаменитая проблема Intel «f00f»), но это не так говорить с полем в целом. И по мере того как изделия из искусственных материалов становятся «мягче», проблемы становятся все труднее предотвратить.
Да. Мы просто не используем эти методологии. Они, как правило, чрезвычайно дороги в эксплуатации, и большинству программистов не нравится работать в рамках их ограничений. Но когда речь идет, например, о человеческой жизни, да, мы стараемся не убивать пользователей.
И последнее замечание: у программного обеспечения финансовая модель отличается от аппаратной, даже программируемой. Большая часть непотребительского программного обеспечения, а также некоторые потребительские программы продаются таким образом, чтобы это стимулировало изменения. Когда вы можете сказать бизнесу: «Платите нам 10 000 долларов сейчас плюс 18% в год», вы можете перепродавать продукт каждые несколько лет. Но чтобы оправдать эту плату, вы должны предоставить клиенту изменения, которые они хотят. Хм ... если подумать о кривой устаревания оборудования Apple, возможно, в конце концов, это не имеет значения - аппаратные средства просто заставляют вас по- настоящему их покупать!
источник
Я хотел бы найти окончательный ответ на ваш вопрос. Но реальность такова, что не существует простого способа сделать это, поэтому экстремальное программирование и техника TDD становятся настолько популярными. Вы должны принять изменения, потому что это произойдет. Я не знаю, смешнее ли это, но гораздо менее напряженно, наверняка ;-)
http://en.wikipedia.org/wiki/Extreme_Programming
Когда вы взаимодействуете с аппаратным обеспечением, аппаратное обеспечение нуждается в значении х, и это все (теоретически), но когда вы взаимодействуете с людьми сегодня, они нуждаются в х, а завтра они могут нуждаться в у и т. Д. Это так, как меняются требования бизнеса и людей. , Поскольку люди! = Машины, поэтому код, который НИКОГДА не меняется в большинстве случаев, невозможен.
Также, как я сказал в моем предыдущем / удаленном ответе, постарайтесь избежать изменений, которые не важны, заставляя людей думать, прежде чем начать писать код. Больше вовлекайте пользователей в процесс принятия решений и т. Д. Уточняйте затраты на изменения, планируйте больше и т. Д. Это не «способы кодирования», а «не кодирование», потому что с большим количеством требований будет меньше изменений и больше веселья.
источник
Да, это. Просто будьте осторожны, как будто вы разрабатываете оборудование, тестируйте все, что можете, и ваше программное обеспечение будет такого же качества.
кстати, разве вы не слышали об ошибках HW? Гораздо страшнее любой ошибки программного обеспечения и ее сложнее исправить (а не просто обновить программное обеспечение)
источник
Я также хотел бы отметить, что программные ошибки в оборудовании часто могут убивать людей. Таким образом, больше внимания уделяется тщательному определению требований и тщательному их тестированию. И эти требования не должны изменяться, пока не изменится оборудование. И, поскольку новое оборудование может потребовать переписывания, я подозреваю, что это не так уж и много.
С другой стороны, бизнес-требования постоянно меняются, иногда вряд ли можно ввести одно требование в производство до того, как будет запрошено изменение. Иногда мне приходилось несколько раз менять требование, прежде чем оно попадет в производство. Это результат нескольких вещей. Во-первых, заинтересованная сторона проекта со стороны бизнеса часто менее заинтересована в том, чтобы тратить время на тщательное определение того, что он хочет, потому что он «занят» и «важен», и люди не умрут, а семьи будут судиться с ним или посадить его в тюрьму, если он сдувает свою часть процесса. Во-вторых, заинтересованные стороны проекта, как правило, имеют лучшее представление о том, что они хотят от оборудования, поскольку оно менее абстрактно для них. Они действительно не знают, чего хотят, пока не увидят это. Что меньше проблем с аппаратным обеспечением.
источник
Существуют инструменты высокого уровня с множеством готовых «кирпичиков», как вы их называете, которые вы можете объединить в приложения. Кирпичи - это готовые кусочки, которые вы можете использовать, вам просто нужно объединить их вместе. Может быть, вы думаете, что это проще ... пока ваш клиент не попросит вас о странных и неожиданных изменениях.
источник