умение разбираться в чужом коде
Как научиться читать чужой код
Предположим, от такого занятия Ваши веки постепенно тяжелеют, и… Приходится пробудиться от необходимости понять чужой код и привести его в порядок. На мой взгляд, визуально сканировать иероглифы не так сложно как может показаться сначала. Как бы то ни было, необходимо уметь читать чужой код и редактировать, и один процесс не существует без второго.
Понимание этого приходит во время изнурительных тренировок. Особенно хорошо мы запоминаем, когда много раз сталкиваемся со своими ошибками из-за отсутствия навыков правильного чтения чужого кода.
Говоря о вероятности наличия ошибок, заметим, что в старых, тысячу раз проработанных файлах их меньше. Обычно массу ошибок мы встречаем в файлах, который никогда не меняли.
Перед реконструкцией кода иногда проще привести его в удобный для Вас порядок и потом вносить небольшие изменения, нежели сначала написать стили или события, а потом изменять верстку, например.
Лучше не оставлять черновых вариантов в рабочих файлах, поскольку Вы обязательно про что-нибудь забудете.
Когда над проектом работает команда, становится необходимостью сначала позаботиться о понимании концепции будущего сервиса. Вы обязательно вспомните этот совет, когда заметите, что продуктивно работали не возвращаясь к вопросам о том как это должно быть. Каждый специалист знает свою работу, и не стоит заблуждаться в том, что кто-то имеет такое же представление о том как будет реализована задача и что оно будет совпадать с Вашим. Поэтому не бойтесь советоваться с коллегами по цеху, чтобы последствия не вышли из области Вашего контроля и не стали неожиданностью.
Если Вы совершаете повторный поиск чего-то, на что вновь потребовалось приличное количество времени – необходимо обратить на это внимание.
Проведите анализ – с чем чаще всего пришлось повторно столкнуться; какого рода элементы вы ищите долго и почему. Возможно, это происходит из-за того, что Вы бы написали определенный фрагмент кода иначе, или не до конца ясна логика. В любом случае, надо действовать исходя из осознания того, что работа с кодом — уже Ваша задача, а не того, кто первым его написал.
Работая с чужими файлами, мы начинаем понимать, что хотел человек, каким он видел будущий сервис. Ход закодированных мыслей становится для нас все более логичным, а иногда и самым верным для реализации конкретной задачи.
Решения многих задач ждут Вас в сетях интернета, и поиск их занимает не так много времени, как кажется может показаться на первых порах.
Приятно воспользоваться благами обычных блокнотов. Например, CTRL + G (поиск по номеру строки) и прочие удобности, что значительно экономит время.
Работая с кодом желательно оставлять комментарии. Со временем они приобретут лаконичную форму и будут размещены в нужном месте. Это облегчает работу не только Вам, но и другим коллегам.
Приблизительно в середине работы над изменением кода для небольшой разгрузки можно просмотреть его на содержание синтаксических ошибок.
Рекомендуется так же редактировать файлы по маленьким частям, а начинать с самого сложного. Если Вы надолго застряли на каком-то моменте — переключитесь на что-нибудь другое. Вернитесь к трудности завтра, с утра, чтобы не тратить много времени на восстановление в памяти последних мыслей.
Не сомневаюсь, что частенько у Вас бывает поток мыслей о том, что необходимо исправить в разных участках кода. Для этого лучше все записывать. В конце рабочего дня это будет хорошим подспорьем. Так проще рассчитать время, необходимое на выполнение поставленной задачи, а так же, пригодится для отчетности.
Когда уходите на перерыв или домой, просмотрите что необходимо еще сделать. Когда перед Вами не будет кода и в памяти будет «висеть» задача, Вы заметите появление свежих оригинальных мыслей, даже если не будете намеренно думать о способе решения. Особенно такой прием подходит для сложных задач. Не говоря о пустяковых, конечно.
Не судите чужой код строго
Так сложилось что большую часть своей сознательной жизни я программирую на PHP. Наш мозг, воспринимая информацию из любого источника, делает это без отрыва от авторитетности этого источника. Грубо говоря, если вы любите PHP — вы автоматически добавили очков авторитетности автору этой статьи, а если не любите — автоматически отняли. Этот процесс происходит на бессознательном уровне и является по сути призмой восприятия, которая с одной стороны защищает нас от падения в бесконечный анализ информации любой степени авторитетности, но с другой стороны ограничивает нас в поиске новой более актуальной информации. Самое поганое здесь то, что авторитетность источника редко когда проверяется на сознательном уровне (потому что на это нужны время и ресурсы в виде драгоценных калорий), я могу быть с той же долей вероятности разработчиком плюсов, домохозяйкой-кухаркой, водопроводчиком без принцессы или генетически модифицированным котом. Не судите мою статью строго, у меня лапки.
То же самое относится к чтению чужого кода: если его автор сидит по левую руку от вашего трона, работает в вашей фирме 10+ лет и зарабатывает на один ноль больше вас, это совершенно не то же самое, что автор, которого уволили за что-то плохое, а вас наняли на его место. Но по сути то и там и там код — это всего лишь набор байтов, которые было бы полезно оценивать без привязки к авторитетности источника.
Когда мы читаем чужой код, нас могут посещать самые разнообразные эмоции: восхищение, смех, раздражение, разочарование, полное неприятие. Полезно знать о том что проявление любых эмоций в любом контексте — это автоматический ответ низшего (первого) уровня нервной системы, сформированный эволюционным путем, необходимый в первобытной среде. Основная задача такого ответа, в случае «негативной» эмоции — запустить механизм действий «бей или беги» с одной единственной целью — выжить. В нашей текущей офисной среде при анализе чужого кода подобный ответ становится скорее бесполезным и даже вредным, поскольку вы тратите на него драгоценное время и ресурсы, плюс загрязняете свой мозг нейромедиаторами, понижающими вашу сообразительность в угоду скорости реакции. Хорошая новость в том что этот ответ можно перепрограммировать. Можно подавлять негативные эмоциональные реакции, а можно их инвентировать, например, смеяться там где вы раньше злились. Смех, в отличие от злости, выбрасывает в мозг хорошие вкусные полезные нейромедиаторы, доставляющие удовольствие, закрепляющие опыт и мотивирующие на дальнейшую работу.
Для того чтобы перепрограммировать эмоцию, нужно мысленно выйти в мета-позицию, чтобы вместо осуждения чужого кода оценить собственную обстановку, оценить себя. Почему этот кусок чужого кода вызывает во мне отвращение? Действительно ли дело в том что его писал дилетант, а мне такому хорошему и опытному теперь приходится страдать? Если я такой хороший и опытный, то почему у меня возникают проблемы с тем чтобы понять чужой код и переписать его так как я считаю нужным? Возможно мне просто не хватает оперативной памяти для того чтобы осознать эту лапшу? Возможно автор этого куска знает что-то чего не знаю я?
Современные средства разработки позволяют практически на лету преобразовывать чужой код в более понятные и приятные структуры. Функция или переменная плохо названа — ctrl+shift+R и в пару секунд она называется по хорошему. Табуляции вместо пробелов, неудобно, непривычно раскиданы отступы и открывающиеся бракеты в египетском стиле — ctrl+shift+F и форматирование восстановлено! Комментарий избыточен или устарел — ctrl+D и его нет. Если изменить призму восприятия, чтение чужого кода может превратиться в увлекательную интерактивную детективную игру.
Код это всего лишь инструмент. Как бы плохо и ужасно он не был написан, в конкретное время и в конкретном месте он успешно решал конкретную проблему, а значит он уже «оправдан». Что-то изменилось в бизнес-требованиях, что то было не учтено — код поломался или стал не актуален, и это нормально. Код имеет свойство эволюционировать самыми разными путями: и постепенно, обрастая пластами и революционно, переписываясь с нуля. Конечно хорошо, когда программист предвидит будущее и на начальных этапах закладывает в код возможности для дальнейшего его развития. Но эта секира остра с двух сторон, вы можете ошибиться с предсказыванием будущего, будущее может не наступить вовсе, а время и ресурсы будут безвозвратно утеряны. Тут важно понимать код какой степени качества от вас требуется. Если это огромная распределенная система, модули к которой программируют ваши коллеги из самых разных точек земного шара в фирмах слабо связанных с вашей, тогда да, имеет смысл использовать модные паттерны, оборачивать модули в сервис-контейнеры даже там где вы не можете себе представить зачем это нужно. Но если это маленькая локальная CRM для одной фирмы, модули которой зависят друг от друга настолько жестко, что отключение любого модуля по сути ведет к остановке работы всей системы… в этом случае вполне оправданно вызывать чужие методы напрямую, это уменьшит количество классов, облегчит вашу оперативную память и сократит время на отладку проблем. Но вот возникает ситуация когда маленькая локальная CRM превращается в нечто расширяемое, что ваша фирма хочет выложить в открытый доступ и продавать. Бизнес-требования изменились. Стоит ли винить программиста в том что он не предвидел этого?
Стандартизация
Код это всего лишь инструмент, но его создание — это чистое творчество. Любую задачу можно решить бесконечным числом самых разнообразных способов. Некоторые из них более производительны, чем другие — пример объективной оценки. Некоторые из них более читабельны, чем другие — пример субъективной оценки. Даже если вы убедите весь офис в том что какой-то кусок кода не читабелен, все еще останется как минимум один автор, который с вами не согласится. Стандартизация кода направлена на то чтобы преобразовать чистое творчество в как можно более рутинный набор действий для того чтобы другим программистам было проще разбираться в вашем коде. То есть, по сути, чтобы вас можно было заменить другим специалистом, более покладистым и дешевым. А через пару десятков лет так и вовсе искусственным интеллектом. Стоит помнить, что если какой-то стандарт противоречит здравому смыслу, возможно его имеет смысл нарушать в некоторых местах, а то и вовсе отказаться от него или заменить на другой, более подходящий.
Матёрые стандарты продают себя с позиции «при выборе стандарта обратите внимание на популярность сообщества». Интересно как они продавали себя когда только-только вышли в свет. Основная мысль в том, что популярность того или иного стандарта это не тот фактор, который вы бы хотели учитывать в первую очередь при выборе. Популярность и сообщества очень инертны и могут на протяжении многих десятилетий отвергать новые более хорошие стандарты. Особенно если они революционны.
Аналогичные примеры встречаются сплошь и рядом и в культуре программирования. Стандарт PSR ратует за 4 пробела вместо табуляции, игнорируя очевидный факт: среда разработки большинства PHP-программистов изменилась с консольных редакторов на полноценные IDE, в которых оперировать табуляциями удобнее во многих смыслах: и удалять проще, нажимая Backspace один раз, и настроить можно индивидуальную длину табуляции по вкусу.
Применяя тот или иной стандарт задавайтесь вопросом: кому вы делаете удобнее? Кому неудобнее? Кому станет лучше от правила «именуем имена методов лоуерКамелКейсом»? Очевидно лишь тем, кто привык их так именовать. Всем остальным станет неудобно, им придется адаптироваться, а это потери времени и ресурсов абсолютно на пустом месте, учитывая то что
а) теперь у нас есть волшебные IDE, подсвечивающие разными цветами разные элементы кода,
б) программисты имеют свойство перескакивать с проекта на проект, стандарты кодирования в которых могут различаться.
Лично я при разработке своих проектов использую:
Умение разбираться в чужом коде
Триггер, вызывающий рвотные порывы у подавляющего большинства программистов (пример субъективной оценки). Вам никогда не казалось странным, что зачастую нам проще переписать весь код с нуля, чем разбираться в чужом? В любой другой отрасли мы действуем иначе: сперва учимся читать, потом — писать; сперва пользоваться (электроприборами, зданиями), затем — их проектировать. Мне кажется все дело в нашем образовании (конкретно в области программирования). Нас учат достигать цели самым прямым и быстрым способом, используя некоторые свеже-приобретенные знания. В результате мы комбинируем их (знания) ровно до тех пор пока «оно» не заработает, немного тестируем и отправляем учителю на модерацию. На мой взгляд было бы неплохо добавить в этот процесс дополнительную ступень, на которой мы сравниваем наш код с мастер-кодом, который хоть и не является идеальным и единственно правильным, но дает альтернативный путь решения, зачастую более оптимальный и читабельный.
Что касается триггера, чтобы его отключить, достаточно просто мысленно поставить себя на место заказчика, который всю свою жизнь наблюдает за уходящими-приходящими программистами, утверждающими что работа их предшественников это фекалии и нужно все переписать чтобы стало хорошо. Заказчик не обладает компетенцией чтобы выяснить говорите ли вы правду или просто ленитесь разбираться в чужом коде. Чтобы завоевать его доверие в подобном вопросе, следует покопаться в чужом коде и найти парочку гигантских дыр в безопасности и продемонстрировать их заказчику. Но даже в этой ситуации с точки зрения бизнеса, возможно, будет выгоднее «закостылить». Особенно если это аутсорс с конкретными сроками и деньгами. Нужно ли винить программиста в этом?
Ужасы чужого кода: как найти смысл и не умереть
Даже самым крутым программистам трудно читать чужой код. Узнайте, почему это так страшно и как с этим справиться.
В жизни каждого разработчика наступает момент, когда нужно взяться за код, написанный другим человеком. Это может быть связано с поддержкой старого проекта, оптимизацией legacy-кода, переделыванием приложения, которое не доделал другой программист.
Хорошо, если этот код написан по архитектурному паттерну, у него есть документация, комментарии или хотя бы понятные названия переменных. Однако чаще всего приходится работать с говнокодом (это термин, если что).
В этой статье я опишу личный опыт чтения ужасного кода. Поэтому приготовьтесь сначала лицезреть моё страдание и только потом получить какие-то полезные советы.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Виновник торжества
Мне и раньше приходилось сталкиваться с плохим кодом (например, своим), но недавно попался настолько ужасный, что я решил написать об этом статью.
Для начала попробуйте понять, что делает этот цикл, зная только, что приложение работает с 3D-графикой:
Первое, что бросается в глаза, — нарушение традиций в выборе имени счётчика.
Чтобы разобраться, что тут происходит, нужно понять, что такое msh, object и gm. С последним всё предельно просто:
Теперь остаётся только понять, что такое oo. Это очень хороший вопрос, потому что oo — это глобальная переменная, объявление которой нужно ещё поискать.
Вот другой фрагмент:
Название метода не вносит никакой ясности. Не говоря уже о том, что разработчик игнорирует соглашение об идентификаторах. Он даже единого стиля не придерживается, потому что в этом же файле можно встретить метод, который называется getPointOfIntersection ().
Складывается ощущение, что разработчик не знает главного правила программирования:
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте».
Как с этим жить
Очевидно, что невозможно заставить всех писать чистый и понятный код. Поэтому единственный выход — научиться читать всё, что попадается под руки. Это умение можно разделить на два навыка: чтение и расшифровка (эти названия условные).
Расшифровка может пригодиться, когда нужно срочно понять, как работает код. Особенно если он настолько ужасный, что просто пытаться вникнуть в проект — глупо. Рассмотрим на примере:
Это достаточно небольшой метод, который, однако, записан таким образом, что невозможно понять, что он делает. В этом случае не стоит тратить силы, чтобы вникнуть, — лучше сразу привести его в человеческий вид.
Для начала можно расставить пробелы и переносы строк:
Сделать это можно с помощью специальных инструментов, но лучше попробовать вручную. Возможно, в процессе получится что-то понять. Попутно можно добавить комментарии:
Становится понятно, что метод проверяет коллизию двух двумерных объектов. Поэтому можно поменять названия переменных и самого метода:
Когда весь код приобретёт более-менее человеческий вид, можно будет провести рефакторинг:
Например, можно вместо координат принимать объекты:
Всё это должно помочь разобраться в коде здесь и сейчас. Если же нужно постоянно работать с чужими проектами, то есть смысл попрактиковаться в чтении. Есть несколько простых советов, которые помогут в этом нелёгком деле.
1. Пробуйте писать в разных стилях
Обычно я пишу вот так:
Даже если нужно выполнить одну инструкцию, я всё равно использую фигурные скобки. Мне кажется, так легче понять, что является частью ветвления, а что — нет.
Но иногда стоит посмотреть, как пишут другие, и попробовать так же. Например, вот так:
Если часто практиковаться, можно привыкнуть, и тогда читать такие конструкции будет проще.
2. Читайте чужой код
Попробуйте зайти в случайный репозиторий на GitHub и разобраться, как там всё устроено и как оно работает. Изучите несколько проектов, чтобы научиться понимать разные стили.
Подумайте, почему разработчик пишет так, а не иначе, как он составляет документацию и так далее. Так вы не только научитесь читать чужой код, но и, возможно, найдёте пару интересных приёмов, которые захотите использовать сами.
3. Давайте другим читать ваш код
Дайте другому разработчику посмотреть ваш проект. Сразу будьте готовы к тому, что ваш код тоже так себе. Обратная связь поможет понять, что вы делаете не так, а если повезёт, получите несколько рекомендаций, как улучшить свой код.
В процессе вы можете понаблюдать, что делают более опытные коллеги, чтобы вникнуть в ваш проект.
4. Попробуйте прочесть код, который писали давно
Скорее всего, сначала вы ничего не поймёте, а потом почувствуете сильный стыд. Это нормально и случается со всеми программистами.
Сейчас вы уже лучше, чем были когда-то давно, поэтому сможете увидеть, что делали не так. Возможно, вы заметите, что до сих пор используете те же самые приёмы, и исправите это.
5. Больше рефакторинга
Иногда код необходимо переделать, даже если он работает. Конечно, это касается в первую очередь проектов, которые нужно поддерживать. Если не прибегать к рефакторингу, то придётся постоянно держать в голове весь плохой код, чтобы не приходилось каждый раз вникать заново. Кроме того, вы вряд ли заметите баги и уязвимости, потому что весь код выглядит как одна большая уязвимость.
Заключение
Последний совет: не обманывайте себя. Вы, я и любые другие разработчики пишут ужасно. Просто потому, что так устроено программирование — приложения не могут быть безупречными и совсем понятными.
Однако это не значит, что можно окончательно забить на чистоту и читаемость кода. Просто нужно понимать, что мастерство в программировании, как и в любом другом деле, это не пункт назначения — это сам путь.
Нужно стремиться к тому, чтобы писать совершенный код, но помнить, что не нужно зацикливаться на этом. Именно так мы подходим к обучению на курсе «Профессия C#-разработчик». Студенты учатся писать чистый, поддерживаемый код с документацией, который не стыдно показать коллегам.
Профессия C#-разработчик
130 часов — и вы научитесь писать программы на языке, созданном Microsoft. Вы создадите 5 проектов для портфолио, даже если до этого никогда не программировали. После обучения — гарантированное трудоустройство.
Sourcetrail: инструмент, чтобы разобраться в чужом коде и не выстрелить себе в голову
I regret to report that I’ve just recently looked again at my programs for prime factors and tic-tac-toe, and they are entirely free of any sort of comments or documentation.
— Donald E. Knuth
Каждый программист не раз сталкивался с ситуацией, когда приходится читать чужой код не имея представления для чего нужна та или иная функция, класс и как оно вообще все взаимосвязано.
Такое случается даже со своими программами и скриптами, написанными на write-only ЯП.
Разработчики, имеющие дар работать с таким кодом высоко ценятся в коллективе.
Такое чудо-лабиринты из кода бывают, когда исходный код имеет:
Герменевтика исходного кода требует особых навыков и инструментов. Навыки такого рода приходят лишь с опытом, однако доскональное знание синтаксических особенностей языка и сопутствующей документации могут облегчить дело тем, кому не хватает практического опыта. Другим таким подспорьем являются специальные инструменты исследования исходного кода.
Sourcetrail на помощь
Приложение Sourcetrail представляет собой продвинутый интерактивный проводники и анализатор, который позволяет активно исследовать исходный код, индексируя и собирая данные о его структуре. Интерфейс приложения включает в себя три основные части.
Структуры и классы отображаются курсивом; пакеты, модули и пространства имен — розоватым цветом; функции и методы — желтым цветом, а переменные и области — голубым. В данный момент реализована поддержка следующих языков программирования:
Мы выбрали проект tictactoe_cpp и затем метод Run. С помощью графа наглядно можно увидеть, что Run вызывается единожды из функции main. Помимо вершин графа, также и ребра несут полезную смысловую нагрузку.
Кроме того существуют определения для переопределения (слева) и наследования метода (справа).
Sourcetrail всячески стремится реализовать интерактивное поведение. При выборе объектов графа в представлении кода автоматически подсвечиваются соответствующие символы. Обратное также верно, выбор символов в представлении кода приводит к автоматической перенастройке графа. Выбранный на графе элемент сразу же переходит в центр, также обновляется содержимое в панели кода. При наведении курсора на объекты графа соответствующие символы выделяются прямоугольной рамкой. И снова обратное верно для наведения курсора на символы в панели кода.
Можно задавать уровень детализации и глубины построения графа с помощью trail controls в левом верхнем углу.
Интересной, для подобного класса приложений, концепцией пользовательского интерфейса является навигация в стиле веб-браузера. На Рис. 2 видны кнопки Назад, Вперед и Дом. Надо сказать — действительно удобно. Кнопка Обновить не перерисовывает граф, как можно было бы предположить, а предлагает заново индексировать файлы исходного кода. Кнопка Закладки позволяет добавить символ в избранные.
Одним из инструментов trail controls является custom trail, в самом верху. Вызвав соответствующую форму, можно выбрать необходимые составные графа, детализацию, отправной и целевой узел и тип построения.
Установка Sourcetrail
Дистрибутив приложения Sourcetrail доступен для ОС Windows, macOS и Linux. Пользователи Windows как обычно запускают setup.exe, для macOS установка проходит штатными средствами операционной системы. Для Linux существует два варианта:
/.config/sourcetrail.
Текущая версия Sourcetrail требует установки среды выполнения Java 8 для индексации Java проектов. Бинарная архитектура Sourcetrail, должна соответствовать таковой для JRE. Для Sourcetrail 32-бит нужна 32-бит JRE, а для 64-бит версии приложения — соответственно 64-бит JRE.
Поддержка сторонних IDE и редакторов
Sourcetrail поддерживает интеграцию с целым рядом IDE и текстовых редакторов. Все плагины идут с открытым исходным кодом, разработка ведется на github.
Возможности CLI
С помощью командной строки можно индексировать, или настроить проект в Sourcetrail.
Резюме
Бытует мнение, что разработчики тратят большую часть времени на то, чтобы осмыслить существующий код, нежели на написание нового. Такие средства анализа исходного кода, как Sourcetrail могут существенно сместить баланс в пользу последнего, без потери качества. Хочется отметить фокус на продуманный и знакомый динамичный пользовательский интерфейс, который отлично выполняет роль ненавязчивого помощника и существенно экономит время на рутинных процедурах.