Подобно письменному языку, код является средством выражения логических и абстрактных идей. Конечно, языки программирования предназначены для интерпретации машиной, но разработчики часто упускают из виду то, что наш код представляет собой руководство пользователя, описывающее движущиеся части системы, которую мы создаем, написанное для ее человеческиесоздатели.
Забери это на секунду.
Код, который я пишу сегодня, должен быть достаточно простым, чтобы его можно было понять не только завтра, но и через месяцы или годы, даже после того, как я забуду свой мыслительный процесс. И что еще более важно, написано не только для меня, но и для следующего человека, читающего это.
Расскажи историю.
Как и творческое письмо, программирование — это форма повествования. Логические объекты, которые вы обсуждаете в своем коде, должны представлять ваши идеи таким образом, чтобы их мог понять ваш коллега. Таким образом, кодирование по своей сути является творческим процессом. Лучший код, который я читал, очевидно, подвергся вдумчивому и творческому рассмотрению, а сложные системы и абстрактные идеи изображаются с помощью рисунков, представляющих концепции, с которыми люди уже знакомы в реальном мире.
Посмотрите на этот (несколько глупый и нелепый) пример.
Для нашего вымышленного приложения нам было поручено создать сервис, который автоматизирует процесс обнаружения и восстановления серверов, которые работают со сбоями. Поскольку среди разработчиков хорошо известно, что метафора «тушить пожары» обычно используется для описания процесса исправления того, что идет не так в (обычно работающей) системе, мы решили использовать реальную идею пожарная машина, представляющая нашу службу реставрации.
class FireEngineFactory {
constructor() {
this.waterTankLevel = 100;
}
dispatch(location) {
// Locates and returns the server.
}
extinguish() {
// Perform server fire extinguishing logic.
this.waterTankLevel--;
}
refill() {
// Refill the resources needed for extinguishing server fires.
this.waterTankLevel = 100;
}
}
/* Use our fire engine service in context. */
const fireEngine = new FireEngineFactory();
const server = fireEngine.dispatch('server.that.is.burning.down');
while(server.status !== 'extinguished') {
fireEngine.extinguish();
if (fireEngine.waterTankLevel === 0) {
fireEngine.refill();
}
}
console.log('Fire successfully extinguished!');
В нашем примере мы создаем новый экземпляр службы пожарной машины, отправляем его в расположение сервера, который не работает, и пытаемся погаситьпожар, пока он не будет успешно потушен, не забывая пополнять наши ресурсы, когда это необходимо. Мы использовали идеи из реального мира, чтобы обозначить наши функции и переменные, которые помогут любому, кто читает этот код, быстро получить интуитивное понимание системы на высоком уровне. Конечно, у нас, скорее всего, будет некоторая сложная логика, написанная в каждой из этих функций, которая выполняет фактическую работу нижнего уровня, но благодаря продуманному и творческому обозначению мы сделали общую картину более легкой для понимания на высоком уровне.
Четко сформулируйте намерение.
Неоднозначный код трудно отлаживать и поддерживать. Как бы ни было заманчиво быстро пройти через процесс написания кода и просто заставить что-то работать, дополнительное время, потраченное на написание кода, который явно выражает свое намерение, — это то, что действительно сэкономит время в будущем. .
Отдавайте предпочтение ясности, а не краткости.
Будучи младшим разработчиком, я часто увлекался попыткой написать код, используя как можно меньше строк. Хотя сокращение кода является важным аспектом удобочитаемости, его не следует делать за счет удобочитаемости. Если вы можете написать фрагмент кода, который более четко иллюстрирует то, что он делает, в двадцати строках вместо десяти, сделайте это! Ваши коллеги поблагодарят вас завтра, когда им нужно будет отладить его. В большинстве случаев дополнительный код будет незначителен во время выполнения и фактически часто даже улучшает производительность.
Сделайте свой код самодокументируемым.
Не слишком полагайтесь на комментарии к исходному коду. Хорошо продуманный код, написанный с явным намерением, часто не нуждается в дополнительных пояснениях. Сегодняшний код, скорее всего, изменится завтра, и комментарии легко не синхронизируются с тем, как ведет себя соответствующий код.
Вот несколько рекомендаций по написанию кода, который объясняет сам себя:
- Точно называйте переменные и функции.
- Нарисуйте четкие отношения между логическими объектами.
- Разбейте сложность. Преобразуйте сложные процессы в удобочитаемые и предсказуемые части.
Для более глубокого изучения написания преднамеренного кода ознакомьтесь со статьей Кеннета Рейли.
Начните с документации.
Написание документации — это то, чего избегает большинство разработчиков, включая меня самого. Мы инженеры, и мы хотим сразу же прыгнуть, запачкать руки и создать классные вещи! Даже когда у нас есть намерение написать документацию после того, как мы закончим, это никогда не произойдет. Почему? Ну, мы никогда не «готовы», не так ли? А деловые дедлайны требуют, чтобы мы подготовили наш код и протестировали его, чтобы мы могли перейти к следующей задаче. Документация падает все ближе и ближе к концу отставания. Цикл продолжается.
Написание документации — это и навык, и дисциплина, и этот навык разовьется сам собой, как только вы войдете в привычку. И чем раньше вы сделаете это привычкой, неотъемлемой частью вашего процесса разработки, тем лучше для всех. Даже если это не входит в критерии приемки, ваша команда позже скажет вам спасибо; позже, когда нужно будет потушить пожар, и ваша потрясающая документация сэкономит команде драгоценные часы или дни времени на отладку. Или когда новому разработчику в проекте нужна всего неделя адаптации вместо месяца.
Самый простой способ начать писать документацию — это начать с документации. Сделайте хотя бы черновой набросок, прежде чем писать хотя бы одну строчку кода. Во-первых, этот процесс заставит вас убедиться, что вы тщательно продумали свое решение, что оно имеет смысл и что вы можете сообщить о нем другим (это также поможет вам в рассказывании историй, когда придет время начинать кодирование). Во-вторых, к тому времени, когда вы приступите к написанию кода, у вас уже будут готовы хотя бы некоторые из ваших документов, что сделает процесс их заполнения менее сложным и более управляемым.
Выучить язык.
Я провел большую часть своей карьеры инженера-программиста, работая в командах разных национальностей. Работать в смешанном коллективе — это прекрасно. Я знакомлюсь с другими культурами и разным образом мышления людей, и это помогло расширить мое собственное мышление и добавило творчества и гибкости в мой подход к проектированию систем и решению проблем в целом.
Одной из проблем, которая может возникнуть в контексте многонациональной команды, является языковой барьер. Общение сложных идей без слов может быть затруднено по обе стороны барьера. Тем не менее, я столкнулся с той же проблемой и с людьми, говорящими на их родном языке, поэтому следующий совет подходит для всех.
Ваша способность эффективно общаться на основном языке команды значительно влияет на вашу работу и ценный вклад в проект. Улучшение ваших устных и письменных навыков общения на основном языке команды положительно повлияет на ваши способности в следующих областях:
Понимание
Распространенной причиной ошибок и плохо написанного кода является отсутствие правильного понимания того, что нужно построить в первую очередь. Чем лучше вы понимаете природу проблемы, тем быстрее вы сможете продвигаться вперед с решением, уверенно и эффективно.
Намерение и повествование
Благодаря богатому словарному запасу у вас есть более богатый выбор цветов для рисования. Творчески выражать свои идеи и свои намерения становится легче только тогда, когда у вас есть больше слов для работы.
Навыки исследования
Понимание документации по инструментам и умение находить решения распространенных проблем на форумах сообщества являются важными навыками. Чем лучше вы понимаете язык, который использует сообщество, тем лучше вы будете понимать инструменты, которые используете.
Заключение
Как программисты, мы рассказчики историй, и у нас гораздо больше общего с творческими писателями, чем просто поглощение слов целыми днями. Чтобы стать выдающимся программистом, нужно сначала стать выдающимся коммуникатором, и, потратив время на развитие своих коммуникативных навыков, вы не только создадите более качественное и надежное программное обеспечение, но и станете все более ценным активом в командах, в которых участвуете.
