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


Оглавление (нажмите, чтобы открыть):

Как грамотно читать чужой код?

Гугл внятного ничего не ответил на мой вопрос. Больше года моя работа заключается в основном в чтении чужого кода и все острее ощущалается нехватка трюков для его эффективного чтения.

Кода более 200 метров, язык си, исходников около 2500. Я работаю над этим один.

Как грамотно вникать в работу сложой большой софт-системы с несколькими слоями интерфесов, дефайнов, call-back-ов и т.д., получить комплексное представление?
Конпектировать на листочке, рисовать в каком-нибудь visio блок-схемы и наколько подробные? Или есть какие-то специальные удобные программы для этого?

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

19.12.2012, 07:32

Как грамотно читать чужой код?
Гугл внятного ничего не ответил на мой вопрос. Больше года моя работа заключается в основном в.

Как научиться эффективно читать чужой код С++
Поделитесь пожалуйста опытом или просто мыслями о том, как всё таки начать разбираться в не своём.

Как грамотно оформить код
Есть код. он огромный. есть ли какие то методы оптимизации. или стандартные методы.

Как грамотно организовать код?
У меня есть программа, уже написанная, но я хочу всё переделать более грамотно. Как разбить.

Как грамотно написать код
Уважаемые форумчане, меня давно интересует один вопрос, надеюсь вы мне подскажите.. Сразу.

19.12.2012, 10:11 2

Во первых нужно разбирать предметную область. Описание предметной области можно делать в текстовом виде.
Я стараюсь использовать для проектирования(и реверсинженеринга) UML. Поэтому от C я ушёл, и перешёл на C++. Так как описывать предметную область проще объектами, то возникает прямая связь между предметной областью и рабочим кодом.

Очень помогает писать комментарии к чужому коду. Так же многие IDE поддерживают метки TODO в коментах. Упрощает навигацию по коду.

Также рекомендую писать сценарии вариантов использования(они напоминают псевдокод), изучать как составляются требования к ПО. Для формирования правильного представления о сборе требований возможно стоит по изучать Visual Paradigm.

19.12.2012, 10:17 [ТС] 3

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

Комменты пишу конечно. В целом код очень прилично написан и прокомментирован. Но все-таки далеко не все понятно из комментариев. Большая часть остается за реверсингом.

19.12.2012, 11:03 4

когда я программировал на C, черпал информацию с сайта www.uml2.ru
В крупных проектах(где используются многокомпонентные системы) обычно используется ООП. Но думаю в вашем случае использование этих приёмов тоже будет полезно.
Системные аналитики обычно для изучения сценариев вариантов использования советуют книгу Коберна, если знаете английский то читайте оригинал.

В вики есть статья Прецедент, но в видео лекциях Дениса Иванова(автора книги Моделирование на UML) говориться, что это неверное название вариантов использования.

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

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

В UML есть возможность моделирования структуры пакетов, когда исходники разделёны по пакетам ими легче управлять, каждый пакет должен отвечать за небольшую область. Я стараюсь не делать больше одного уровня вложенности, то есть у меня папка src и в ней папки protocol,database,и др. . в большем количестве уровней нет необходимости

Страница поста от канала Типичный Верстальщик

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Пожаловаться

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Как читать код: 8 принципов, которые стоит запомнить

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

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

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

Все, что вы увидите как читатель — это законченный продукт. И если не провести некоторых раскопок, единственный контекст, с которым вы будете работать — это тот самый код на вашем экране.

1. Учитесь копать

Когда вы впервые знакомитесь с серьезной кодовой базой, возможно, вы не будете чувствовать себя разработчиком. Скорее вы будете себя чувствовать археологом, частным сыщиком, или исследователем религиозных книг. Это вполне нормально, ведь в вашем распоряжении есть несколько инструментов для «раскопок». Если вам повезло, и ваши предшественники использовали контроль версий, это стоит отпраздновать! У вас есть доступ к богатству метаданных, и это очень сильно облегчит вам понимание контекста, в котором создавался код. Далее я исхожу из того, что вы используете Git, но в случае с SVN, все будет примерно так же.

git blame

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

git log

Используйте эту команду, чтобы увидеть историю коммитов по всему репозиторию. Эта команда выводит сообщения коммитов, и команда grep поможет вам найти в коммитах конкретный текст, например название функции someFunction: git log | grep someFunction -C 3 (последние флаги покажут вам найденные выражения с тремя строками окружающего контекста.)

Также git log может показать вам историю отдельного файла, для этого используйте флаг -p: git log -p index.js . Обращайте внимание на имена авторов коммитов, чтобы знать, кому в будущем адресовать вопросы.

2. Вернитесь в прошлое

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


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

3. Читайте спецификации

Спецификации — это новые комментарии. Читайте юнит-спецификации, чтобы выяснить предназначение функций и модулей, и возможные пограничные случаи (edge-cases), которые они обрабатывают. Читайте интеграционные спецификации, чтобы выяснить, как пользователи будут взаимодействовать с вашим приложением и какие процессы поддерживает ваше приложение.

4. Думайте о комментариях, как о подсказках

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

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

5. Найдите Main

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

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

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

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

6. Обращайте внимание на стиль.

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

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

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

7. Ожидайте встретить мусор

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

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

8. Не отчаивайтесь

Держите предыдущие пункты в голове, и не падайте духом, если чувствуете, что совершенно запутались. Изучение кода — это не линейный процесс, не ожидайте сразу понять все на 100%. Обращайте внимание на важные детали и знайте, как копать, чтобы найти ответы на вопросы, и вы довольно быстро обнаружите, что все становится понятно.

Мастер Йода рекомендует:  10 советов, как составлять JavaScript без jQuery Javascript

Автор: Уильям Шон, консультант и разработчик в Ann Arbor. Оригинал здесь.

Будь как кот, вылижи свой код: 8 хороших практик по повышению качества кода

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

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

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

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

4 октября 2020 – 1 марта 2020, Москва и онлайн, беcплатно

А теперь давайте рассмотрим принципы, которые помогут писать более качественный код.

Термины

Для начала дадим несколько определений:

  • состояние (state) — это данные, хранящиеся в памяти приложения. Каждая назначенная переменная является частью состояния приложения;
  • рефакторинг (refactor) — изменение кода программы без изменения ее поведения (по крайней мере, видимого пользователю). Цель рефакторинга — упростить код и сделать его проще для чтения и понимания.

1. Разделение проблем

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

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

Если знать, что на кухне будет несколько поваров, тогда стоит разделить рецепт на несколько субрецептов. Тогда каждый из поваров будет работать только над своей частью рецепта с минимальным взаимодействием. Один — готовит кипящую воду для макарон, второй — нарезает и готовит овощи, третий — измельчает сыр. Четвертый — делает соус. Благодаря четко определенным задачам каждый из них делает свою работу.

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

Более хороший вариант написания кода похож на пример со вторым поваром. Некоторые операции передаются другим частям программы, что частично упрощает код, но не приводит к его упорядочению. Это, конечно, улучшение, но этого недостаточно.

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

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

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


2. Глобальные переменные

Возьмем, например, переменную username . При создании формы авторизации в приложении вы вдруг решили, что имя пользователя будет использоваться в нескольких местах приложения, например, на странице авторизации и в настройках. Поэтому сделали эту переменную глобальной. В Python она обозначается как global , а в JavaScript это свойство объекта window . На первый взгляд, это хорошее решение. Теперь в любом месте, где вам нужно использовать переменную username , вы легко можете это сделать. Но почему не сделать глобальными все переменные?

Представим, что что-то пошло не так. Нашелся баг в коде, который связан с переменной username . Даже с использованием инструментов поиска в вашей IDE найти эту переменную будет сложно. При поиске переменной username вы получите сотни, а то и тысячи результатов. Некоторые результаты поиска будут глобальной переменной, которую вы установили в начале проекта, некоторые — другими переменными с именем username , некоторые будут просто словом username, которое использовалось в комментарии, имени класса, имени метода и т. д. Можно будет установить дополнительные фильтры для поиска, но все же отладка займет много времени.

Решение проблемы заключается в том, чтобы поместить username в контейнер (например, класса или объекта данных), который вводится или передается в качестве аргумента классам и методам, нуждающимся в нем. Контейнер также может хранить любые подобные данные, связанные с входом в систему (только не пароль пользователя). Также можно сделать этот контейнер неизменяемым, например, при установке имени пользователя оно уже не может быть изменено. Это упростит отладку, даже если имя пользователя используется десятки тысяч раз.

Такое использование кода облегчит вашу жизнь. Нужные данные всегда будут находиться только в одном месте. И если вам понадобится отследить, когда часть кода или данных была изменена, вы всегда сможете использовать getter или setter .

3. Не повторяйте себя

Давайте поговорим про отношения.

Быть в отношениях — это хорошо, ведь вы всегда находите поддержку в своем партнере. Часто бывает, что приходится рассказывать историю вашего знакомства. И редко такая история бывает такой простой, как: «Мы завязали разговор в продуктовом магазине и вышли замуж на следующий день». Таким образом, вам приходится рассказывать одну и ту же историю каждый раз, несколько раз в неделю, что довольно утомительно.

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

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

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

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

4. Сокрытие сложности

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

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

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

Когда вы создаете класс или метод, первое, что вам нужно создать, — это интерфейс, то есть часть кода, которую должен знать другой кусок кода (вызывающий) для использования этого класса или метода. Для метода это также называется сигнатурой. Каждый раз во время просмотра функции или класса в API документации (например, на MDN или jquery.com) вы видите интерфейс — все, что вам нужно знать для его использования без содержащегося в нем кода.

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

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

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

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

В JavaScript переменные, объявленные с помощью var , let или const , автоматически становятся приватными в функции, в которой они объявлены, до тех пор, пока вы не возвращаете или не назначаете их объекту. Во многих других языках используется ключевое слово private . Оно должно стать вашим лучшим другом. Переменные стоит делать публичными только в случаях крайней необходимости.

5. Близость

Нужно объявлять переменные как можно ближе к месту их использования.

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

getA() и другие подобные функции не определены в этом сегменте кода, но представьте, что они возвращают полезные значения.

Смотря на этот небольшой метод, можно подумать, что код хорошо организован и легко читается. Но это не так. d , по какой-то причине, объявляется в строке 4, хотя она не используется до строки 9, а это значит, что нужно прочитать весь метод, чтобы убедиться, что переменная больше нигде не используется.

Мастер Йода рекомендует:  Какой язык программирования выбрать первым для изучения новичку

Хорошо организованный метод будет выглядеть так:

Теперь понятно, что переменная будет использоваться сразу после ее объявления.

Конечно, в большинстве случаев ситуация не настолько простая. Что, если b нужно передать два метода: doSomething() и doOtherStuff() ? В этом случае вашей задачей будет взвесить параметры и убедиться, что метод все еще прост для чтения (в первую очередь, оставляя его небольшим). В любом случае нужно убедиться в том, что b не объявляется раньше момента ее использования и используется в ближайшем сегменте кода.

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

6. Многоуровневое вложение кода (Deep nesting)

JavaScript известен своей сложной ситуацией, известной как «callback hell»:

Видите )>; ,повторяющийся начиная с середины кода? Это и есть пресловутый ад обратного вызова (callback hell). Этого можно избежать, но это история для еще одной статьи.

Но давайте рассмотрим нечто, что называется if hell.

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

Теперь посмотрим на это:

Так намного лучше. Теперь это нормальный путь кода, и только в некоторых ситуациях код отклоняется в блок if . Процесс отладки упрощается в разы. И если мы хотим добавить дополнительный код для обработки условий ошибки, можно легко написать пару строк внутри этих блоков if (а представьте, что блоки if в исходном коде также имели бы блоки else , ужас).

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

7. Чистые функции

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


Это чистая функция:

А это не чистая функция:

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

Если же надо сделать отладку второй функции, то придется перерыть всю программу, чтобы убедиться, что найдены все места, где доступны scope.sum и scope.exp . И если нужно переместить эту функцию в другой класс, придется проверить, имеет ли она доступ ко всем тем же областям.

Не все методы могут стать чистыми, но если в вашем приложении их совсем нет, его полезность будет ограниченной. Чистые функции нужно создавать как можно чаще. Это сделает ваше приложение легким в обслуживании и масштабировании.

8. Модульное тестирование

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

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

Заключение

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

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

Григорий Петров: Как и зачем читать чужой код

Тысячи лет практика “посмотреть работу молодого специалиста, ужаснуться, подсказать что-нибудь полезное” помогает нам передавать опыт и знания. Нужно ли говорить о том, что более опытным разработчикам необходимо читать код своих начинающих коллег и помогать им советами? Это же очевидно и все об этом знают? Или нет?

В одной из первых статей я уже писал про code review, настало время рассказать подробности. Тысячи лет практика “посмотреть работу молодого специалиста, ужаснуться, подсказать что-нибудь полезное” помогает нам передавать опыт и знания. Нужно ли говорить о том, что более опытным разработчикам необходимо читать код своих начинающих коллег и помогать им советами? Это же очевидно и все об этом знают? Или нет?

Давайте вспомним проблемы разработки: Кошелек Миллера, отсутствие фундаментального образования, отсутствие выработанных методик. Написанный разработчиком код – это отражение его ментальных моделей, пропущенное через его личный опыт разработки. А опыт у него уникальный, потому что в университетах не учат разрабатывать программы. Там учат математике, алгоритмам, структурам данных. Алгоритм сортировки у всех будет одинаковый, как в университете научили. Только вот в коде никто не пишет сортировку. Пишут немного другое, а этому не учат.

Легко ли более опытному разработчику читать код, созданный не его ментальными моделями по другому опыту? Четырем из пяти моих знакомых разработчиков это невероятно трудно. Это очень трудно мне. По сути, чтобы действительно понять чужой нетривиальный код, нужно понять, как работает разум другого человека, плюс провести реверсию Кошелька Миллера – разбить картину на последовательность мазков и эскизов, иначе оно просто не влезет в фокус внимания. Странный вывод: если действительно внимательно читать чужой код, то вам для этого потребуются либо уникальные люди (я таких встречал, одного человека), либо опытный разработчик будет тратить на чтение чужого кода примерно столько же времени, сколько автор потратил на его написание.

И это только первые грабли. Есть еще вторые. Так как код является отражением ментальной модели разработчика, то чужой код разработчику в большинстве случаев не понравится! При чтении чужого кода разум будет пытаться воспринять его как свой, пропустить через собственные ментальные модели. Но код – это не книга. Естественный язык допускает множество трактовок каждого предложения, чтобы большинство читателей, пропустив текст через призму своего восприятия, увидели каждый свою картину. С языком программирования все не так: программист будет всегда видеть чужую картину, слепок работы чужого разума. И это ему не понравится. Отсюда нелюбовь разработчиков разбираться в чужом коде и инстинктивное желание “все переписать с нуля”.

Что читать

Получается, читать чужой код – слишком сложно? Не совсем. Внимательно читать чужой код сложно. Но для того, чтобы чтение кода принесло пользу, не обязательно читать его внимательно! Ведь важные вещи: архитектура, уровень сложности, соблюдение стандарта кодирования – можно проверить и при быстром просмотре чужого кода. Именно в этом кроется контринтуитивный секрет code review: не нужно внимательно читать все. Опытные разработчики, делая code review, быстро просматривают код в поисках подозрительных моментов, не пытаясь понять каждую строчку и разобраться в хитросплетениях борьбы автора со сложностью. Если что-то привлекло внимание – то на это смотрят внимательнее. Если нет – специально не ищут. Действительно опасные проблемы с архитектурой и скопления сложности видны опытному разработчику сразу. Остальное покажу тесты. У вас ведь есть тесты?

Конечно, ситуации бывают разные. Для медицинского софта особо важные участки кода могут построчно ревьювить сразу несколько разработчиков – слишком высока цена ошибки. Но, в большинстве случаев, главная задача code review – избежать ситуации, когда опытный разработчик тратит все свое время на очень внимательный review кода двух-трех джуниоров, и в конце дня гордо говорит – ” посмотрите, сколько я у вас нашел багов!”. Нашел, молодец. Но сколько на это было потрачено времени и сил? Стоило ли оно того? Плюс не забываем о микроменеджменте – свой мозг в чужую голову не установить.

Что не читать

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

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

Автоматика спешит на помощь

Тим лид знает, что читать чужой код тяжело. Тим лид знает, что читать чужой код необходимо. И чтобы не расслаблялись, и чтобы вовремя отследить уползшую “не туда” архитектуру, и чтобы опыт передавался. Из всего, что я видел, хорошо зарекомендовал себя комбинированный подход. Код читается, но очень быстро, для поиска страшных, видных на первый взгляд проблем. Чтобы оценить его “читаемость” другим человеком. А все остальное: стандарт кодирования, баги, логика работы, эффективность и множество других параметров проверяет автоматика. У вас ведь не только тесты есть, но и автобилд?

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

Считывать мысли на расстоянии очень просто!

Может ли человек считывать чужие мысли на расстоянии? Да! Это может даже тот, у кого нет развитого дара ясновидения! Узнайте об этой технологии!

Врожденные сверхспособности есть у каждого!

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

Любая мысль тоже является волной.

Как обычному человеку научиться считывать чужие мысли на расстоянии? Особенно, если у него нет развитого дара ясновидения² или других сверхспособностей?

Техника считывания мысли на расстоянии

Предложенная техника очень проста; единственное, что необходимо – концентрация внимания. Принцип ее похож на скачивание файла в компьютер из «облака» (хранилища информации в сети интернет).

1. Практик мысленно задает вопрос, который его интересует. К примеру: «Что думает обо мне А. (имя нужного человека)?»

2. Затем практикующий выбирает место вокруг себя, на котором будет концентрироваться. Например, точка на стене. Единственное условие: расстояние до объекта должно быть не менее 1 метра.

3. Сосредоточившись на выбранной точке (это «облако»), практикующий начинает чувствовать ее как нечто материальное.

Нужно продолжать смотреть на точку и довести концентрацию до того момента, чтобы почувствовать «плотность» этой точки, будто она – материальный объект.

4. Сконцентрировавшись и прочувствовав ее, практик мысленно «протягивает» ощущения от точки до самого себя.

Это напоминает «нить», которая тянется от точки на стене к голове практика.

Так выстраивается «волна», канал, по которому информация перетекает от точки концентрации в разум человека!


Внимание!

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

5. Практикующий осознанно удерживает в сознании этот чувственный канал от точки («облака»). Через определенное время к практику начнет поступать нужная информация: ответ на вопрос, который он задал в самом начале.

Так происходит считывание мысли на расстоянии. Мысли могут касаться любых людей и самых разных вопросов.

Примечания и тематические статьи для более глубокого понимания материала

¹ Телепатия — способность мозга передавать мысли, образы, чувства и неосознаваемое состояние другому мозгу или организму на расстоянии, либо принимать их от него, без использования каких бы то ни было известных средств коммуникации или манипуляции (Википедия).

7 уловок сознания, из-за которых мы принимаем неверные решения

Ребята, мы вкладываем душу в AdMe.ru. Cпасибо за то,
что открываете эту красоту. Спасибо за вдохновение и мурашки.
Присоединяйтесь к нам в Facebook и ВКонтакте

Ученые давно развенчали миф, что мы используем только 10 % нашего мозга. На самом деле даже при выполнении элементарных задач он задействован более чем наполовину. При этом мозг использует 1/5 часть всей нашей энергии. Нет ничего удивительного, что в процессе анализа данных он придумывает различные уловки, чтобы собрать важные сведения и на их основе как можно быстрее принять решение. Вот только это решение далеко не всегда является лучшим.

Мастер Йода рекомендует:  12 лучших плагинов WordPress для перевода

Мы в AdMe.ru собрали для вас несколько ошибок мышления, из-за которых мы порой делаем абсолютно неверные выводы и усложняем себе жизнь, а также советы, как не допустить такого поворота событий.

1. Сладкий эксперимент

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

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

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

2. Наш мозг любит нас обманывать

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

Оказывается, что домашними пирожками вы балуете себя редко, а пожарить в мультиварке за 1 раз можно только 6–7 котлет. Дело в том. что в режиме сравнения мы лучше определяем количественные различия, а в режиме испытания — качественные.

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

3. Путь наименьшего сопротивления

Авторы книги «Nudge. Архитектура выбора» Ричард Талер и Касс Санстейн уверены, что люди очень часто делают выбор, который требует от них минимальных усилий, даже если для них это невыгодно, ну а компании этим активно пользуются. К примеру, раз в месяц вам приходит сообщение об автоматическом продлении подписки на какой-либо ресурс или журнал. Многие таким образом платят за издания, которых даже не открывают.

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

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

Создатели интернетов

они среди нас

Умение разбираться в чужом коде

»’«Умение разбираться в чужом коде»»’ — строка-детектор, которая содержится в чуть более, чем всех вакансиях на должность [[быдлокодер|программиста]] и смежные должности. Чаще всего акцент на этой фразе делается для вакансий разработчика на [[C++]] и [[PHP]].

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

[[На самом деле]] [[There is no spoon|никакого такого умения не существует]]. Любой человек, способный писать, может и читать. Другое дело, что можно писать так, что потом сам хрен прочитаешь. Для этого существуют [[Lurkmore:Гайдлайны|гайдлайны]], и если их придерживаешься, то код хоть немного, но можно читать. Однако, код, написаный [[дедлайн|в спешке]], почему-то получается нечитабельным у большинства разработчиков Наверное излишне добавлять, что в [[95%|большинстве]] случаев код таки пишется в состоянии крайней спешки. .

== Настоящее значение фразы ==
* Нужен идиот, который будет разгребать это дерьмо
* Руководитель свято верит, что причина получающегося дерьма в нерадивых программистах, а не в нём
* Разгрести это дерьмо у тебя не получится при любом желании, так как от тебя будут требовать писать всё больше и больше кода, который непонятно как придётся прикручивать к существующему, на разгребание времени не останется совсем
* В разработке архитектуры ПО используется метод «снизу вверх», требования меняются постоянно в зависимости от настроения левой пятки руководителя
* .
* PROFIT [[На самом деле]] профитом здесь и не пахнет, пункт присутствует исключительно как дань [[луркоеб|традиции]].

== Что мы узнаём об организации по такой вакансии ==
* [[Макдональдс|Большая текучка кадров]]
* Никто толком не может поставить процесс разработки. (При грамотной организации процесса разработки ПО, код получается таким, что разобраться в нём не составит труда для любого программиста)
* Темпы разработки постоянно подгоняются начальством, качество кода ужасно, переписывать приходится больше чем писать
* Качество ПО, производимого этой конторой — дерьмо
* Вам будут перманентно ебать мозг

== Умение разбираться в чужом коде в резюме ==
Если же фраза встречается в резюме, это означает обратное:
* Я готов копаться в любом дерьме
* Я буду писать такой код, разобраться в котором можно, только обладая данным умением

Умение разбираться в чужом коде

«Умение разбираться в чужом коде» — строка-детектор, которая содержится чуть более, чем во всех вакансиях на должность программиста и смежные должности. Чаще всего акцент на этой фразе делается для вакансий разработчика на C++ и PHP, где «чужой» не только код.

Содержание

[править] Значение фразы

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

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

Потому и существуют гайдлайны, они же правила оформления. Например, не лениться использовать «говорящие» названия переменных и функций, даже если они длинноваты, оставлять комментарии в ключевых местах (то есть почти везде), не использовать goto-подобные операторы и так далее. И если подобных единых правил придерживаешься, то код хоть немного, но можно читать. Однако код, написанный в спешке, почему-то получается нечитабельным у большинства разработчиков.

[править] Настоящее значение фразы

  • Нужен идиот, который согласен разгребать это дерьмо.
  • Руководитель свято верит, что причина получающегося дерьма в нерадивых программистах, а не в нём.
  • Разгрести это дерьмо у тебя не получится при любом желании, так как от тебя будут требовать писать всё больше и больше кода, который непонятно как придётся прикручивать к уже существующему, на вдумчивое разгребание времени не останется совсем.
  • В разработке архитектуры ПО используется метод «снизу вверх», требования меняются постоянно в зависимости от настроения левой пятки руководителя.
  • С 2011 года среди Java-разработчиков фраза приобрела новый оттенок: программисту подсовывают («посмотреть», доделать, переделать, заставить работать…) под видом собственной разработки довольно качественный код, декомпилированный из какого-нибудь коммерческого продукта. Ну и…

[править] Что мы узнаём об организации по такой вакансии

  • Большая текучка кадров.
  • Некому толком поставить процесс разработки в верную позу (при грамотной организации процесса разработки ПО код получается таким, что разобраться в нём не составит труда для любого программиста).
  • Темпы разработки постоянно подгоняются начальством, качество кода ужасно, переписывать приходится больше, чем писать.
  • Качество ПО, производимого этой конторой — дерьмо.
  • Вам будут перманентно ебать мозг.

[править] Что мы узнаём о работнике

Если фраза встречается в резюме, то означает симметричное:

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

[править] Когда сабж оправдан

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

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

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

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

[править] А на самом деле

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

[править] См. также

[править] Примечания

    ↑ На самом деле, код из книжки Александреску и из либы Loki и при вдумчивом чтении всё совершенно понятно.

    — Я делаю особую, шаблонную магию
    — Не-не-не, Андрей Александреску, не-не-не

    Считывать мысли на расстоянии очень просто!

    Может ли человек считывать чужие мысли на расстоянии? Да! Это может даже тот, у кого нет развитого дара ясновидения! Узнайте об этой технологии!

    Врожденные сверхспособности есть у каждого!

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

    Любая мысль тоже является волной.

    Как обычному человеку научиться считывать чужие мысли на расстоянии? Особенно, если у него нет развитого дара ясновидения² или других сверхспособностей?

    Техника считывания мысли на расстоянии

    Предложенная техника очень проста; единственное, что необходимо – концентрация внимания. Принцип ее похож на скачивание файла в компьютер из «облака» (хранилища информации в сети интернет).

    1. Практик мысленно задает вопрос, который его интересует. К примеру: «Что думает обо мне А. (имя нужного человека)?»

    2. Затем практикующий выбирает место вокруг себя, на котором будет концентрироваться. Например, точка на стене. Единственное условие: расстояние до объекта должно быть не менее 1 метра.

    3. Сосредоточившись на выбранной точке (это «облако»), практикующий начинает чувствовать ее как нечто материальное.

    Нужно продолжать смотреть на точку и довести концентрацию до того момента, чтобы почувствовать «плотность» этой точки, будто она – материальный объект.

    4. Сконцентрировавшись и прочувствовав ее, практик мысленно «протягивает» ощущения от точки до самого себя.

    Это напоминает «нить», которая тянется от точки на стене к голове практика.

    Так выстраивается «волна», канал, по которому информация перетекает от точки концентрации в разум человека!

    Внимание!

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

    5. Практикующий осознанно удерживает в сознании этот чувственный канал от точки («облака»). Через определенное время к практику начнет поступать нужная информация: ответ на вопрос, который он задал в самом начале.

    Так происходит считывание мысли на расстоянии. Мысли могут касаться любых людей и самых разных вопросов.

    Примечания и тематические статьи для более глубокого понимания материала

    ¹ Телепатия — способность мозга передавать мысли, образы, чувства и неосознаваемое состояние другому мозгу или организму на расстоянии, либо принимать их от него, без использования каких бы то ни было известных средств коммуникации или манипуляции (Википедия).

    Добавить комментарий