К чему готовиться, когда приходишь в команду, где применяют Agile. Кому нужен Scrum, в чем его сила и когда он мешает. 

Слова Agile и Scrum прочно вошли в жизнь разработчиков за рубежом и в России. Мнения о гибких правилах разработки в профессиональном сообществе расходятся. Сегодня мы обсудим эту тему с человеком, который работает по принципам Agile уже более 10 лет и успел получить опыт проведения скрамов в российской и международной компаниях. Мой собеседник — Владимир Морозов — преподаватель факультета Android-разработки в GU, он нам расскажет про функции Scrum мастера и какую роль он играет в команде.

— Владимир, какие курсы вы сейчас ведете в GeekUniversity и GeekBrains?

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

— В каких компаниях и командах вы занимались разработкой и практиковали Agile и Scrum?

— Я не любитель часто менять работу: в 2007 году пришел в компанию, которая разрабатывала ПО для ритейловых сетей. В этой компании мало кто знал про Agile, и когда команда столкнулась с проблемами, мы стали анализировать ситуацию и искать решение. В итоге пришли к необходимости использовать Scrum. Сейчас работаю в DXC Technology — тоже по скраму. 

Уточню, что Scrum — это не методология и не технология, а фреймворк, как утверждают авторы скрам-гайда Ken Schwaber и Jeff Sutherland. На русский язык тяжело перевести, что такое фреймворк, поэтому говорят «методология». На самом деле это контейнер с правилами, который каждая компания и команда заполняет своими процессами. Я бы сказал, что скрам — это набор правил и рекомендаций. 

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

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

— В чем ключевые особенности взаимодействия в командах, применяющих Agile?

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

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

— Чем еще занимается скрам-мастер?

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

— Чем на практике отличается применение методологии Agile в разных компаниях (российских и зарубежных) и командах? Какие факторы влияют на эти различия?

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

— По вашему опыту, когда Scrum работает лучше всего и какие у него противопоказания?

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

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

— Когда в феврале этого года в блоге вышла небольшая статья про Agile, у одного читателя возник вопрос: есть ли в Scrum место «причесыванию кода» — рефакторингу и «выпиливанию костылей»? Или в погоне за новыми запросами пользователя трудно найти на это время?

— Интересно, что в твиттере недавно появилось на эту тему сообщение от автора принципов SOLID, Роберта Мартина, или Дядюшки Боба, как зовут его в сообществе. Он посоветовал при оценке задачи закладывать в нее рефакторинг и написание тестов. Считаю этот совет очень разумным и полезным. 

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

— У себя в профиле вы указали, что в программировании, помимо прочего, вам важна тестируемость кода. Что вы под этим подразумеваете?

— К сожалению, начинающие разработчики, да и не только они, часто пренебрегают написанием автотестов. Как проверить код? Только тестированием. Это можно сделать вручную либо написать автотест — кусок кода для проверки другого кода. 

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

— И еще один вопрос от читателей: «Agile — это модно, молодежно, но можно пример успешного Agile-проекта в топовых компаниях? Скорее всего, даже если вы найдете ссылку, это будет классический подход с элементами Agile. В отличие от чистого аджайла, там будет документация и заранее заданная архитектура». От себя добавлю: разве наличие документации и заданной архитектуры нарушает принципы Agile?

— Работаю по Scrum в компании DXC Technology. Почитайте, чем она занимается. Не уверен, что это компания топовая, но международная — точно. 

Как связана архитектура с Agile? Я не понимаю. Это как сравнивать зеленое с круглым. 

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

— Есть ли в Agile механизм защиты продукта от перегрузки лишними функциями из-из «хотелок» пользователей? Или это за рамками подхода?

— За рамками. За этим следит владелец продукта: он ведет backlog (список задач) и расставляет приоритеты. Любая «хотелка» должна быть проанализирована.

— В каких ситуациях уместно так называемое экстремальное программирование (XP)? Был ли у вас такой опыт?

— Мы работаем по этим методикам. Фактически Scrum — часть экстремального программирования. Добавим сюда парное программирование, непрерывную интеграцию и разработку через тестирование — получим XP. 

Если заказчик недоступен, в скраме его замещает владелец продукта. Мне кажется, чем больше элементов экстремального программирования вы применяете, тем качественнее продукт. XP — это работа без стрессов, а не наоборот. :)

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

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

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

— Как выглядит спринт в команде Android-разработчиков? Что чаще всего идет не так и что при этом может сделать мастер?

— В данном случае не важно, идет ли речь об Android- или веб-разработке, о десктопных приложениях или сервисах. Проблемы бывают общими или командными. Общие проблемы — это неправильное прогнозирование задач (времени их выполнения), неверная расстановка приоритетов, отсутствие или неясность цели на спринт. 

В каждой команде — свои проблемы. Это может быть внутренняя коммуникация, назойливое руководство или еще что-то. С подобными препятствиями помогает бороться скрам-мастер. К слову, сейчас наша команда работает на Java, C#, Golang, Python и Angular (TypeScript).

— Читала, что в веб-разработке в распределенных командах американцы чаще берут на себя фронтенд, а россияне сосредотачиваются на бэкенде. В Android-разработке подобного не прослеживается?

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

У меня не настолько большой опыт работы с зарубежными Android-разработчиками, чтобы говорить о подобных нюансах. Но сейчас наша команда пишет микросервисы на C# — это тоже можно считать бэкендом :)

— Насколько понимаю, Аgile ориентирован на опытных специалистов, которые умеют брать на себя ответственность. Когда в команду приходит Junior, которого предстоит многому научить, он еще не полностью вовлечен в проект. Что, кроме собственного желания сотрудника, влияет на скорость вовлечения? Как этому способствует скрам?

— Обучать таких людей — одна из обязанностей scrum-мастера. Чтобы скорее вовлечься, нужно просто начать работать в команде.

— Насколько обременительно быть скрам-мастером: какую часть рабочего времени приходится выделять на организационные моменты? Насколько это сочетается с другими задачами ведущего разработчика?

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

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

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

— Спасибо за ответы! Интересно было узнать мнение человека, который не первый год в теме Agile и знает изнутри, как работает Scrum.

В 2019 году исполняется 20 лет концепции интернета вещей (Internet of Things, или IoT). Она уже не нова, но не всем известно, какое изобилие технологий и инженерных решений под ней скрывается. Расскажем, как интернет вещей и связанные с ним технологические новшества изменят нашу жизнь уже в самом скором будущем.

Что такое интернет вещей, как работает и зачем он нужен

Еще один интернет? Неужели нам не хватало старого?!

Нам — хватало. Но мы в этом мире уже не одни. Эксперты прогнозируют, что к 2020 году к Сети будет подключено около 28 миллиардов устройств, причем лишь треть из них — компьютеры, смартфоны и планшеты. Остальные ⅔ приходятся на другие девайсы: телевизоры, платежные терминалы, фитнес-браслеты, автомобили, бытовую электронику, производственное оборудование, всевозможные датчики и контроллеры. Прежде мы не видели необходимости предоставлять им доступ ко Всемирной паутине. В самом деле, для чего может понадобиться интернет розетке или жалюзи?.. Но теперь мы знаем, что это открывает новый мир невероятных возможностей.

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

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

Физически это могут быть ИК-сигналы, связь по радио, стандарту Bluetooth или даже обычный Wi-Fi. Когда эти протоколы связи используются для передачи информации между устройствами, они становятся частью интернета вещей.

В информационном обмене может участвовать не только умная электроника, но и книги, письма и посылки, одежда и многие другие бытовые вещи.

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

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

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

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

Умный дом, который построим мы

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

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

Зачем нужен интернет вещей — кратко

Например, компания Samsung выпустила холодильник Family Hub, помогающий заказывать продукты с доставкой, не выходя из кухни: с помощью сенсорного экрана на дверце холодильника. На него можно вывести каталог магазина и выбрать товары. Холодильник может отслеживать сроки годности каждого продукта и напоминать о них хозяевам. И при каждом закрытии дверцы Family Hub делает фотографию своего содержимого и отправляет ее хозяину на смартфон. Так что не приходится вспоминать, есть ли дома молоко, йогурт или помидоры — достаточно заглянуть в телефон!

Китайская компания Xiaomi выпускает ряд устройств для умных домов. Это и смарт-электрика (розетки, выключатели, удлинители), и беспроводные контроллеры для управления другими гаджетами, и всевозможные датчики — движения, протечки воды, открывания дверей и окон, температуры, влажности и давления. Для большинства девайсов можно настроить сценарии поведения. К примеру, кнопка Xiaomi Smart Wireless Switch предлагает задать разные действия при одиночном щелчке, двойном или долгом нажатии, а Xiaomi Mi Magic Cube Controller, выполненный в виде кубика, можно повернуть, встряхнуть, постучать или сдвинуть — в зависимости от действия он умеет выполнять шесть команд, которые можно запрограммировать самостоятельно. Кнопка дверного звонка пришлет вам на смартфон сообщение, если кто-то придет к вам в ваше отсутствие, а при наличии камеры — еще и покажет фотографию гостя.

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

Ванная комната, оборудованная интеллектуальными девайсами, поможет экономить воду. Система снизит напор в кране, когда вы бреетесь или чистите зубы, и выдаст полную мощность, когда вам понадобится принять душ или набрать ванну. В Японии и Китае уже разработаны умные унитазы, которые умеют проводить анализы, чтобы отслеживать состояние здоровья хозяина, — например, выявлять сахарный диабет или определять группу риска. В перспективе развития этих технологий можно ожидать, что у нас появятся персональные врачи, сопровождающие каждого в режиме 24/7. Результаты анализов, информация с фитнес-браслетов, данные о питании и режиме сна, занятиях спортом, показания электронных весов — все эти сведения будут объединяться и обрабатываться, чтобы формировать рекомендации по поддержанию здоровья или напоминать обратиться врачу, если появятся тревожные сигналы.

Интернет вещей помогает в работе

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

Одно из подразделений компании General Electric, GE Renewable Energy, сумело снизить расходы на техническое обслуживание на 10 %, а расходы на внеплановый ремонт — на 20 %, внедрив систему мониторинга данных на своем полевом оборудовании. Филиал занимается выработкой энергии из возобновляемых источников и производит ветрогенераторы, электростанции на солнечной энергии, гидроэлектростанции. Специальные датчики в непрерывном режиме контролируют работу этого оборудования, передавая данные телеметрии в единый центр. При малейших отклонениях в работе специалисты GE готовы оперативно выполнить профилактические работы или срочный ремонт, предотвращая поломку и экономя средства на восстановление техники. Та же телеметрия позволяет предсказывать будущие объемы выработки энергии и планировать, как эффективнее использовать генераторы. Все это снижает эксплуатационные расходы и минимизирует финансовые потери компании.

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

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

Еще одна область использования интернета вещей — это системы мониторинга автопарка, которые уже сберегают финансы компаний. Установка нескольких датчиков и навигационного оборудования GPS или ГЛОНАСС позволяет практически полностью исключить злоупотребления служебным транспортом: хищение топлива, нецелевое использование и многое другое. Такая система способна контролировать буквально каждое движение водителя: маршрут передвижения, пройденное расстояние, точки заправки, объемы залитого и израсходованного топлива, стоянки и их продолжительность, соблюдение скоростного режима.

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

Устройства интернет вещей для здоровья

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

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

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

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

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

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

Зачем нужен интернет вещей в школе и вузе

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

Несомненно! 

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

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

Интернет делает удобнее и удаленное обучение. Если ребенок не может посещать школу, он будет заниматься с классом, присутствуя «виртуально» — подключаясь к занятиям по видеосвязи. 

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

Интернет вещей помогает путешественникам

Приходилось ли вам терять багаж при перелете? В 2016 году авиакомпания Delta Airlines разработала систему отслеживания багажа, которая отправляет пассажиру на смартфон сообщение о местонахождении его чемоданов. Если пассажир опаздывает на стыковочный рейс или его багаж по ошибке отправляют в Каир вместо Нью-Йорка, система помогает быстро исправить ошибку. Впрочем, некоторые чемоданы и сами способны отслеживать свое местоположение по GPS и сообщать владельцу координаты.

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

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

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

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

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

Умные и безопасные города

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

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

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

Подобные технологии выглядят как часть сюжета фантастического романа, но они уже существуют. В Китае с 2015 года действует проект по созданию системы национального масштаба по распознаванию лиц. К 2020 году планируется использовать более 600 миллионов камер для контроля за гражданами страны. Система сможет с высокой точностью узнавать в лицо каждого жителя Поднебесной всего за 3 секунды.

Еще один китайский проект запустила компания LLVision Technology Co. Она выпустила смарт-очки для полицейских, также оборудованные системой распознавания лиц. Правда, этому гаджету требуется около 3 минут, чтобы выяснить имя и адрес человека. Тем не менее проект уже показал свою перспективность. Полицейские, использовавшие очки во время дежурств на железнодорожном вокзале города Чжэнчжоу, сумели за короткий срок арестовать 7 человек, подозреваемых в нападениях и похищении людей. Еще 26 нарушителей были задержаны за менее серьезные преступления. 

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

Умные технологии продолжают развиваться

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

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

По определению, данному компанией Goldman Sachs, ключевые особенности интернета вещей, которые отличают его от обычного интернета и М2М, описываются аббревиатурой SENSE: 

• Sensing (чувствующий) — большая часть информации, которая передается через интернет вещей, поступает от датчиков и сенсоров либо генерируется самими девайсами, а не человеком;
• Efficient (рациональный) — интернет вещей использует умные алгоритмы для достижения максимальной эффективности и продуктивности в работе всех устройств;
• Networked (сетевой) — интернет вещей использует сети для «общения» устройств;
• Specialized (специализированный) — в отличие от компьютеров или смартфонов, большинство устройств, задействованных в интернете вещей, узко специализированы и созданы для конкретной сферы: энергетики, здравоохранения, нефтедобычи;
• Everywhere (повсеместный) — устройства интернета вещей можно встретить буквально везде: в домах, офисах, в городской среде. А некоторые девайсы даже сопровождают человека, куда бы он ни направлялся.

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

За чем дело стало?

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

Причина 1. Мы не можем договориться

Чтобы связать тысячи и миллионы устройств, окружающие нас, требуется выработать единые стандарты и протоколы связи, по которым они будут обмениваться данными. На сегодняшний день таких стандартов нет, хотя работа над ними ведется. Крупнейшие компании рынка — General Electric, Intel, IBM, AT&T и Cisco — объединили усилия и создали Консорциум индустриального интернета (IIC). С 2014 года в консорциум вошли сотни компаний по всему миру: Boeing, Hitachi, Microsoft, Huawei, Bosch, Mitsubishi, Nokia, Siemens и многие другие. В задачи этой организации входит в том числе выработка единых протоколов интернета вещей, но эта работа все еще очень далека от завершения. Производители устройств, создавая новые гаджеты для наших домов и офисов, вынуждены изобретать собственные протоколы и интерфейсы, что затрудняет взаимодействие между электроникой разных компаний. 

Причина 2. Безопасно ли это?

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

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

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

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

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

Но если смотреть в будущее с оптимизмом, можно представить, как совсем скоро мы откроем дверь своего дома и скажем: «Привет, дом! Сделай мне чай и набери ванну». И услышим в ответ: «Добрый вечер! Все будет готово через минуту».

GeekBrains продолжает рассказывать о методологиях разработки программного обеспечения. Если вы еще не читали предыдущие тексты о методологиях «Водопад», Scrum и XP, бережливой разработке и Kanban — самое время наверстать упущенное!

Сегодня мы рассмотрим методологию, которую успешно применяет один из самых мощных IT-гигантов — компания Microsoft. Это Microsoft Solutions Framework, или MSF. С ее помощью создано большинство современных решений и проектов «Майкрософт». 

Ты помнишь, как все начиналось

История создания MSF берет начало в 1993 году. Компания Microsoft уже была ведущей в IT-сфере и искала способы повысить эффективность и отдачу от своих проектов.

90-е годы стали временем расцвета новых подходов к разработке. Модель «Водопад», которую использовали больше двух десятилетий, уже в полной мере не отвечала требованиям в IT: была слишком жесткой и формализованной, медленно реагировала на новые потребности пользователей.

У Microsoft был обширный опыт в создании программных продуктов и продвижении масштабных IT-проектов: были уже выпущены Windows 3.11, Office 3.0 и многое другое. Компания суммировала накопленные знания и навыки, проанализировала опыт конкурентов и в 1993 году выпустила серию руководств, посвященных организации труда разработчиков — «белые книги» MSF. 

Пять лет спустя, в 1998, была выпущена вторая ревизия MSF. В 2001 за ней последовала третья, а в 2005 вышла последняя на данный момент версия — MSF 4.0.

Отличительными чертами Microsoft Solutions Framework стали гибкость и масштабируемость. Эта методология подходит для работы в проектной группе или организации любого масштаба. MSF включает основополагающие принципы, модели и дисциплины управления персоналом, процессами и технологиями. Другим преимуществом методологии стала ее демократичность и отсутствие иерархических отношений «начальник — подчиненный». 

Основополагающие принципы MSF

Принципов, на которых базируется MSF, всего восемь. 

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

Работайте над общим видением
Данный принцип Microsoft Solutions Framework подразумевает, что все члены команды должны детально понимать цели и задачи, над которыми работает коллектив. Общий взгляд на то, каким должен быть результат, гарантирует, что усилия разработчиков будут согласованными.

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

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

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

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

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

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

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

Будьте готовы к переменам и оставайтесь гибкими
Любая разработка программного обеспечения требует времени. Это означает, что на каком-то этапе работы требования заказчика могут измениться — к этому стоит быть готовыми.

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

Инвестируйте в качество
Успех команды зависит от того, насколько каждый специалист осознает свою ответственность за продукт. Чтобы обеспечить высокое качество решения, на протяжении всего проекта работает группа тестирования — в ее задачи входит раннее выявление ошибок и недочетов. Обнаруженные баги надо исправлять как можно скорее, чтобы они не повлияли на разработку. Microsoft Solution Framework требует, чтобы в планы и графики изначально вносилось время на устранение недостатков. Только в этом случае можно уложиться в срок.

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

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

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

Пять «белых книг» MSF

MSF разработана как комплекс отдельных компонентов — моделей и дисциплин. Всего их пять, и они описаны в пяти «белых книгах» (white papers) MSF. 

Моделей используется две:

• модель команды;
• модель процесса.

А дисциплин в MSF три:

• управление проектами;
• управление рисками;
• управление готовностью.

Рассмотрим их.

Модель команды MSF

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

Пример традиционной иерархической организации труда

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

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



Модель команды в MSF

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

Примеряем роли

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

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

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

Разработчик
Кажется, что роль разработчика — самая незатейливая. Рабочая лошадка: создает код и воплощает идеи клиента, трансформированные в техническое задание усилиями бизнес-аналитика и архитектора. И придерживается сроков, установленных проект-менеджером. 

Но в MSF разработчик — полноправный участник всех обсуждений. Он определяет, какое время потребуется ему для создания функциональных блоков программы. Помогает архитектору выстраивать удачную структуру проекта с точки зрения его реализации, основываясь на своем глубоком знании языка программирования. Участвует в создании дизайна приложения. В проекте считается экспертом по всем техническим вопросам, и за ним зачастую остается последнее слово в совещаниях о том, «как все это реализовать в рамках используемых технологий». 

Тестировщик
Задача тестировщика — выявить в продукте баги, проблемы и неудачные решения, которые могут негативно сказаться на качестве и снизить ценность приложения для клиента. Тестировщик обязан понимать и учитывать контекст применения программного продукта: кто, как и для чего будет его использовать на стороне заказчика. Если функция X выполняется корректно и выдает правильный результат, но его получение занимает в среднем час, тестировщик может признать ее работу неудовлетворительной — зная, что клиенту требуется выполнять эту функцию 20–30 раз в день. 

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

Релиз-менеджер
В Microsoft Solutions Framework, что касается выпуска готового продукта или любой его работоспособной версии, — на релиз-менеджере. Он создает план выпуска версий, сертифицирует готовый продукт и следит за тем, чтобы программа дошла до клиента. Кроме того, в его обязанности входит информационное сопровождение версий, например описание новых функций, изменений и нововведений. 

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

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

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

Методология MSF подчеркивает, что все роли — равноправны, и ни один член команды не может считаться более влиятельным или принимать решения единолично.

Модель процесса MSF

Еще один важный компонент методологии MSF — модель процесса, то есть последовательность действий, необходимых для построения IT-решения. Модель не предписывает конкретных процедур и не содержит жестких формализованных требований к процессу — при создании MSF компания Microsoft стремилась сделать ее гибкой и адаптируемой к условиям любого проекта. В MSF объединились две концепции разработки: «Водопад» и спиральная модель. 

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

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

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

Весь процесс разработки в MSF разбит на отдельные итерации. Каждая проходит несколько этапов (фаз).



Модель процесса MSF

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

2. Планирование (Planning)
Задачи, которые необходимо выполнить в ходе итерации, разбиваются на подзадачи, определяется сложность их реализации, устанавливаются сроки и назначаются ответственные. В планы закладывается время на тестирование и исправление дефектов, а также предварительно намечается, как именно будет проходить тестирование.

3. Разработка (Developing)
На данном этапе MSF создается программный код новой функциональности в соответствии с концепцией и утвержденными планами.

4. Стабилизация (Stabilizing)
К делу подключаются тестировщики. После тестирования выявленные баги и недочеты возвращаются разработчикам для исправления. 

5. Внедрение (Deploying)
Очередной релиз программного продукта передается заказчику и устанавливается на клиентских компьютерах. 

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

Дисциплины MSF

Управление проектом

В MSF это целый набор навыков и компетенций, в том числе:

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

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

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

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

Управления рисками

Риски — это факторы и события, которые могут оказать негативное влияние на проект в перспективе. В MSF есть специальный процесс, который помогает выявлять, отслеживать и минимизировать риски. Он состоит из шести шагов.



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

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

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

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

4. Отслеживание и отчет
Придерживаться принятого плана неукоснительно — половина дела в MSF. Любое изменение в проекте может повлечь новые риски или рецидив старых. Отслеживание рисков помогает держать их под контролем и своевременно пересматривать тактику борьбы с ними.

5. Контроль
Контроль — это исполнение планов в отношении рисков и связанных с ними отчетов. 

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

Управления готовностью

Эта дисциплина занимается вопросами профессионального роста и подготовки специалистов.

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

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

Процесс управления готовностью включает четыре этапа:

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

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

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

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

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

В заключение

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

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

Методология не требует применять специализированные средства компании Microsoft. Существуют системы, «заточенные» под MSF, например Visual Studio Team System — и Microsoft прямо призывает организации, использующие ее, следовать MSF. Но ничто не мешает применять MSF с любыми другими средствами организации производства.

Microsoft Solutions Framework используется уже более четверти века, помогая компании Microsoft разрабатывать новые решения и развиваться. И это аргумент в пользу методологии.

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

Степан Ермилов, руководитель мобильной разработки IT-компании MediaSoft

Не зависать на фрилансе

— Карьерный рост в IT невозможен без профессионального, поэтому первый совет — не зависать надолго в «одиночном полете», работать вместе с более опытными коллегами. После института я некоторое время программировал на фрилансе: до всего приходилось доходить самому, чувствовалась нехватка знаний по ряду направлений. Через год я пошел в компанию, где было много разработчиков высокого уровня. Один из них стал моим наставником — привет, Лев, если ты это читаешь! Он дал мне просто море информации о том, как должен работать программист. Потом я решил перейти в мобильную разработку, начал с нуля осваивать Android и ушел в проект, где целых 5 лет работал «соло». В конце концов почувствовал, что без живого общения с коллегами по Android почти не развиваюсь. Снова пошел в большую команду, где вскоре начал решать задачи более высокого уровня. В общей сложности путь от начинающего разработчика до тимлида занял у меня 7 или 8 лет. Но если бы не было «сольных» периодов, это произошло бы намного быстрее.

Быть самостоятельным

— Важно быть целеустремленным, не бояться вызовов и ответственности. Невозможно добиться повышения, если 100 % времени заниматься рутинными делами и выполнять чужие указания. Если хочется вырасти в должности и зарплате, нужно брать на себя более сложные задания и самостоятельно принимать решения. А еще — заслуживать авторитет в команде, делая что-то полезное для коллег.

Адекватно оценивать себя

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

Денис Восквицов, руководитель отдела R&D EXANTE

Брать на себя ответственность или получать уникальную экспертизу

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

Прокачивать не только hard skills, но и soft skills

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

Находить время на саморазвитие

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

Роман Грязнов, Team Lead в Accenture Russia

Be on the Edge

— Будьте в курсе последних тенденций в IT. Следите за рынком труда. Старайтесь освоить технологии, которые будут актуальными и востребованными. Пройдитесь по списку требований к молодым кандидатам и составьте перечень общих скилов, которые требуются. Постарайтесь изучить их на практике или в теории, чтобы вопрос «Что такое GIT или SVN?» не вводил вас в ступор.

Взаимодействуйте с коллегами

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

Ренат Сарымсаков, руководитель мобильных продуктов FL.ru

Попробуйте себя в стартапах

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

Наращивайте социальный капитал

— Я имею в виду нетворкинг, создание open source проектов. Например, мы сделали в Zvooq один из первых фреймворков для реализации MVP, вокруг которого образовалось сообщество.

Миронов Илья, performance-инженер в REG.RU

Проявляйте инициативу грамотно

— От джуниора до нынешней должности я шел около 5 лет. Расти помогает желание максимально разобраться в своей предметной области, плюс инициативы по улучшению технологий и рабочего процесса. И это должно видеть руководство. Важно не только продуктивно работать, но и уметь адекватно демонстрировать итоги выполненных задач. Адекватная демонстрация — это качественное демо, описание объема проделанной работы, описание профита, который принесет новая функциональность или улучшенная старая. Я начал с доработки нашего баг-трекера, потом занялся фичами для тикет-системы параллельно с системой статистики по тикетам (заявкам от клиентов). Сейчас решаю задачи по скорости и надежности наших сервисов.

Сергей Смирнов,  ведущий разработчик информационных систем компании «Нетрика»

Кайфуйте

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

А на какой ступеньке карьерной лестницы находитесь вы?

На вопросы отвечает декан факультета iOS-разработки Андрей Антропов.

— Андрей, приветствую! Сколько вы уже в iOS-разработке?

— Здравствуйте. В iOS-разработке я три года. Перешел из бэкенд-сферы и до сих пор не жалею: получаю сплошное удовольствие от связки Swift-iOS. Успел поработать и фрилансером, и в команде. Сейчас разрабатываю приложения в замечательной студии Morizo-Digital.

— Чем вас привлекла сфера iOS? И какие она предлагает пути развития? Особенно интересны самые перспективные, на ваш взгляд, направления iOS-разработки.

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

Основной путь развития очевиден — создание мобильных приложений для iPhone и iPad. Но в последнее время открываются и другие возможности.

• Разработка приложений для умных часов (watchOS), которые все плотнее входят в нашу жизнь.
• Серверная Swift-разработка. Еще пару лет назад она была причудой энтузиастов, а сейчас вовлекает все больше людей. Я говорю не только о фреймворках Vapor, Kitura, но и о системной библиотеке SwiftNIO от Apple, которая позволяет использовать вышеперечисленные библиотеки в серверных решениях. Появление SwiftNIO показывает, что Apple заинтересована развивать серверное Linux-направление.
• MacOS-разработка. Она все ближе и доступнее с выходом Marzipan — фреймворка, который позволит создавать macOS-приложения при помощи основной iOS-библиотеки UIKit. Знания, полученные при изучении iOS, становятся еще универсальнее.
• Всеми любимая разработка игр. Их можно создавать не только при помощи Unity (привет факультету разработки игр), но и посредством встроенных системных инструментов SpriteKit и SceneKit.
• Многое другое. Что говорить, если уже сейчас можно запускать Swift на Raspberry Pi и создавать умные устройства, управляемые с телефона.

Конкретно в iOS-разработке наибольший ажиотаж за последний год — вокруг приложений, использующих машинное обучение (ML) и дополненную реальность (AR).

Для обеих этих сфер Apple создала очень удобные системные библиотеки MLKit и ARKit соответственно. Они позволяют интегрировать последние достижения ML и AR при помощи нескольких строк кода.

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

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

— Swift очень вырос, окреп за последние годы и де-факто стал основным языком iOS-разработки. Думаю, не сильно ошибусь, если скажу, что 95 % новых iOS-приложений создаются на Swift. Кроме того, как я уже сказал, продолжается экспансия языка Swift на платформу Linux.

Реализованный в 2014 году Swift 4.2 LSP (Language Server Protocol) позволяет удобно работать с языком не только в заточенной под macOS среде Xcode, но и в других IDE, которые можно запускать и на Linux. Например, в Visual Studio Code. Количество системных приложений, которые Apple переписали с Objective-C на Swift, в iOS версий 10, 11 и 12 растет экспоненциально.

— Чтобы начать писать для iOS, нужно иметь Apple-устройство под рукой. Каков минимальный набор начинающего разработчика? Я слышала, надо еще платить какие-то отчисления...

— К сожалению, входной барьер в iOS-разработку высок, но это связано со стоимостью оборудования. Для начала вам потребуется MacBook, желательно не очень древней модели. На него вы установите среду разработки Xcode, после чего сможете начать писать первую программу. Больше на старте ничего платить не придется: достаточно бесплатного сертификата, привязанного к вашему Apple ID.

А вот чтобы загрузить свое приложение в магазин, понадобится оплатить distribution-лицензию. Она стоит 99 $ в год, но обычно эти деньги вносит не разработчик, а заказчик приложения.

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

— iOS-разработка — это не только Swift, но и Objective-C. Для каких задач предпочтительнее каждый из этих языков? И зачем студенты факультета еще учат основы C?

— Надо понимать, что Objective-C долгие годы был единственным языком разработки для macOS и iOS. За это время программисты написали на нем множество библиотек и модулей, которые до сих пор повсеместно используются, и заменить их в один миг нельзя. Да и, скорее всего, не нужно. Так что Swift и Obj-C — это спайка двух родственных технологий.

Да, сейчас Swift вышел на уровень, когда вы можете писать приложения, не зная Obj-C. О существовании последнего вы можете даже не подозревать. Но для полного понимания системных процессов знание Obj-C очень полезно. А ведь мы хотим, чтобы подход студентов к разработке был глубоким.

Кроме того, спрос на программистов Obj-C до сих пор высок. Особенно в компаниях с богатой историей разработки и массой так называемого legacy-кода, который нужно поддерживать и оптимизировать.

Если мы копнем еще глубже, то увидим, что некоторые iOS-проекты требуют библиотек на C/C++. В отдельных случаях это позволяет достичь большого прироста производительности. Чтобы не ходить далеко за примером: на C/C++ реализована популярная библиотека Realm для хранения данных в мобильных приложениях.

Поэтому мы считаем, что знание основ языка С (например, указателей и memory layout) сегодня пригодится любому разработчику.

— Главный вопрос, который я задаю всем деканам: какие проекты делают ваши студенты?

— Приложения для работы с VK, для интернет-магазина и системы поиска билетов. Полученного в итоге опыта оказывается достаточно для трудоустройства. Многие наши выпускники работают в крупных компаниях, таких как Сбербанк, «Мамба», «Везёт».

— Что можно рассказать о факультативах от партнеров?

— Факультативы — это видеоуроки и вебинары от экспертов, которые обучают студентов продвинутым технологиям. Например, в прошлом году мы записали факультатив по Core Data от «Тинькофф Банка». Сейчас записываем факультатив по архитектурам приложений со старшим разработчиком браузера Mail.ru Group. Также готовим факультатив «Реактивное программирование» от AGIMA.

— Вы начали писать для iOS, уже имея опыт в Python. Был ли этот переход легким и насколько отличается процесс изучения этих языков?

— Кривая обучения у обоих языков довольно пологая — они очень дружелюбны к новичкам. Это здорово, ведь программирование должно привлекать, а не отталкивать. Безусловно, если вы знаете один из популярных языков, будь то С/C++, Java, Python, Go или Ruby — освоить Swift вам гораздо легче, чем тому, что учит его с нуля. Все перечисленные языки реализуют объектно-ориентированный подход, а значит у них много общего.

— В обращении к студентам вы упомянули о сходстве Swift и Python в плане интуитивной семантики. А было что-то, что поначалу удивило в Swift?

— Меня очень удивила легкость, с которой в Swift мы можем отойти от ООП-парадигмы в сторону функциональной.

Как и многим техническим специалистам, в университете нам преподавали Lisp и Prolog. С тех пор к функциональному программированию я относился очень настороженно и поначалу сторонился функционального подхода в Swift. Но со временем понял, что FP на Swift и Lisp — это земля и небо, а работа с математическими вычислениями и функциями может быть лаконичной, логичной и приятной.

— Ваша основная работа в Morizo-Digital тоже связана с iOS-разработкой?

— Да. В нашей студии я отвечаю за iOS-разработку. Но уточню: 14 лет мы создавали в основном сайты и бэк. Мобильными приложениями занимаемся совсем недавно. У меня сейчас на попечении два проекта, которые готовятся к релизу. До окончания разработки я не могу раскрывать подробности.

— По вашему опыту, какие темы в Swift для студентов — самые трудные?

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

Если вам интересно, о чем я, можете посмотреть на opaque result types, которые появятся в Swift 5.1. Увидите, какие проблемы они решат.

— Какие материалы вы рекомендуете ученикам в дополнение к занятиям и методичкам?

— Я советую черпать знания изо всех проверенных источников. Условно их можно разделить на три типа:

1. Блоги, статьи, подкасты.

• Обновленный блог Мэтта — автора популярнейших библиотек AFNetworking/Alamofire. Здесь можно почитать думы опытного программиста об iOS-делах насущных. Сложность материала: высокая.
• Блог Джона Санделла — большого iOS-энтузиаста и участника всех возможных конференций. Он написал больше 100 статей о самых разных аспектах разработки и жизни программиста. Сложность материала: умеренная.
• Шон Аллен — программист, который интересен искренностью и открытостью, с которой он рассказывает сообществу о своей работе. По понедельникам он делится с аудиторией новостями Swift.
• Flawless App Stories — блог на Medium с подборкой статей по актуальным проблемам разработки от разных авторов. Замечателен тем, что позволяет взглянуть на процесс глазами сотен людей. Сложность материалов: очень разная.
• Антуан Ван дер Ли — голландец, который в своем блоге сочетает множество тем: от разбора основ программирования до проблем выгорания и личности программиста.
• iOS Dev Weekly — подборка самых актуальных новостей мира Swift. Уже несколько лет выходит каждую пятницу.
• iOS Goodies — еще одна подборка новостей и обучающих статей, только выходит по вторникам.

2. Обучающие сайты.

• RayWendelich — сайт №1 с обучающими материалами по iOS. Здесь много статей, видеоуроков и абсолютно замечательных книг, но в основном, конечно, платных.
• ObjC.io — аналог предыдущего сайта, но с более глубокой академической подачей материала. Это для философов от Swift.
• HackingWithSwift — сайт Ивана Урганта от Swift, Пола Хадсона (Paul Hudson) — мастера презентаций, Adobe After Effects и заготовленных шуток-каламбуров. В отличие от первых двух сайтов, здесь полно бесплатных статей и видео. Есть даже бесплатная обучающая программа.
• Pointfree.co — мой любимый сайт, где двое дядек рассуждают о функциональном подходе в Swift. Их увлеченные лица как бы намекают, что они с удовольствием дискутировали бы и бесплатно. Но, к сожалению, для просмотра большинства видео нужна платная подписка.

3. Конференции разработчиков (записи выступлений, скорее всего, доступны на YouTube).

Русскоязычные:

• Mobius;
• CocoaHeads Russia;
• Стачка.

Англоязычные:

• try! Swift (New York/Tokyo);
• dot.Swift;
• iOSCon London;
• iOS Conf Singapore;
• NSSpain;
• Swift And Fika;
• AppBuilders.

И конечно, главное событие года для каждого iOS-программиста — конференция WWDC от Apple.

— Спасибо! Андрей, будем ждать вопросов от желающих изучать Swift и iOS-разработку. :)

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

Мы запускаем цикл статей в которых подробно расскажем о каждой профессии через опыт людей. В первом выпуске обсуждаем Python-разработчиков. Свои истории рассказали Артем Сухаренко и Данила Лобанов. Они пришли в профессию совсем недавно, но успели набраться опыта в других сферах. А экспертом выступил Алексей Петренко — декан факультета Python в Geekbrains.

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

Для чего учить Python

Артем Сухаренко учился в СибГИУ на кафедре автоматики и информатики. Его специальность была инженерной, но не связанной с программированием. После выпуска Артем устроился работать на завод ЗСМК — один из самых крупных металлургических комбинатов в России

«Я обалдел, насколько там все ужасно», — говорит он, — «Полуразвалившийся советский электропривод, никакой модернизации, специалисты особо не нужны». Долго на заводе он не задержался, но продолжил работать с электрикой дальше. Вырос до ведущего инженера в Сибирьтелекоме, затем переехал из Сибири в Москву и устроился в коммерческий ЦОД, где отвечал за инфраструктуру.

Программирование иногда подразумевалось. Артем пытался работать с микроконтроллерами, делать что-то более сложное, но всегда упирался в отказы работодателей и заказчиков — им это было не нужно. Хватало элементарных вещей, которыми, как говорит Артем, интересно заниматься только первые 15 минут, и особых скиллов для этого не нужно.

«Может быть, я не туда совался, но развития для себя не нашел. Пять лет вуза — просто чтобы крутить провода. Это было так обидно».

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

В 36 лет Артем пошел на курсы Python-разработчика.

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

«Зная Пайтон можно делать много всего — от простейших скриптов до анализа данных и построения нейронных сетей. Но конкретно разработка на Пайтон — это бэкенд для веб-серверов, разработка скрытой части интернета — той, которую не видят обычные пользователи. Сервер, его логику, взаимодействие с базами данных», говорит Алексей Петренко, декан факультета Python в Geekbrains.

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

«Хоть Python и пропагандируется как язык для всего, по факту у него только две сферы применения: всякие data science, ML и прочая математика — и веб-разработка. В этом он меня немного разочаровал», — говорит Данила Лобанов, бывший сисадмин, который недавно стал Python-разработчиком.

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

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

«Я попытался изучать С, PHP, Java еще какие-то языки, но не заходило — начинал и бросал. Не мог писать даже простейшие скрипты. Когда я ходил на курсы по С, у меня получалось читать код, но не получалось его писать. Мне давали задачу, я смотрел на нее и не представлял, как делать. Преподаватель садился рядом, писал построчно, объяснял, и я понимал, что именно так и надо было делать. Но мне давали аналогичную задачу, и я снова был в ступоре».

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

«Новичку лучше первым делом разобраться в синтаксисе», — считает Алексей Петренко, — «Только потом стоит думать, куда хочется идти дальше. Чем больше ты учишься, тем больше уходишь от синтаксиса к библиотекам, паттернам проектирования, отдельным шаблонам».

Данила все-таки выбрал Python потому, что язык считался легким. «Синтаксис реально оказался простым», — говорит он, — «Как писать текст на английском языке. Сначала я изучал его самостоятельно по видеоматериалам на Ютубе, по статьям, решал задачи на pythontutor.ru. Но потом понял, что ресурсы в интернете — это только основы и азы. Они доступны всем и везде, и не помогут научиться программированию основательно. Я понял, что надо искать курсы, которые дадут все то же самое, только систематизировано, а потом поведут меня дальше».

Что надо знать перед началом обучения

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

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

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

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

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

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

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

«Все признавали, в том числе сотрудники Geekbrains, что уровни 2 и 3 в программе по Python были одними из самых сложных курсов в университете. Очень много информации в слишком сжатые сроки, очень большие домашние задания. Многие усваивали только часть материала. Я лично два раза переводился в следующий поток. Мы просили облегчить программу, нас спрашивали как, и я предлагал разбить два курса на три. Что-то из этого приняли во внимание и сейчас реализовали».

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

«Преподавать программирование тоже очень сложно. Всем кажется, что раз человек может писать программы, значит может и научить. Это не так. Когда мышление перестроено, и знаешь много всего — уже не можешь вспомнить, каково это — не понимать».

Алексей предупреждает, что Python легкий только в начале. А после легкой базы придется приложить усилия, чтобы освоить более серьезные аспекты — библиотеки и фреймворки. «Если сравнить язык программирования с водоемом, то, например, язык С — это океан. Ты ныряешь с обрыва на огромную глубину, и либо плывешь, либо тонешь. Язык Пайтон — это пляж с чистым песком, где ты можешь далеко зайти, спокойно поплавать, и если понял, что хочешь двигаться дальше — то за красивым пляжем есть огромная впадина, по глубине сопоставимая с С и Java».

«Асинхронное программирование в Python — это мозгодробительная штука», вспоминает Артем. «Мы проходили это как-то поверхностно, и потом даже на собеседованиях, когда по нему спрашивали, я чувствовал, что плыл.

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

Данила же вспоминает модуль select как самое трудное: «Все три потока помнят мою боль с селектами. Есть такой модуль, и он мне прямо очень не давался в свое время. Сейчас-то он для меня простой — я теперь не понимаю, как его можно не понять».

«В базовой конфигурации Python лежит около 70 функций и несколько десятков зарезервированных слов, но даже крутой программист не обязательно использует их все. То есть, чтобы выучить сотню слов и понять, что они делают, можно потратить одну-три недели при желании и активной работе», говорит Алексей.

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

Чтобы в будущем работать в команде и показывать код кому-то еще, надо знать общепринятые стандарты стиля. В Python они называются «Пепы» (Peps). Я бы советовал читать Pep8 параллельно с изучением синтаксиса. Это соглашение программистов, которые пишут на Пайтоне. Оно рекомендует как правильно писать, а как неправильно.

Несколько лет назад в Python произошло разделение. Был Python 2.7, а потом вышла версия 3. Вторая версия все еще используется, но только в старых фирмах для поддержания легаси-кода. Если устроиться в такую фирму, то изучать Python 2 придется, но я бы рекомендовал учить третью версию. Все современные проекты и сторонние библиотеки пишутся под нее».

Как выдержать первые собеседования

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

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

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

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

«Мой опыт в Geekbrains показывает, что некоторые студенты находят работу, до того как они заканчивают годовой курс обучения», говорит Алексей. «Работодатель хочет видеть у серверного разработчика элементарное умение работать с синтаксисом, знание как работают сайты, как устроен бэкенд, тот же самый набирающий популярность Django. Я бы сюда ещё добавил работу в команде и знания баз данных, потому что любой бэкенд любого сайта неразрывно связан с хранением информации.

Ежемесячно на «Моём круге» открывается порядка 200 вакансий python-разработчиков, вы можете посмотреть самые свежие и подписаться на рассылку о новых вакансиях.

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

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

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

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

«Я считаю, не спрашивать технические вещи — это правильный подход», говорит Данила. «Очень известный в Python-сообществе Григорий Петров тоже говорит, что скилы по программированию (хард скилы) подтянуть всегда можно. Главное сойтись во взглядах на жизнь, чтобы было комфортно вместе работать. Я с ним согласен.

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

«Собеседование, которое проходил я, расплавило мне мозг еще как», вспоминает Артем. «Когда я вышел, состояние было, как будто иду на автопилоте — так сильно продолжали жужжать мысли».

Проходило оно так: сидели два эйчара и два технаря. Один питонист и фулстек, который занимался вебом — куда пробовался и я. Второй — судя по вопросам —  совершенный надмозг. У него такой был сильный матан, что просто ого-го!

Сначала пошли житейские вопросы, все эти «как себя видишь, как себя чувствуешь». Потом за меня принялся фулстек, погонял меня по Python, по Django. Он прямо на бумаге накидывал примеры и спрашивал по ним. Не сложные, но с подковырками.

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

Честно, даже не ожидал, что мне перезвонят. Тем не менее — получил оффер. Через несколько дней будет первый рабочий день».

На какие деньги стоит рассчитывать

Люди идут в ИТ не только по зову души. Это индустрия с одними из самых быстро растущих зарплат в России. И иногда кажется, что зарплаты программистов по сравнению со среднестатистическими профессиями отличаются как зарплаты в Москве и в регионах. Тем не менее, ни Артем, ни Данила не шли в эту профессию за богатством. Больше того — они его пока так и не нашли.

«Даже в Москве на начальных позициях программистам предлагают 40-50 тысяч, может даже меньше. В регионах 20 тысяч для джуниора тоже не редкость. Это не такая уж высокооплачиваемая работа, как все утверждают. Да, когда достигаешь уровня синьора, зарплаты могут переваливать за 200-300 тысяч. Но где таких зарплат нет? Недавно одна такси-компания показала доходы таксистов, которые больше всех заработали. Там 230, 240 тысяч.

На диаграмме зарплат python-разработчиков с разбивкой по квалификациям видно, что медиана для джуна составляет почти 60 000 рублей, тогда как мидл получает уже в среднем чуть больше 100 000 рублей. Зато разница между показателями медиан для сеньора и лида совсем небольшая — 151 000 рублей и 167 000 рублей соответственно.
При построении диаграммы были использованы данные зарплатного калькулятора «Моего круга».

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

«Зарплаты зависят от региона», говорит Алексей, «Кто-то устроится за 40 тысяч как начинающий, кто-то может и сразу на 100 тысяч. Смотря как себя проявить. Если покажешь, что можешь писать не только код, но и разбираешься в архитектуре, можешь набросать схему проекта целиком, всех модулей, сервисов, связей между ними».

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

Несмотря на то, что в программировании одна из самых четких и понятных градаций по уровню мастерства (джуниор, мидл, синьор) — она все равно остается относительной и постоянно разжигает споры размытостью своих критериев. Споры в духе «ты в компании Х синьор, а в компании Y и джуниором не возьмут» или «пока десять лет не работал — не синьор».

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

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

Без фейлов в IT никак. Конечно, немногие готовы открыто рассказать о своих ошибках, а часто это еще и запрещает NDA. Но случай, из-за которого и стыдно и смешно, есть у каждого. Вот несколько таких историй.

Бесконечный баг

Данил Юсупов, инженер-программист компании ICL Services:

— Сломался у нас однажды деплой на тестовую среду. При этом CI-билды благополучно собирались, и мы считали, что наш сервис успешно деплоится.

В итоге бедная тестировщица всю неделю тестила один и тот же баг, а мы все это время думали, что заливали свежую версию сервиса.

Компьютер все время побеждает

Stoo, разработчик:

— Я написал карточную игру (Pontoon, «21», блек-джек — называйте как угодно) для проекта в выпускном классе. Надо было показать экзаменатору, как работает программа. Но за несколько минут до презентации игры я заметил, что компьютер все время побеждает… даже когда не нужно.

И тут я осознал, что компьютерному игроку достались «руки» обоих соперников (причина — копипаста без изменения имен переменных), поэтому он такой крутой и всегда выигрывает. (источник: sharkyforums.com)

Отключение дата-центра

Игорь Наметчинюк, full-stack разработчик:

— Один раз коллега выключил половину дата-центра, потому что выдернул не ту вилку из розетки. Не спрашивайте, что за дата-центр. Благо его уже нет.

Коварство овощей

Андрей Попов, системный администратор:

— Звонит пользователь: не включается компьютер, хотя все везде подключено. Я отправляюсь наверх и вижу — действительно не работает. Минут 15 суетился. Потом все-таки додумался перепроверить шнур питания. Следую по кабелю...

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

Я кодил в поте лица

Анонимный разработчик:

— Во время моего первого технического интервью меня спросили: «Знаете про задачу FizzBuzz?» Я честно признался, что нет. Подумал, что это какая-то алгоритмическая задача. Тогда интервьюер объяснил: «Надо вывести числа от 1 до 100. Если число делится на 3 — выведите Fizz, если на 5 — Buzz, если и на 3, и на 5, — FizzBuzz. Другие числа просто выведите без изменений».

Как только я это услышал, в моем беспокойном сознании появилась куча идей. Я немного подумал и сказал: «Если сумма цифр числа кратна 3, то число кратно 3, если последняя цифра 0 или 5, то число кратно 5». Я начал кодить свое решение, а интервьюер говорит: «Есть решение попроще. Что думаете об этом?»

Я взволновался еще сильнее. Немного подумал и выпалил: «Начинаем с 3. Счетчик учитывает, сколько итераций было после этого. Через каждые три итерации число точно кратно 3. Можно попробовать это решение?» Интервьюер: «Конечно».

Я кодил в поте лица минуты 3 и потом осознал, что это решение внедрить еще сложнее. Интервьюер заметил мою борьбу и решил вмешаться: «Вы когда-нибудь слышали о делении с остатком?»

В полном смущении я написал код за 30 секунд. Конечно, после этого не было никаких вопросов. Только немой укор самому себе и потребность переоценить свой интеллект. (источник: quora.com)

Ирония судьбы или неделя восстановления данных

Анна Пашаян, разработчик:

— Была в базе данных процессинга таблица, которая называлась «платежи2», и все удивлялись, почему такое тупое название. А его история такая: была таблица «платежи», и там хранились все проводимые процессингом платежи. Это была главная таблица системы, там было очень много важных данных. И вот один разработчик, имея доступ на продовую базу, случайно перепутал ее с тестовой БД. Хотел поменять ее структуру — зашел и удалил эту таблицу. Ирония судьбы — не было ее свежего бэкапа. В итоге вся команда неделю восстанавливала данные таблицы по логам практически в ручном режиме, благо их оттуда можно было извлечь.

И напоследок легендарная история из техподдержки IBM:

Клиент (К): Вы прислали мне установочный диск, и теперь мой дисковод не работает!
Оператор техподдержки (О): Дисковод не работает?

К: Именно! Вы прислали мне плохой диск! Он застрял, и теперь ничего не работает!

О: Он не установился должным образом? Какие сообщения об ошибках вы получали?

К: Ничего я не получал! Диск застрял, и я попробовал достать его с помощью плоскогубцев, но это тоже не сработало.

О: Извините, повторите, пожалуйста, что вы сделали?

К: Я взял плоскогубцы. Попробовал достать диск. Он не сдвинулся с места. Только пластик хрустнул немного.

О: Я немного не понял, вы нажимали на кнопку Eject, чтобы достать диск?

К: Нет. Потом я взял немного сливочного масла, растопил его и положил в дисковод. После этого плоскогубцы вошли отлично и я достал диск. Не ожидал, что вы пришлете мне брак!

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

К: Именно! Я положил масло в дисковод, чтобы достать ваш чертов диск, а потом воспользовался плоскогубцами!

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

К: (Молчание.)

О: Сэр?
К: Да.

О: Cэр, вы нажимали на кнопку извлечения диска?

К: Нет! Но я подам на вас в суд за то, что вы сломали мне компьютер!

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

К: Хм....

О: Вы действительно надеетесь выиграть суд, учитывая, что каждый разговор с поддержкой записывается?

К: (уже жалобным голосом) Но вы же должны помогать!

О: Простите, сэр. Но сейчас мы ничего не можем сделать для вас. Хорошего дня!

А у вас есть подобные истории? Признавайтесь.

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

Развлечения и соцсети

Spotify (бесплатно)

Музыкальный сервис Apple Music доступен не всем. К счастью, есть десктопное приложение Spotify — идеальная альтернатива для тех, кто ищет варианты за пределами экосистемы Apple. Приложение для Mac предоставляет доступ ко всему каталогу Spotify, как и его мобильный аналог: вы можете бесплатно искать и слушать треки и альбомы любых исполнителей.

Еще в Spotify можно создавать личные плей-листы или слушать персональные рекомендации с самой разной музыкой на ваш вкус.

HandBrake (бесплатно)

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

Parcel (бесплатно)

Немногие до сих пор покупают вещи только в офлайн-магазинах. Сервис Parcel предназначен для поклонников интернет-шопинга — покупателей в постоянном ожидании посылок. Приложение работает с более чем 250 сервисами доставки, включая FedEx, и помогает пользователям отслеживать посылки. Пуш-уведомления и интеграция с Spotlight — в виде бонуса.

Transmission (бесплатно)

Хороших торрент-клиентов не так много, но Transmission входит в число лучших. Приложение не занимает много места, превосходит другие по скорости загрузки и идеально сочетается с macOS. Это не самый мощный клиент, но лучший для операционной системы от Apple с учетом надежности и безопасной загрузки торрентов.

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

VLC (бесплатно)

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

Slack (бесплатно)

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

Tweetbot 3 (749 ₽)

Приложение для опытных пользователей, которые отказываются от устаревшего официального Twitter для macOS в пользу более функционального. В последнем обновлении презентовали работу в нескольких окнах, отключение уведомлений, хештеги и ключевые слова. Tweetbot также поддерживает сторонние приложения вроде Paper и Bitly. Усовершенствованный интерфейс идеально сочетается с последними версиями macOS.

Безопасность и память

1Password (3 $)

Приложение для тех, кому надоело запоминать пароли от всех учетных записей. 1Password — это менеджер паролей, который защищает их в зашифрованном хранилище, доступ к которому тоже по паролю. Базовая подписка стоит 3 $ в месяц, но можно обновиться до аккаунта для группы из пяти человек за 5 $.

Little Snitch 4 (47 $)

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

Больше о приложениях безопасности на macOS

Google Drive (бесплатно)

Скорее всего, вы знакомы с Google Drive. Но можете не знать, что работать с документами, таблицами и презентациями можно в офлайн-режиме, без подключения к интернету. Десктопное приложение Google предоставит быстрый доступ ко всем файлам и папкам. Как и в мобильном приложении, есть специальная папка, в которой можно синхронизировать до 15 Гб файлов — при условии, что вы не платили за дополнительное место на диске. А еще Google Drive может бэкапить все содержимое.

Dropbox (бесплатно)

Приложение для хранения данных, которое быстро и надежно синхронизирует файлы. Версия для macOS работает почти так же, как веб-версия и мобильное приложение: дает доступ к файлам и папкам, а фотографии, видео и документы можно загружать прямо с рабочего стола. В вашем распоряжении 2 ГБ бесплатного хранилища только за регистрацию в системе. Если пригласите друзей или подключитесь к Dropbox в соцсетях, сможете получить больше.

The Unarchiver (бесплатно)

Нативные приложения macOS не всегда умеют распознавать сжатые и заархивированные файлы. Но Unarchiver работает почти со всеми форматами, от RAR до более старых вроде StuffIt, ARC или Tar. Приложение даже не требует от вас его открывать — доступ к файлам можно получить в Finder одним кликом.

Стефан Нильссон преподает информатику в Королевском технологическом институте Стокгольма и очень много пишет о языке Go. Предлагаем вам перевод его статьи Why Go? — Key advantages you may have overlooked, где он рассказывает о главных плюсах языка. Статья ориентирована на читателей, уже знакомых с основами программирования, в том числе на Java и/или Python.

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

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

Go — мой основной язык с 2012 года. До этого, с 1998 года, я использовал Джаву, а еще раньше — Си. Python нужен мне главным образом в преподавательской работе.

Заниматься программированием я начал в далеком 1978 году. Тогда я писал для калькулятора TI-57, с его программной памятью на 50 шагов и 8 регистрами.

Минимализм

Go — минималистичный язык, и это (по большей части) очень хорошо.

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

«Ядро» Go составляют простые ортогональные конструкции, которые можно сочетать сравнительно малым числом способов. Это упрощает изучение языка, чтение и написание кода.

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

Некоторые из ключевых особенностей Go:

• Полноценные встроенные фреймворки для тестирования и профилирования программ компактны и просты в изучении. Скорее всего, вам не понадобится ни один из многочисленных аддонов от сторонних разработчиков.
• Можно отлаживать и профилировать оптимизированный бинарник, который уже запущен в production на HTTP-сервере.
• Документация к языку Go генерируется автоматически и содержит примеры, которые можно запускать прямо на странице справки [для этого под каждым листингом есть кнопка Run — прим. пер.]. Опять же, интерфейсы минималистичны и не требуют долгого изучения.
• Go — язык с сильной статической типизацией и явным приведением типов, но его синтаксис на удивление необременителен. Все благодаря нетипизированным числовым константам и определению типа по присвоенному значению. Как результат, в работе с типами Go безопаснее, чем Java (где есть неявное приведение). При этом его код по легкости чтения ближе к Питону, где есть нетипизированные переменные.
• Программы на языке Go состоят из пакетов, что позволяет понятно делить код и легко управлять зависимостями. Механизм пакетов — пожалуй, в числе наиболее удачно реализованных в языке. И самых недооцененных.
• Структурно типизированные интерфейсы обеспечивают динамический полиморфизм за счет динамической диспетчеризации.
• Конкурентность — неотъемлемая часть Go, для нужд которой в языке есть горутины, каналы и оператор select. Чем конкурентность отличается от параллелизма, можно посмотреть здесь.

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

Задел на будущее

В Go нет ряда возможностей, обычных для других современных языков.

Вот универсальный ответ проектировщиков языка на вопрос «Почему в Go нет такой-то функции?».

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

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

Вот наиболее вероятные кандидаты на добавление в Go 2:

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

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

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

Сравнение с Java

Спецификация языка Java® сейчас насчитывает 750 страниц. Сложность изучения связана в первую очередь с перегруженностью «фишками» [явление известно как feature creep — прим.пер.].

Вот вам несколько примеров. Внутренние классы внезапно появились в Java в 1997 году. На обновление спецификации ушло больше года, и она увеличилась в объеме почти вдвое. Это высокая цена для функции, появление которой было не критично.

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

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

Прозрачность кода

Блок обработки данных суперкомпьютера ILLIAC IV

Если вы не можете читать и понимать свой код, ваш проект обречен.

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

Создатели Go постарались сделать так, чтобы обе эти потребности было легко удовлетворить.

Синтаксис языка создан с расчетом на прозрачность и поддерживает только один стандарт оформления кода, который можно автоматически применить утилитой fmt.

Другой пример: Go не скомпилирует программу, если она требует каких-то пакетов (через import), но в реальности не использует их в коде. Такой подход повышает ясность кода, а в долгосрочной перспективе — его производительность.

Подозреваю, что создатели Go нарочно усложнили некоторые вещи. Например, надо очень постараться, чтобы поймать исключение (панику). Причем, чтобы переступить через типобезопасность, вам придется пометить свой код ключевым словом unsafe.

Сравнение с Python

В Python фрагмент кода del a[i] удаляет элементы с индексом i из списка a. Этот код, конечно, вполне читаем, но не прозрачен: легко упустить из вида, что временная сложность алгоритма представлена как O(n), где n — число элементов списка.

У Go нет такой полезной функции. Это не так удобно, зато более прозрачно. Если вы копируете элемент списка, вам нужно явно указать это в коде. Смотрите пример кода: 2 способа удалить элемент из среза в Go. Но можно и проще — с помощью аppend.

Сравнение с Java

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

• Циклические зависимости могут вести к нежелательным последствиям. В отличие от кода на Java, Go-программа с зацикленной инициализацией не скомпилируется.
• Программа на Go завершает работу только из функции main. Java-приложение закрывается после завершения всех пользовательских потоков, не являющихся демонами.

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

Совместимость

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

Для первой версии Go были кратко и сжато сформулированы гарантии совместимости для языкового «ядра» и стандартных библиотек: программы на Go, которые работают сегодня, должны работать и с будущими версиями Go 1. До сих пор обратная совместимость соблюдается безукоризненно.

Go — это проект с открытым кодом и BSD-подобной лицензией, которая разрешает коммерческое использование, внесение изменений, распространение и личное пользование.

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

Сравнение с Python

Если вы Python-разработчик, вам приходилось мучаться с различиями между Python 2.7.x and Python 3.x. И хотя есть веские основания выбирать Python 3, если вы используете библиотеки, доступные только для 2.7, у вас может не быть выбора.

Сравнение с Java

У языка Java очень хороший опыт обратной совместимости и подробное руководство по совместимости для JDK 8. Плюс, Java долгое время был в свободном доступе для разработчиков.

К сожалению, на горизонте сгущаются тучи. Причиной тому — судебное разбирательство между Oracle America и Google о сущности компьютерного кода, авторском праве и новой модели лицензирования Java от Oracle.

Производительность

Снаружи Go неброский, но под капотом у него — прекрасно отлаженный движок.

Бессмысленно обсуждать производительность вне контекста. Такие параметры программы, как время исполнения и потребление памяти, сильно зависят от алгоритмов, структур данных, входных данных, мастерства программиста, операционной системы и «железа».

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

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

Объем и скорость генерации машинного кода зависят от целевой архитектуры. Генерация кода Go довольно хорошо проработана и поддерживает все основные ОС (Linux, macOS, Windows) и архитектуры (Intel x86/x86-64, ARM64, WebAssembly, ARM и др.). Поэтому от go-приложений можно ждать производительности на уровне C++ или Java. Выигрыш относительно интерпретируемого кода на Python может быть огромным.

В Go есть сборщик мусора, что предотвращает утечки памяти. Причем задержка в работе сборщика минимальна. На деле вы можете даже не замечать, что «поток-мусорщик» запущен.

Практически все стандартные библиотеки исполнены очень качественно: их код оптимизирован по эффективным алгоритмам. К примеру, регулярные выражения в Go работают настолько хорошо, что время исполнения напрямую зависит от объема ввода. К сожалению, с Java и Python все иначе.

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