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

Сегодняшний вопрос: каковы лучшие практики для начинающих программистов?

Игнорируя инструменты или парадигмы, специфичные для языка, вот некоторые из самых основных вещей и концепций, которые следует иметь в виду начинающему программисту.

Я не перечислял вещи в каком-то определенном порядке, все они одинаково важны;)

Краткие функции / процедуры

Функция должна быть такой, какой должна быть, и не больше. Когда вы думаете, что он такой короткий, каким должен быть ... Обычно вы можете объединить его немного дальше!

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

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

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

Когда ваша функция достигает 15–20 строк или около того, пора оценить, следует ли разбить ее на несколько связанных, но специализированных функций. Здесь нет жесткого правила! Иногда нужно, а иногда нет, но новичку лучше ошибиться и разделить это, чтобы выработать привычку.

Разумные и информативные имена функций и переменных

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

В этом случае обычно используется префикс с буквой, например bUserHasAccess для логического значения, aUserPosts для массива и т. Д.

Единственное, что я позволяю людям избегать при проверке кода, - это циклы и переменная i, как в for(i=0; i<=length(users); i++), просто потому, что это очень распространенный шаблон, сокращение от index, и он используется только для обозначения позиции в массиве.

Код с хорошими именами не только легче читать и понимать, но и помогает, когда IDE используют автоматическое предложение, потому что вместо бесконечного списка «id» вы знаете, что вам нужен «enterpriseId», а не какой-либо другой.

Пример:

// Bad variable name
var a=4;
// Better
var userId=4;
// Best
var studentUserId=4;

Что касается функций, то на самом деле то же самое.

// Bad function and parameter names
function validate(a, b){}
// Good
function validateStringRegex(stringValue, regexPattern) {}

Множество комментариев

Но, пожалуйста, оставляйте их полезными комментариями!

// Bad developer, don't do this
// Loop the values
for(a=0; a < 100; a++){}
// Good
// Sort users into arrays based on age
for(index=0; index < length(userArray); index++){}

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

/*
   This class deals with Twilio messages as it relates to a specific
   enterprise client and their validations.
   Most are the same but a few clients have variations in their 
   validators accounted for by using standardValidator() or
   <client id>Validator(), see documentation entry someurl.com/docs 
   for details
*/

Комментарии к функциям следуют той же концепции.

// Bad comment
// This function validates usernames
function validate(username){}
// Good
// Validates a username for char count, UPPER lowercase, length, and that it doesn't contain parts of their email or username
function validateUsername(username){}

Я тоже ошибаюсь.

Я пишу библиотеку и просто вернулся к фрагменту кода, чтобы продолжить с того места, на котором остановился вчера рано утром. Чтобы вспомнить, что такое _closeText, потребовалось больше нескольких секунд!

Вот сигнатура функции

function alert(_message, _closeText){}

Это имело смысл, когда я выбил его вчера, но, глядя на это сейчас, явно недостаточно ясно. Новая версия выглядит так:

function alert(_modalBodyText, _closeButtonText){}

Избегайте «умного» кода

Может быть интересно выяснить, как сделать что-то «по-умному», чтобы сэкономить несколько строк кода или получить небольшое улучшение скорости.

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

Когнитивная нагрузка в этом случае примерно равна «Сколько времени и умственных усилий требуется, чтобы обработать и понять то, что я читаю».

Это включает в себя странные троичные операторы, смешивание положительных и отрицательных проверок в одном операторе, очень длинные однострочные выражения и т. Д.

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

Классы / юниты - ваш друг

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

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

Разделение его также упрощает работу над одной и той же кодовой базой в команде. У вас меньше шансов наступить друг другу на пятки (адское слияние) или внести изменения, нарушающие чужой код.

Простым примером является класс пользователя и некоторые связанные с ним функции.

Допустим, у вас также есть электронная почта, телефон и проверка адреса.

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

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

Лучше иметь несколько четко определенных файлов / классов, чем несколько больших файлов, охватывающих слишком много.

Не оптимизируйте преждевременно, но и не игнорируйте это

Это скорее опыт, но все же важно упомянуть.

Скорость имеет значение, но если вы тратите полдня, чтобы набрать 50 мс, вы либо тратите время, вам действительно нужны, либо вы просто развлекаетесь.

Главное - проводить время там, где это наиболее ценно, помните, что ваша работа не в написании кода, а в решении проблем.

Это базовая приоритезация, или сортировка, вы определяете, какая работа наиболее эффективна, и начинаете с нее.

Попросить помощи

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

Но все просто, как в шахматах!

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

Просто следуйте нескольким простым правилам, и все будет в порядке:

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

Никто не хочет тратить время на поиски вещей, копаться в своем старом коде или писать подробные ответы на простые вопросы только потому, что вы сдались через 10 минут.

Но если вы это сделаете

  • Проведите время, пробуя что-нибудь
  • Сделайте свое исследование
  • И ты все еще застрял

Тогда люди обычно более чем рады помочь вам.

Имейте в виду, что большинство из нас не просто даст вам ответ, а даст вам способ решить проблему самостоятельно.

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

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

Помочь другим

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

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

Пишите много кода

Но самое главное - писать много кода. Фактически, не просто писать код, а писать свой код!

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

Простая прогрессия

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

Конец

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

Я надеюсь, что вы сможете использовать что-нибудь в этом посте, чтобы улучшить себя и свои навыки.