Подтвердить что ты не робот

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

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

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

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

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

- Tetha.

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

False.

Диаграммы в порядке.

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

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

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

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

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

Нижняя строка

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

Почему?

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

Но схематическое резюме какой-либо другой разметки LP будет хорошо работать.

Ответ 5

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

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

Я также довольно часто использовал ImageJ и смотрел под капюшон в базовой Java - довольно сложно следовать без идеи лежащей в основе философии.

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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