Як людям вдається написати та підтримувати надзвичайно складний і важко читається код? [зачинено]

Читання вихідного коду SQLite - місія IMO неможлива. Але це корисна частина досить складного програмного забезпечення (це все-таки повноцінна вбудована база даних), яку можна завантажувати, компілювати та використовувати з інших кодів, і вона постійно оновлюється.

Як людям вдається написати та підтримувати такий надзвичайно складний і важко читається код?

Існує велика різниця між складними та складними. Наступне посилання про його підсумки :)

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicate.aspx

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

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

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

У конкретному випадку SQLite основним інструментом, який вони обрали для розробки та обслуговування, є автоматизоване тестування. Вони пишаються 100-відсотковим покриттям (покриття відділеннями, а не покриття звітів) у своєму тестовому наборі. За їх словами, це один з найкращих тестованих програмних продуктів у світі. Тож вони одразу знають, коли щось, що вони додали чи змінили, викликає регрес, і можуть розвиватися досить безстрашно внаслідок цього.

http://sqlite.org/testing.html

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

EDIT: Це питання піднято з мертвих, схоже! І трохи більше, ніж через рік, ця ж сторінка повідомляє, що у них в 1177 разів більше рядків тестового коду, ніж у виробництві!

• функціональність розвивається з часом.
  • нові функціональні можливості визначаються новими вимогами замовника.
  • Старий код був написаний таким чином, що дозволяє додавати майбутні функції, які ще реалізуються, не порушуючи старий код.
• фахівці з домену (у цьому випадку база даних - це добре відомий домен у галузі комп'ютерних наук.)
• відгуки спільноти
  • клопи
• крута крива навчання не була проблемою для добре підготовлених та наполегливих. Це може зайняти 6 місяців, 1 рік або навіть довше, щоб стати комфортно, і це те, що деякі люди можуть миритися.
• комерційні мотивації. без грошової підтримки дуже мало людей можуть вкласти час та енергію у круту криву навчання.

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

SQLite насправді порівняно невеликий у масштабі "великих програмних проектів", але якщо ви подивитеся на щось на зразок операційної системи Windows, у вас з’являться люди, які просто працюють над ядром, люди, які просто працюють на оболонці, люди, які просто працюють в Internet Explorer, люди, які щойно працюють з менеджером Window, тощо. Хтось, хто працює в "оболонці", не зможе виправити помилку в ядрі при падінні капелюха.

Також є користь у тому, що ці проекти розвиваються з часом: вони не завжди починали це складно. Це означає, що нового розробника зазвичай можна «навчити» більш досвідченим розробникам.

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

Для проектів з відкритим кодом, таких як SQLite, насправді трохи складніше, тому що існуючі розробники не мають мотивації "навчати" нових розробників. Таким чином, ви дізнаєтесь, що на самому собі трохи більше. Але ви все ще можете знайти допомогу на форумах розробників чи списках розсилки (наприклад, просто розмістити запитання на зразок "Я хотів би реалізувати таку функцію" та "Я знайшов помилку XYZ, з чого я починаю шукати?", І ви, ймовірно, отримаєте якась форма допомоги.

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

Моя порада:

• Переконайтесь, що ви розумієте мову проекту. Мало знати мову.
• Дізнайтеся кожну деталь про домен, перш ніж ставити на руки код.

Для мене SQLite далеко не складний і нічого складного. Сфера цього проекту вимагає глибокого розуміння широких понять.

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

Як людям вдається написати та підтримувати такий надзвичайно складний і важко читається код?

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

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

Ви можете обернути голову навколо будь-якої бази кодів, якщо у вас є - наполегливість, терпіння та методичний підхід - але в основному наполегливість :-)

Управління стає набагато простішим, якщо речі робляться завжди однаково. Я не знаю коду SQLite, але я працюю в середовищі, де є кілька проектів. Окрім розуміння ділового випадку (eq логіки), оскільки в основному все робиться однаково скрізь (доступ до бази даних тощо), відносно легко розпочати роботу над іншим проектом. Короткий короткий текст: Правила кодування - відповідним чином - полегшують життя та такий код. Це може бути одним з помічників для кодерів SQLite.

• Якщо ви оригінальний автор програмного забезпечення, і ви працювали з ним протягом 10 років, і ви геній, то, можливо, можна зрозуміти все це. Великі фрагменти складного програмного забезпечення (наприклад, SQLite або Linux ядро) дійсно зазвичай мають саме одного оригінального автора, який має повне глибоке розуміння цього, навіть якщо інші люди зробили внесок.
• Якщо архітектура програмного забезпечення є розумною (висока згуртованість, низька зв'язаність), розуміння всього цього не є необхідною умовою для внесення корисних доповнень та модифікацій до нього.
• Розуміння RDBMS або ОС - це дещо особливі випадки, що вимагають глибокого розуміння основних CS принципів. Не так із звичайними програмними програмами.

Вони намагаються написати це просто, але не спрощено.

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

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

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