Масштабирование грамотного программирования?

Question

Привет.Сейчас я немного присматриваюсь к грамотному программированию, и мне нравится идея, лежащая в его основе:вы в основном пишете небольшой документ о своем коде и записываете как можно больше проектных решений, код, вероятно, окружающий модуль, внутреннюю работу модуля, предположения и выводы, вытекающие из проектных решений, потенциальное расширение, все это можно записать вниз хорошим способом, используя tex.Согласен, первый пункт:это документация.Его необходимо поддерживать в актуальном состоянии, но это не должно быть так уж плохо, потому что ваше изменение должно иметь обоснование, и вы можете это записать.

Однако как грамотное программирование масштабируется в большей степени?В целом, Грамотное Программирование — это всего лишь текст.Текст, конечно, очень удобочитаемый, но все же текст, и поэтому за большими системами сложно следить.Например, я переработал большую часть своего компилятора, чтобы использовать >> и немного магии для объединения шагов компиляции, потому что некоторые "x.register_follower(y);y.register_follower(z);y.register_follower(a);..." стал действительно громоздким, и изменение его на x >> y >> z >> a сделало его немного лучше, хотя это тоже находится на пределе возможностей.

Итак, как же Грамотное Программирование масштабируется на более крупные системы?Кто-нибудь пытается это сделать?

Моя идея заключалась в том, чтобы использовать LP для определения компонентов, которые взаимодействуют друг с другом с помощью потоков событий, и объединить их все вместе, используя подмножество графвиза.Это было бы вполне естественным расширением LP, поскольку вы можете извлечь документацию (диаграмму потока данных) из сети, а также очень хорошо сгенерировать на ее основе код.Что вы думаете об этом?

-- Тета.

Answer 1

Отличный вопрос.Мотивация к грамотному программированию никогда не исчезнет, ​​но я думаю, что к этому следует относиться как к гибкому.Это означает «дайте читателю передышку и объясните ему, что вы пытаетесь сделать».Я не думаю, что это означает «сделайте свой код по-настоящему многословным».

Тем не менее, читателю придется приложить некоторые усилия, в зависимости от того, что он уже знает.По-видимому, код стоит понять, и ничего не дается бесплатно.

Я также думаю, что это означает нечто большее, чем просто создание читаемого кода.Скорее всего, причина, по которой кто-то читает код, заключается в том, что ему нужно внести изменения.Вы должны предвидеть возможные изменения, которые могут потребоваться, и рассказать им, как это сделать, если это необходимо.

Answer 2

Книга «Физически обоснованный рендеринг». (pbrt.org) — лучший пример масштабного грамотного программирования, который мне известен.В книге реализована полноценная система рендеринга, и текст книги, и код трассировки лучей генерируются из одного и того же «источника».

На практике я обнаружил, что просто использовать такую ​​систему, как Doxygen, по-настоящему копаться и использовать все ее функции лучше, чем полноценное «грамотное» программирование, за исключением подобных вещей, т.е.учебники, учебные материалы.

Answer 3

Около 15 лет назад я немного занимался программированием в WEB.Совсем недавно я попробовал извлечь код из вики и создать документацию из среды Squeak Smalltalk.

С восходящей частью можно относительно хорошо справиться, генерируя документы из фреймворков TDD/BDD, но LP фокусируется на объяснении кода читателю.

Есть несколько проблем:

• история, которую нужно рассказать, разная для разных заинтересованных сторон/читателей;
• структура проекта в большинстве случаев не является структурой, необходимой для рассказывания историй;
• поддержка последовательного уточнения/раскрытия отсутствует;
• помимо текста необходима поддержка картинок;
• из комментариев в системе контроля версий можно понять, как была построена система.История должна рассказывать о том, как можно было построить систему (с полным ретроспективным подходом).

Чтобы LP работал в более крупных системах, вам нужна лучшая поддержка IDE, чем вики или браузер объектов.

Answer 4

«В целом, грамотное программирование все еще просто текст»

ЛОЖЬ.

С диаграммами все в порядке.

Я бы подумал использовать LP для указания компонентов, которые взаимодействуют друг с другом с помощью потоков событий.

Это просто архитектура, и это нормально.

вы можете извлечь документацию - диаграмму потока данных - из сети, а также очень хорошо сгенерировать из нее код.Что вы думаете об этом?

Диаграммы потоков данных на самом деле не очень полезны для создания подробного кода.Это удобное резюме, а не точный источник информации.

Хороший инструмент для письма (например, LaTex) может закодировать диаграмму в документе.Вероятно, вы могли бы найти путь к диаграмме из других частей документации.

Нижняя граница

В конечном итоге лучше создать диаграмму как краткое изложение текста.

Почему?

Диаграммы намеренно умалчивают детали.Диаграмма – это сводка или обзор.Но как источник кода диаграммы ужасны.Для того, чтобы предоставить все детали, схемы становятся очень загроможденными.

Но схематическое изложение какой-либо другой разметки LP вполне подойдет.

Answer 5

пбрт — это физически обоснованный трассировщик лучей, написанный в грамотном стиле для обучения выпускников компьютерных наук (и меня), это умеренно крупномасштабная система.Для неспециалиста-программиста этот уровень документации очень важен для понимания того, что делает программа и почему она это делает.

У меня также есть доступ к средству исследовательского рендеринга на Java, которое хорошо написано, но относительно недокументировано, за исключением нескольких статей SIGGRAPH.Это тоже относительно понятно, но у меня тоже есть доступ к авторам.

Я также использовал ИзображениеJ довольно много, и заглянул под капот базовой Java - за ней довольно сложно следить, не имея представления о базовой философии.

Подводя итог, я считаю, что грамотное программирование — это здорово, если кто-то может найти время, чтобы делать это хорошо, и это, скорее всего, будет в образовательных учреждениях.Трудно представить, чтобы это делалось при создании коммерческого кода.Я скептически отношусь к идее, что код может быть полностью самодокументируемым.

Answer 6

Идея грамотного программирования заключается в акценте на документации, где код разбросан по документации, а не на комментариях, разбросанных по коду.

Это существенно другая философия, и такие различия, как более длинные имена переменных, пространства имен и классы, не влияют на философию.Грамотное программирование выступает за осмысленные имена переменных.

Он масштабируется до более крупных систем, поскольку базовое соотношение документации и кода линейно масштабируется в зависимости от размера кода.

Answer 7

Грамотное программирование было разработано в эпоху, когда длинные имена переменных и функций были просто невозможны.Из-за этого код действительно был не очень читабельным.

Очевидно, с тех пор многое произошло.

В современном мире сам код является документацией, отсюда и термин «код самостоятельного документирования». Реализация заключается в том, что ни один набор комментариев или внешней документации не может оставаться синхронизацией с базовым кодом.Итак, цель многих современных программистов — написать код так, чтобы его могли читать другие.

Answer 8

Попробуйте NanoLP - расширяемый инструмент LP, поддерживает множество форматов документов (Markdown, OpenOffice, Creole, TeX, Asciidoc и другие), импорт других программ LP, создание шаблонов и многое другое.Пользователь может добавлять собственные команды/макросы (на Python), например, для специального импорта, например, из VCS...http://code.google.com/p/nano-lp