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