Речь в данной заметке пойдет не об известном законе Брукса, связывающем количество людей, задействованных в проекте, и скорость разработки, а о менее известной статье, написанной им еще в 1987 году.
Статья называлась «No Silver Bullets – Essence and Accidents of Software Engineering». В ней утверждалось (и с этим сложно не согласиться), что сущностью программирования является, прежде всего, не написание инструкций машине на конкретном языке программирования, а выработка подробной структуры взаимодействующих сущностей, представляющих сущности проблемной области, а также проверка внутренней непротиворечивости этой структуры. Поэтому даже если, например, изобрести компьютерный язык, оперирующий понятиями на уровне проблемной области, или какое-либо другое средство, призванное существенно облегчить разработку ПО, программирование все равно останется сложной задачей, поскольку придется точно определять взаимосвязи между объектами реального мира, устанавливать исключения, предусматривать все возможные переходы между состояниями и т.д. Следовательно, ни одно средство разработки ПО не сможет существенно (на один-два порядка) снизить сложность разработки. Именно в описании структуры взаимодействующих сущностей проблемной области Брукс и видит главную сложность программирования.
Когда я прочел обзор данной статьи в книге С. Макконнелла «Профессиональная разработка программного обеспечения», я был поражен тем, насколько прозорлив оказался Брукс в своих рассуждениях, опубликованных более 20 лет тому назад. Примером, подтверждающими его правоту, в наше время могут являться языки визуального программирования (например, LabVIEW, SFC, LD и др.), оперирующими как раз на уровне предметной области. Еще два примера я сразу же нашел в своей практике.
Контора, в которой я работаю, занимается разработкой SCADA-систем для энергетических объектов (ГРЭС, ГЭС, АЭС, ТЭЦ и т.п.). Она разбита на 2 отдела: отдел программирования, разрабатывающий систему в целом, и отдел проектировки, занимающийся разработкой графических АРМ диспетчера для конкретных объектов. Второй отдел как раз по сути и выполняет программирование на уровне проблемной области, используя графические блоки, связывая их с БД и описывая дополнительную функциональность с помощью специального высокоуровневого языка. И сложность и объем работы этого отдела не меньше, чем у отдела программирования.
Параллельно с работой я учусь в аспирантуре, занимаюсь разработкой среды для моделирования генетического развития организмов. Сейчас мы разработали достаточно универсальную систему моделирования, позволяющую исследователю описывать процессы жизнедеятельности организмов с помощью набора достаточно простых математических правил. И тут-то мы и столкнулись с тем, что для конечного пользователя — биолога — создание данного описания, опирающегося на экспериментальные данные, и представляет главную проблему. Это связано как раз с необходимостью «выработки подробной структуры взаимодействующих сущностей проблемной области». Причем, похоже, эта проблема не может быть решена созданием более удобного пользовательского интерфейса, как нам сначала казалось. Сейчас работаем над этим…
Какие из всего этого можно сделать выводы? Ну, во-первых, можно сказать, что мы (программисты) без своей работы в ближайшие лет так 50 точно не останемся. Во-вторых, хотелось бы предостеречь коллег-разработчиков: если будете разрабатывать инструментальную среду, призванную автоматизировать работу пользователей, подумайте, не упретесь ли в описанную проблему — необходимость в навыках программирования (в том или ином виде) у конечного пользователя.
UPD: перенес в блог «Разработка»
UPD2: исправил неточности с языками визуального программирования, спасибо товарищу Fortums
Брукс о сложности программирования
Статья называлась «No Silver Bullets – Essence and Accidents of Software Engineering». В ней утверждалось (и с этим сложно не согласиться), что сущностью программирования является, прежде всего, не написание инструкций машине на конкретном языке программирования, а выработка подробной структуры взаимодействующих сущностей, представляющих сущности проблемной области, а также проверка внутренней непротиворечивости этой структуры. Поэтому даже если, например, изобрести компьютерный язык, оперирующий понятиями на уровне проблемной области, или какое-либо другое средство, призванное существенно облегчить разработку ПО, программирование все равно останется сложной задачей, поскольку придется точно определять взаимосвязи между объектами реального мира, устанавливать исключения, предусматривать все возможные переходы между состояниями и т.д. Следовательно, ни одно средство разработки ПО не сможет существенно (на один-два порядка) снизить сложность разработки. Именно в описании структуры взаимодействующих сущностей проблемной области Брукс и видит главную сложность программирования.
Практическое подтверждение
Когда я прочел обзор данной статьи в книге С. Макконнелла «Профессиональная разработка программного обеспечения», я был поражен тем, насколько прозорлив оказался Брукс в своих рассуждениях, опубликованных более 20 лет тому назад. Примером, подтверждающими его правоту, в наше время могут являться языки визуального программирования (например, LabVIEW, SFC, LD и др.), оперирующими как раз на уровне предметной области. Еще два примера я сразу же нашел в своей практике.
Контора, в которой я работаю, занимается разработкой SCADA-систем для энергетических объектов (ГРЭС, ГЭС, АЭС, ТЭЦ и т.п.). Она разбита на 2 отдела: отдел программирования, разрабатывающий систему в целом, и отдел проектировки, занимающийся разработкой графических АРМ диспетчера для конкретных объектов. Второй отдел как раз по сути и выполняет программирование на уровне проблемной области, используя графические блоки, связывая их с БД и описывая дополнительную функциональность с помощью специального высокоуровневого языка. И сложность и объем работы этого отдела не меньше, чем у отдела программирования.
Параллельно с работой я учусь в аспирантуре, занимаюсь разработкой среды для моделирования генетического развития организмов. Сейчас мы разработали достаточно универсальную систему моделирования, позволяющую исследователю описывать процессы жизнедеятельности организмов с помощью набора достаточно простых математических правил. И тут-то мы и столкнулись с тем, что для конечного пользователя — биолога — создание данного описания, опирающегося на экспериментальные данные, и представляет главную проблему. Это связано как раз с необходимостью «выработки подробной структуры взаимодействующих сущностей проблемной области». Причем, похоже, эта проблема не может быть решена созданием более удобного пользовательского интерфейса, как нам сначала казалось. Сейчас работаем над этим…
Выводы
Какие из всего этого можно сделать выводы? Ну, во-первых, можно сказать, что мы (программисты) без своей работы в ближайшие лет так 50 точно не останемся. Во-вторых, хотелось бы предостеречь коллег-разработчиков: если будете разрабатывать инструментальную среду, призванную автоматизировать работу пользователей, подумайте, не упретесь ли в описанную проблему — необходимость в навыках программирования (в том или ином виде) у конечного пользователя.
UPD: перенес в блог «Разработка»
UPD2: исправил неточности с языками визуального программирования, спасибо товарищу Fortums
