Как правильно кодировать веб-приложения

Вы не можете. Не существует «правильного» пути. Там это было легко. Спасибо за чтение.

Какая? Более? Ладно, пошли. Не говори, что я тебя не предупреждал.

В этой статье обсуждается разработка веб-приложений с помощью Node/JavaScript, но она применима и к другим языкам и средам.

Подход к разработке программного обеспечения

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

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

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

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

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

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

Работайте четкими шагами

Важно работать четкими шагами и знать, над какой конкретной задачей вы работаете в любой конкретный момент времени. Звучит очевидно, да? По моему опыту, это легко забыть. Если у вас есть более одной отдельной задачи, над которой вы работаете, особенно если они взаимосвязаны (что может быть столь же общим, как и части одного и того же приложения), это усложнит задачу.

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

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

Определите свои задачи

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

Так что это то, с чего вам нужно начать, прежде чем приступать к кодированию. Это помогает записать его. Я предпочитаю бумагу. Посмотрите на задачу, которая стоит перед вами, посмотрите, считаете ли вы, что вы можете разумно и желательно без труда, ожидайте достичь за один сеанс. Возможно, это «отображать сообщения на главном экране». Мы будем придерживаться этого примера, когда будем рассматривать это.

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

Предположим, что это выглядит возможным за один сеанс. Запиши это. Теперь запишите шаги, которые, как вы видите, необходимы для ее достижения. Будьте как можно более конкретными. Если вы не уверены в конкретных шагах, это придет с опытом. Проведите небольшое исследование или получите совет. Как минимум, выясните, как вы можете начать, а позже пересмотрите план. Получите как можно более четкое представление о том, что вам нужно сделать, чтобы это произошло.

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

Пошаговый пример

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

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

Так как же нам «настроить представление»? Что вы видите, когда смотрите на это? Возможно, домашний экран с красивым списком сообщений отображается четко. Это конечная цель, но слишком много работы для одного шага. Даже разбивка всех шагов, чтобы добраться туда, вероятно, бесполезна на этом этапе. Как мы можем начать?

Первое, что нам нужно, это иметь файл для представления и отрисовать его. Мы можем легко проверить, работает ли он, поместив некоторый текст-заполнитель в файл представления. Большой. Итак, следующий шаг.

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

Итак, мы почти у цели, шаги для нашего примера примерно такие.

Настройте маршрут и обработчик маршрута
Настройте файл представления и выполните рендеринг с тестовым содержимым.
Потяните данные в обработчик запросов, консольный журнал для тестирования
Передайте данные в представление, напишите минимальный код шаблона для тестирования
Прокручивайте сообщения в представлении, отображая сообщение для каждого
Работайте над стилем представления, пока оно не будет выглядеть правильно.

После каждого шага тестируйте и отлаживайте. Не переходите к следующему шагу, пока не завершите предыдущий. Шаг номер 6 нужно разбить с тем же подходом, но вы поняли идею. Это не религия, используйте ее, чтобы направлять свою работу, не слишком мешая. Работайте над созданием прочных привычек вокруг этого. Вам поможет контроль версий, и мы рассмотрим его, прежде чем закончить.

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

Сокращение объема кода, который необходимо написать для возможности тестирования, является частью процесса принятия решений, через который вы проходите, определяя этапы своей задачи. Это изменится позже, когда вы перейдете к более формальному и автоматизированному процессу тестирования. А пока познакомьтесь с этим таким образом. И получать удовольствие! Это может избавить вас от разочарования в кодировании, если все сделано правильно. Обсудите свой подход с наставником.

Работа с git

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

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

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

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

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

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

Знание того, чего вы не знаете

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

Дело в том, что в разработке программного обеспечения предположения могут быть опасны и, вероятно, приведут к более длительным сеансам исправления ошибок, чем любая другая проблема. Пока ты не остановишь это. И после этого он все еще может укусить вас.

Не думайте, что какая-то часть вашего кода делает то, что вы думаете.

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

Идентификатор сообщения находится в этой переменной? Это? Вы вошли в консоль? Просто сделай это. Не думайте: «О, я проверял это час назад» и т. д. и т. д. Протестируйте еще раз. Вы будете поражены тем, как часто проблема заключается в том, что, как вы предполагали, работает.

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

Вывод

Это все, на что у нас есть время на сегодня, и, безусловно, есть еще много чего сказать. Надеюсь, это дало вам некоторые идеи для работы.

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