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

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

Сьогодні я написав функціональне програмне забезпечення, і я засвоїв основи 3-х мов, і я проміжний лише в одній мові. Коли я дивлюся на передові речі, такі як програмування MYSQL або OpenGL, або навіть візуальний код студії C ++, це дає мені головні болі, і навіть при візуалізації вихідного коду HTML багатьох веб-сайтів (Більшість вихідних кодів на веб-сайтах, переглянуті google chrome, здаються дуже брудними та неорганізованими ) мене це бентежить до самої межі мого мозку. Спочатку все здається простим, але, дивлячись на ці передові речі, це просто змушує мене замислитися, як можна так багато навчитися.

Коротше кажучи, питання полягає в тому, якщо ці програми стануть зрозумілішими для програміста, коли він просувається в кар'єрі. Чи складніші теми, перелічені вище (OpenGL, MySQL, розширені html-сайти), стають легшими читати, писати та розуміти, коли ви дізнаєтесь більше, чи це просто ускладнюється, коли ви проходите? Як ти можеш боротися з цим почуттям того, що ти мураш у світі програмування, і ця штука збирається розчавити тебе?

Коротка відповідь: ні.

Довга відповідь:

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

• Ви не хочете просто писати код. Ви хочете написати гарний код .

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

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

• Ви не обмежуєтесь лише невеликим набором бібліотек, які знаєте. Якщо ви кодуєте в C #, ви хочете знати і використовувати всю потужність багатьох бібліотек .NET Framework.

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

• Ви не хочете скромно обмежувати себе основним набором інструментів, які надає вам мова . У C # ви хочете використовувати дженерики, кодові контракти, рефлексію, розвиток, керований подіями, функціональні аспекти з LINQ, реактивні розширення та багато інших речей, які ви дізналися, все в одному проекті, якщо ці речі допоможуть вам писати краще код.

• Ви не починаєте писати код . Ви витрачаєте від 80 до 90% свого часу на збирання потреб , на створення архітектури вашої програми, написання одиниць тестів, написання документації тощо, і лише 10-20% вашого часу пишете фактичний код .

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

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

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

Коротко:

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

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

3. ... І ти задаєш собі питання: "Як я могла це зробити?" точно так само, як і десять років тому, коли вам довелося відображати цифри на екрані з циклом.

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

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

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

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

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

Тут вже є кілька справді хороших відповідей, але я подумав, що можу додати ще кілька коротких моментів:

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

Це називається ефектом Даннінга-Крюгера . Це надзвичайно часто серед початківців програмістів, а насправді і у початківців у багатьох сферах.

Більшість вихідних кодів на веб-сайтах, які бачать Google Chrome, здаються дуже безладними та неорганізованими

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

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

За спеціалізацією . Я є експертом у надзвичайно вузькій галузі: розробка та реалізація семантичних аналізаторів компілятора C #. Якби я провів п’ятнадцять років, вивчаючи OpenGL, XML чи HTML чи будь-що інше, я би був знавцем цього та містифікований семантичними аналізаторами. Але я цього не зробив, і тому я маю лише дуже базове розуміння OpenGL, XML та HTML.

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

Так, тому що ви починаєте бачити більші візерунки. Візьмемо для прикладу OpenGL. Ви, напевно, бачили купу "бібліотек API" - великих фрагментів пов'язаного коду, де спосіб взаємодії з кодом викликає купу іменованих функцій з певними аргументами. І ви можете отримати базове розуміння OpenGL лише з розуміння того, що це API.

Коли ви набули більше досвіду і побачили купу різних методик програмування, то розумієте, що, здавалося б, не пов'язані між собою технології - скажімо, OpenGL та LINQ в C # - мають спільність. Обидва - це API, де ви створюєте робочі процеси, що передають дані навколо, і ви можете запускати оптимізатори та інші перетворення на робочому процесі насиченими та цікавими способами. Після того, як ви знайдете цю концепцію у вашій коробці інструментів, раптом стає набагато простіше використовувати всю потужність будь-якого API, який використовує цю схему.

Чи складніші теми, перелічені вище (OpenGL, MySQL, розширені html-сайти), стають легшими читати, писати та розуміти, коли ви дізнаєтесь більше, чи це просто ускладнюється, коли ви проходите?

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

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

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

Коротка відповідь, так.

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

Пам'ятайте, коли ви переглядаєте сайти з інструментів розробки у вашому браузері, вони часто генеруються рамкою. Нехай це буде будь-яка кількість речей ... ASP.NET, JSP, RoR, Django, ... хто знає. Деякі з цих рамок дають чистіший код, ніж інші.

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

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

Один із прикладів, який ви наводили, дивився на кучу HTML-коду:

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

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

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

Коротка відповідь ТАК, але багато залежить від того, як Ви визначаєте досвід.

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

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

2. Розуміння ТЕХНІЧНИХ вимог . Це як номер 1, за винятком його розуміння того, чому на технічному рівні. Деякі інструменти та технології мають свої примхи, поки ви не впоралися з ними, перш ніж важко зрозуміти, чому все робиться певним чином. Це більш очевидно, коли ви маєте справу зі застарілими системами. Наприклад, програма використовує певну службову шину, яка приймає лише XML.

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

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

Пам'ятайте, що досконалість (і мета) в чужому коді завжди відносно №1 і №2. Це основні драйвери, чому код знаходиться в такому стані, в якому він знаходиться. Часті зміни в цих двох областях є найбільшою причиною, чому ми постійно отримуємо код спагетті. Тому, якщо ви не вмієте читати ділові та технічні вимоги, завданням для читання коду завжди буде королівська PITA.

Це стає простіше і складніше одночасно!

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

переведено на розробку програмного забезпечення

Знати багато технологій - це мудрість. (Все походить від ALGOL)
Знання того, чого ви не знаєте, - це просвітлення. (LISP)
Оволодіння багатьма мовами, рамками та платформами вимагає великих зусиль. (Java)
Оволодіння лише тим, що потрібно знати, і лише те, що вимагає сил. (і Google або stackoverflow.com)
Знати, коли потрібно припинити кодування та доставити щось - це коли ти знаєш досить добре. (Ні паралізу аналізу, ні золочення)
Продовжуйте працювати над тим, що ви намагаєтеся досягти, це вимагає зосередженості та сили волі. (Все постійно змінюється, ти ніколи не закінчуєш)
Дотримуйся однієї або двох технологій, і ти будеш терпіти. (COBOL все ще добре платить, як і C)
Кинути програмування та перейти до управління - це вічно присутнє. (або залиште спадщину програмного забезпечення FOSS, яке всі надалі добре використовуватимуть після того, як ви померли).

Коротше кажучи, питання полягає в тому, якщо ці програми стануть зрозумілішими для програміста, коли він просувається в кар'єрі. Чи складніші теми, перелічені вище (OpenGL, MySQL, розширені html-сайти), стають легшими читати, писати та розуміти, коли ви дізнаєтесь більше, чи це просто ускладнюється, коли ви проходите? Як ти можеш боротися з цим почуттям того, що ти мураш у світі програмування, і ця штука збирається розчавити тебе?

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

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

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

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

Наприклад, усі три згадані вами мови (MYSQL, OpenGL, C ++) мають деякі спільні риси:

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

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

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

Коротка відповідь: Так , загалом

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

Коли ви рухаєтеся через час, ви отримуєте досвід.

По мірі руху в часі інші мови / візерунки тощо розвиваються паралельно вашому розвитку.

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

Хорошим питанням може бути також: чи ви занадто тонким чи товстим поширюєтесь певною мовою.

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

Усі ці варіації мають два виміри складності.

1. Їх лексика та синтаксис відрізняються.
2. Абстракції (концепції високого рівня), які вони підтримують, відрізняються.

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

Потім перейдіть на "легкі речі", такі як CSS, HTML, Javascript і, можливо, також такі рамки, як Bootstrap і React, і ваш мозок буде смажитися - як і Альберт Ейнштейн. Люди думають, що "я знаю французьку мову, тому вивчити німецьку мову слід просто". Немає!

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

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

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

Чи складніші теми, перелічені вище (OpenGL, MySQL, розширені html-сайти), стають легшими читати, писати та розуміти, коли ви дізнаєтесь більше, чи це просто ускладнюється, коли ви проходите? Як ти можеш боротися з цим почуттям того, що ти мураш у світі програмування, і ця штука збирається розчавити тебе?

Коли досягається якийсь прогрес, ми вчимося і заново вчимося тому, що думали, що знали раніше. - Генрі Девід Торо

Існує історія майстра Дзен і Переливного чашки .

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

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

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

Ваше ставлення має усе значення.