Независимо от того, работаете ли вы над своей первой работой по разработке программного обеспечения, учитесь программировать и создаете свое первое приложение или надеетесь впервые пробиться в отрасль, я надеюсь, что вы найдете это полезным
Официальные документы по переполнению стека
Когда вы только начинаете учиться программировать, переполнение стека - ваш лучший друг. Это позволяет вам добиваться прогресса, когда вы не уверены или когда вы сталкиваетесь с ошибками, которые не знаете, как исправить. Но я заметил, что более старшие разработчики гораздо реже ищут ответы на вопросы о переполнении стека и вместо этого предпочитают обращаться к официальным документам для языка или инструмента, которые они используют. Они понимают преимущества реального понимания инструмента или языка, с которым они пытаются работать, а не просто поиска быстрого решения для решения текущей проблемы. Всякий раз, когда я оказываюсь в переполнении стека, в большинстве случаев это происходит потому, что у меня недостаточно глубокое понимание технологии, с которой я работаю. Это может быть полезно в крайнем случае, но не должно использоваться для сокрытия поверхностного понимания выбранного вами инструмента или языка.
Нии Ашиквей Теттех является разработчиком программного обеспечения в ThoughtWorks, а также был тренером в пятиминутном учебном лагере для выпускников (младших) разработчиков под названием ThoughtWorks University. Он работал с десятками младших разработчиков и говорит: “Хотя полезно обратиться к более широкому сообществу и использовать примеры кода или находить работающие решения, гораздо важнее понять, почему и как они работают, и что вы могли бы сделать, чтобы добраться туда самостоятельно”. Он говорит, что, хотя чтение документации может быть немного скучным, крайне важно получить реальное представление о языке или структуре, с которыми вы имеете дело.
Уменьшить масштаб
Младшие разработчики, как правило, имеют гораздо меньшую зону внимания при работе в системе. Это как если бы мы смотрели на код через микроскоп, в то время как более старшие разработчики смотрят на него через широкоугольный объектив. Более опытным разработчикам потребуется время, чтобы продумать потенциальные побочные эффекты того, над чем они работают, а также то, как это вписывается в общую систему. Они будут задавать такие вопросы, как: согласуется ли это с тем, как все было сделано в других частях кодовой базы? Используется ли код повторно в другом месте системы? Будет ли этот код легко поддерживать в будущем? Во время работы не забывайте уменьшать масштаб и думать о том, как ваш код вписывается в контекст системы в целом.
Сделайте свой собственный контроль качества (QA)
Большинство команд будут иметь некоторую комбинацию автоматизированного и/или ручного тестирования, чтобы убедиться, что новые функции соответствуют требованиям, отличаются высоким качеством и не нарушают никаких существующих функций. Возможно, вам даже повезет, если в вашей команде будет специальный тестировщик, который сможет убедиться, что то, что вы создали, соответствует поставленной цели, и продумать различные сценарии для тестирования. В гибких средах это анти-шаблон, когда работа откладывается (т. Е. со стадии "В разработке" на стадию "Проверки’ (QA), снова на стадию "В разработке"). Обычно это происходит, когда разработчик не понял или не соответствовал критериям приемлемости – перечню вещей, которые должна выполнить работа, чтобы считаться "выполненной".
Проведя тщательное тестирование вашей собственной работы до того, как она перейдет к этому этапу проверки, вы улучшите качество работы, продумаете сценарии тестирования и крайние случаи, сэкономите время для остальной части вашей команды и продолжите работу вперед, а не назад. Если вы работаете в одиночку, этот дополнительный этап контроля качества еще более важен. Если вы не обнаружите ошибки и ошибки до того, как они попадут в производство, никто другой этого не сделает!
Не игнорируйте мир, окружающий вашу работу
Легко почувствовать, что нет ничего важнее следующей функции или проблемы, которую необходимо решить. Встречи, исследования и время, потраченное на сбор более широкого контекста для вашей работы, могут показаться болезненными перерывами между тем, как вы пачкаете руки в коде. Однако вскоре вы поймете, что понимание причин того, что вы делаете, важнее, чем "как". Если вам не хватает контекста или понимания бизнеса, отрасли или организации, в которой вы работаете, вы можете в конечном итоге создавать вещи, которые людям не нужны или не будут использоваться. Значительная часть ошибок младших разработчиков связана с тем, что мы неправильно понимаем или делаем предположения о домене, в котором мы работаем. Потратьте время, чтобы понять, как все работает в реальном мире, прежде чем пытаться перевести их в код.
Тесты - это ваша система безопасности и ваш компас
Написание тестов чрезвычайно важно для младших разработчиков, особенно когда вы работаете в команде или вносите свой вклад в более крупную систему, поддерживаемую несколькими разработчиками. Тесты - отличный способ улучшить вашу реализацию, но что более важно для младших разработчиков, они являются фантастической системой безопасности, которая защищает вас во время вашей работы. Хорошие тесты дадут вам знать, как только вы что-то сломаете. Старайтесь запускать свой набор тестов с интервалами во время работы, чтобы убедиться, что ничто из того, что вы сделали, не имело непреднамеренных побочных эффектов. Тесты дадут вам уверенность в том, что вы внесете изменения и улучшения, необходимые для базы кода.
Если вы работаете самостоятельно и еще не пишете тесты, стоит потратить время на то, чтобы научиться писать модульные тесты на выбранном вами языке.
Разделите свои проблемы
Независимо от того, работаете ли вы с объектно-ориентированными или функциональными языками, хорошее разделение задач является признаком квалифицированного разработчика. У опытных разработчиков есть инстинкт для определения отдельных проблем и границ между ними. Но что означает "беспокойство" в данном контексте?
Сферы ответственности в кодексе
Основные области в кодексе
Или конкретную "работу", которую выполняет код
Младшие разработчики часто с трудом выявляют и разделяют различные проблемы. Хорошим правилом является создание одного файла для каждой области ответственности в коде.
Полезным приемом для определения отдельных областей ответственности является "И тест": если при описании файла или класса в вашем коде вам нужно использовать слово "И", вы, вероятно, определили обязанности, которые могут (и, вероятно, должны) быть разделены.
Вот пример:
Класс конференций отвечает за планирование И отображение расписаний конференций. (Не проходит тест И).
Вместо этого, как насчет:
Класс ConferenceScheduler отвечает за планирование конференций.
SchedulePresenter отвечает за представление расписаний.
Когда вы разделяете свой код таким образом, вы можете получить довольно сжатые файлы – даже менее 50 строк. Это нормально! С приложением, состоящим из небольших классов, которые хорошо работают вместе, вероятно, будет намного проще работать, чем с монолитным приложением, состоящим из нескольких больших классов, каждый из которых выполняет множество разных функций.
Напишите короткие методы
Если и есть какой-то запах кода, который я часто вижу среди младших разработчиков, то это длинные методы/функции. Распространенный шаблон - это метод, названный в честь его конечного результата, который делает абсолютно все необходимое для достижения этого конечного результата, часто на протяжении многих строк кода, и работает на очень низком уровне (манипулирование строками, циклический перебор данных). Это может затруднить работу с вашими методами и понимание – на самом деле, есть несколько вещей более пугающих, чем попытка понять длинный, сложный метод, который запускает машинную цепочку событий, подобную Рубу Голдбергу, для достижения некоторого конечного результата.
Один из способов подойти к этому - позволить вашей реализации начаться как один длинный метод, затем разбить его на частные методы, которые выполняют шаг, и документировать то, что делается.