Чому програмувати так важко?

Привіт, Хабр!

У лютому ми публікували переклад крутий статті "Чому навчитися програмувати так чертовски важко?", яку тепер показуємо новачкам. Так, навчитися програмувати – це ціла історія, довга, з купою різних етапів, з емоційними злетами і падіннями. Ми всі через це проходили (або ще проходимо – так тримати!).

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

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




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

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

Означення 1: Програма це те, що перетворює вихідні дані в результат.
Програміст-це людина, яка пише програму, а програмування — процес написання цієї програми.

Тепер давайте додамо кілька умов до мого визначенням програми.

Означення 2: Програма це що-те, що перетворює вихідні дані в результат і залежить від наступних умов:

  • Результат програми чудовий.
  • Вихідні дані чудові.
  • Програма чудова.
  • Вихідні дані якісно і чітко задокументовані.
  • Сама програма якісно і чітко задокументовано.
  • Програма добре протестована і виконується вірно.
  • Розв'язувана задача чітко деталізована.
  • Поставлена задача чітко деталізована.
З цими додатковими умовами програмування стає вкрай складним. Для конкретної задачі деякі з цих умов можна послабити. Кілька типових сценаріїв напрошуються самі собою.

Програми, які не потрібно підтримувати

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

Моя книга по Erlang виступає прикладом. Як тільки книга була опублікована, підтримка вихідних даних і програми, яка справила книгу, перестали бути необхідними. Результат виглядає відмінно, а ось вихідні дані це місиво XML-файлів і маленьких тестових програм, які ніколи не потрібно підтримувати.

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

Програми, які потрібно підтримувати

Для підтримуваних програм все протилежно останнім сценарієм. Вихідні дані для програми і сама програма повинні бути чудовими і добре задокументованими.

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

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

Що ще ускладнює програмування

Є три речі, які роблять програмування складним завданням:
  • Виправлення тих проблем, яких не повинно було бути взагалі.
  • Відсутність часу на вивчення нового
  • Погана атмосфера для програмування
Давайте розглянемо ці складності — справжніх злодіїв часу.

Виправлення тих проблем, яких не повинно було бути взагалі

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

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

Що робити, якщо в документації сказано «виконайте XYZ, тоді у вас вийде PQR», ви виконуєте «XYZ», але «PQR» не виходить? Якщо ви везунчик і ті, хто написав програму перебувають десь поблизу, ви можете піти і придушити їх, а якщо не вийде, можна спробувати знайти відповідь в Google або поколупати код в пошуках відповіді.

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

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

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

Ця проблема, до речі, та сама річ, яка відбирає у мене максимум часу, думаю, 60-70%. Одного разу я витратив близько тижня намагаючись розібратися зі зламаним LDAP сервером (мій начальник заборонив мені застосувати мій власний LDAP-сервер), але через тиждень боїв зі зламаним сервером, хреново задокументованим і написаним на мові С, у мене стався провал у пам'яті, так що я забув, що мені сказав начальник і випадково встановив сервер на Erlang з нуля під час обідньої перерви.

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

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

Рішення проблем без отримання нових знань

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

Коли я вирішую проблеми, я вдаюся до методу швидкого вирішення, але в довгостроковій перспективі — це катастрофа.

Взяти, наприклад, створення документів. Я ніяк не міг вибрати між TeX/LaTeX і XSLT-FO і моїм власним Erlguten.

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

Думаю Джамбаттіста Бондони, коли він створював свій Manuale Tipografico в 1818 році, не був особливо стурбований, що верстка однієї сторінки займе кілька тижнів. Але тепер, коли у нас з'явилося набагато більше часу, тому що ми можемо змусити верстати робити нудну і небезпечну роботу, у нас не залишилося часу, щоб робити щось якісно.

Я запитав начальника, чи не хоче він «симпатичні слайди» для наступної презентації, він погодився, за умови, що я зроблю їх до завтра. Але часу для вивчення TeX як слід не залишилося (а це, гадаю, буде потрібно рік або щось близько того), як його не залишилося й для того, щоб застосувати свою власну мову розмітки (що вимагало б п'ять-десять років) і для того, щоб написати його безпосередньо у PostScript (за тиждень або близько того). Так що, мабуть, PowerPoint…

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

На щастя, у нас є місце, куди ми можемо піти, щоб не відволікатися. Сон. Безліч програмних проблем вирішується, поки ви спите.
Є два способи:

Перший: ви завантажуєте мозок проблемами, потім засинаєте, а на наступний день прокидаєтеся, і деякі з проблем вирішені. Легко.

Спосіб другий: ви постите проблему в інтернеті, або пишете про це твіт перед сном, і на наступний день хтось надсилає вам рішення по мейлу.

Щоб стати хорошим програмістом потрібно багато часу: вам потрібно отримати багато інформації, і знати, до кого звернутися, якщо ви застрягли.

Дивно, але факт

Коли я закінчив цю статтю, я хотів перевірити орфографію. Режим Emacs-Ispell вирішив провести страйк. Він не зміг знайти aspell, програму, яку я використовую для перевірки правопису.

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

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

Я не бачу причин, чому мій орфографічний контролер міг зламатися — все гаразд, я нічого не міняв. Ну, я встановив нову версію Erlang і Julia, написав кілька лекцій, після того як в останній раз перевіряв документ на помилки.

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

Думаю, існують такі речі, про які ми просто ніколи не дізнаємося.

Переклад: Наталія Басс / Hexlet.io

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.