Читая статьи, которые советуют мне, как изучать программирование, я прихожу к выводу, что их авторы давно не являются новичками в свое деле и поэтому часто не помнят проблем, с которыми я, начинающий программист, борюсь каждый день. Поэтому я решил описать этот вопрос с собственной точки зрения.
Программирование может быть очень расстраивающим искусством. Художник нарисует картину и все. Писатель напишет книгу и на этом тоже все. Даже инженер может не всегда хорошо произвести расчеты, и все же мост будет построен. Конечно, картину можно критиковать, книга может лежать на полках, а мост в конце концов рухнет. Тем не менее, программа, помимо того, на что она способна: подвергаться критике, плохо продаваться и разрушаться (вызывать серьезный сбой), также связана с дополнительной проблемой программиста: ошибками.
Вы могли бы многое сказать о постельных клопах — я имел обыкновение бороться с Гейзенбагом в течение двух недель (с перерывами, потому что у меня есть на это время), и, наконец, оказалось, что ошибка была вызвана Adobe (речь о Actionscript). Я не смог подтвердить следующее: в результате ошибки геодезистов труба Польского туннеля не слилась, что привело к самоубийству геодезистов, затем оказалось, что доски не были достаточно точными, и в самих геодезистах не было никакой ошибки.
Что в таком случае я собираюсь делать? Повторюсь, программирование может очень опечалить и расстроить. Из-за высокой конкуренции я рекомендую программировать только людям с энтузиазмом, для которых было бы нормальным начинать программирование, а не читать, как программировать хорошо (например, как вы думаете, началось ли прирожденное вождение машины на ралли приключение с чтения энциклопедии об автомобилях?). Кроме того, лучше не знать хороших практик вообще, чем использовать их. Важно использовать хорошие практики, а не ограничиваться ими.
Я мог бы закончить эту статью, потому что все, что я опишу ниже — программист узнает рано или поздно. Однако всё-таки продолжим в качестве бонуса для тех, кто хочет учиться на чужих ошибках.
Слишком долгая подготовка
Многие потенциальные программисты ищут лучший язык программирования, а затем, без конкретного ответа, теряют энтузиазм. Мой совет: выбирайте любой язык программирования, а если он вам не нравится, попробуйте следующий. Не используйте фреймворки, не ищите хорошие практики и правильные решения.
Технологий и решений, которые необходимо учитывать перед началом данного проекта, так много, что ни один новый программист не сможет справиться с этим. Тем не менее, изменение языка программирования для новичка тривиально (такая миграция может быть болезненной только для опытного программиста, который уже привык к именам функций, внешним библиотекам, сообществам и так далее., хотя бы потому, что вы новичок).
Учимся с книгой
Несомненно, каждый должен изучать базовые понятия, такие как циклы, условные инструкции и так далее, но ради мотивации, прочитав одну книгу или просмотрев один курс, вы должны нарушить соглашение о переписывании кода из книги и начать программировать самостоятельно.
Подумайте о том, что вы уже можете сделать и что вы можете создать с помощью этих инструментов. Не создавайте калькулятор или платформенную игру только потому, что это то, что должен делать каждый программист. Подумайте о том, что вы хотели бы использовать (или в какую игру хотели бы играть), ограничиваясь только двумя вещами:
- Это должно быть осуществимо в течение недели, максимум месяца, чтобы не потерять мотивацию,
- Это должно быть возможно сделать с текущими знаниями (по крайней мере, на первое время для поиска и изучения возникающих проблем).
Кто знает, может быть, ваш первый проект будет иметь большой успех как «Flappy Birds» (игра очень проста, и все же продается).
Хождение по туману
Вероятно, каждый программист взял что-то, чтобы обнаружить в какой-то момент, что это невозможно, глупо, или это займет слишком много времени. Некоторые также берут на себя программирование своих идей, а затем заявляют, что программа не работает, и они не знают, как это исправить.
Представьте или нарисуйте, как вы представляете свой законченный проект со стороны пользователя: как он должен работать, как должен выглядеть интерфейс (кнопки, поля ввода и так далее). Какими будут его ограничения и каковы будут самые большие проблемы при создании этой программы, затем спланируйте модульную структуру программы и определите, что именно модуль должен принимать на входе, и каким будет алгоритм, который преобразует входной сигнал в выходной. Затем, в случае возникновения проблем, вы можете просто сделать так называемый «Модульный тест», то есть проверка один за другим, какой модуль не выполняет свою работу должным образом (принцип «Разделяй и властвуй»).
Редизайн
Многие люди, читая приведенный выше совет, попадают в ловушку создания усовершенствованного плана своего приложения. Помните, что понятие «редизайн» создано в крупных компаниях или представляет идею потенциальному инвестору, который не даст денег тому, кто, по его мнению, имеет классную идею и ничего больше не предлагает. Существует целая философия, которая борется с этим понятием. На мой взгляд, лучший designdoc просто создан для быстрой предварительной программы с заменой картинок. Это самый простой способ визуализировать проблемы.
Лишние комментарии
Такие комментарии, как designdoc, слишком часто хвалят в Интернете. Я даже встретился с мнением, что комментарии вообще не должны быть разрешены, потому что программирование должно быть запрограммировано так, чтобы код программы был достаточно разборчивым. Тем не менее, я думаю, что начинающий программист обречен говорить, что через несколько месяцев или лет он будет думать совсем иначе (благодаря программированию) и не сможет понять свой старый код. Таким образом, комментарии — это хорошая вещь для него, поскольку он помнит, что не должен писать комментарии для незнакомца, потому что, скорее всего, исходный код его первых программ не будет прочитан никем. На данный момент я не имею в виду, что комментарии каким-то образом ухудшают код, но занимают много времени, энергии и внимания у начинающего программиста.
Большие блоки кода
Подрыв среди начинающих программистов. Проще добавить код к существующим функциям построчно, чем создать новую функцию. Такой код трудно пересмотреть, сложно отладить и сложно изменить. Для вашего же блага научитесь делить программу на файлы, классы, функции.
Прогрессивное программирование и невозможность отладки
Многие начинающие программисты записывают свои программы в блокнот, а затем запускают компилятор (или открывают веб-страницу в браузере). Если программа не работает (или не компилируется), достаточно удалить последнее изменение и разделить его на более мелкие фрагменты, которые добавляются последовательно, наблюдая, какой фрагмент вызывает ошибку. Это может быть запрограммировано, но ошибки окажутся очень демотивирующими. Тем не менее, все, что вам нужно сделать, это Google, как отлаживать на языке программирования по вашему выбору, чтобы изменить ваш опыт от ада до веселья.
Преждевременная или ненужная оптимизация
Оптимизация должна быть последним этапом создания кода, если вы не планируете существенно изменить способ работы модуля, если вы не знаете, можете ли вы оптимизировать модуль, или если он потерпит неудачу, весь проект попадет в корзину.
Некоторые попадают в ловушку ненужной оптимизации, которая является следствием устаревших показателей или использования отдельных переменных или небольших таблиц, рекомендаций по большому количеству переменных — например, кто-то может посоветовать использовать переменные TINYINT в базе данных для экономии места, в то время как для отдельных задач — это вовсе не нужно. Переменные в программе приведут только к экономии нескольких байтов за счет ошибок вне диапазона, несовместимости типов или ненужных комбинаций для уменьшения значения. К сожалению, однажды из любопытства я установил в свой браузер плагин, который рекламировал, что он ничего не делает. И на самом деле этот плагин абсолютно ничего не делал и занял 5 Мб памяти (что, вероятно, является ошибкой Google, а не создателя плагина). Поэтому думайте об этих вещах заранее.