Connect with us

Разработка

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

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

Григорий Петров

Опубликовано

/

     
     

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

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

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

code-review

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

Что читать

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

dltf8

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

Что не читать

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

7713228_orig

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

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

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

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

Григорий Петров
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Обучение

Разработка iOS 11 приложений на Swift

Стэнфордский университет опубликовал новую версию курса по Swift в iTunes U.

Леонид Боголюбов

Опубликовано

/

В новом курсе учтены все изменения, сделанные в iOS 11 и новой версии Swift.

Темы:

  • Инструменты и API, которые понадобятся для разработки приложений для iPhone и iPad/
  • Пользовательский интерфейс.
  • MVC-парадигма.
  • Анимации.
  • Многопоточность.
  • Работа с сетью.

Курс бесплатен и доступен для прохождения на iPhone и iPad. Язык – английский.

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Новости

Интересные материалы: 16.11

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

Опубликовано

/

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

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

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

AppCraft

Опубликовано

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

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

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

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

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

Так происходит из-за того, что бизнес – это решение реальных проблем. Он развивается и растет в синергии с потребностями людей, которые:

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

Как только вы начнете запускать идею, с вероятностью близкой к 100% вам придется если не полностью изменить вашу задумку, то значительно ее переработать. Зачем в этом случае патентовать в самом начале то, от чего в последствие вы сами откажетесь?

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

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

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

Итого

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

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

AppCraft
Комментарии Facebook
Продолжить чтение

Календарь

ноябрь

16ноя - 18Весь деньVIII Всероссийский форум молодых лидеров YouLead

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

18нояВесь деньDevFest Gorky 2017

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньLadies Code: время технологий

25нояВесь деньSmart Taler 2017

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Наш Facebook

Популярное

X

Спасибо!

Теперь редакторы в курсе.