Почему программное обеспечение так подвержено ошибкам? Почему программные продукты так часто откладываются или даже отменяются? Действительно ли разработка программного обеспечения сложна, или разработчики программного обеспечения просто не так хороши в этом? В статье Проблема с программным обеспечением Адам Барр, инсайдер отрасли, объясняет, почему существует так много плохого программного обеспечения и почему академические круги не учат программистов тому, что отрасль хочет, чтобы они знали.

Ниже прочтите отрывок из главы 11 книги Адама Барра Проблема с программным обеспечением.

Будущее

Книга [Атул] Гаванде Манифест контрольного списка имеет подзаголовок Как все исправить. В какой-то момент он разговаривает с инженером-строителем о том, как изменилась строительная отрасль:

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

Сегодняшние инженеры-программисты - мастера-строители, и им грозит поражение.

Гаванде также рассказывает о пилотах-испытателях с первых дней создания высокоскоростной авиации, как это описано в книге Тома Вулфа The Right Stuff. Им удалось добиться успеха благодаря импровизации и смелости, но в конце концов «возобладали ценности безопасности и добросовестности, и статус рок-звезд летчиков-испытателей пропал». [6] Вселенная применяет естественные поправки к пилотам-испытателям, которые не могут адаптироваться, но это не так. эффект существует в программном обеспечении; Средний и высший менеджмент компаний-разработчиков программного обеспечения полон успешных программистов-самоучок. Надеюсь, недавние выпускники слышали о шаблонах проектирования и модульных тестах; хотя они далеки от обеспечения научной основы для разработки программного обеспечения, по крайней мере, они открыли людям глаза на тот факт, что общепринятые знания возможны в индустрии программного обеспечения, что, в свою очередь, должно сделать их более открытыми для изучения новых способов, если мы сможем открыть их. Но, конечно, сначала их нужно обнаружить.

В противном случае нам придется столкнуться с другой цитатой из книги Гаванде:

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

Программисты неумелые? Я не думаю, что они в точности таковы, как Гаванде обвиняет медицину, что является главной темой его книги. Он говорит о ситуациях, в которых знание того, как оказывать надлежащую медицинскую помощь, несомненно, доступно и согласовано всеми участниками, но по разным причинам не применяется должным образом. Гаванде видит параллели с этой борьбой в «почти любом начинании, требующем мастерства сложности и большого объема знаний» - список, который для него включает в себя неудачи внешней разведки, шатающиеся банки и (мало ли он знает) несовершенный дизайн программного обеспечения [8].

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

В 1986 году [Фредерик П.] Брукс написал эссе под названием «Нет серебряной пули» - ссылку на боеприпасы, которые, по общему мнению, необходимы для убийства оборотней. «Мы слышим отчаянные крики о серебряной пуле, о чем-то, что заставит стоимость программного обеспечения упасть так же быстро, как и стоимость компьютерного оборудования», - посетовал он.

Но, заглядывая в будущее десятилетия спустя, мы не видим серебряной пули. Не существует единой разработки ни в технологии, ни в технике управления, которая сама по себе обещает хотя бы на порядок повышение производительности, надежности, простоты ... Сейчас не только нет серебряных пуль, но и сама природа программного обеспечения делает это маловероятно, что они будут. [9]

Брукс описывает то, что, по его мнению, составляет суть проблемы, присущие программному обеспечению трудности: сложность, согласованность (необходимость встраивать новый код в существующий API), изменчивость и невидимость (сложность визуализации внутренности). Он перечисляет различные разработки, которые могут помочь, включая объектно-ориентированное программирование (которое в то время только начинало преобразовываться в Object-Oriented Silver Bullet Amalgamated Holdings), но сомневается, что какое-либо из них обеспечит необходимую магию.

Девять лет спустя, почти в конце периода времени, который он рассматривал в исходной статье, Брукс выпустил следующее эссе «Никакая серебряная пуля» не обновилась », в котором обсуждалась реакция на оригинал. Он писал: «Большинство из них нападают на главный аргумент о том, что магического решения не существует, и на мое четкое мнение о том, что его не может быть. Большинство согласны с аргументами «NSB», но затем продолжают утверждать, что действительно существует серебряная пуля для программного зверя, изобретенного автором ». [10] Курсив мой, потому что я не могу придумать более краткого изложения продолжающейся вереницы предполагаемых программных панацеев.

Брукс заканчивает свое второе эссе коротким разделом, озаглавленным «Сеть на пулях - положение без изменений». Он цитирует известного обозревателя программного обеспечения Роберта Гласса в эссе в журнале System Development: «Наконец-то мы можем сосредоточиться на чем-то более жизнеспособном, чем пирог в небе. Теперь, возможно, мы сможем продолжить постепенные улучшения производительности программного обеспечения, которые возможны, вместо того, чтобы ждать прорывов, которые вряд ли произойдут »[11].

История разработки программного обеспечения была поиском серебряной пули. Структурированное программирование, формальное тестирование, объектно-ориентированные языки, шаблоны проектирования, гибкие методологии - все это полезно, но никто в одиночку не может убить оборотня. Я лично пережил все эти переходы, даже структурированное программирование; Из-за того, что я провел свои первые годы в пузыре самоучки Fortran и BASIC, я смог лично испытать закат GOTO, на десять лет позже, чем в остальной отрасли. Каждый из них начинался с малого, набирался сторонников и в конечном итоге был разрекламирован как решение всех проблем программирования, что привело к неизбежному разочарованию и разочарованию. Я могу понять, почему программисты безнадежно надеются на серебряную пулю и с нетерпением устремились к череде блестящих объектов. Как говорится, «любой порт в шторм». К сожалению, как выразился Парнас, «[программистов] накормили так много« серебряных пуль », что они больше ни во что не верят» [12].

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