Как могли заметить последователи этого блога, последние несколько недель я довольно часто упоминал Чистый код. Я начал читать книгу по совету друга и коллеги-программиста, который превозносил ценности этого классического текста по программированию. Я прохожу через это очень медленно, читая всего одну главу в неделю, чтобы убедиться, что эти уроки глубоко укоренились в моей голове. Тем не менее, я вижу, как Чистый код существенно влияет на то, как я думаю о коде, который пишу, а также о коде, который буду писать в будущем.
Написанный Бобом Мартином - или дядей Бобом для тех, кто о нем знает, Clean Code был впервые выпущен в 2009 году и отражает некоторые из лучших идей, которые программисты обнаружили за последние несколько десятилетий. Вы, наверное, слышали об этом раньше, и почти наверняка он есть на полках почти каждой компании, работающей в сфере высоких технологий. Поскольку вычисления - это создание машин, которые могут выполнять определенные задачи более эффективно, чем люди, нам было бы неплохо прислушаться к мнению некоторых из наиболее проницательных умов.
В этом сообщении в блоге я собираюсь вернуться к коду, который я написал для предыдущего проекта, и рефакторинг его, чтобы отразить уроки, которые я извлек из Чистого кода. Поскольку я прочитал только первую пару глав, я буду очень конкретен в своих мыслях, сосредоточившись только на значимых именах и комментариях. Я надеюсь, что это вдохновит вас всегда, что бы вы ни делали, писать чистый код.
В частности, я буду заниматься рефакторингом простого приложения для викторин, которое я создал, чтобы научиться TypeScript. Не стесняйтесь проверить репозиторий GitHub здесь или прочитать мою статью на Medium об изучении TypeScript. Запустите приложение локально, и вы должны увидеть что-то вроде этого:
Мне было очень весело изучать TypeScript, и я определенно понимаю, почему программистам нужна вся функциональность JavaScript с более строгим набором текста. Хотя мне нравилось создавать это небольшое приложение, я подозреваю, что написал не самый чистый код. И хотя это был сольный проект, в котором я был единственным разработчиком, кто-то другой мог легко прийти и решить построить на основе того, что я сделал. Сотрудничество - это часть красоты Интернета, и такие инструменты, как GitHub, делают программирование таким мощным. Однако, если бы появился другой программист, отсутствие у меня чистого кода, несомненно, замедлило бы его работу. Как дядя Боб снова и снова говорит нам, количество времени, затрачиваемого на чтение кода, а не на его написание, легко составляет 10: 1. Давайте углубимся в код и посмотрим, что мы можем отремонтировать.
Имена
Одна из первых глав Чистого кода посвящена именам. Первое предложение главы гласит: «Имена везде в программном обеспечении». Среди прочего, мы постоянно называем функции, переменные и аргументы. Поскольку именование элементов наших программ происходит так часто, мы должны делать это хорошо, давая четкие и значимые обозначения. Возьмем следующую функцию:
Вышеупомянутая функция довольно проста. Он принимает значение события щелчка (какой бы ответ ни выбрал пользователь) и проверяет, верен ли этот ответ. Хотя я вполне доволен некоторыми соглашениями об именах, которые использовал здесь, я думаю, что мы можем сделать немного лучше. Во-первых, я думаю, что checkAnswer() мог бы быть более конкретным. Если бы это был более крупный проект с разными типами вопросов викторины, просто сказать своему товарищу-программисту «Да, эта функция проверяет ответ или что-то еще» было бы недостаточно. Проверяет ли он ответ пользователя? В каком контексте проверяется ответ? Есть ли какой-то «ответ» фонового процесса, который он проверяет? Как сообщает нам Чистый код, мы, программисты, хотим использовать имена, раскрывающие намерение. То есть мы хотим показать читателю, почему эта функция существует и что она делает. Попробуем сейчас его почистить:
На мой взгляд, это небольшое обновление значительно улучшает нашу программу. Теперь, когда другие кодировщики сталкиваются с checkUserAnswerForCorrectness(), они ясно видят, что он принимает MouseEvent от пользователя и проверяет, соответствует ли этот ответ данным в нашей базе данных. Это небольшое изменение может сэкономить драгоценное время членам нашей команды.
Проницательные читатели могли заметить, что я также заменил переменные prev на previous. Хотя большинство людей поняли бы, что сокращение prev, я сделал этот рефакторинг по очень важной причине чистого кода: Избегайте дезинформации. Быть ясным - значит быть конкретным, и мы не хотели бы, чтобы наши товарищи-программисты сталкивались prev и думали, что это может означать что-то иное, кроме предыдущего. Хотя программисты, скорее всего, всегда будут использовать i для итерации или x для хранения особенно очевидного бита данных, написание полных слов должно помочь вам в долгосрочной перспективе.
Хотя подробные соглашения об именах важны, написание чистого кода требует баланса. Вы не можете просто назвать свою функцию примерно так:
Хотя это технически более конкретное имя для этой функции, оно явно хуже, чем checkUserAnswerForCorrectness. Мы даже не можем увидеть полное имя функции, не говоря уже о любых аргументах, которые она принимает! Наши программы - это рассказы, и нам, как рассказчикам, было бы неплохо развить свои описательные навыки. Хотя в этой главе Чистый код есть еще много уроков, это хороший учебник по использованию эффективных имен.
Комментарии
Проще говоря, программисты не могут полагаться на комментарии, чтобы спасти свой запутанный код. Как говорит дядя Боб, ничто не может быть «настолько полезным», как хорошо помещенный комментарий, но он также может загромождать ваши программы, чем больше вы их используете. Хотя может быть полезно предоставить вашему читателю информацию об авторских правах или объяснение намерений в форме комментария, в целом комментарии не нужны и отвлекают взгляд от кода, основного источника истины в вашей программе.
Признаюсь, я неплохо избегаю комментариев. Программисты, которые меня учили, постоянно инструктировали меня выражать себя с помощью кода, и что комментарии в большинстве своем несерьезны. Скорее всего, они научили этому, потому что прочитали Чистый код раньше меня. Чтобы сохранить верность этому сообщению в блоге, я вставлю несколько комментариев в приложение и поделюсь некоторыми важными уроками из Чистого кода. Сначала рассмотрим следующий плохой комментарий:
Приведенный выше комментарий является хорошим примером того, что Чистый код называется избыточным комментарием. Комментарий хоть что-нибудь для читателя здесь? Разве ваша программа не была бы более понятной, если бы вы изменили имя функции, сделав ее более описательной, возможно, назвав ее чем-то вроде provideNextQuestionToUser()? В конце концов, вы не хотите, чтобы комментарий, который должен дать понимание, занимал больше времени, чем сама функция, так что этого комментария легко избежать в будущем. Давайте посмотрим на еще один плохой комментарий:
Приведенные выше комментарии представляют то, что дорогой дядя Боб называет шумовыми комментариями. Они забивают плохо написанные функции, раздувая ваш код до тех пор, пока вы не сможете его усвоить. В то время как программист может захотеть включить один комментарий в верхней части функции, чтобы направлять читателя, использование хороших соглашений об именах может сэкономить несколько строк комментариев. Посмотрите, насколько чище код, если немного его урезать:
Я думаю, мы можем согласиться, что это значительно легче читать, и ваши коллеги-программисты, вероятно, оценят верхний комментарий, описывающий, что будет делать функция. Помните, прежде чем писать комментарий, посмотрите, сможете ли вы реорганизовать свой код, чтобы сделать его более понятным. Давайте посмотрим на последний плохой комментарий, который мы рассмотрим здесь:
Надеюсь, это отчасти очевидно, но Закомментированный код практически не полезен для других людей, читающих ваши программы. Может быть, приведенный выше код был для более ранней итерации приложения, может быть, это просто вздор, который невнимательный программист забыл удалить. Тем не менее, его, вероятно, не должно быть в программе, и, поскольку он содержит так мало информации, он, вероятно, сохранится. Как сообщает Чистый код, у других людей, скорее всего, не хватит смелости удалить этот комментарий, потому что они не знают, насколько он важен. Как первоначальные авторы наших программ, мы должны обращать пристальное внимание на то, что можно исключить из наших программ, чтобы сделать их более понятными. Комментарии могут быть полезны, но только если они сделаны хорошо.
В течение следующих нескольких недель я буду больше читать Чистый код и делиться своими знаниями для начинающих программистов. Читая эту книгу очень медленно (примерно одну главу в неделю), я хочу действительно усвоить как можно больше информации, что в конечном итоге сделает меня в целом значительно лучшим программистом. Заходите сюда еженедельно, чтобы увидеть мой прогресс!
