попытка выполнения команды по чужому или отсутствующему коду в z front

Legacy: что нужно знать о работе с чужим кодом

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

У вас бывало так, что вы смотрите на чужой код и не знаете, с чего начать? В этом лабиринте чужих решений не придет на помощь и нить Ариадны: полагайтесь только на свои силы. А мы подскажем 🙂

Пожалуй, первое правило звучит так:

«Если в коде что-то реализовано не так, как вы привыкли – это не значит, что оно реализовано неправильно.»

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

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

О рефакторинге есть не одна книга. Поэтому вторым советом будет обратиться к литературе, например, Working Effectively With Legacy Code.

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

Уважайте чужой труд

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

Легко критиковать чужую систему, но от этого она не станет понятней. Поэтому при вхождении в новый проект приложите максимум усилий к пониманию внутреннего устройства и заложенных знаний. Вам помогут официальные или собственные юнит-тесты. Задокументируйте все, что слышите от людей, связанных с проектом, анализируйте ссылки и документацию проекта, сверяйте с собственными результатами. Фундаментальные знания помогут понять сложную систему.

Привыкните к тому, что люди редко жертвуют временем ради того, что уже работает, и предпочитают сосредоточиться на новых тасках. Но в legacy часто нужен человек, который способен внести ясность. Решение этой проблемы может не входить в прямые обязанности действующих или бывших сотрудников. Так что «новичку» приходится разбираться самому: разворачивать среду разработки, искать повторяющиеся конфигурации, процессы, улучшать виртуальную среду или контейнеры, подключать внешние службы к локальной среде или использовать заглушки, проводить тесты.

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

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

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

Учитывайте интересы бизнеса

Есть поставленные цели и задачи: их нельзя игнорировать. Учитывайте интересы бизнеса и вносите изменения, когда:

Умение правильно определять решения – тоже навык. Поэтому вместе с утверждением, приведенным в начале, спросите себя:

«Открою ли я новую возможность, которая была нереализуема до этого, и принесет ли это пользу кому-то, кроме меня?»

Если нет уверенного «Да», отложите изменения. Улучшение одного или нескольких показателей стоит немалых усилий.

Проблема абстрагирования

Абстрагирование – это важный инструмент ООП наряду с полиморфизмом, наследованием и инкапсуляцией. Абстракция позволяет работать с объектами, не вдаваясь в подробности их реализации.

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

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

Правильный способ – упрощение существующего кода или рефакторинг.

Общайтесь

Да, бывает откровенно плохой код.

Но нужно сперва разобраться.

Общение – важный навык. Без него тяжко разобраться в сложной системе. Поэтому, прежде чем проводить рефакторинг и тесты, спросите других разработчиков:

Если разработчики недоступны, ищите ответы в коде.

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

А еще помните, что разработчики часто копируют код из интернета, и реализовывают идеи, которые изучили недавно (все этим грешат, верно? 🙂 ). Для подозрительных отрывков кода используйте поисковики.

Следуйте сценарию использования для анализа уровней приложения с помощью debugger’а. Возьмите на заметку непонятные фрагменты и набросайте диаграмму архитектуры.

Источник

Один из простых способов улучшить свои навыки программирования — читать чужой код

Примечание: первоначально эта статья была написана для сайта Fuel Your Coding back в мае 2010 года. К сожалению, этот сайт сейчас не работает, поэтому я публикую статью здесь, чтобы сохранить её для потомков. Я собирался обновить её, учитывая последние веяния, но решил оставить так, как она была написана. Те части, что подустарели, могут показаться немного смешными, но да ладно. Получайте удовольствие…

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

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

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

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

Что читать

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

Читайте программы, имеющие к вам отношение

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

• Плагин WordPress, который вам действительно нравится;
• Ruby gem, который вы считаете полезным;
• Плагин jQuery, к которому вы продолжаете возвращаться.

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

Читайте программы, впечатлившие вас

Помню, что, когда я первый раз просматривал сервис создания презентаций 280 Slides, я подумал: «Да! Круто!». Я быстро выяснил, что программа, управляющая этим сайтом, является проектом Cappuccino с открытым кодом. Это знание вошло глубоко в моё сознание, и когда я как-то наткнулся на ещё одно впечатляющее приложение, работавшее на Cappuccino, я уже знал, что на этом проекте я смогу многому научиться. Что произвело сильное впечатление на вас в последнее время? Эта программа имеет открытый исходный код? Если так, то она — отличный выбор для чтения: код, скорее всего, впечатлит вас так же, как и само приложение.

Читайте программы, написанные теми, кого вы уважаете

Программисты, достойные уважения

Если вы уже занимаетесь программированием с открытым исходным кодом какое-то время, то, вероятно, у вас уже есть на примете программисты, заслужившие ваше уважение. Я мог бы с ходу назвать несколько разработчиков, программы которых вызывают у меня просто «белую зависть».

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

Читайте программы, которые вы сможете, действительно, достаточно глубоко понять

Если вы склонны рисковать, то можете рассмотреть погружение в большой проект, как, например, Ruby на Rails, Drupal или jQuery. Но я предложил бы вам не использовать пока такие проекты, если вы, конечно, не являетесь опытным читателем программ.

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

Как читать

Теперь, когда код для чтения выбран, как наилучшим способом читать его? Я прочитал на сегодня множество программ и могу предложить несколько способов максимизации вашего КПД.

Изучите общую картину

Структура каталога twitter gem

Я предполагаю, что вы, по крайней мере, знаете на макроуровне, что делает код, который вы читаете. Если нет, то предлагаю прочитать веб-сайт проекта, учебные пособия, документацию и всё остальное, что вы можете достать помимо кода.

После того как надлежащая ясность внесена, вашим первым шагом должно быть рассмотрение структуры проекта. Объём этой работы зависит от размера выбранной базы исходного кода, но даже если она занимает больше одного файла, это потребует лишь ненамного больше времени.

Прежде всего, зафиксируйте для себя структуру файлов. Этот шаг легче выполнить с помощью редактора, который имеет вид иерархии папок, как, например, TextMate. Здесь, как пример, показан прекрасный вид Twitter Ruby gem.

Цель этого шага состоит просто в ознакомлении с источником. Разберитесь, какие файлы включают в себя / вызывают / загружают другие файлы, где находится основная часть кода, какие пространства имён используются (если таковые имеются) и прочее такого рода. Получив общее представление, можно погружаться в детали.

Документируйте ваши результаты

Чтение кода не должно быть каким-то пассивным действием. Рекомендую добавлять комментарии по мере продвижения, документировать ваши предположения и ваши выводы, когда вы начнёте понимать ход выполнения программы. Когда вы начнёте впервые, ваши комментарии будут выглядеть, вероятно, так:

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

Используй тесты, Люк

(Прим. переводчика: автор вспомнил «Используй силу, Люк» из «Звёздных войн»)

Будем надеяться, что проект, который вы выбрали, имеет набор тестов. Если нет, то можете пропустить этот раздел вообще (или найти проект, имеющий такой набор).

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

Измените код, скомпилируйте

Кто сказал, что чтение кода должно быть пассивным? Вы начнёте, действительно, понимать код, только после того, как сломаете всё и снова соберёте вместе. Вспомните пройденные тесты? Сделайте так, чтобы они завершились неудачно, добавьте кое-что или попытайтесь изменить реализацию так, чтобы они прошли нормально. Попробуйте добавить какую-нибудь небольшую «фичу», которая вам кажется «крутой», или настройте регистрацию по всему проекту так, чтобы можно было распечатать вывод на различных этапах выполнения программы. Это по-прежнему чтение? Абсолютно, но такой подход является больше собственным приключением, чем чтением детективного романа. И это — именно то, что надо!

Смыть и повторить

(Прим. переводчика: из анекдота про айтишника, моющегося шампунем строго по инструкции — бесконечно)

Закончив с чтением одной кодовой базы, возьмите другую и начните процесс снова. Чем больше кодов вы читаете, тем лучше идёт это чтение и тем больше вы получаете из него за меньшее время. Я думаю, вы обнаружите, что ваш КПД растёт довольно быстро и что это действительно очень приятный способ обучения.

Где начать

Единственным, самым важным источником для чтения кода является для меня GitHub. Этот сайт позволяет так легко найти новые проекты и действительно великих программистов, что вы действуете себе во вред, если не используете его. Я предлагаю начать на GitHub и читать код прямо на сайте, пока не найдёте проект, из которого по вашему мнению вы сможете извлечь какие-то уроки. Затем склонируйте его и читайте!

А вы используете чтение кода как обучающий инструмент? Какие проекты вы порекомендовали бы коллегам? Прочитали какую-нибудь хорошую программу в последнее время?

Источник

Умение разбираться в коде Чужих или как правильно делать рефакторинг

Вступление: Для кого мы пишем код?

“Нет ничего более постоянного, чем временное”.

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

Как вы считаете, что объединяет все программы в мире, что у них есть общего? Если отбросить такие очевидные вещи, что они написаны людьми на каком-либо языке программирования и состоят из символов, используемых в этом языке, то останется еще одно важное свойство. Что, кроме языка, отличает текст программы от текста книги? Да, книга нужна для того, чтобы ее читать, а не выполнять, но есть еще одно важное отличие. Любая программа, чтобы продолжать существование, вынуждена изменяться! И касается это абсолютно всего, начиная с модных мобильных приложений и вплоть до корневых компонентов операционных систем. Можно сказать, что код, создаваемый программистом, как бы адресован другим программистам (или самому себе в будущем). Вы думаете я что-то помню о коде проектов над которыми работал пять лет назад? Да я ничего не помню даже о том, что писал полгода назад!

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

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

Часть 1: Именование

“Мир был таким первозданным, что многие вещи не имели названия и на них просто тыкали пальцем”.

Однажды мой коллега-программист рассказал историю, которая весьма меня позабавила. Речь шла о том, что в некоторых компаниях с очень высоким уровнем безопасности от разработчиков скрывается смысл бизнес-логики, которую они реализуют. Разработчики не должны понимать, что делает их программа. Точнее, они должны этого НЕ понимать. Но как можно написать программу, не понимая, что она делает? Для того, чтобы это осуществить, нанимают специальных аналитиков, уровень доступа безопасности у которых выше, чем у штатных программистов. Эти аналитики все-таки могут понимать, о чем будет программа, но сами они не программируют. У них есть специальные таблички, в которых хранятся соответствия реальных имен с кодовыми. Они просматривают их и дают задания разработчикам. К примеру: “Напиши функцию func_352, которая должна принимать число DEP20, умножать его на коэффициент CF1850 и записывать результат в базу, в ячейку FIELD255”. А на самом деле функция func_352 принимает сумму вклада, умножает на ежегодный процент и записывает в баланс пользователя, но разработчик, создавая функцию, об этом не знает.

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

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

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

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

Часть 2: Принцип Разделения Ответственности

Сложное лучше, чем запутанное”.

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

Многие живут в подобном графике — ничего плохого тут нет. Но если бизнес расширяется, и у вас уже не один, а десять магазинов, то не будете же вы нанимать десять подобных сотрудников? Куда логичнее нанять одного бухгалтера, одного водителя, а выкладку товара доверить администратору или продавцу.

Что-то подобное происходит и в разработке программы. До тех пор, пока программа небольшая, подобный сценарный стиль кода показывает себя неплохо, ведь на его планирование тратится минимум времени. Но как только программа разрастается, а любая программа растет, то сценарии ее становятся все сложнее и все запутаннее. Возникают вопросы: “А как бы назвать ту функцию из 200 строчек, чтобы название передавало суть? Может назовем ее “функция СДЕЛАТЬ ВСЕ”?

Будет логично разбить эту функцию на более мелкие функции, каждая из которых будет решать конкретную задачу. Да, подобные советы звучат слишком очевидно, но, возможно вы мне не поверите, многие профессионалы-разработчики до сих пор совершают подобные ошибки. В чем причина? Лень перерабатывать свой код? Или здесь как с английским: мы годами учим его правила, но когда должны что-то сказать, все знания забываются? Неважно, пусть это остается на совести нерадивых программистов, а мы пойдем дальше.

Есть такое замечательное правило:

Если для функции сложно подобрать имя, то ее нужно переписать (разбить на подфункции)

И еще один хороший принцип:

Одна функция — одна задача

Часть 3: Уровни Абстракции

“Чем больше употребляет художник эти абстрагированные или абстрактные формы, тем более он будет дома в их стране и тем глубже будет он вступать в эту область”.

Любой IT продукт, будь то веб-сайт, мобильное приложение или наручные электронные часы, является наглядным примером многоуровневых абстракций. К примеру, кнопки, которые мы видим на веб-сайте, через интернет запускают функции в коде. Но это лишь начало. Затем код, написанный разработчиком сайта, будет использовать библиотеки языка программирования, на котором написан сайт, допустим, Python. Python в свою очередь будет вызывать библиотеки более низкоуровнего языка программирования, при помощи которого он работает. В данном случае, это язык C++. Дальше библиотеки C++ будут обращаться к языку Assembler, на котором написаны компоненты операционной системы, а они будут совершать системные вызовы, через которые запрос дойдет до процессора и где-то там преобразуется в нолики и единички, а дальше в электрические сигналы, которые и сделают нужное нам вычисление. После чего результат вычисления по той же цепочке вернется обратно.

И это очень упрощенная схема того что происходит, когда мы спрашиваем у Гугла, сколько будет два плюс два. В действительности этих ступеней намного больше. Их созданием занимались самые разные специалисты: физики, инженеры-микроэлектронщики, программисты операционных систем, создатели и разработчики языков программирования, программисты веб-сайтов. Каждый из них старался максимально упростить жизнь другим специалистам, которые будут пользоваться результатом их трудов. Сегодня мы можем очень быстро разработать веб-сайт только потому, что 99.9% работы уже сделано до нас.

Те же самые законы действуют, когда мы работаем с кодом внутри проекта. Нам необходимо разделять код по уровням абстракции, чтобы разработка не стала слишком сложной. Каждый компонент системы должен “думать” на том уровне, на котором он находится. Функция, записывающая e-mail пользователя в базу данных, не должна знать, откуда пришел этот e-mail: из формы на веб-сайте, из мобильного приложения или из интеграции с социальной сетью. За это отвечают более высокие уровни. Этот принцип работает и в другую сторону: функция для записи e-mail в базу не должна знать, в какую базу она запишет данные. За это отвечают более низкие уровни, адрес и вид базы должен быть обозначен в них. Такой подход с четким разделением уровней абстракции в коде дает огромное преимущество в разработке, позволяет сделать ее проще и быстрее.

Не мешайте конкретику с абстракциями

Часть 4: DRY (Don’t repeat yourself / Не повторяйся)

“Хотя бы свитер ему купи. Смотреть стыдно. Ведь он уже не маленький. Ему стыдно ходить раздетым. Хоть свитер ему купи. Смотреть стыдно. Ведь он уже не маленький. Ему совестно ходить раздетым”.

— Из к/ф “Чеховские Мотивы”, реж. Кира Муратова

Дублирующее значение

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

Любое значение должно присутствовать в коде в одном экземпляре

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

Дублирующие блоки кода

C данной проблемой нередко сталкиваются даже профессиональные разработчики. Представьте, что перед вами стоит задача создать процедуру, похожую на какую-либо уже имеющуюся. Действительно, легче и быстрее скопировать блок кода, чем выносить его в отдельную функцию и вызывать ее в нужном месте. Но сколько такой подход может создать проблем! Изменение этого блока необходимо применять сразу в двух, а часто в трех и более местах, куда был скопирован код. А если вынести этот код в отдельную функцию, то, кроме очевидной выгоды от отсутствия дублирования, мы приобретаем еще несколько менее очевидных, но не менее важных преимуществ.

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

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

Не копируйте код! Выносите его в отдельную функцию

Дублирующее поведение

Данный вид дублирования сложнее всего уловить в коде. Чтобы его успешно избегать, требуется опыт. В паттерне проектирования “Шаблонный метод” представлен замечательный способ, которым можно бороться с дублирующим поведением, почитайте про него. В этой статье я не буду ставить перед собой задачу пересказать реализацию этого шаблона проектирования, а просто расскажу о проблеме дублирующего поведения, и как ее можно решить данным способом.

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

Здесь две процедуры не только имеют общую стратегию поведения, но также имеют один общий этап. Реализовав поведение этих процедур в абстрактном базовом классе, мы вполне можем переместить в него код их общих этапов, наподобие этапа “Оповещение” в табличке, что будет удобно для совместного использования этого кода. А выделение основных схожих этапов в базовом классе упростит создание новых процедур.

Если вы видите, что создаваемые вами процедуры имеют схожее поведение, то попробуйте определить его в родительском (базовом) классе данных процедур

Автор статьи может стать твоим ментором и научить тебя программировать. Нанять

Заключение: Рефакторинг

— Людвиг Мис ван дер Роэ и другие

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

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

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

Создавая код, стремитесь к простоте и выразительности

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

Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!

Источник