Привет! Собрал некоторые очевидные и не очень ошибки начинающих программистов. Это модели поведения и ложные представления, которые могут или вообще закрыть вам дорогу в программирование, или, по крайней мере, растянуть этот путь на много лет. Статья предназначена в первую очередь для новичков.
Это перевод статьи Даниэля Лебреро, которая также была опубликована на dev.to (там в комментариях есть интересное обсуждение на английском).
Меня удивил дядюшка Боб в посте под названием: "Type Wars". Он пишет: "Так что я предполагаю, что чем более общепринятой необходимостью профессиональной дисциплины будет становится TDD, тем более предпочтительными будут становится динамические языки. Smalltalker'ы постепенно победят".
Это утверждение не всем пришлось по душе. В сообществе сторонников статически-типизированных языков многие высказались, что достаточно продвинутая система типов (и типы — как доказательства) делает юнит-тесты ненужными. Haskell даже утверждает, что "если скомпилировалось, то обычно работает".
Во время обучения бывают ситуации, когда ожидания не совпадают с реальностью и вы не видите нужного результата. Причин может быть масса, но среди них выделяется группа, связанная с когнитивными искажениями. Вот об этой группе мы и поговорим.
Как начать писать тесты? Сколько нужно писать? На что их нужно писать, а на что — не нужно? Стоит ли всегда применять TDD? Если вас интересуют ответы на эти вопросы, то вы читаете правильную статью. В своей жизни я написал не одну тысячу тестов всех мастей для разных платформ, использовал во все поля TDD и ставил процесс тестирования в командах, проектах и даже целых компаниях. И теперь я попробую обобщить этот опыт и поделиться им.
Что самое трудное в работе программиста? Выдумывать имена для переменных.
Эта шутка пользуется популярностью среди программистов не случайно. Именование часто становится причиной целых баталий. И действительно, то, как мы именуем наши сущности (функции/переменные/константы/классы/модули), имеет большое значение, ведь большую часть времени мы читаем код, а не пишем.
Итак, вы изучаете программирование. Это замечательно! И как правило в процессе изучения, и в процессе работы у вас возникает много вопросов. Способов получить ответы на эти вопросы существует несколько:
Всем привет! Меня зовут Андрей, я фронтенд-разработчик в RAMBLER&Co, ранее в Иннове. Программированием я занимаюсь около года, до этого около двух лет занимался HTML-вёрсткой. Расскажу о том, какие ошибки я совершил за эти три года, чтобы вы (если вы новичок) их не повторяли.
Свой путь в веб-разработке я начинал с книги по HTML/CSS, которую мне дал
почитать знакомый программист. В конце книги был дополнительный раздел
с основами языка JavaScript. Разумеется, я начал его читать и ничего не понял.
Помню как увидел пример простого цикла for (var i = 0; i < 10; i++) и долго
недоумевал, как это вообще работает. В итоге у меня сложилось неправильное
впечатление о языке: я решил, что JS ужасный язык и его нельзя изучать.
Несколько дней назад вышла юмористическая (но наполненная болью и страданиями автора) статья “На что похоже изучение JavaScript в 2016г.”
В одном из комментариев к статье засветился сам Addy Osmani, один из ведущих JavaScript разработчиков в мире. Далее идет текст его ответа в вольном переводе:
Я полностью понимаю ваше отчаяние :)
Я советую людям, изучающим экосистему JavaScript придерживаться такого подхода: сперва сделай это, потом сделай это правильно, потом сделай это лучше.
Для настройки окружения проекта можно использовать (а многие так и делают) стандартные средства операционной системы. Такие, как пакетный менеджер (yum, apt), прямое редактирование конфигурационных файлов, bash-скрипты, curl/wget и многое другое.
Этот подход, с одной стороны, самый простой, но он обладает рядом недостатков, некоторые из которых критические.
Первая проблема - это отсутствие повторяемости. Обычно изменения в первую очередь делаются локально, потом их нужно перенести на рабочие машины ваших коллег, а в конце концов все изменения должны оказаться на сервере. При этом иногда вам придется пересобирать локальное окружение (по множеству причин). Такой подход всегда приводит к рассогласованию настроек на разных машинах, появляются разные версии программного обеспечения, неправильно настроенные конфиги, забытые ключи.
Настройка рабочего окружения — не такое простое занятие, как может показаться на первый взгляд. Обычно начинающие разработчики (и не только) устанавливают проект и его зависимости прямо на ту систему, где они работают. Этот подход обладает рядом недостатков.
Часто бывает, что разработчик работает не на одном компьютере. Более того, иногда разработчики работают на разных компьютерах с разными операционными системами. Все это приводит к тому, что сам процесс разворачивания окружения всегда разный и отличается от боевой среды. Что приводит к багам, которые возникают либо только локально, либо только на продакшене. Засоряется система. Практически невозможно вернуть систему в первоначальное состояние, чтобы пересетапить проект. Придется устанавливать с нуля основную систему.