Организационный код
При написании кода функциональность — это только самая основная необходимость, к которой вы должны стремиться. Практически весь код нужно будет обновить, исправить, расширить или иным образом изменить после первоначального развертывания, и если ваша исходная версия была написана без учета удобочитаемости или организации, вы можете каждый раз начинать с нуля.
Первый шаг к организации кода включает в себя сохранение согласованности синтаксиса и интервалов. По мере того, как вы прокручиваете все больше и больше циклов, отслеживание того, где вы находитесь в коде, может превратиться в кошмар, если вы отказываетесь от отступов случайных блоков кода, чередуете различные размеры отступов или добавляете непоследовательные пробелы. Каждый модуль должен быть легко отличим от других независимых частей вашего кода.
Кроме того, организация кода по модулям и приложениям имеет решающее значение, поскольку ваши проекты становятся все больше и сложнее. Если новая часть вашего приложения имеет свою долю методов и свойств, не помещайте все это в конец несвязанного модуля; лучше иметь слишком много отдельных файлов, чем слишком много компонентов в одном месте.
Наконец, попробуйте и убедитесь, что расположение кода имеет смысл. Маловероятно, что все приложение будет запускаться в хронологическом или строго процедурном порядке каждый раз, но это помогает заранее составить разумную дорожную карту. Не включайте функцию onExit перед загрузкой страницы, если только для этого нет веской причины.
Рабочий процесс
Мой общий рабочий процесс при разработке веб-проекта почти всегда включает в себя работу на доске или мозговой штурм общей идеи о том, как приложение будет работать. Если вы еще не понимаете логический процесс, стоящий за реализацией чего-либо, вряд ли можно ожидать, что вы объясните это компьютеру. Метод проб и ошибок для отдельных компонентов может быть полезен, но для общей реализации это может принести больше вреда, чем пользы.
Затем я пытаюсь определить любые части процесса, которые я еще не знаю, как вписать в код. Возможно, я еще не знаю, как разобрать конкретный файл на предмет его данных, или, может быть, я не уверен, какие прототипные методы есть у типа данных. На этом этапе я удостоверюсь, что то, чего я хочу достичь, по крайней мере, возможно, прежде чем продолжить, или же я могу изменить схему всей идеи программы, чтобы приспособиться к ней. Лучше понять, что то, что вы хотите сделать, невозможно, еще до того, как вы напишете несколько сотен строк кода.
После этого следует написание кода и базовая отладка. По крайней мере, я хочу убедиться, что я могу заставить код строго выполнять то, что я планировал. Если да, то я преодолел самое большое препятствие.
И, наконец, оптимизация кода. Редко первый набросок является лучшим решением проблемы. Избыточные переменные, более медленные алгоритмы, плохое структурирование и синтаксис — все это можно улучшить, чтобы код работал и выглядел лучше. Этот шаг потенциально может длиться вечно.
Решение проблемы
Баги и ошибки неизбежны практически в любом проекте. Первым шагом в их решении является определение того, где и почему возникает ошибка, что можно обнаружить с помощью точек останова и ведения журнала консоли. Часто исправить ошибку так же просто, как добавить или удалить лишний символ здесь или там. Если проблема более сложная, может потребоваться помощь извне. Скорее всего, в мире веб-разработки кто-то еще столкнулся с подобной проблемой, и знание того, как искать советы в Интернете, является неотъемлемой частью успешного кодирования.
Проблемы, не связанные с кодированием
Так же часто вы будете сталкиваться с проблемами, связанными с реализацией или стратегией, а не с ошибками кодирования; возможно, вы не осознавали, что итерация по определенной переменной не будет невозможной при первоначальной работе с доской. Это, как правило, потребует переоценки всей структуры вашего проекта, и, хотя может быть неприятно обнаружить, что вам нужно проделать так много работы снова, это обеспечит опыт обучения, который вы вряд ли забудете, и приведет к большему понимание языка и самого программирования.
Другие проблемы могут существовать вне проекта. Если ваше окружение слишком шумное или отвлекающее, вы никогда не получите ясности мысли, необходимой для того прорыва, когда ваш проект начнет собираться воедино. Найдите лучшее место для работы и найдите время, чтобы посвятить себя своему проекту, чего бы это ни стоило. Правильный настрой и среда могут быть даже важнее, чем ваше знание языка или любых алгоритмов.
Предпочтительная среда
У разных текстовых редакторов и сред выполнения есть свои плюсы и минусы, и в каждой из них может быть полезно следить за последними обновлениями. Готовность переключаться на другие инструменты по мере добавления или изменения новых функций может быть трудной, но она окупается в виде дивидендов. Моя предпочтительная рабочая среда для веб-проектов включает в себя использование VSCode из-за его множества плагинов и беспрецедентной системы отладки, а также запуск проекта в Chrome для реалистичной идеи совместимости (не говоря уже о полезных инструментах разработчика Chrome). Меньшие функции или другие фрагменты кода могут выполняться в таких средах, как Plunker или REPTL, просто для экономии времени.
Будьте в курсе последних событий
Есть несколько отличных источников для того, чтобы быть в курсе новостей отрасли, включая Hacker News и Stack Overflow. Лучше всего сохранять разнообразие в своих источниках, и еще лучше практиковаться в чтении и участии в активных сценах социальных сетей, таких как Reddit, чтобы убедиться, что вы ничего не пропустите. Если будет большое развитие, вряд ли оно не попадет на первую полосу.
