Рубрика «процесс разработки» - 3

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

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

В итоге, рейтинг мой статьи разделился почти пополам 37 «против» и 39 «за», собрав больше 200 комментариев, что само по себе подтвердило, что тема в тренде.

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

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

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

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

Как мы починили свой процесс и стали меньше отвлекаться - 1Читать полностью »

PVS-Studio & Unreal Engine

Проект Unreal Engine развивается — добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта — появление в коде новых ошибок, которые желательно выявлять как можно раньше. Одним из способов сокращения количества ошибок является использование статического анализатора кода PVS-Studio. Причем анализатор также быстро развивается и учится находить новые паттерны ошибок, некоторые из которых будут рассмотрены в этой статье. Если вас заботит качество кода ваших проектов, то эта статья для вас.
Читать полностью »

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

image

Создавая современные интернет-инструменты для роста прибыли, необходимо максимально глубоко внедриться в сферу интересов заказчика и выведать множество специфической информации. Затем перевербовать заказчика на свою сторону, расколоть его на истинные цели и заполучить доступ к секретнейшему документу любого бизнеса — его бизнес-плану. Сложно, но для настоящих Штирлицев 21 века это возможно, но только при условии соблюдения тактики “Четырех НЕ”. Читать полностью »

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

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

Читать полностью »

Рано или поздно IT-проекты сталкиваются со сложностями поддержания высокого качества кода и/или увеличивающимся временем доставки изменений в production. Lingualeo испытала на себе все проблемы роста и готова поделиться своей историей повышения эффективности разработки. О том, как это происходило, рассказал teamlead инфраструктурой команды Lingualeo Михаил Кабищев.
image

Как и любая другая технологическая компания, Lingualeo проходила через несколько этапов:

  • Начало разработки продукта. Разработка и отладка происходит на одном-единственном сервере, где запущено все, что нужно проекту. Ошибки бывают часто, но это не страшно, т.к. это все лишь прототип, и живых пользователей там еще нет.
  • Появление первых пользователей. Компания начинает ощущать цену ошибок и проблем на продакшене. Уже нельзя править все на продакшене, приходит понимание того, что нужно мыслить релизами. Разработчики внедряют workflow для работы с кодовой базой, появляется что-то вроде stage-сервера, на котором тестируются релизы.
  • Рост проекта и команды. В разработке одновременно находится большое количество задач. Требования к процессу и качеству кода сильно возрастают. За всем очень тяжело следить: кто-то забывает запустить юнит-тесты, кто-то не знает, куда и как нужно задеплоить очередную задачу для тестирования.

В итоге рутинные операции начинают отнимать очень много времени, и компания думает, как автоматизировать эти процессы.
Читать полностью »

image

Под катом интересный опрос

Возможно, заголовок этой статьи покажется Вам не корректным, ”Как можно писать open-source код? И что это за код такой?” — спросите Вы.

Чем open-source код отличается от “просто-кода”? Open-source проект — это ответственность за качество кода, за покрытие его тестами, за документацию, за своевременные ответы на вопросы и реагирование на bug репорты, за обработку pull-request’ов. Ваше поведение и мысли во время написания open-source кода, который увидит мир будут другие, соответственно и код на выходе получается другой.

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

Читать полностью »

image

Я помню то замечательное время, когда сборка релизной версии мобильного приложения сводилась к тому, что нужно было выставить debug = false и запустить экспорт apk-файла. Проходит 2 минуты, пока пыхтит IDE, и все готово. Все усилия сосредотачивались на необходимости указать данные сертификата подписи. Это было совсем недавно. Cейчас процесс сборки того самого приложения разросся настолько, что, если мне, вдруг, потребуется выполнить все операции самостоятельно, и даже если я все вспомню и проделаю безошибочно (во что я не верю), то это займет не час, который сегодня кажется непозволительно долгим, а, скорее всего, сутки, после чего терапевт обязан будет прописать мне больничный по усталости недели на две.

Итак, процесс сборки мобильного приложения. Попробую рассказать, из чего он у нас состоит — не потому, что в последнее время стало модным катать посты о CI той или иной мобильной команды (с покером, русалками и прочими обязательными атрибутами), а потому, что это отличный опыт, который я получил, работая над Почтой Mail.Ru для Android, и потому, что этой возможности, вероятнее всего, не было бы, работай я в другой команде, над другим проектом или в другой компании.
Читать полностью »

Предлагаю читателям «Хабрахабра» перевод заметки «Maslow's Hierarchy of Needs of Software Development», которую я нашел в блоге Скота Ханселмана.

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

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

image

Недавно я общался с заказчиком, где один хороший человек большей частью был озабочен стилем кода: расположением фигурных скобок, применением проверенных решений («best practices») в дизайне интерфейсов и еще кучей важных, но едва ли критичных вещей. В то же время в их организации не было поставлено модульное тестирование («unit-testing»), развертывание («deployment») проводилось вручную, а сборки были слабо верифицируемыми («verifiable build»).

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

Я подумал: что если спроецировать пирамиду потребностей Маслоу на нашу предметную область — разработку ПО? Под катом пример того, что у меня получилось (благодарю Фила Хаака, Джона Галлоуэя, Джонатана Ванагела и Пола Стовела за участие в «мозговом штурме»).
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js