Почему Программирование Так Сложно?

Привет, Хабр! В феврале мы опубликовали перевод крутой статьи» Почему научиться программировать так чертовски сложно? ", который мы сейчас показываем новичкам.

Да, обучение программированию - это целая история, долгая, с кучей разных этапов, с эмоциональными взлетами и падениями.

Мы все через это проходили (или проходим до сих пор) - Так держать!).

К сожалению, не бывает такого момента, когда можно встать и заявить: «Я закончил учёбу и теперь я программист!» Вам придется учиться всю жизнь, и всю жизнь вы будете сталкиваться с неизвестными проблемами, сталкиваться с совершенно непонятными ситуациями и спрашивать «что за черт?!» даже будучи профессиональным программистом с многолетним опытом.

Сегодня мы публикуем перевод заметки «Почему программировать так сложноЭ» Тем, кто еще изучает основы программирования и разработки, будет полезно узнать, что их ждет в будущем.

А опытным разработчикам будет просто приятно смотреть на реальность и кивать головой.



Почему программирование так сложно?

Много лет назад я думал, что программирование — это легко, но прошли годы и я понял, что это не так.

Все из-за неправильного представления о том, что я считал программированием и какую работу выполняет программист. Сначала я думал, что программирование — это всего лишь указание компьютеру, что делать, и эта часть процесса относительно проста.

После более чем двадцатилетнего опыта я пришел к выводу, что эта часть программирования довольно проста.

Определение 1 : Программа — это то, что преобразует входные данные в выходные.

Программист – это человек, который пишет программу, а программирование – это процесс написания этой программы.

Теперь давайте добавим некоторые условия в определение моей программы.

Определение 2 : Программа – это нечто, преобразующее входные данные в результат и зависящее от следующих условий:

  • Результаты программы отличные.

  • Исходные данные отличные.

  • Программа отличная.

  • Исходные данные качественно и четко документированы.

  • Сама программа хорошо документирована и четко документирована.

  • Программа хорошо протестирована и работает корректно.

  • Решаемая задача четко детализирована.

  • Поставленная задача четко детализирована.

При наличии этих дополнительных условий программирование становится чрезвычайно сложным.

Для конкретной задачи некоторые из этих условий могут быть смягчены.

Напрашивается несколько типичных сценариев.



Программы, которые не нуждаются в поддержке

Иногда мы пишем программы просто ради результата.

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

Моя книга об Erlang служит примером.

После того как книга была опубликована, в сохранении исходных данных и программы, создавшей книгу, больше не было необходимости.

Результат выглядит великолепно, но исходные данные представляют собой беспорядок из XML-файлов и небольших тестовых программ, которые никогда не нужно поддерживать.

Типографские ошибки и исправления, внесенные при необходимости в копии, приведут лишь к незначительным изменениям исходных данных.

Их легко исправить, даже если исходные данные программы недостаточно документированы.



Программы поддержки

Для поддерживаемых программ все наоборот последнему сценарию.

Входные данные для программы и сама программа должны быть качественными и хорошо документированными.

Недавно я разговаривал со специалистом, занимающимся разработкой веб-приложений.

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

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

Это для проектов, которые требуют поддержки в будущем.



Что делает программирование еще более сложным?

Есть три вещи, которые затрудняют программирование:
  • Исправление проблем, которых вообще не должно было быть.

  • Недостаток времени на изучение нового
  • Плохая атмосфера для программирования
Давайте разберемся в этих сложностях – настоящих похитителях времени.



Исправление проблем, которых вообще не должно было быть

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

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

Но часто бывает, что программа вообще не имеет инструкции или плохо описана.

Что, если в документации написано «выполните XYZ, тогда вы получите PQR», вы выполните «XYZ», но «PQR» не работает? Если вам повезет и люди, написавшие программу, находятся где-то рядом, вы можете пойти и придушить их, а если это не сработает, вы можете попробовать загуглить ответ или поковыряться в коде, чтобы найти ответ. Использование Google Roulette для исправления ошибок невероятно раздражает. Немного гуглю и очень скоро нахожу где-то печальный пост от такого несчастного человека, как я, который столкнулся с проблемой, полностью идентичной моей.

Мое сердце бьется в предвкушении.

Дрожащими пальцами ввожу волшебную формулу, которая снимет проклятие, и.

ничего.

Проблема не уходит. Как может быть, что кому-то фикс работает, а мне нет. Есть ли где-то где-то гнусное божество, которое наблюдает за мной, или я нахожусь в каком-то определенном месте во вселенной, где законы физики временно изменились? Нет, просто исходное состояние на разных устройствах разное, поэтому то, что исправляет ошибку на одном, не обязательно исправит ее на другом.

Бывают моменты, когда мне хотелось бы программировать на SmallTalk, чтобы мы все начинали с одного и того же образа программирования: программисты SmallTalk должны жить на небесах, где такие вещи не могут случиться, но однажды их программы должны будут взаимодействовать с другими программами, и тогда начинается веселье.

Эта проблема, кстати, как раз и отнимает у меня максимум времени, думаю 60-70%.

Однажды я потратил около недели, пытаясь разобраться со сломанным сервером LDAP (мой начальник посоветовал мне не использовать собственный сервер LDAP), но после недели борьбы с сломанным сервером, который был плохо документирован и написан на C, у меня возникла проблема.

потеря памяти, так что.

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

По правде говоря, это был не полноценный LDAP-сервер, но мне он и не нужен был.

Я хотел, чтобы несколько команд работали, и это оказалось легко исправить.

Сейчас я не нахожу радости в использовании архаичных и кривых протоколов, но зачастую самый простой способ что-то изменить — это переустановить их с нуля.



Решение проблем без получения новых знаний

Мне лень.

Я отлично умею бездельничать.

Но когда я хочу создать диаграмму в LaTeX, я не хочу читать 391-страничное руководство.

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

Когда я решаю проблемы, я прибегаю к методу быстрого решения, но в конечном итоге это катастрофа.

Возьмем, к примеру, создание документов.

Я не мог сделать выбор между TeX/LaTeX, XSLT-FO и моим собственным Erlguten. Примерно раз в три года у меня возникает сильное желание писать всю документацию в постскриптуме, и тогда все, что я могу сделать, это глубоко вздохнуть и подождать, пока это желание пройдет. Думаю, Джамбаттиста Бондони, когда в 1818 году создавал свое «Manuale Tipografico», не особенно беспокоился о том, что верстка одной страницы займет несколько недель.

Но теперь, когда у нас появилось гораздо больше времени, потому что мы можем заставить машины выполнять скучную и опасную работу, у нас не остается времени, чтобы делать что-либо хорошо.

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

Но времени на то, чтобы как следует изучить TeX (что, по-моему, заняло бы год или около того), не оставалось, как не оставалось времени и на использование собственного языка верстки (что заняло бы пять-десять лет) и на то, чтобы написать это прямо в PostScript (примерно через неделю).

Итак, видимо, PowerPoint.

Плохая атмосфера для программирования

Если вы дочитали до этого момента, то знаете, что я думаю, что программирование — это чертовски сложно.

Вот почему рабочие пространства спроектированы таким образом, чтобы еще больше усложнить программирование.

У нас есть офисы открытой планировки, в которых шумная обстановка мешает сосредоточиться, мобильные телефоны отвлекают нас, а Интернет отвлекает нас.

К счастью, у нас есть место, куда мы можем пойти, чтобы не отвлекаться.

Мечтать.

Многие проблемы с программным обеспечением решаются пока вы спите.

Есть два способа: Первый : Вы загружаете свой мозг проблемами, потом засыпаете, а на следующий день просыпаетесь и часть проблем решена.

Легко.

Способ второй : вы публикуете проблему в Интернете или пишете о ней перед сном, а на следующий день кто-то присылает вам решение по электронной почте.

Чтобы стать хорошим программистом, нужно много времени: вам нужно получить много информации и знать, к кому обратиться, если вы застряли.



Удивительно, но факт

Когда я закончил эту статью, мне захотелось проверить орфографию.

Режим Emacs-Ispell решил объявить забастовку.

Не удалось найти aspell — программу, которую я использую для проверки правописания.

Моя программа проверки правописания emacs исправно работала на этом устройстве в течение нескольких лет. И как раз в тот момент, когда я жаловался, что трачу полжизни на исправление ошибок, которых не должно быть, emacs решает сломаться.

Я не верю в гнусных божеств или в то, что законы физики в левом углу дивана в гостиной, где я пишу это, другие, хотя есть косвенные доказательства того, что они верят. Не вижу причин, по которым у меня могла сломаться проверка орфографии - все в порядке, я ничего не менял.

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

К счастью, одиннадцать минут в Google Roulette помогли.

Второй пост о том, как решить мою проблему, сработал, и я до сих пор не знаю, почему emacs не смог найти aspell, а жизнь слишком коротка, чтобы понять, почему.

Я думаю, есть вещи, о которых мы просто никогда не узнаем.

Перевод: Наталья Басс / Хекслет.io Теги: #программирование #сложность #сложность #программирование

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.