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

Випадково я натрапив на таку цитату Лінуса Торвальда:

"Погані програмісти турбуються про код. Хороші програмісти турбуються про структуру даних та їх зв'язки."

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

• Яке тлумачення цього можливого / має сенс?
• Що можна застосувати / дізнатися з цього?

Це може допомогти розглянути те, що Торвальдс сказав прямо перед цим:

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

Він говорить, що хороші структури даних роблять код дуже простим у розробці та обслуговуванні, тоді як найкращий код не може компенсувати погані структури даних.

Якщо вам цікаво прикладу git, багато систем управління версіями відносно регулярно змінюють свій формат даних, щоб підтримувати нові функції. Під час оновлення для отримання нової функції вам часто доводиться запускати якийсь інструмент для перетворення бази даних.

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

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

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

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

Ця цитата дуже знайома з одним із правил у "Мистецтві програмування Unix", який Форвальд Торвальдс є творцем Linux. Книга знаходиться тут в Інтернеті

З книги наведена наступна цитата, яка пояснює те, що говорить Торвальдс.

Правило представництва: складіть знання в дані, щоб логіка програми могла бути дурною та надійною.

Навіть найпростішу процедурну логіку люди важко перевірити, але досить складні структури даних досить легко моделювати та міркувати. Щоб побачити це, порівняйте виразність та пояснювальну силу діаграми (скажімо) дерева вказівника на п'ятдесят вузлів із схемою послідовності п’ятдесяти рядкової програми. Або порівняйте ініціалізатор масиву, що виражає таблицю перетворення, з еквівалентним оператором перемикання. Різниця у прозорості та чіткості є драматичною. Дивіться правило 5 Роба Пайка.

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

Спільнота Unix не виникла з цього розуміння, але багато код Unix демонструє його вплив. Можливість мови C, зокрема, маніпулювати покажчиками, заохочує використання динамічно модифікованих опорних структур на всіх рівнях кодування від ядра вгору. Прості погони на покажчики в таких структурах часто виконують обов'язки, які, натомість, втілення в інші мови повинні були втілювати в собі більш детальні процедури.

Код легко, це логіка, що стоїть за кодом, який є складним.

Якщо ви турбуєтесь про код, це означає, що ви ще не отримаєте цих основ і, швидше за все, втратите комплекс (тобто структури даних та їх зв’язки).

Щоб трохи розширити відповідь Моронса , ідея полягає в тому, що зрозуміти особливості коду (синтаксис і, в меншій мірі, структуру / макет) досить легко, щоб ми створили інструменти, які можуть це зробити. Компілятори можуть зрозуміти все, що потрібно знати про код, щоб перетворити його у функціонуючу програму / бібліотеку. Але компілятор насправді не може вирішити проблеми, які роблять програмісти.

Ви можете зробити аргумент ще на крок далі і сказати "але у нас є програми, які генерують код", але код, який він створює, заснований на певному введенні, який майже завжди створюється вручну.

Отже, який би шлях ви не дійшли до коду: будь то через якусь конфігурацію чи інший вхід, який потім виробляє код через інструмент, або якщо ви пишете його з нуля, це не важливий код. Важливе значення має критичне мислення всіх фрагментів, які потрібні. У світі Лінуса це значною мірою структури даних та взаємозв'язки, хоча в інших областях це можуть бути й інші фрагменти. Але в цьому контексті Лінус просто говорить: "Мені все одно, чи можете ви написати код, мені байдуже, що ви можете зрозуміти речі, які вирішать проблеми, з якими я маю справу".

Лінус означає це:

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

- Фред Брукс, «Міфічний місяць людини», ч. 9.

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

І те й інше важливо, але я погоджуюся, що загалом набагато краще зрозуміти велику картину та мати проблеми з деталями, ніж навпаки. Це тісно пов'язане з тим, що я намагався висловити про розбиття великих функцій на маленьких .

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

Однак вищі речі важливіші.

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

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

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

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

Малоцінний матеріал є важливим, а його важливе значення часто серйозно занижується, але воно блідне порівняно з великим.

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

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

Якщо ви повернетесь назад через двадцять років, це було однією з найбільших точок продажу об'єктно-орієнтованого підходу, використовуючи або SmallTalk, C ++, або Java. Великий крок - принаймні, за допомогою C ++, тому що це я навчився спочатку - було проектувати клас та методи, а потім все інше стане на свої місця.

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

Що можна застосувати / дізнатися з цього?

Якщо можна, мій досвід останніх тижнів. Попередні дискусії пояснили відповідь на моє запитання: "чого я навчився?"

Я переписав деякий код і розмірковував над результатами, які я постійно бачив і говорив "структура, структура ...", чому була така різка різниця. Тепер я бачу, що все змінило саме структура даних . І я маю на увазі все .

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

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

Розплата

• Нова реалізація мала більше функціональних можливостей, але код алгоритму був коротшим і явно простішим.

У фіксації поведінки / результатів коду:

• Я змінив структуру даних, а не алгоритм.
• Ніякої логіки управління не торкалося ніде в коді.
• Жоден API не змінено.
• Фабричний клас структури даних взагалі не змінився.

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

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

Я бачив, що це численні області.

Подумайте про бізнес-аналіз ... Скажімо, ви аналізуєте найкращий спосіб підтримки маркетингу в компанії споживчих товарів на зразок Colgate. Якщо ви почнете з вигадливих вікон або найновіших технологій, ви не допоможете бізнесу майже так само, як якщо б спочатку продумати потреби в даних, а потім піклуватися про презентацію. Модель даних переживає програмне забезпечення для презентації.

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

Це не означає, що кодування теж не важливо. Вам потрібні навички програмування, щоб отримати в кінцевому підсумку те, що вам потрібно. Саме дані є основою. Погана модель даних відображає або надмірно складну, або непродуману бізнес-модель.

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

якість індикатора коду = [зміни коду] / [зміни схеми бази даних]

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

Схоже, ця ідея має різні інтерпретації в різних видах програмування. Це справедливо для розвитку систем, а також стосується розвитку підприємств. Наприклад, можна стверджувати, що різкий зсув уваги до домену в дизайні, орієнтованому на домен, дуже схожий на фокус на структурах даних та відносинах.

Ось моя інтерпретація цього: Ви використовуєте код для створення структур даних, тому слід зосередити увагу на останніх. Це як будівництво мосту - ви повинні налаштувати проектувати міцну конструкцію, а не ту, яка виглядає привабливо. Так буває, що добре написані структури даних та мости виглядають добре в результаті їх ефективних конструкцій.