Масштабирование грамотного программирования?
-
08-07-2019 - |
Вопрос
Привет.Сейчас я немного присматриваюсь к грамотному программированию, и мне нравится идея, лежащая в его основе:вы в основном пишете небольшой документ о своем коде и записываете как можно больше проектных решений, код, вероятно, окружающий модуль, внутреннюю работу модуля, предположения и выводы, вытекающие из проектных решений, потенциальное расширение, все это можно записать вниз хорошим способом, используя tex.Согласен, первый пункт:это документация.Его необходимо поддерживать в актуальном состоянии, но это не должно быть так уж плохо, потому что ваше изменение должно иметь обоснование, и вы можете это записать.
Однако как грамотное программирование масштабируется в большей степени?В целом, Грамотное Программирование — это всего лишь текст.Текст, конечно, очень удобочитаемый, но все же текст, и поэтому за большими системами сложно следить.Например, я переработал большую часть своего компилятора, чтобы использовать >> и немного магии для объединения шагов компиляции, потому что некоторые "x.register_follower(y);y.register_follower(z);y.register_follower(a);..." стал действительно громоздким, и изменение его на x >> y >> z >> a сделало его немного лучше, хотя это тоже находится на пределе возможностей.
Итак, как же Грамотное Программирование масштабируется на более крупные системы?Кто-нибудь пытается это сделать?
Моя идея заключалась в том, чтобы использовать LP для определения компонентов, которые взаимодействуют друг с другом с помощью потоков событий, и объединить их все вместе, используя подмножество графвиза.Это было бы вполне естественным расширением LP, поскольку вы можете извлечь документацию (диаграмму потока данных) из сети, а также очень хорошо сгенерировать на ее основе код.Что вы думаете об этом?
-- Тета.
Решение
Отличный вопрос.Мотивация к грамотному программированию никогда не исчезнет, но я думаю, что к этому следует относиться как к гибкому.Это означает «дайте читателю передышку и объясните ему, что вы пытаетесь сделать».Я не думаю, что это означает «сделайте свой код по-настоящему многословным».
Тем не менее, читателю придется приложить некоторые усилия, в зависимости от того, что он уже знает.По-видимому, код стоит понять, и ничего не дается бесплатно.
Я также думаю, что это означает нечто большее, чем просто создание читаемого кода.Скорее всего, причина, по которой кто-то читает код, заключается в том, что ему нужно внести изменения.Вы должны предвидеть возможные изменения, которые могут потребоваться, и рассказать им, как это сделать, если это необходимо.
Другие советы
Книга «Физически обоснованный рендеринг». (pbrt.org) — лучший пример масштабного грамотного программирования, который мне известен.В книге реализована полноценная система рендеринга, и текст книги, и код трассировки лучей генерируются из одного и того же «источника».
На практике я обнаружил, что просто использовать такую систему, как Doxygen, по-настоящему копаться и использовать все ее функции лучше, чем полноценное «грамотное» программирование, за исключением подобных вещей, т.е.учебники, учебные материалы.
Около 15 лет назад я немного занимался программированием в WEB.Совсем недавно я попробовал извлечь код из вики и создать документацию из среды Squeak Smalltalk.
С восходящей частью можно относительно хорошо справиться, генерируя документы из фреймворков TDD/BDD, но LP фокусируется на объяснении кода читателю.
Есть несколько проблем:
- история, которую нужно рассказать, разная для разных заинтересованных сторон/читателей;
- структура проекта в большинстве случаев не является структурой, необходимой для рассказывания историй;
- поддержка последовательного уточнения/раскрытия отсутствует;
- помимо текста необходима поддержка картинок;
- из комментариев в системе контроля версий можно понять, как была построена система.История должна рассказывать о том, как можно было построить систему (с полным ретроспективным подходом).
Чтобы LP работал в более крупных системах, вам нужна лучшая поддержка IDE, чем вики или браузер объектов.
«В целом, грамотное программирование все еще просто текст»
ЛОЖЬ.
С диаграммами все в порядке.
Я бы подумал использовать LP для указания компонентов, которые взаимодействуют друг с другом с помощью потоков событий.
Это просто архитектура, и это нормально.
вы можете извлечь документацию - диаграмму потока данных - из сети, а также очень хорошо сгенерировать из нее код.Что вы думаете об этом?
Диаграммы потоков данных на самом деле не очень полезны для создания подробного кода.Это удобное резюме, а не точный источник информации.
Хороший инструмент для письма (например, LaTex) может закодировать диаграмму в документе.Вероятно, вы могли бы найти путь к диаграмме из других частей документации.
Нижняя граница
В конечном итоге лучше создать диаграмму как краткое изложение текста.
Почему?
Диаграммы намеренно умалчивают детали.Диаграмма – это сводка или обзор.Но как источник кода диаграммы ужасны.Для того, чтобы предоставить все детали, схемы становятся очень загроможденными.
Но схематическое изложение какой-либо другой разметки LP вполне подойдет.
пбрт — это физически обоснованный трассировщик лучей, написанный в грамотном стиле для обучения выпускников компьютерных наук (и меня), это умеренно крупномасштабная система.Для неспециалиста-программиста этот уровень документации очень важен для понимания того, что делает программа и почему она это делает.
У меня также есть доступ к средству исследовательского рендеринга на Java, которое хорошо написано, но относительно недокументировано, за исключением нескольких статей SIGGRAPH.Это тоже относительно понятно, но у меня тоже есть доступ к авторам.
Я также использовал ИзображениеJ довольно много, и заглянул под капот базовой Java - за ней довольно сложно следить, не имея представления о базовой философии.
Подводя итог, я считаю, что грамотное программирование — это здорово, если кто-то может найти время, чтобы делать это хорошо, и это, скорее всего, будет в образовательных учреждениях.Трудно представить, чтобы это делалось при создании коммерческого кода.Я скептически отношусь к идее, что код может быть полностью самодокументируемым.
Идея грамотного программирования заключается в акценте на документации, где код разбросан по документации, а не на комментариях, разбросанных по коду.
Это существенно другая философия, и такие различия, как более длинные имена переменных, пространства имен и классы, не влияют на философию.Грамотное программирование выступает за осмысленные имена переменных.
Он масштабируется до более крупных систем, поскольку базовое соотношение документации и кода линейно масштабируется в зависимости от размера кода.
Грамотное программирование было разработано в эпоху, когда длинные имена переменных и функций были просто невозможны.Из-за этого код действительно был не очень читабельным.
Очевидно, с тех пор многое произошло.
В современном мире сам код является документацией, отсюда и термин «код самостоятельного документирования». Реализация заключается в том, что ни один набор комментариев или внешней документации не может оставаться синхронизацией с базовым кодом.Итак, цель многих современных программистов — написать код так, чтобы его могли читать другие.
Попробуйте NanoLP - расширяемый инструмент LP, поддерживает множество форматов документов (Markdown, OpenOffice, Creole, TeX, Asciidoc и другие), импорт других программ LP, создание шаблонов и многое другое.Пользователь может добавлять собственные команды/макросы (на Python), например, для специального импорта, например, из VCS...http://code.google.com/p/nano-lp