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

238

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

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

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

  • Какая интерпретация этого возможна / имеет смысл?
  • Что можно применить / извлечь из этого?
beyeran
источник
18
Я думаю, что этот вопрос, вероятно, имеет несколько ответов, которые одинаково действительны. Но это хороший вопрос в любом случае. Мне нравится эта цитата. Это объясняет, почему я не понимаю программистов, которые беспокоятся о переключении языков. Редко язык, который имеет значение в программе, это структуры данных и то, как они связаны.
Райан Кинал
5
Может быть, если вы потратите время на то, чтобы сделать структуры данных «элегантными», тогда не нужно извлекать код для работы с этими структурами данных? Я, вероятно, слишком туп, чтобы действительно знать смысл цитаты Торвальдса. :}
программист
3
@RyanKinal Но, конечно, язык имеет значение , потому что он значительно облегчает работу и анализ определенных структур данных. Подумайте, например, обо всех языках, которые специализируются на LISt Parsing, или о языках, которые имеют встроенную поддержку структур данных, которые должны быть взломаны на другие языки (на ум приходят наборы и разреженные массивы).
Кодзиро
83
Кстати, Торвальдс не одинок в этом: «Покажи мне свою блок-схему и спрячь свои таблицы, и я буду продолжать удивляться. Покажи мне свои таблицы, и мне обычно не понадобится твоя блок-схема; это будет очевидно». " - Фред Брукс, Мифический человеко-месяц. «Покажи мне свой код и скрой свои структуры данных, и я буду продолжать загадывать. Покажи мне свои структуры данных, и мне, как правило, не понадобится твой код; это будет очевидно». и «Умные структуры данных и тупой код работают намного лучше, чем наоборот». - Эрик С. Рэймонд, Кафедральный собор и базар.
Йорг W Mittag
4
Это объясняет, почему ядро ​​Linux - беспорядок :)
l1x

Ответы:

326

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

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

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

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

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

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

Карл Билефельдт
источник
25
лучший код не может восполнить плохие структуры данных, хорошая правда, это правда
Конрад Фрикс
5
Он говорит с точки зрения программистов, вносящих изменения в сам git. Точка зрения конечного пользователя полностью ортогональна этому обсуждению, за исключением легко поддерживаемого создания кода для меньшего количества ошибок и более быстрого добавления функций.
Карл Билефельдт
2
@James: он говорит, что программное обеспечение лучше (следовательно, проще в использовании и используется большим количеством людей), потому что структуры данных лучше. Конечно, вам не нужно знать о структурах данных программного обеспечения, которое вы используете, но вы заботитесь о них косвенно, даже если вы этого не понимаете, потому что структуры данных - это то, что движет теми вещами, которые вы действительно понимаете. заботиться о.
Руах
1
+1. Этот ответ помещает контекст в утверждение, которое в противном случае могло бы быть истолковано как означающее нечто совершенно иное. Любой, кто прочитал монструозность файла в 5000 строк, точно знает, что я имею в виду.
Rwalk
20
«Сначала надо беспокоиться о структурах данных, и ваш код, естественно, будет чище». Римский государственный деятель Катон ( en.wikipedia.org/wiki/Cato_the_Elder ) говорил: «Rem tene, verba sequentur» = «Получите аргумент ясно в ваш разум, слова будут следовать естественно ". То же самое и с программированием: сначала разберитесь в структурах данных и дизайне, сам код будет следовать сам по себе.
Джорджио
60

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

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

оборота zxcdw
источник
Последнее издание ethoberon.ethz.ch/WirthPubl/AD.pdf
dchest
Это верно для процедурного программирования; в ООП немного по другому.
m3th0dman
3
Это не принципиально какой - либо иной. У вас есть данные и вы выполняете множество операций с ними. Член переменные и методы. Точно так же. Вся сущность вычислений с 50-х годов была построена на том очень простом правиле, что программы состоят из алгоритмов, модифицирующих структуры данных, и это продолжает действовать 60 лет спустя. Вы также можете рассматривать программы как функции . Они берут вход, на котором они работают, чтобы произвести выход . Точно так же, как математические функции.
zxcdw
31

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

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

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

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

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

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

Джей Аткинсон
источник
Я тоже это запомнил!
Джесвин Хосе
1
ОТО, посмотрите на любой вопрос о StackOverflow int**. Это должно убедить вас, что данные на самом деле НЕ очевидны; это становится возможным только путем добавления значения к данным. И это значение в коде.
MSalters
29

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

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

дебилы
источник
17
Хех, интересно, будет ли следующее поколение программистов спрашивать: «Однажды придурки сказали Code is easy, it's the logic behind the code that is complex, что он имел в виду?»
Яннис
36
@YannisRizos Это будет особенно запутанно, когда люди не уверены, говорили ли они люди, которые были идиотами, или один человек по имени Моронс.
KChaloux
14

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

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

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

Даниэль ДиПаоло
источник
Каждый программист использует программы, которые генерируют код. Их часто называют «компиляторами», иногда в сочетании с «компоновщиками». Они принимают (относительно) удобочитаемый и читаемый человеком ввод, который обычно (но не всегда) предоставляется в каком-либо текстовом формате, и превращают его в данные, которые компьютер может понимать как инструкции и выполнять.
CVn
13

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

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

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

Дэниел Шоукросс Уилкерсон
источник
12

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

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

оборота ГленПетерсон
источник
+1: я с тобой согласен. Другой аспект заключается в том, что часто программисты больше беспокоятся о том, какую классную языковую функцию они собираются использовать, вместо того, чтобы сосредоточиться на своих структурах данных и алгоритмах и на том, как записать их простым и понятным способом.
Джорджио
Я тоже согласен. Дело в том, что легко изменить отдельные части кода, но сложнее изменить структуры данных или интерфейсы между частями кода (так как эти типы изменений могут влиять на многие вещи, а не только на одну вещь).
Брендан
5

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

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

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

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

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

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

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

Джон Ханна
источник
2

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

Том Ау
источник
2
Но сосредоточение внимания либо на лесу, либо на деревьях, исключая другого, может быть вредным, поэтому я не думаю, что эта аналогия подходит.
Кодзиро
1
@kojiro: В выражении не видно леса для деревьев , предполагается, что тот, кто видит лес, также увидит деревья (см. en.wiktionary.org/wiki/see_the_forest_for_the_trees ). Поэтому я думаю, что это хорошая аналогия здесь.
Треб
2

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

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

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

octopusgrabbus
источник
2

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

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

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

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

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

Выплата

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

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

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

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

Тюдор Уотсон
источник
1

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

mc2
источник
0

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

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

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

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

MathAttack
источник
0

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

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

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

Джоэл Джейкобсон
источник
-2

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

eulerfx
источник
-4

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

боб
источник