Чи нормально програміст часом не мати 100% ясності над власним кодом? [зачинено]

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

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

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

Ні, це не нормально ¹ . Принаймні, це не нормально для хороших програмістів. Напевно, це нормально, щоб хтось навчився програмувати.

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

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

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

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

Це два види: 1.) плутанина 2.) блаженна незнання

Перший - поганий і може зникнути з часом і досвідом.

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

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

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

Я б сказав, що це звичайніше, ніж люди хочуть визнати. Навіть Брайан Керніган на це наголосив:

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

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

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

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

Я думаю, що це щось, що піде з досвіду.

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

У вас буде багато моментів, коли ви дивитесь на якийсь код, який ви написали 6 місяців тому, і думаєте: "що за чорт тут відбувається?", Але якщо це станеться через день після того, як ви написали код, ви повинні подумати "чисто" код 'більше.

Джерело: ніколи не використовувався 5-мірний масив :)

"Нормальний" дуже суб'єктивний, тому я кажу: це дуже часто, але його слід уникати.

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

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

Пов'язані:

• Коли розуміння означає переписування - стаття про проблему розуміння коду.
• Ефективний ML - довгий розмова серед ML / OCaml, як написати код для "читачів" (тобто обслуговуючого персоналу): "Улюблені читачі над письменниками". Я рекомендую переглянути це, незалежно від того, якою мовою ви користуєтесь.

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

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

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

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

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

Тут є багато гідних відповідей.

Я маю на цьому пару заходів.

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

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

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

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

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

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

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

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