Это перевод статьи Артёма Чистякова "The language of programming", породившей интересные дискуссии на HackerNews и Reddit.

Я помню, как изучал свой первый язык программирования. Мы должны были освоить какой-то из диалектов BASIC в рамках обязательной школьной программы по информатике для второго класса. Скрючившись на своих партах под тусклыми флуоресцентными лампами, мы нетерпеливо поглядывали на жужжащие компьютеры IBM, расставленные вдоль стен душной классной комнаты. Это был 1997 год, Россия. Ни у кого из нас не было домашнего компьютера. На доске в меловых разводах учитель написала:

SCREEN 15, 0
PSET (100, 100)
DRAW "R20 D20 L20 U20"
END

Перевели для вас небольшой пост со StackExchange, в котором юзер под ником Etherable делится историей о своей нелегкой кодерской жизни.

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

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

Как вы уже догадались, эта работа легко может считаться самой скучной работой в мире. Однако, это фуллтайм с приличной зарплатой. А также я работаю удаленно и могу оставаться дома со своим сыном.

Итак, я делал это примерно 18 месяцев и за это время изучил все подводные камни и написал программу, которая уже 6 месяцев делает всю работу за меня. Теперь то, на что у моего предшественника уходил месяц, требует 10 минут. Нужно просто подготовить таблицу и прогнать ее через программу.

И моя проблема теперь такова — должен ли я сказать им? Если я скажу, они, наверное, оставят программу и избавятся от меня. В этой компании не очень много работы связанной с IT. Есть эта легаси система, в которой они годами хранят пользовательские данные, и им просто нужен кто-то, чтобы ее поддерживать. В то же время, я не чувствую, что поступаю правильно. Ведь моя работа сейчас выглядит так: я получаю спецификации, прогоняю через программу и затем примерно каждую неделю говорю, что я закончил часть работы, и они могут проверять. Я даже вставляю туда несколько ошибок, чтобы было похоже на то, что работа на самом деле проделана человеком.

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

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

Что думаете, коллеги? Стоит ли парню рассказать о своем маленьком секрете и потерять хорошую работу? (вернее, потерять отличный источник пассивного дохода :D)

Оригинальный топик

«Ненавижу читать чужой код», — эту мантру часто можно услышать от разработчиков любого уровня. Тем не менее, это необходимое умение, особенно для разработчиков, которым предстоит освоиться в существующей кодовой базе, и если вы подойдете к этой работе с правильным настроем и правильными инструментами, это может быть весьма приятным и просветляющим опытом.

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

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

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

Это перевод статьи Даниэля Лебреро, которая также была опубликована на dev.to (там в комментариях есть интересное обсуждение на английском).

Меня удивил дядюшка Боб в посте под названием: "Type Wars". Он пишет: "Так что я предполагаю, что чем более общепринятой необходимостью профессиональной дисциплины будет становится TDD, тем более предпочтительными будут становится динамические языки. Smalltalker'ы постепенно победят".

Это утверждение не всем пришлось по душе. В сообществе сторонников статически-типизированных языков многие высказались, что достаточно продвинутая система типов (и типы — как доказательства) делает юнит-тесты ненужными. Haskell даже утверждает, что "если скомпилировалось, то обычно работает".

Будь это уменьшение багов, улучшенное документирование, более продвинутая поддержка IDE или простота понимания, для меня все это означает одно обещание: меньше багов.

А я ненавижу баги. Я считаю, что баги — одно из худших сжирателей времени и энергии в проекте. Нет ничего, что раздражает меня сильнее, чем слышать в демо в конце итерации гордое «мы сделали Х стори-пойнтов и исправили 20 багов! Ура!».

По мне так это звучит как «В прошлой итерации мы написали более 20 багов, но наши клиенты смогли найти лишь 20! И нам заплатили и за их написание, и за их исправление. Ура!»

Как начать? Сколько нужно писать тестов? На что нужно писать тесты? На что не нужно писать тесты? Стоит ли всегда применять TDD?

Если вас интересуют ответы на эти вопросы, то вы читаете правильную статью. В своей жизни я написал не одну тысячу тестов всех мастей для разных платформ, использовал во все поля tdd и ставил процесс тестирования в командах, проектах и даже целых компаниях. И теперь я попробую обобщить этот опыт и поделиться им.

Что самое трудное в работе программиста? Выдумывать имена для переменных.

Эта шутка пользуется популярностью среди программистов не случайно. Именование, часто становится причиной целых баталий. И действительно, то как мы именуем наши сущности (функции/переменные/константы/классы/модули) имеет большое значение, ведь большую часть времени мы читаем код, а не пишем.

Для настройки окружения проекта можно использовать (а многие так и делают) стандартные средства операционной системы. Такие, как пакетный менеджер (yum, apt), прямое редактирование конфигурационных файлов, bash-скрипты, curl/wget и многое другое.

Этот подход, с одной стороны, самый простой, но он обладает рядом недостатков, некоторые из которых критические.

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

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

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

Давайте для начала явно отметим отличие рекурсии (в общем смысле) от процесса. Эти понятия никак не связаны. Рекурсия — просто абстрактная концепция, которую можно наблюдать в природе, которая используется в математике и в других областях. Такая же абстрактная, как, например, музыкальная гармония.

пример рекурсии: художник рисует картину, в которой он рисует картину, в которой он рисует картину...

Теперь на секунду забудем про рекурсию, и просто подумаем про компьютеры. Для выполнения задач компьютерам нужны инструкции. Когда компьютер выполняет набор инструкций — это процесс. Ваш работающий сейчас браузер — это процесс. Простой цикл, выводящий на экран десять раз число "42" — это процесс. Некоторые задачи можно решать рекурсивно, то есть в инструкциях использовать эту концепцию, когда что-то является частью самого себя. В частности, функция может быть частью самой себя, то есть вызывать саму себя.

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

1. Производство (разработка)
2. Сборка
3. Контроль и испытания
4. Доставка