Программирование: в язык и нестандартно

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

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

В качестве альтернативы он заявляет, что

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

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

Нестандартно

Некоторые выступают против теории программирования в языке. Они утверждают, что языковые идиомы и другие особенности языка будут мешать. В 2008 году Джон Скит заявил, что стили программирования делают программирование на языке неоптимальным, что иллюстрируется Java, написанной в стиле C++.

Это верное замечание, но я думаю об этой концепции немного по-другому. Для меня это не столько стиль, сколько инструменты. Без ограничений языка программирования, говорящих вам, что вы можете и чего не можете делать, вы создадите лучший дизайн. Меньше размышлений об имеющихся у вас инструментах и ​​больше о наилучшем решении позволяет раскрыться вашему творческому потенциалу. Программирование — чрезвычайно творческое занятие; некоторые даже говорят программирование — это искусство.

Техника программирования на языке

Любое программирование начинается с проблемы. Типичный поток может выглядеть примерно так:

Определение проблемы. — Подумайте, что мы пытаемся решить. Задайте кучу вопросов. Когда вы думаете, что нашли основную проблему, задайте больше вопросов. Действительно добраться до сути проблемы. Легко остановиться на поверхности. Легко думать, что вы нашли проблему, которую нужно решить, только чтобы обнаружить, что копали недостаточно глубоко. Ключевыми здесь являются пять почему.

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

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

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

Запрограммируйте решение. — К настоящему времени я обдумал проблему, еще немного подумал о проблеме, спроектировал что-то стоящее, начал писать псевдокод, и я готов либо написать несколько тестов, либо просто начать применять структуру, которую я хочу.

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

Что подводит меня к другому моменту. Ищите существующие решения. Если вы нашли подходящий вариант и оценили его, используйте его. Оценка зависимостей — это совсем другая тема. Главное не быть привязанным к инструментам языка.

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

Принятие ограничений

Но как насчет принятия ограничений? Конечно, это может быть хорошо. Это правда. Иногда может. Возможно, вы ограничены в том, что можно реализовать. Возможно, из-за временных ограничений вам придется придерживаться фреймворка или языка.

Тот же процесс применим. Что меняется, так это этап проектирования. Если вы не можете найти что-то в языке или фреймворке, вам нужно сделать резервную копию и убедиться, что в дизайне используется что-то доступное.

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

Соавтор: Кэролайн Джоб