Цитата Торвальдса о хорошем программисте [закрыто]

Случайно я наткнулся на следующую цитату Линуса Торвальдса:

«Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их отношениях».

Я думал об этом последние несколько дней, и я все еще в замешательстве (что, вероятно, не очень хороший знак), поэтому я хотел обсудить следующее:

• Какая интерпретация этого возможна / имеет смысл?
• Что можно применить / извлечь из этого?

Это может помочь рассмотреть то, что Торвальдс сказал прямо перед этим:

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

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

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

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

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

Алгоритмы + структуры данных = программы

Код - это просто способ выражения алгоритмов и структур данных.

Эта цитата очень знакома одному из правил "Искусства программирования на Unix", которое является сильной стороной Торвальдса как создателя Linux. Книга находится онлайн здесь

Из книги приводится следующая цитата, в которой разъясняется, что говорит Торвальдс.

Правило представления: объедините знания в данные, чтобы логика программы была глупой и надежной.

Даже простейшую процедурную логику людям сложно проверить, но довольно сложные структуры данных довольно легко моделировать и рассуждать. Чтобы увидеть это, сравните выразительность и объяснительную силу диаграммы (скажем) дерева указателей из пятидесяти узлов с блок-схемой программы из пятидесяти строк. Или сравните инициализатор массива, выражающий таблицу преобразования, с эквивалентным оператором switch. Разница в прозрачности и ясности драматична. См. Правило Роба Пайка 5.

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

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

Код прост, это логика кода сложна.

Если вы беспокоитесь о коде, это означает, что вы еще не овладели этими основами и, вероятно, потерялись в комплексе (то есть структурах данных и их отношениях).

Чтобы немного расширить ответ Моронса , идея состоит в том, что понимание особенностей кода (синтаксиса и, в меньшей степени, структуры / компоновки) достаточно просто, чтобы мы создали инструменты, которые могут это сделать. Компиляторы могут понимать все, что нужно знать о коде, чтобы превратить его в работающую программу / библиотеку. Но компилятор не может на самом деле решить проблемы, которые делают программисты.

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

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

Линус означает это:

Покажи мне свои блок-схемы [код] и скрой свои таблицы [схему], и я буду продолжать загадывать; покажи мне свои таблицы [схемы], и мне обычно не нужны твои блок-схемы [код]: они будут очевидны.

- Фред Брукс, «Мифический человеко-месяц», гл. 9.

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

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

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

Однако высшие вещи важнее.

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

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

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

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

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

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

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

Если вы вернетесь назад на двадцать лет назад, это было одним из главных преимуществ для объектно-ориентированного подхода с использованием SmallTalk, C ++ или Java. Большой шаг - по крайней мере, с C ++, потому что это то, что я узнал первым, - это дизайн класса и методов, а затем все остальное встало бы на свои места.

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

Что можно применить / извлечь из этого?

Если позволите, мой опыт за последние несколько недель. Предыдущие обсуждения прояснили ответ на мой вопрос: «что я узнал?»

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

• После проверки моей первоначальной поставки бизнес-аналитик сказал мне, что она не работает. Мы сказали «добавить 30 дней», но мы имели в виду «добавить месяц» ( день в итоговой дате не меняется). Добавить отдельные годы, месяцы, дни; например, не 540 дней в течение 18 месяцев.

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

Выплата

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

В Исправление кода поведения / результатов:

• Я изменил структуру данных, а не алгоритм.
• Никакая логика управления не была затронута где-либо в коде.
• API не был изменен.
• Класс фабрики структуры данных не изменился вообще.

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

Не могу согласиться с Линусом. Сосредоточение на данных помогает значительно упростить простое и гибкое решение данной проблемы. Сам Git является убедительным примером - благодаря тому, что в годы разработки было поддержано так много функций, основная структура данных практически не изменилась. Это волшебство! --2c

Я видел это в многочисленных областях.

Подумайте о бизнес-анализе ... Допустим, вы анализируете лучший способ поддержки маркетинга в компании по производству потребительских товаров, такой как Colgate. Если вы начнете с модных окон или новейших технологий, вы не поможете бизнесу почти так же сильно, как если бы вы сначала продумали потребности бизнеса в данных, а потом стали беспокоиться о презентации. Модель данных превосходит программное обеспечение для презентаций.

Подумайте о создании веб-страницы. Намного лучше сначала подумать о том, что вы хотите показать (HTML), а потом о стиле (CSS) и сценариях (выбрать инструмент).

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

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

показатель качества кода = [изменения кода] / [изменения схемы базы данных]

«Покажите мне свои блок-схемы и скройте ваши таблицы, и я буду продолжать озадачен. Покажите мне ваши таблицы, и мне обычно не понадобятся ваши блок-схемы; они будут очевидны». (Фред Брукс)

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

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