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

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

  

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

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

  • Какая интерпретация этого возможно /имеет смысл?
  • Что можно применить /узнать от него?
238 голосов | спросил 2 revs, 2 users 94%
beyeran
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

17 ответов


326

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

  

git фактически имеет простой дизайн со стабильными и достаточно хорошо документированными структурами данных. Фактически, я являюсь огромным сторонником разработки кода вокруг данных, а не наоборот, и я думаю, что это одна из причин, по которой git был довольно успешным [â € |] Я, по сути, утверждаю, что разница между плохим программистом и хорошим заключается в том, считает ли он свой код или свои структуры данных более важным.

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

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

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
60

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
31

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

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

  

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

     

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

     

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

     

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
29

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
14

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

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
13

Linus означает следующее:

  

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
12

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
5

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

Однако более важные вещи важнее.

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

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

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

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
2

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
2

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

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
2
  

Что можно применить /узнать от него?

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

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

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

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

Выплата

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

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

  • Я изменил структуру данных, а не алгоритм.
  • Никакая логика управления не была затронута в любом месте кода.
  • API не был изменен.
  • Класс фабрики данных не изменился вообще.
ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
1

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
1

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
0

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

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

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
0

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

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

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
-2

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19
-4

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

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132