Сейчас в области Software Engineering все движеться в направлении развития надежных средств тестинга для исправления создавшихся ошибок по в процессе разработки. А нет ли каких то наработок в обратном направлении : создание надежных средств разработки с жесткими правилами не допускающих ошибок (предотвращение вместо исправления).
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Software Engineering
- Thread starter sealm
- Start date
Такие наработки есть, причём очень много.
Сначала отвлечение.
Первый тезис не совсем верен, Software Engineering движется во все стороны.
Сам вопрос тоже сформулирован слишком строго. Средств разработки, не допускающих ошибок, быть не может. А вот средства разработки, предотвращающие или снижающие число ошибок отдельных классов, разрабатываются непрерывно.
Всё развитие инструментальных средств - это борьба в том числе и с большим объёмом неконцептуальных ошибок. Один язык Ада со соответствующей инфраструктурой чего стоит. Но всё в мире взаимосвязано, а понятие "ошибки" настолько сложно, что борясь с некоторыми классами ошибок, мы теряем что-то другое. Поэтому важен компромисс. Навскидку рекомендую посмотреть некоторые эссе Джоэла Сполски, особенно про дырявые абстракции, "Мифический человекомесяц" Брукса, "Совершенный код" Макконнелла, историю создания Ады и Оберона.
Непосредственно сабжем занимаются огромные разделы теории алгоритмов, семантики и прагматики языков программирования, теории трансляции. Сюда же - методологии проектирования, модели ЖЦ, построение СПЖЦ.
Причём сколько всего конкретного придумано!
Принудительное проектирования, объектно-ориентированная парадигма в своём первоначальном виде, логическое и функциональное программирование и вообще декларативный подход к решению стандартных задач, шаблоны проектирования (от банды четырёх и далее). Программирование по контракту (предусловия и постусловия, автоматическая проверка инвариантов и т.д.), модульное программирование. Строгая типизация, сборщики мусора, умные указатели, виртуализация ресурсов. Автоматическая геннерация кода по модели. Автоматическая оптимизация. Автоматическая верификация и т.п.
Сначала отвлечение.
Первый тезис не совсем верен, Software Engineering движется во все стороны.
Сам вопрос тоже сформулирован слишком строго. Средств разработки, не допускающих ошибок, быть не может. А вот средства разработки, предотвращающие или снижающие число ошибок отдельных классов, разрабатываются непрерывно.
Всё развитие инструментальных средств - это борьба в том числе и с большим объёмом неконцептуальных ошибок. Один язык Ада со соответствующей инфраструктурой чего стоит. Но всё в мире взаимосвязано, а понятие "ошибки" настолько сложно, что борясь с некоторыми классами ошибок, мы теряем что-то другое. Поэтому важен компромисс. Навскидку рекомендую посмотреть некоторые эссе Джоэла Сполски, особенно про дырявые абстракции, "Мифический человекомесяц" Брукса, "Совершенный код" Макконнелла, историю создания Ады и Оберона.
Непосредственно сабжем занимаются огромные разделы теории алгоритмов, семантики и прагматики языков программирования, теории трансляции. Сюда же - методологии проектирования, модели ЖЦ, построение СПЖЦ.
Причём сколько всего конкретного придумано!
Принудительное проектирования, объектно-ориентированная парадигма в своём первоначальном виде, логическое и функциональное программирование и вообще декларативный подход к решению стандартных задач, шаблоны проектирования (от банды четырёх и далее). Программирование по контракту (предусловия и постусловия, автоматическая проверка инвариантов и т.д.), модульное программирование. Строгая типизация, сборщики мусора, умные указатели, виртуализация ресурсов. Автоматическая геннерация кода по модели. Автоматическая оптимизация. Автоматическая верификация и т.п.