Connect with us

Разработка

Григорий Петров: Программисты разной силы на одном проекте

Про ментальные модели я много раз рассказывал. Это уже 45-я статья цикла по управлению разработкой, поэтому пора раскрыть страшную правду. Мы не знаем, как работает наш мозг. Не знаем от слова “вообще”.

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

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

/

     
     

Про ментальные модели я много раз рассказывал. Это уже 45-я статья цикла по управлению разработкой, поэтому пора раскрыть страшную правду. Мы не знаем, как работает наш мозг. Не знаем от слова “вообще”. Лучшее на данный момент объяснение:

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

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

Силушка программистская

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

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

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

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

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

А для кода таких областей нет.

Образования нет. Фундаментальных учебников нет. Устоявшихся методологий нет. Все что есть – это опыт, который у каждого разработчика свой. Если опыт сильно различается, то таким разработчикам будет тяжело читать, понимать и поддерживать код друг друга. Даже такие фундаментальные вещи, как “действующие лица”, о которых я недавно писал, будут различаться. И мы даже не можем использовать микроменеджмент и объяснить, как делать правильно! Потому что собственную картину мира в чужую голову запихнуть проблематично.

А что можно?

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

  • Соблюдать баланс между изоляцией разработчиков и командной работой. Хорошо, когда разработчики знают, что делают их коллеги и могут “подстраховать” в редких случаях. Хуже, когда несколько разработчиков работают над одной и той же частью проекта, постоянно споря и “сталкиваясь лбами”. Опытный тим лид разделяет проект на изолированные части, над каждой из которых работает отдельный боец. В случае, если он покинет компанию, его преемник сможет постепенно их переписать “под себя”. Если они небольшие, конечно.
  • Использовать и развивать стандарт кодирования. Внешняя похожесть кода – это, конечно, не панацея, но хоть немного уменьшает когнитивную нагрузку. А Continuous Integration позволяет сделать проверки автоматическими.
  • Чтение разработчиками кода друг друга. Не с целью поиска ошибок. А с целью “привыкания” к чужим ментальным моделям. Ну и ошибки иногда тоже находят, в качестве приятного бонуса.
  • Использование opinionated фреймворков, которые навязывают соглашения по именованию объектов, их взаимодействию и общей структуре проекта. Тут главное – побороть желание каждого разработчика “все переделать с нуля”. Выбранный фреймворк будет не нравиться всем, потому что не они его писали, зато бойцы смогут лучше понимать код друг друга. Оно того стоит.
Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Дизайн и прототипирование

30 UI-китов для iOS-разработчиков

Соосновательница Flawless App Лиза Дзюба поделилась полезными наборами с готовыми интерфейсами iOS-приложений.

Анна Гуляева

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

/

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

Стандартные UI-киты

Design+Code iOS 11 UI Kit —  Sketch-набор, который содержит стили текстов, вложенные символы с изменяемыми размерами и набор компонентов в темной теме. Название каждого компонента соответствует документации Apple.

iOS 11 Screens & Components — огромная коллекция ключевых компонентов iOS 11 и более 60 экранов, доступна для Sketch и Figma.

iOS 11 GUI for Sketch App — набор содержит 22 экрана, 10 клавиатур, векторные элементы и формы, доступные в формате Sketch.

iOS 11 iPhone GUI by Facebook — полный набор файлов для Origami, Sketch и Photoshop от команды Facebook.

UI-киты для социальных приложений

Bronze UI Kit — простой и изменяемый набор с формами регистрации, входа, профилем пользователя, экранами блога и шаблонами для статей. Доступен в формате Photoshop и подходит не только для iOS.

Mail UI Kit — новейший кроссплатформенный набор от InVision, который подойдет для десктопа, смартфона, планшета и умных часов, доступен в Sketch и Photoshop.

Snap UI Kit — UI-кит от сотрудников Marvel, включающий более 50 экранов и большое количество элементов в формате файлов для Sketch. Подойдет для создания приложения с фото.

UI-киты для приложений про путешествия

Travel App UI Kit — более 15 экранов для входа, просмотра информации о месте, фотографий, карты и многого другого.

Navigo UI Kit — UI-кит для приложения про поездки с социальными профилями, в котором находится 60 экранов, организованных в 6 категорий. Набор сделан в формате Adobe XD.

Travel Guide App UI Kit — это не совсем набор элементов, а концепция реального приложения, которое оптимизировано для iPhone X, чтобы показать наилучшее использование фильтра локаций и карт.

Travelisto UI Kit — UI-набор для Sketch с более чем 22 экранами в векторном формате.

Harmony UI Kit — концепция основанного на локации мобильного приложения для того, чтобы искать и оценивать места для прогулок вокруг вас.

UI-киты для приложений с рецептами

Delicious UI Kit — набор включает 11 экранов в формате Sketch.

iOS Recipes App UI Kit — отличный набор с 11 экранами для приложения о готовке в формате Sketch.

1357 Recipe App UI Kit — современный и элегантный набор с 25 базовыми экранами.

UI-киты для чатов и мессенджеров

Mochi — Chat UI Kit — милый набор для мобильного чата с экранами для входа, регистрации, списков чатов, контактов и других.

iOS WeChat UI Kit — этот UI-кит включает в себя множество элементов и взаимодействий для главного китайского приложения WeChat, доступных на английском и китайском.

Messenger Platform Design Kit — официальный набор для бота Facebook Messenger.

UI-киты для eCommerce

Minimal Chic Kit стильный UI-кит для приложения о продаже с экранами страниц категорий товаров и самих товаров, доступных в формате Adobe XD.

Portal freebie — пример приложения, сделанного в Sketch.

Wilhelm iOS UI Kit — набор с изменяемыми экранами в Sketch, которые подойдут не только для продаж, но и для социального приложения.

Helen UI Kit — профессионально разработанный набор пользовательских интерфейсов для Sketch и Photoshop, организованных в более чем 11 экранов.

Mcommerce UI Kit —  набор стильных пользовательских интерфейсов для продаж с более чем 120 экранами, созданными для Sketch.

Другие UI-киты

iOS 11 Place UI Kit — если вы планируете сделать мобильное приложение в ARKit, вы можете использовать набор пользовательского интерфейса, который содержит 22 экрана для iOS 11 и векторные значки (в бесплатной версии).

Movies App UI Kit — красочный набор, который включает более 30 экранов с полностью настраиваемыми макетами и слоями для Sketch.

Wonep Calling App — довольно крутой набор для создания приложения для совершения международных звонков.

Banking UI Kit — аккуратный набор для пользовательского интерфейса банка для Sketch с 50 экранами.

Real Estate App UI Kit — UI-кит для создания приложения о недвижимости с 25 элементами, организованными в 8 страниц в формате Sketch.

DO UI Kit — набор для приложения для заметок с более чем 130 экранами, 10 темами, в котором есть все нужное в форматах для Sketch, Photoshop и Craft.

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

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

Обучение

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

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

Анна Гуляева

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

/

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

Взгляд назад

Я работала веб-разработчиком и ранее, но в начале прошлого года поняла, что недовольна своей карьерой. Я не могла понять, почему так происходит, пока не прочитала статью Three types of programmers, которая перевернула мой взгляд:

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

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

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

И если вы делаете все это на PHP, то начинаете нервничать и становитесь подозрительнее, а кроме того выполняете много монотонной работы. Поэтому я начала изучать Ruby.

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

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

Новая работа

Оказалось, что этот проект начался ещё в 2014. В проекте использовались Rails 4.1 и Ruby 2.2.3, а также было много технических проблем, которые не были исправлены уже год. Ничего не тестировалось уже долгое время: в папке было только несколько тестов, и они явно были написаны на ранних стадиях проекта.

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

Как справиться со всем этим?

Существует два уровня проблем: проблемы на уровне компании или проекта и персональные проблемы с уровнем навыков и организацией работы.

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

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

1. Большой незнакомый проект

Большую часть времени я провожу за поиском информации, пытаясь понять проект и его работу. После этого возникает проблема изучения ранее написанного кода. Для начала я в общем изучаю предметную область. Так я узнаю основные термины, которые будут всплывать в каждой задаче. Затем я ищу эти термины в объектах, например, моделях или базах данных. И уже потом я могу анализировать сами объекты и искать связи между ними.

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

2. Нехватка времени на тестирование

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

3. Недостаточная спецификация задачи

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

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

4. Ревью кода в конце задачи

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

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

5. Я не вижу для себя возможности развития

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

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

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

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

Проблемы на уровне компании

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

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

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

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

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

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

 

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

Новости

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

Игра из пластилина, инструменты, чистая архитектура и многое другое.

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

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

/

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

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

Программирование

Применение Google Cloud Vision API в приложении для Android

Android-разработчик Леонардо Пирро рассказал об инструменте компьютерного зрения от Google и его применении в приложениях.

Анна Гуляева

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

/

Искусственный интеллект и машинное обучение — это одни из самых популярных тем в бизнесе. Google, лидер области, разработала набор инструментов для разработчиков, которые позволят создать новый пользовательский опыт с безграничными возможностями. Сегодня мы исследуем Google Cloud Vision API и его применение в приложениях Android.

Google Cloud Vision API

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

Для примера возьмем это изображение:

Vision API удивителен, он может распознать основной субъект фото (животное), определить его вид (собака) и породу (бигль). Более того, вы можете получить дополнительные данные о траве и горах на фоне.

Давайте взглянем на все функции Google Cloud Vision API:

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

В нашем примере мы используем две функции: обнаружение меток и оптическое распознавание символов. Давайте посмотрим, как интегрировать Vision API в приложение Android. Мы создадим пробный проект, который позволит пользователю выбирать изображение из галереи и получать о нем информацию.

Внедрение Google Cloud API

Чтобы использовать API, мы должны внедрить его в Google Cloud Developer Console. Вот как это сделать:

  1. Создайте проект в Google Cloud Console или используйте существующий.
  2. Включите в проекте Billing. Если это ваше первое использование Google Cloud Console, вы можете начать бесплатный пробный период использования. У вас могут попросить данные карты, но денег не спишут.
  3. Включите Google Cloud Vision API, используя эту ссылку.
  4. Откройте в боковом меню слева секцию Credentials.
  5. Выберите в меню OAuth Client ID: установите тип приложения Android, введите название приложения и отпечаток SHA1 (если у вас его нет или вы не знаете, как его сгенерировать, введите эту команду в терминале keytool -exportcert -keystore path-of-your-keystore -list -v). Затем введите имя пакета вашего приложения: оно должно совпадать с именем, указанным в файле build.gradle вашего приложения, в ключе applicationId. В моем случае —  com.lpirro.cloudvision.

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

Cloud Vision API в действии

Создайте новый проект в Android Studio и помните, что имя пакета должно совпадать с названием в проекте в Google Cloud Developer Console. Затем откройте build.gradle и добавьте зависимости Vision API.

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

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

Файл макета нашей активности очень прост: у нас есть один ImageView, используемый для отображения выбранного изображения из галереи, два TextView для отображения результатов и одна Button, используемая для выбора изображения из галереи.

Вот файл с макетом нашей активности:

Теперь остановимся на Activity. В этом примере мы используем библиотеку Google API Client для Java, и так как мы используем OAuth request, нам нужно получить от Google токен аутентификации. Давайте определим класс, который позволит нам получить этот токен.

Примечание: для простоты мы будем использовать AsyncTask для сетевых операций, но если вы будете использовать этот API в реальном проекте, используйте библиотеку, например, Retrofit, возможно, вместе с RxJava.

Теперь у нас есть вся необходима информация, чтобы вызвать Cloud Vision API и получить результаты.

При помощи метода setType() мы определим тип функции, которую хотим использовать: в нашем случае это LABEL_DETECTION и TEXT_DETECTION. Формат изображения, переданного API, находится в Base64. Как только результаты будут получены, они передаются методу getDetectedText (), который будет форматировать строку и фильтровать информацию, после чего мы можем окончательно отобразить их в интерфейсе.

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

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

Постеры для разработчиков

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

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

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

Вакансии

Популярное

X
X

Спасибо!

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