Чи писати програмне забезпечення простіше, ніж читати та розуміти його з нуля? [зачинено]

Я та мій друг обговорили вчора розбіжності між написанням великого програмного забезпечення C ++ та розумінням його як нового рекрута.

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

Спочатку це звучить дивно, але після того, як ми трохи подумали, це здалося розумним

Виходячи зі свого досвіду, я б класифікував такі дії для того, щоб від найлегших до найважчих.

1. Читання хорошого коду
2. Написання неправильного коду
3. Написання хорошого коду
4. Читання неправильного коду

Наведений вище рейтинг призводить до 2 висновків

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

Звичайно, хороший і поганий код - це широкі узагальнення. Я рекомендую Code Complete і Clean Code для отримання більш детальної інформації про хороший код.

Це питання звертається до помилкового консенсусу. http://en.wikipedia.org/wiki/False-consensus_effect

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

відмінності між написанням великого програмного забезпечення на C ++ та розумінням його як нового рекрута

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

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

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

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

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

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

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

Більшість програмістів легше зрозуміти код, який вони написали самі, порівняно з кодом, який написали інші люди. Це пов’язано як із згаданим вище лінійним навчанням, так і просто питанням індивідуального стилю та таланту. Ось чому трапляється стільки інновацій колеса.

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

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

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

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

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

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

Це призводить до питання: чи це має значення?

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

Все це правда, новіші методики розробки, наприклад BDD , визнають, що для логіки бізнесу важливо зрозуміти код, а не код просто бути засобом для управління машиною. Це, звичайно, не є новим - ця концепція існувала з моменту семінарської роботи Дональда Кнута: Грамотне програмування .

Я вкладаю відповідь StMotorSpark, просто додаю:
Це залежить від дуже багатьох факторів, наприклад, це не може бути питання "так" або "ні":

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