Connect with us

Разработка

Григорий Петров: Объектно-Ориентированное программирование

Но самое главное во всей этой истории: понимание, почему при взгляде на чужой код хочется все выкинуть и переписать. Очень часто это совсем не потому, что код плохой. А потому, что его писал другой человек.

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

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

/

     
     

Я уже много раз рассматривал гипотезу о работе нашего мозга, который любит строить и использовать модели окружающего мира. Это даже не одна гипотеза, а целый ряд наблюдений: как люди рождаются, растут, изучают окружающий мир и взаимодействуют с ним. Одна из гипотез предполагает, что многие механизмы моделирования у нас встроенные. К примеру, есть подозрение, что у младенцев существуют готовые механизм моделирования и распознавания лиц, социальных ситуаций, выделения “действующего лица” (actor) и его цели (intent).

Если вы посмотрите на две точки и линию под ними, то увидите “лицо”. Как в этом смайлике: “:)”. Встроенный механизм этого, возможно, заложен у нас на генетическом уровне. Похожий механизм, известный как “мифологическое сознание”, это выделение “действующих лиц” и их “целей”. Люди по своей природе социальны, эти механизмы позволяют ребенку понять, как работает социум и стать его частью. Когда ребенок видит другого человека, то он воспринимает этого человека как “действующее лицо”, а его действия воспринимает как имеющие какую-то “цель”. Механизмы довольно простые и распространяются не только на живых людей, но и на окружающий мир. Ребенок нескольких месяцев от роду уже способен различать, что квадратик на экране “гонится” за треугольником, а круг треугольнику “помогает”.

Действующие лица и их мотивы

Мозг – не компьютер, в нем, скорее всего, нет жестко изолированных друг от друга программ. Мифологическое сознание не только позволяет ребенку понять работу нашего общества и верить в деда мороза. Эти же механизмы влияют на наш язык и на модели окружающего мира. Во фразе “машина едет к дому” этот механизм формирует образ одушевленного действующего лица, машины, которая движется с определенной целью. “Дождь идет”. “Солнце светит”. “Кофеварка сломалась мне на зло!”. Все эти привычные фразы раскрашивают окружающий мир осознающими себя существами, совершающими действия с какими-то целями.

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

Декомпозиция

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

А теперь следите за руками. Наши модели мира используют “действующих лиц”. Наш язык использует “действующих лиц”. И тут нам нужно именовать в программе объекты, с которыми что-то происходит! Логично предположить, что мозг будет использовать для этой сложной задачи уже существующие, обкатанные и более-менее хорошо работающие механизмы. “файл.открыть()”, “окно.закрыть()” – все вот это.

А теперь сюрприз. Механизм, который позволяет ребенку понять, что квадратик “гоняется” за треугольником, а секретарше, что “кофемашина на нее обиделась” – не то чтобы очень точный инструмент. И если для окружающего мира у нас есть жизненный опыт, прочитанные книги, пример других людей – то в случае программы, в отсутствии фундаментального образования, программист предоставлен самому себе. Как сгруппировать объекты? Какие у них будут отношения друг с другом? Окно будет регистрироваться в области нотификаций, или область нотификаций будет добавлять в себя окно?

А это важно?

Кто вокруг кого вращается

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

Нарисованная справа Марсом траектория как бы намекает нам, что неудачно выбранные объекты могут привести к печальным последствиям. Я сам могу вспомнить множество случаев, когда при разработке Windows приложений все начиналось с объекта “главное окно”. Который со временем начинал обрастать все большей и большей функциональность, пока, наконец, не превращался в чудовищный клубок запутанных связей, обеспечивающий работу нескольких десятков других окон, фоновых потоков, дочерних процессов и множества других шутки. Поддерживать, а тем более развивать такие программы было очень тяжело.

Программист художник, он так видит

Программирования – очень молодая отрасль. Множество программистов – самоучки. “Лучшие практики” разработки сменяют друг друга раз в пару лет. Полагаю, что не открою Америку, если скажу, что программисты по-разному группируют объекты и методы их взаимодействия. А потом им тяжело читать и поддерживать код друг друга. Чужая ментальная модель – она как чужая одежда. Иногда жмет, иногда свисает, а иногда просто не налезает.

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

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

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

1 Comment

  1. iBeginner4

    25.02.2017 at 23:52

    хорошо

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
Продолжить чтение

Календарь

ноябрь

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

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

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

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

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

декабрь

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

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

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

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

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

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

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

Наш Facebook

Популярное

X

Спасибо!

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