Як проекти з відкритим кодом можуть бути успішними без документації про їх дизайн чи архітектуру?

11

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

Тому я вирішив прочитати їх документацію щодо їх дизайну чи архітектури (наприклад, UML-діаграми), щоб спершу отримати загальне уявлення про організацію коду. На мій подив, однак, я не можу знайти жодної архітектурної документації для великих проектів з відкритим кодом, таких як Hibernate, Spring, ASP.NET MVC, Rails тощо.

Тож я почав замислюватися: Яким чином проект з відкритим кодом може бути успішним, якщо розробники нових розробників не мають архітектурної / проектної документації для читання, або якщо менеджер проекту просто відкрив вихідний код, але закрив свою документацію?

open-source documentation asp.net-mvc

— TomCaps
джерело

3

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

— S.Lott

@ S.Lott Вибачте за суб'єктивне "найбільше". Я новачок у галузі програмного забезпечення. Я намагаюся шукати документи, про які я чув у школі коледжу (наприклад, UML-діаграма, блок-схема, короткий дизайн-документ, детальний дизайн-документ тощо) для згаданих проектів як на веб-сайті проекту, так і в сховищі коду, але без удачі, лише знайти якийсь посібник користувача doc. Ви можете, будь ласка, навчити мене якихось поширених способів пошуку їхніх документів про походження / архітектуру?

— TomCaps

1

Видаліть "Багато". Це так само неправильно, як і більшість. будь ласка , поновіть питання конкретно перерахувати конкретні проекти з відкритим вихідним кодом , які конкретно НЕ вистачає конкретної документації , який ви хочете бачити. Будьте точні та конкретні. Будь ласка, не будьте суб’єктивними та розпливчастими.

— S.Lott

Я підозрюю, що причина ASP.NET MVC не включає UML-діаграми в тому, що Visual Studio може створювати їх з вихідного коду.

— user16764

5

Ви працюєте за помилковим припущенням, що "підприємливість" - це добра справа. Те, що ви дізналися в коледжі про дизайн - це все брехня: UML абсолютно не має значення. Створюючи проект, все, що вам потрібно, - це загальне уявлення про те, що він повинен робити, і готовність викинути його, якщо ви зробите це неправильно з першого разу. Для існуючого проекту, як правило, достатньо лише прогортання головного заголовка, щоб добре уявити про макет проекту.

— o11c

10

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

Припущення незмінно робиться так, що ви знаєте, що робите, і маєте досить інтимне розуміння того, що ви збираєтесь (і очікуєте) побачити.

Наприклад, якщо ви заглянете в PHP-код рамки Symfony, то, можливо, ви вже будете знати про введення залежності, події, модель / перегляд / контролер тощо.

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

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

Коротше кажучи, якщо вам не вистачає будь-яких навичок, які очікують, що вас знають, до моменту, коли ви зазирнете до їх коду, ви, ймовірно, перебираєте речі, що значно перевищують ваш рівень оплати. Познайомтеся спочатку з поняттями - що таке модель MVC? Що таке ін'єкційна залежність? Тоді пірнайте.

— Дені де Бернарді
джерело

1

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

— edA-qa mort-ora-y

17

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

— Ніл
джерело

У моїй компанії, це вимога, згідно з якою розробники повинні надати Детальний проектний документ перед затвердженням написати будь-який код на проект. Чи ця процедура ненормальна для проекту з відкритим кодом?

— TomCaps

5

@TomCaps Я думаю, що найбільшою причиною того, що так мало проектів FOSS є обширна документація, є досить проста: якщо ви пишете невелику програму для вирішення необхідної вами проблеми , то, швидше за все, оскільки ваш розробник, що вам також не потрібна документація, ви Ви хочете витратити свій час на вдосконалення програми, а не на написання документації, яка не гарантована навіть для когось корисною (що робити, якщо проект ніколи не використовується, окрім розробника?). Це не найкраща практика, але багато проектів FOSS не вистачає часу для розробника.

— Джефф Веллінг

5

@TomCaps: Ця процедура є ненормальною для більшості компаній, які я знаю ...

— Треб,

1

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

— Елін

1

@TomCaps - кожен, хто пише програмне забезпечення з відкритим кодом, може робити саме те, що їм подобається. У деяких проектах (наприклад, сімейство Apache) є правила та вказівки для тих, хто вводить код, а іноді це включає стандарти дументації і т.д. мій особистий досвід), як правило, неоптимальний. Детальний опис програми "що" має робити, залишає розробника вільним для оптимізації реалізації та застосування креативних стратегій до рішення.

— Джеймс Андерсон

12

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

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

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

— MaR
джерело

8

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

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

— ГрандмайстерB
джерело

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

— Василь Старинкевич