Питер Сейбел недавно написал в блоге, чтобы бросить вызов идее чтения кода ради чтения . «Кодекс не литература, а мы не читатели», — заключил он. «Скорее, интересные фрагменты кода — это образцы, а мы натуралисты».
Это частично правда. Интересные фрагменты кода — это образцы. Вырванные из их контекста в программах или инфраструктурах, строки кода становятся как мертвые ошибки на булавках в коробках.
Было бы неплохо посидеть с бокалом бренди и обсудить дюжину строк кода, как если бы они были каким-то экзотическим насекомым или даже поэзией, но немногие разработчики могут позволить себе такую роскошь. У разработчиков есть работа, которую нужно решить, и задачи, которые встроены в тысячи строк кода поддержки. Часто эти линии строятся многочисленными разработчиками, пытающимися решить ряд проблем, которые непредсказуемо развиваются с течением времени.
Но это не значит, что разработчики не читают исходный код. На самом деле чтение — это первое, что входит в решение большинства проблем. Первоначальный шаг обычно состоит в том, чтобы отделить трассировку стека или выполнить поиск по всем файлам журналов, которые могут быть под рукой. Но затем начинается чтение подозрительных частей исходного кода, и начинается детективная работа.
Это чтение не гламурно. Повседневные практики чтения исходного кода часто остаются вопросом выживания: их достаточно, чтобы исправить или взломать код и, возможно, некоторые модульные тесты, чтобы дожить до следующего дня.
Чтобы поднять чтение исходного кода до уровня профессионального развития, я предлагаю модель для лучшего понимания того, что происходит в процессе чтения исходного кода. Цель? Чтобы показать, как использовать это в постоянном, встроенном профессиональном развитии. Нет чтения групп или бренди снифферы не требуется.
Чтение не простая деятельность
Большинство людей говорят о чтении, как о простом и скучном занятии, например, дыхании или сидении. Но чтение на самом деле очень сложное занятие. Даже сам процесс чтения исходного кода требует много разных типов понимания. Признание этих различных типов понимания по мере их возникновения является ключом к превращению источника чтения из навыка выживания в нечто, что делает нас лучшими разработчиками.
Существуют многочисленные таксономии понимания прочитанного. Тот, который я нашел полезным и относительно простым, обрисован в общих чертах в статье Ричарда Р. Дея и Чон Сука Парк, опубликованной в онлайн-академическом журнале « Чтение на иностранном языке» .
Дей и Парк определяют шесть типов понимания — буквальный, реорганизационный, логический, прогнозирующий, оценочный и личный ответ — который я сопоставлю с чтением исходного кода. Я также опишу каждый из уровней и предложу способы, с помощью которых разработчики могут использовать идеи каждого типа чтения для перехода от выживания к профессиональному развитию.
Буквальное понимание: строки кода
Вероятно, буквальное понимание — это то, что люди чаще всего представляют, когда говорят о «чтении исходного кода»: настоящие глазные яблоки сканируют настоящие строки исходного текста. На буквальном уровне чтение сводится к пониманию синтаксиса Ruby: создается экземпляр класса; члены массива передаются в блок. Этот уровень чтения важен для начинающих, изучающих язык, но это также режим чтения для исправления ошибок, таких как переменные или методы с ошибками.
Но как практика чтения в служении непрерывному профессиональному развитию, даже для начинающих, это уровень понимания, когда мы сталкиваемся с незнакомыми шаблонами и специфическими для Ruby идиомами. Я помню, как впервые столкнулся с условным присваиванием, которое следовало этому шаблону:
x = if condition
true
else
false
end Этот пример подтверждает, что да, все выражения в Ruby возвращают значение: xif x Но я забегаю вперед: это наблюдения, выведенные из логического уровня понимания, описанного ниже. На буквальном уровне имеет значение то, что все операторы Ruby могут находиться справа от =
На уровне буквального понимания, распознавание новых моделей — огромная возможность профессионального развития. Я сохраняю для себя то, что пишущие учителя называют обычной книгой удивительных шаблонов исходного кода: личная коллекция примеров, найденных в дикой природе (например, образцы Сейбеля), чтобы служить руководством или вдохновением в будущих усилиях по программированию.
Обычная книга — полезный счетчик книг по антипаттернам с их серией предупреждений и ошибок, которые не позволят вам случиться. Буквальное понимание, которое фокусируется на плохих примерах, дает возможность непреднамеренно повторять то, что мы видим чаще всего (вероятно, поэтому разработчики Ruby, пришедшие, например, из PHP, обычно начинают с написания Ruby, который во многом похож на PHP). Уравновешивание антипаттернов или просто старого плохого кода с яркими, умными примерами — важное профессиональное упражнение. Это также важно для создания репертуара Ruby идиом.
Реорганизационное понимание: части образуют целое
Код — это не литература, отчасти потому, что он меньше похож на роман, чем на огромный словарь, разбитый на множество томов. Это особенно верно в Ruby с его чрезвычайной гибкостью для разделения модулей и классов по нескольким файлам, определения одноэлементных методов и так далее. В реорганизационном понимании разработчик строит мысленную модель составных частей исходного кода — фактических строк исходного текста, встречающихся в буквальном понимании — независимо от того, как организован код.
Для профессионального развития реорганизационное понимание является центром значимого рефакторинга. Например, модели и контроллеры в Rails 4 были значительно реструктурированы с появлением проблем, которые абстрагируют и извлекают повторно используемые части моделей и / или логику контроллера.
В более скромном масштабе профессиональные уроки чтения, включающие реорганизационное понимание, могут помочь разработчикам переосмыслить организацию модулей, классов и методов Ruby, а также файлы, которые их содержат. Реорганизационное понимание устанавливает ментальную модель программы. Рефакторинг может быть нацелен на приведение этой модели в соответствие с фактическими компонентами программы.
Инференциальное понимание: заполнение пробелов
Буквальное и реорганизационное понимание зависит от чтения определенных строк кода. На уровне вывода, однако, разработчики используют имеющиеся знания для чтения определенных строк кода.
Например, метод, подобный #eachArrayEnumerable Начинающие новички в фреймворке, таком как Rails, часто пытаются определить, какие методы или классы предоставляются Rails, а какие являются частью стандартной библиотеки Ruby.
Инференциальное понимание побуждает разработчиков читать и ссылаться на документацию, а также проводить другие виды исследований в книгах и блогах. Инференциальное понимание, особенно для новых разработчиков, представляет собой серьезную проблему. Но, как и в кратком обзоре о возвращаемых значениях присваивания и выражений, он также становится методом профессионального развития для определения того, где вы находитесь в своем собственном понимании.
Предсказательное понимание: интерпретатор в вашем разуме
Если умозаключение связано с заполнением деталей вокруг конкретных строк кода, предиктивное понимание больше относится к общей картине того, что программа, вероятно, сделает (или, что более мрачно, как она может потерпеть неудачу). Интеллектуальное понимание — это интерпретатор Ruby в вашем уме: это среда выполнения для реорганизационного понимания.
В идеальном мире разработчики имели бы идеальное прогнозирующее понимание. Это будет означать устранение всех ошибок, поскольку это будет означать полное понимание всей кодовой базы и даже ее непреднамеренных, ошибочных побочных эффектов.
Но если этого не произойдет, прогнозирующее понимание направляет профессиональное развитие в очень важной области: модульные тесты. Как и само чтение, разработка набора тестов не может быть основанием для продвижения или всемирной известности. Но тестовые наборы — не что иное, как результат прогностического понимания. Знание того, что тестировать и где ожидать сбой в программе, — это первые шаги в создании полезных тестов. Более продвинутые методы, такие как разработка через тестирование, требуют другого типа прогнозирующего понимания: предсказания поведения программы, которая еще даже не была написана.
Оценочное понимание: отбор и пересмотр
Оценочное понимание — самый сложный тип чтения. Он принимает форму сравнения, например, множества различных драгоценных камней для обработки Markdown. Но это также чтение, необходимое для официальных проверок кода в организациях и проектах с открытым исходным кодом.
На этом этапе профессиональное развитие смещается наружу. Достигнув уровня оценки чужого кода, особенно в обзорах, профессиональное развитие поворачивается к обучению и наставничеству. Задача состоит в том, чтобы стать более четким в определении критериев оценки. Это, в свою очередь, поможет вам направлять и наставлять новых разработчиков в команде или проекте, а также помогать вам стать более внутренне последовательными в оценке вашей собственной работы и работы других.
Личный ответ: корни стиля
Тернистый двоюродный брат оценки является личным ответом . В его менее блестящие моменты этот уровень является питательной средой для религиозных дебатов, связанных с вопросами стиля программирования. Дэй и Парк отмечают, что «хотя личные ответы неверны, они не могут быть необоснованными».
И это становится профессиональным развитием на этом уровне: за пределами стиля личный ответ выходит за рамки знания и к чему-то вроде мудрости. Вы можете быть лично против использования троичного оператора ( x = condition ? 'foo' : 'bar'||=
Интегрированные уровни понимания
Как вы, наверное, уже заметили, в повседневной работе ни один уровень понимания не задействован полностью сам по себе. И иногда уровень понимания вообще не задействован. Сколько кодовых баз имеют ошибки, случайно введенные (или оставленные без исправлений) из-за плохого предиктивного понимания? И насколько плохое предиктивное понимание является результатом плохого реорганизационного понимания, которое само по себе может быть результатом плохо организованных кодовых баз?
Но это в конечном итоге задача любого профессионального развития. Независимо от того, посещаете ли вы конференцию или берете книгу, чтобы изучить новый метод или платформу Ruby, любое значимое мероприятие по профессиональному развитию требует выхода за пределы молчаливых, укоренившихся навыков и формирования вдумчивого понимания сложностей, связанных с каждой строкой источника, которая пишется каждый день. ,
Принимая некоторую активность, такую же скучную и обыденную, как чтение, изучение ее составных частей, таких как уровни понимания прочитанного, в данном случае, позволяет каждому из нас заново собрать игру и получить профессиональные преимущества, которые иначе были бы невозможны.