Автор оригинала: Nigel B. Peck.
Ты не можешь. “Правильного” пути не существует. Ну вот, это было легко. Спасибо за чтение.
Что? Еще? Ладно, ладно, поехали. Только не говори, что я тебя не предупреждал.
В этой статье рассматривается разработка веб-приложений с помощью Node/JavaScript, но она применима для начала работы с другими языками и средами.
Подход к разработке программного обеспечения
То, как вы подходите к написанию программного обеспечения, будет зависеть от многих факторов. Инструменты, которые вы используете, люди, с которыми вы работаете (если таковые имеются), среда, для которой вы пишете, и время, которое у вас есть, – все это повлияет на то, как вы подходите к написанию программного обеспечения.
Есть несколько общих принципов, которые могут помочь вам сформировать прочную рабочую практику, когда вы узнаете, что работает для вас. Эта статья представляет собой попытку изложить подход, основанный на этих принципах. Он предназначен для людей, которые только начинают.
По мере того, как вы продвигаетесь вперед в своем обучении и опыте, ваш подход будет естественным образом развиваться. Этот подход предназначен для того, чтобы помочь вам, пока вам больше не нужно думать об этом, и вы можете применять его с более формальными практиками и инструментами.
Например, мы не будем рассматривать работу в филиалах, автоматизированное тестирование или разработку на основе тестирования. Если это то, к чему вы готовы, этот подход уже должен быть вам ясен.
Мы ищем простой подход, который позволит вам внести некоторую структуру в вашу рабочую практику, в то же время работая таким образом, чтобы поддерживать знакомство с языком и окружающей средой.
Он написан для изучения основ разработки веб-приложений путем написания веб-приложений в узле, но применим к кодированию в других областях. Обратная связь приветствуется.
Работайте четкими шагами
Важно работать четкими шагами и знать, над какой конкретной задачей вы работаете в данный момент. Звучит очевидно, да? По моему опыту, это легко забыть. Если у вас есть несколько отдельных задач, над которыми вы работаете, особенно если они взаимосвязаны (что может быть настолько общим, насколько они являются частями одного и того же приложения), это усложнит ситуацию.
Это легко сказать. На практике потребуется опыт, чтобы понять, как это сделать. Мы не говорим о “завершении” каждой части, прежде чем вы начнете следующую. Код развивается небольшими шагами, и одной области придется подождать, чтобы двигаться вперед, пока другая область не продвинется вперед.
То, о чем мы говорим, – это получение каждого шага туда, где он должен быть, прежде чем работать над следующим. И желательно иметь возможность проверить это. Это искусство и уравновешивание. Основным фактором, влияющим на это, является то, как вы определяете свои задачи.
Определите Свои Задачи
Обычно у вас есть общая задача, которая затем разбивается на более мелкие задачи. На самом деле, ты всегда так делаешь. “Создайте приложение, чтобы сделать x” – это ваша самая большая общая задача, и она рушится оттуда. Ясно, что нам нужно быть более конкретными, и есть уровни этого. Мы должны работать с этим процессом до конца.
Итак, вот с чего вам нужно начать, прежде чем приступать к какому-либо кодированию. Это помогает записать его. Я предпочитаю бумагу. Посмотрите на задачу, стоящую перед вами, посмотрите , считаете ли вы, что это то, чего вы можете разумно и предпочтительно легко достичь за один сеанс. Возможно, это “отображение сообщений на главном экране”. Мы будем придерживаться этого примера, когда будем смотреть на это.
Процесс тот же, если вы не рассчитываете достичь его за один сеанс, но сначала попробуйте разбить его на несколько больших частей. Ты скоро освоишься. Вы уже все это знаете, это просто пример того, как применить это к разработке программного обеспечения.
Предположим, что это возможно за один сеанс. Запишите это. Теперь запишите шаги, которые, как вы видите, необходимы для его достижения. Будьте как можно конкретнее. Если вы не уверены в конкретных шагах, это придет с опытом. Проведите какое-нибудь исследование или получите совет. Как минимум, выясните, как вы можете начать, и пересмотрите план позже. Постарайтесь как можно яснее понять, что вам нужно сделать, чтобы это произошло.
Мы стремимся работать в шагах, которые включают в себя написание кода как можно меньше мест, предпочтительно одно, и которое мы можем протестировать, прежде чем перейти к следующему шагу. Что нам нужно сделать, чтобы отобразить сообщения на главном экране?
Шагая через пример
Предположим, что домашний экран еще не существует. Так что это хорошее место для начала. Нам нужно добавить маршрут, обработчик маршрута и создать представление. Где мы можем проверить этот процесс? Ну, мы не можем с пользой протестировать маршрут без того, чтобы он не обрабатывался чем-то, а добавление обработчика маршрута-это не так уж много кода, так что это будет хорошим первым шагом.
Нам не нужно представление для тестирования маршрута, так как мы можем консольно вести журнал из обработчика маршрута. Мы можем настроить вид, как только узнаем, что он работает. Если маршрут не работает, мы можем исправить его, не думая, что это проблема с видом. Когда мы перейдем к просмотру, мы будем знать, что маршрут работает, и у нас будет только одно место, чтобы начать искать, если возникнут проблемы.
Так как же нам “настроить вид”? Что вы видите, когда смотрите на это? Возможно, домашний экран с хорошим списком сообщений, четко отображаемых. Это конечная цель, но слишком много работы для одного шага. Даже ломать все шаги, чтобы добраться туда, вероятно, не полезно в этот момент. Как мы можем начать?
Первое, что нам нужно, – это иметь файл для представления и визуализировать его. Мы можем легко проверить, что он работает, поместив некоторый текст-заполнитель в файл представления. Здорово. Итак, следующий шаг.
Есть несколько вещей, которые нужно сделать после этого, и это обычно хорошо работает, чтобы начать с данных. Если данные поступают в процесс, это отличное место для начала, потому что остальная часть процесса, скорее всего, будет зависеть от него, и его, вероятно, будет легко проверить. Я говорю “вероятно”, потому что, возможно, вы могли бы работать над представлением, в котором есть данные, но они очень минимальны и не имеют большого значения. В этом случае, как и в других, другой выбор может быть лучше. Вот тут – то и приходит опыт.
Итак, мы почти достигли цели, шаги для нашего примера примерно таковы.
- Настройка маршрута и обработчика маршрутов
- Настройка файла представления и рендеринга с тестовым содержимым
- Вытяните данные в обработчик запросов, консольный журнал для тестирования
- Передайте данные в представление, напишите минимальный код шаблона для тестирования
- Повторите цикл над сообщениями в представлении, отображая сообщение для каждого из них.
- Работайте над стилизацией вида до тех пор, пока он не будет выглядеть правильно
После каждого шага тестируйте и отлаживайте. Не переходите к следующему шагу, пока не завершите предыдущий. Шаг номер 6 будет нуждаться в разрушении с тем же подходом, но вы получите идею. Это не религия, используйте ее, чтобы направлять свою работу, не слишком мешая. Работайте над созданием сильных привычек вокруг этого. Контроль версий поможет вам, и мы рассмотрим это дальше, прежде чем закончим.
Возможно, вы заметили, что мы делаем дополнительное кодирование, чтобы иметь возможность тестировать. Ведение журнала консоли, написание кода шаблона, чтобы показать, что у нас есть данные, отображение необработанных сообщений для тестирования шаблона представления и т. Д. Это полезно, потому что позволяет нам ограничить область действия областей, на которые мы должны обратить внимание при отладке. По крайней мере, с чего начать поиски. Проблемы все еще могут всплывать из проверенных областей и шагов, но это помогает.
Сокращение объема кода, который вам нужно написать, чтобы иметь возможность тестировать, является частью процесса принятия решений, который вы проходите при определении шагов вашей задачи. Это изменится позже, когда вы перейдете к более формальному и автоматизированному процессу тестирования. А пока познакомьтесь с ним таким образом. И получайте удовольствие! Это может привести к большому разочарованию от кодирования, когда все сделано правильно. Обсудите свой подход с наставником.
Работа с Git
Контроль версий может вам очень помочь здесь, и именно поэтому я призываю своих подопечных использовать Git с самого начала. Это большая и мощная тема, и я не предлагаю изучать ее на ранней стадии, но использование ее с самого начала, с простым подходом, может очень помочь. Вот он.
У вас есть одна главная ветвь, и вы научитесь фиксировать код, который у вас есть. Это все, что вам нужно на данном этапе. Он помогает вам, поддерживая вашу работу в задачах.
Вы ищете, чтобы совершить, как вы завершаете каждый шаг. Это означает, что вам нужно писать только тот код, который применим к вашему текущему шагу, иначе он будет находиться в неправильном коммите.
Не переживайте из-за этого, это поможет. Если вы заблудились в своем кодировании и не можете сделать чистую фиксацию для шага, сделайте то, что вы можете. Приведите все в порядок как можно лучше, зафиксируйте то, что есть, и возвращайтесь к одному фиксатору за шаг, когда сможете. Если вы не можете зафиксировать каждый шаг, по крайней мере, сделайте это для каждой задачи.
Есть много интересных методов, чтобы улучшить этот подход позже. Этот простой подход заставит его работать на вас, и на данный момент этого достаточно.
В моей следующей статье этот подход к использованию Git будет подробно рассмотрен. Следуйте за мной сюда или в Твиттере чтобы знать, когда все будет готово.
Знать То, Чего Не Знаешь
Разве я говорил, что контроль версий-это последнее? Ну что ж, все меняется. Именно об этом и идет речь в этом разделе. Знать то, чего не знаешь. Это можно было бы лучше назвать “Знание Того, чего Вы не знаете Или Не можете знать”.
Дело в том, что в разработке программного обеспечения предположения могут быть опасными и, вероятно, привести к более длительным сеансам исправления ошибок, чем любая другая проблема. Пока не остановишь. И он все еще может укусить тебя после этого.
Не думайте, что какая-то часть вашего кода делает то, что вы думаете.
Как только вы определили область кода, которая вызывает проблему, пройдите через нее подробно с самого начала. Проверь все. Надеюсь, это небольшая область кода, которую вы идентифицировали, и вышеприведенный подход помогает в этом.
Идентификатор сообщения находится в этой переменной? Так ли это? Вы уже зарегистрировали его на консоли? Просто сделай это. Не думайте: “О, я проверил это час назад” и т. Д. Проверьте еще раз. Вы будете поражены, как часто проблема заключается в том, что вы предполагали, что это работает.
Вы не знаете, что любой код, на который вы смотрите, делает то, что вы думаете, пока не протестируете его. И вы все еще не можете быть уверены после этого. Подходите к нему как к ребенку, будьте любопытны и пробуйте все. Забудьте то, что вы думаете, что знаете, это часто самая большая часть проблемы.
Вывод
Это все, на что у нас сегодня есть время, и, конечно, есть еще много чего сказать. Надеюсь, это дало вам некоторые идеи для работы.
Попробуйте, прочтите это еще раз через неделю или две и обсудите со своим наставником. Обучение разработке программного обеспечения требует времени, и с четкой структурой, чтобы направлять вашу работу, должно быть более продуктивным и менее разочаровывающим. Повеселиться.
Программа наставничества Web App Foundation
Я создаю программу наставничества, чтобы изучить основы разработки веб-приложений. Вы можете работать со мной в качестве своего наставника, или это доступно для других наставников, чтобы использовать и помочь улучшить. Весь материал свободен и находится на GitHub. У него даже есть сайт ! Я предлагаю бесплатный сеанс , чтобы обсудить, как это может работать для вас.