Привет, Хабр!
В феврале мы публиковали перевод крутой статьи "Почему научиться программировать так чертовски тяжело?", которую теперь показываем новичкам. Да, научиться программировать – это целая история, длинная, с кучей разных этапов, с эмоциональными взлетами и падениями. Мы все через это проходили (или еще проходим – так держать!).
К сожалению, нет такого момента, когда можно встать и заявить, что «я закончил обучение и теперь я программист!». Учиться придется всю жизнь, и всю жизнь вы будете встречать неведомые проблемы, сталкиваться с совершенно непонятными ситуациями и спрашивать «какого хрена?!» даже будучи профессиональным программистом с многолетним стажем.
Сегодня мы публикуем перевод заметки «Почему программировать так тяжело?». Тем, кто еще изучает основы программирования и разработки будет полезно узнать, что их ждет в будущем. А опытным разработчикам будет просто приятно взглянуть на реальность и покивать головой.
Много лет назад я думал, что программировать легко, но прошли годы, и я понял, что это не так. Всё из-за неверного восприятия того, что я считал программированием и того, какую работу выполняет программист.
Вначале я думал, что программировать – это только указывать компьютеру, что делать, эта часть процесса относительно лёгкая. После двадцати с лишним лет опыта, я действительно пришёл к выводу, что эта часть программирования достаточно лёгкая.
Определение 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 не cмог найти аspell, а жизнь слишком коротка, чтобы выяснять, почему.
Думаю, существуют такие вещи, о которых мы просто никогда не узнаем.
Перевод: Наталия Басс / Hexlet.io
В феврале мы публиковали перевод крутой статьи "Почему научиться программировать так чертовски тяжело?", которую теперь показываем новичкам. Да, научиться программировать – это целая история, длинная, с кучей разных этапов, с эмоциональными взлетами и падениями. Мы все через это проходили (или еще проходим – так держать!).
К сожалению, нет такого момента, когда можно встать и заявить, что «я закончил обучение и теперь я программист!». Учиться придется всю жизнь, и всю жизнь вы будете встречать неведомые проблемы, сталкиваться с совершенно непонятными ситуациями и спрашивать «какого хрена?!» даже будучи профессиональным программистом с многолетним стажем.
Сегодня мы публикуем перевод заметки «Почему программировать так тяжело?». Тем, кто еще изучает основы программирования и разработки будет полезно узнать, что их ждет в будущем. А опытным разработчикам будет просто приятно взглянуть на реальность и покивать головой.
Много лет назад я думал, что программировать легко, но прошли годы, и я понял, что это не так. Всё из-за неверного восприятия того, что я считал программированием и того, какую работу выполняет программист.
Вначале я думал, что программировать – это только указывать компьютеру, что делать, эта часть процесса относительно лёгкая. После двадцати с лишним лет опыта, я действительно пришёл к выводу, что эта часть программирования достаточно лёгкая.
Определение 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 не cмог найти аspell, а жизнь слишком коротка, чтобы выяснять, почему.
Думаю, существуют такие вещи, о которых мы просто никогда не узнаем.
Перевод: Наталия Басс / Hexlet.io
