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