Об авторе. Тудор Гриба — разработчик свободного редактора кода Glamorous Toolkit. Это программируемая MDE с движком визуализации и встроенной системой управления знаниями. В своей программной статье автор объясняет, с какой целью создана среда разработки Moldable Development Environment.
Давайте разберёмся, на что уходит время разработчиков. Самый старый из известных мне источников по этой теме — книга «Принципы разработки и проектирования программного обеспечения» Зелковица, Шоу и Гэннона (1979). Там написано, что две трети времени программиста уходит на сопровождение проектов.
Скан страницы:
Затраты на разработку программного обеспечения (1979)
Конечно, в книге не сообщается, откуда такая цифра. Но последующие исследователи посчитали проблему достаточно важной и уделили ей значительное внимание.
Итак, насколько мы продвинулись спустя почти четверть века?
Вот недавняя научная статья Ся, Бао, Ло, Син, Хассана и Ли «Измерение понимания программ. Крупномасштабное полевое исследование с участием профессионалов» в журнале IEEE Transactions on Software Engineering (44, 951-976, 2018). Статья интересна тем, что в ней очень подробно описывается, как получены цифры. И там говорится, что процесс понимания (сomprehension) занял в среднем ~58% всего времени.
Теперь внимательнее посмотрите на таблицу.
Среднее время, которое разработчики тратят на понимание, навигацию, редактирование и другие задачи
Скрипичная диаграмма затрат на разработку программного обеспечения (2018)
Конкретно, посмотрите на третий столбец в таблице. Там говорится, что на навигацию приходится 24% усилий. То есть она вообще считается отдельно!
Итак, спустя четверть века можно констатировать: время на понимание программ практически не изменилось. Ну разве что мы научились его хорошо измерять.
Что же теперь?
Ну, это самая большая «статья расходов». Если мы хотим что-то оптимизировать в нашей отрасли, следует обратить внимание именно на неё. Мы часто рассуждаем о разработке систем, но как часто мы обсуждаем время, которое требуется для их понимания? Если об этом не говорить, то мы не увидим проблему. А если не увидим, то и не решим.
Со стороны процесс «понимания системы» выглядит как чтение. Так оно и есть. Как показано в вышеупомянутой работе, понимание реально измеряется как чтение! Эти два понятия считаются синонимами.
Но что же происходит на самом деле? Процесс познания — как он выглядит, что он в себя включает?
Поскольку за четверть века мы не сдвинулись с мёртвой точки, возможно, следует сформулировать проблему по-другому.
Пожалуйста, потерпите немного. Сейчас будет интересно.
Итак, зачем разработчики читают код? Они хотят понять ситуацию и определить, что делать дальше. Намерение очень важно. Это принятие решения.
Время на выяснение ситуации — это время на принятие решения
С этой точки зрения, чтение — просто способ извлечь информацию из данных. И это самый медленный способ, что открывает широкие возможности для оптимизации.
Если вы хотите произвести важные изменения в каком-то явлении, нужно дать ему название. Иначе будет как с Волдемортом. Много лет назад я ввёл термин «оценка» (assessment) как определение усилий по «изучению системы, чтобы понять, что делать дальше». И я утверждал, что мы должны оптимизировать разработку вокруг этого ключевого понятия.
Оценка — это процесс понимания ситуации в системе, достаточный для принятия решения
В течение целого десятилетия мы с коллегами исследовали эту идею. И в результате пришли к тому, что назвали «формуемой разработкой» (moldable development) [в процессе которой можно изготовлять и применять пресс-формы (molds) для штампования инструментов, подходящих к решению конкретных проблем — прим. пер.].
Что это такое?
Если сравнивать процесс извлечения информации из программного кода с производственным процессом, то чтение — это работа вручную. Она не масштабируется, порождает проблемы из-за неполной информации и неопределённости.
Программное обеспечение — сложная система. Незнание текущей системы не должно быть переменной в уравнении. Нарисованная от руки картинка о текущей системе — это вера. Надёжные решения нельзя строить на вере. Только не инженерные системы.
Когда мы признали, что системы — это данные, становится очевидным, что и подходить к ним нужно как к данным. Наука о данных говорит, что нужно отталкиваться от проблемы, а затем использовать инструмент, соответствующий контексту.
Инструменты должны соответствовать контексту
В программных системах многое зависит от контекста. Поэтому невозможно предсказать конкретные проблемы. Только классы проблем. Ключевая идея формуемой разработки — после определения проблемы изготовить инструмент. Таким образом, инструмент будет работать с учётом контекста, а для его применения не нужно будет тратить время на чтение кода. Конечно, для удобства практического использования процесс изготовления кастомных инструментов должно быть простым и быстрым.
Мне кажется, что конвейер по созданию кастомных инструментов во время разработки, а в идеале для каждой отдельной проблемы — это следующий большой скачок в разработке программного обеспечения.
Через десятилетие мы не должны измерять «понимание системы» в терминах чтения. Мы должны тратить энергию на решение реальных проблем. Для начала нужно подумать, как избавиться от чтения кода. Мы не можем себе его позволить, оно отнимает слишком много ценного времени.
Мы создали Glamorous Toolkit, чтобы начать разговор на тему «Как избавиться от чтения кода». Это среда разработки, которая позволяет быстро создавать пользовательские инструменты для работы с программными системами.
Так что заходите на сайт. Поиграйте с редактором. Почувствуйте #MoldableDevelopment.
Присоединяйтесь к каналу в дискорде.
Сделаем этот разговор реальным.
По теме:
Давайте разберёмся, на что уходит время разработчиков. Самый старый из известных мне источников по этой теме — книга «Принципы разработки и проектирования программного обеспечения» Зелковица, Шоу и Гэннона (1979). Там написано, что две трети времени программиста уходит на сопровождение проектов.
Скан страницы:
Затраты на разработку программного обеспечения (1979)
Конечно, в книге не сообщается, откуда такая цифра. Но последующие исследователи посчитали проблему достаточно важной и уделили ей значительное внимание.
Итак, насколько мы продвинулись спустя почти четверть века?
Вот недавняя научная статья Ся, Бао, Ло, Син, Хассана и Ли «Измерение понимания программ. Крупномасштабное полевое исследование с участием профессионалов» в журнале IEEE Transactions on Software Engineering (44, 951-976, 2018). Статья интересна тем, что в ней очень подробно описывается, как получены цифры. И там говорится, что процесс понимания (сomprehension) занял в среднем ~58% всего времени.
Теперь внимательнее посмотрите на таблицу.
Среднее время, которое разработчики тратят на понимание, навигацию, редактирование и другие задачи
| Проект | Понимание | Навигация | Редактирование | Другое |
|---|---|---|---|---|
| В среднем | 57,62% | 23,96% | 5,02% | 13,40% |
| A | 63,37% | 19,31% | 5,02% | 12,30% |
| B | 55,80% | 24,83% | 6,36% | 13,02% |
| C | 58,86% | 27,62% | 3,90% | 9,62% |
| D | 53,32% | 28,36% | 5,31% | 13,01% |
| E | 56,15% | 23,59% | 5,53% | 14,73% |
| F | 64,05% | 20,30% | 4,66% | 10,99% |
| G | 51,80% | 28,02% | 4,59% | 15,41% |
Скрипичная диаграмма затрат на разработку программного обеспечения (2018)
Конкретно, посмотрите на третий столбец в таблице. Там говорится, что на навигацию приходится 24% усилий. То есть она вообще считается отдельно!
Итак, спустя четверть века можно констатировать: время на понимание программ практически не изменилось. Ну разве что мы научились его хорошо измерять.
Что же теперь?
Ну, это самая большая «статья расходов». Если мы хотим что-то оптимизировать в нашей отрасли, следует обратить внимание именно на неё. Мы часто рассуждаем о разработке систем, но как часто мы обсуждаем время, которое требуется для их понимания? Если об этом не говорить, то мы не увидим проблему. А если не увидим, то и не решим.
Со стороны процесс «понимания системы» выглядит как чтение. Так оно и есть. Как показано в вышеупомянутой работе, понимание реально измеряется как чтение! Эти два понятия считаются синонимами.
Но что же происходит на самом деле? Процесс познания — как он выглядит, что он в себя включает?
Поскольку за четверть века мы не сдвинулись с мёртвой точки, возможно, следует сформулировать проблему по-другому.
Пожалуйста, потерпите немного. Сейчас будет интересно.
Итак, зачем разработчики читают код? Они хотят понять ситуацию и определить, что делать дальше. Намерение очень важно. Это принятие решения.
Время на выяснение ситуации — это время на принятие решения
С этой точки зрения, чтение — просто способ извлечь информацию из данных. И это самый медленный способ, что открывает широкие возможности для оптимизации.
Если вы хотите произвести важные изменения в каком-то явлении, нужно дать ему название. Иначе будет как с Волдемортом. Много лет назад я ввёл термин «оценка» (assessment) как определение усилий по «изучению системы, чтобы понять, что делать дальше». И я утверждал, что мы должны оптимизировать разработку вокруг этого ключевого понятия.
Оценка — это процесс понимания ситуации в системе, достаточный для принятия решения
В течение целого десятилетия мы с коллегами исследовали эту идею. И в результате пришли к тому, что назвали «формуемой разработкой» (moldable development) [в процессе которой можно изготовлять и применять пресс-формы (molds) для штампования инструментов, подходящих к решению конкретных проблем — прим. пер.].
Что это такое?
Если сравнивать процесс извлечения информации из программного кода с производственным процессом, то чтение — это работа вручную. Она не масштабируется, порождает проблемы из-за неполной информации и неопределённости.
Программное обеспечение — сложная система. Незнание текущей системы не должно быть переменной в уравнении. Нарисованная от руки картинка о текущей системе — это вера. Надёжные решения нельзя строить на вере. Только не инженерные системы.
Когда мы признали, что системы — это данные, становится очевидным, что и подходить к ним нужно как к данным. Наука о данных говорит, что нужно отталкиваться от проблемы, а затем использовать инструмент, соответствующий контексту.
Инструменты должны соответствовать контексту
В программных системах многое зависит от контекста. Поэтому невозможно предсказать конкретные проблемы. Только классы проблем. Ключевая идея формуемой разработки — после определения проблемы изготовить инструмент. Таким образом, инструмент будет работать с учётом контекста, а для его применения не нужно будет тратить время на чтение кода. Конечно, для удобства практического использования процесс изготовления кастомных инструментов должно быть простым и быстрым.
Мне кажется, что конвейер по созданию кастомных инструментов во время разработки, а в идеале для каждой отдельной проблемы — это следующий большой скачок в разработке программного обеспечения.
Через десятилетие мы не должны измерять «понимание системы» в терминах чтения. Мы должны тратить энергию на решение реальных проблем. Для начала нужно подумать, как избавиться от чтения кода. Мы не можем себе его позволить, оно отнимает слишком много ценного времени.
Мы создали Glamorous Toolkit, чтобы начать разговор на тему «Как избавиться от чтения кода». Это среда разработки, которая позволяет быстро создавать пользовательские инструменты для работы с программными системами.
Так что заходите на сайт. Поиграйте с редактором. Почувствуйте #MoldableDevelopment.
Присоединяйтесь к каналу в дискорде.
Сделаем этот разговор реальным.
По теме:
- «При найме разработчика попросите его читать существующий код». Так можно оценить способности программиста к пониманию системы, а именно этот процесс занимает основную часть рабочего времени, судя по результатам вышеупомянутого исследования. Непосредственно написание кода после полного понимания уже не представляет особой трудности при наличии необходимых навыков кодирования.
