Грамотное программирование, методология хорошего / плохого дизайна


10

Недавно я нашел концепцию грамотного программирования . И я нашел это довольно интригующим. И все же я не сталкивался с утверждениями, что это плохой способ структурировать программу. Кажется, не во многих местах. Даже здесь я не смог найти никаких вопросов по этому поводу.

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

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

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

Поэтому я хотел бы получить обратную связь о том, почему следует считать это плохой / хорошей методологией проектирования?


2
Zeroth, я создал тег для грамотного программирования и добавил резюме на основе статьи в Википедии. Пожалуйста, помогите расширить тег вики с соответствующей информацией.
Яннис

@YannisRizos Я добавлю это здесь, у меня нет прав на редактирование.
Нулевая

1
Ну, я тоже :) Я добавил некоторые ресурсы (статью в Википедии и ссылки в вашем вопросе), они появятся, когда редактирование будет рецензировано и принято (?!). Это интригующий подход, и, поскольку вы уже изучаете его, возвращайтесь и улучшайте тег вики каждый раз, когда вы найдете что-то, что, по вашему мнению, стоит упомянуть.
Яннис

1
Я бы порекомендовал автору сайта Literate Programming посетить сайт UX stackexchange - цвета действительно плохо читаются.
Дэнни Варод

1
К вашему сведению, literate-programmingна StackOverflow также есть тег. Там больше контента, хотя и не так много.
Росс Паттерсон

Ответы:


9

Это приведет к автоматической вставке кода вместо отдельной компиляции функции и последующего требования шага оптимизации межпроцедурной компиляции для получения эквивалентной скорости

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

Поэтому я хотел бы получить обратную связь о том, почему следует считать это плохой / хорошей методологией проектирования?

Там нет недостатков в грамотном программировании. (Я ожидаю десятки -1 голосов за это чувство.) Как практикующий, я никогда не видел никаких проблем.

Есть некоторые аргументы, против которых все сводится к тому, что «программирование на языке более высокого уровня может быть подорвано путем настройки результирующего кода». Правильно. Точно так же, как программирование на C ++ подрывается путем настройки создаваемого .oфайла. Это правда, но не имеет значения.

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

Когда Кнут изобрел грамотное программирование, основных ОО-языков не было. Поэтому большая часть оригинальных веб-инструментов и инструментов плетения позволила ему создать классоподобные определения для абстрактных типов данных.

Многое из этого не имеет значения в настоящее время. Инструменты грамотного программирования могут быть довольно простыми, если они ориентированы на современные высокоуровневые объектно-ориентированные (или функциональные) языки программирования. Существует меньше необходимости в сложных обходных решениях из-за ограничений C (или Pascal или Assembler).

Подход к написанию грамотных программ ничем не отличается от подхода к написанию неграмотных программ. Это все еще требует тщательного проектирования, модульного тестирования и аккуратного кодирования. Единственная дополнительная работа - написание объяснений в дополнение к написанию кода.

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

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


7
Большое количество программистов едва ли связно объясняют что-либо на любом носителе, формальном или неформальном, будь то грамотное программирование, написание комментариев или даже электронное письмо. Это удивительно, программное обеспечение работает вообще :)
Андрес Ф.

3

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

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

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


1

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

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

Для меня та же самая идея, или, по крайней мере, ее основа, такая же или, по крайней мере, тесно связана с грамотным программированием.

Например, в мире Groovy существует сильный стимул для более регулярного использования DSL и создания новых DSL для решения общих проблем. Этот толчок исходит как от инструментов в языке (простые сборщики), так и от базовых библиотек, поддерживающих API на основе DSL.

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

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

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


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

В версии 1.8 groovy возможности DSL на естественном языке были значительно улучшены с добавлением более мощных цепочек команд.

Например, следующие строки кода являются программированием , а не просто псевдо-предложениями:

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

Примечание: пример кода взят из блога Гийома Лафоржа

Основная идея, лежащая в основе грамотного программирования, заключается в том, что естественный язык более понятен людям, и именно это имеет значение. На мой взгляд, возможности DSL на языке Groovy делают эту реальность намного ближе. Особенно, когда эти DSL используются для создания бизнес-правил для приложения.

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

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

Для большего количества примеров этого в действии (без определенного порядка):


2
Интересная точка зрения. С моей точки зрения, он не очень хорошо сочетается с DSL. Поскольку грамотное программирование написано на не-DSL языке. И инструменты не очень похожи на DSL. Они не ориентированы на проблемную область. Не могли бы вы привести пример того, как вы думаете, грамотное программирование похоже на DSL? Ссылка или ссылка на пример может помочь уточнить ваш ответ.
С.Лотт

Одним из примеров этого являются цепочки команд в Groovy 1.8, которые позволяют «программировать» такими вещами, как turn left then rightили paint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/…
cdeszaq

@ S.Lott - Я согласен, что есть определенная разница между DSL и грамотным программированием, но я думаю, что DSL могут быть инструментом для достижения истинно грамотного программирования, где вы можете печатать на естественном языке и выражать желаемый алгоритм. Для меня смешение естественного языка и кода - ублюдочная форма грамотности.
cdeszaq

«Вы можете печатать на естественном языке и выражать желаемый алгоритм» в лучшем случае маловероятно. Есть справочная информация, обоснование, подтверждение правильности, утверждения о сложности (big- O ) и множество неалогритмической подтверждающей документации, которая не является частью схемы DSL. Я не уверен, что согласен с параллелью теперь, когда вы ее прояснили.
С.Лотт

1
«объяснение логики программы». Не сама логика. Но объяснение. Логика редко говорит сама за себя. Он никогда не содержит доказательств правильности (это сложно, а иногда и невозможно). Он редко содержит обоснование сложности big-O. И это редко объясняет альтернативы, которые являются или более низкой производительностью или большим объемом памяти. Итак, я бы предположил, что DSL не дотягивает до «объяснения».
S.Lott

-2

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

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

Сегодня многие программисты пишут код, а иногда добавляют комментарии! Байт-программа - это не только код - это мысли, идеи, воображение, концепции, а когда новый разработчик наследует чужой код - он часто ломает все идеи и концепции, создает разные «лазейки» и «черные ходы», надеюсь, вы меня понимаете :)

Таким образом, основное требование для LP (как инструмента!) Слишком разрешает все это с простым, легким, читаемым синтаксисом. Я перепробовал много инструментов LP, но сегодня я разрабатываю собственный - NanoLP ( http://code.google.com/p/nano-lp/ ), который призван удовлетворить этот спрос.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.