• Управление командой программистов: как и чем их правильно мотивировать? Часть первая

      Эпиграф:
      Муж, глядя на чумазых детей, говорит жене: ну, что, этих отмоем или новых нарожаем?


      Под катом рассуждения нашего тимлида, а также директора по развитию продукта RAS — Игоря Марната об особенностях мотивации программистов.

      image
      Секрет успеха в создании классных программных продуктов известен — возьмите команду крутых программистов, дайте команде классную идею и не мешайте команде работать. Крутые разработчики — ребята редкие и востребованные. Некоторые рекрутеры даже говорят, что у них создаётся такое впечатление, что родить крутого программиста проще, чем нанять его с рынка. Помимо трудностей с наймом, как таковым, опыт каждого конкретного разработчика, его знания о существующем продукте и истории его разработки зачастую незаменимы или восполняются тяжело и долго. Поэтому если вам повезло, и вас уже есть крутая команда программистов, важно работать над их мотивацией. Нанять, обучить новых разработчиков, сделать из них команду — почти также трудно и долго, как родить и вырастить детей.
      Читать дальше →
    • Модульное тестирование Json сериализации в Spring Boot



      Введение


      Одной из основных задач каждого веб-сервиса является возврат модели на клиентскую сторону, и в этом случае Spring Boot предоставляет удобный уровень абстракции, позволяя разработчику оставаться на уровне работы с моделями, а сам процесс сериализации модели оставлять вне исходного кода программы. Но как быть, если сама сериализация становится частью бизнес-логики приложения и, следовательно, требует покрытия тестовыми сценариями?

      В данной статье будет рассмотрен один из сценариев, когда нам может понадобиться учесть особенности бизнес-логики приложения при сериализации (сценарий округления денежных сумм), на примере которого мы столкнёмся с механизмом сериализации в Spring Boot, а также описан возможный способ тестирования.
      Читать дальше →
    • Я провел сто собеседований, отказал сотне людей — и только потом научился собеседовать

        image

        Не желал бы я вам попасть ко мне на собеседование года два назад. Я провел их около сотни, и за все время взял может человек четырех. Не знаю почему, но эйчары считали, что это круто. Слава строгого интервьюера шла впереди меня. Знакомые звали меня собеседовать для чужих команд, и даже для чужих компаний, о которых вы слышите каждый день. И везде — не проходил никто.
        Читать дальше →
      • Docker: невредные советы

          В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.


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



          Сейчас разберемся, что не так с этим Dockerfile.


          Итак, прошла неделя.

          Читать дальше →
        • Инженерные подходы и чеклисты: как не сойти с ума в хаосе задач



            Привет! Меня зовут Олег, и я frontend-разработчик в Альфа-Банке. Я хочу рассказать вам немного философскую историю — про инженерный подход к разработке, про мою первую работу и грабли, которые я там собрал, про то, почему чеклисты очень важны (и спасают жизни).

            А еще про то, как продолжать продуктивно работать и не закопаться во множестве мелких и не очень задач.

            Всё началось с хаоса.
            Читать дальше →
          • Гнев на код: программисты и негатив

            • Перевод


            Я смотрю на кусок кода. Возможно, это худший код, что мне когда-либо встречался. Чтобы обновить всего одну запись в базе данных, он извлекает все записи в коллекции, а затем отправляет запрос на обновление каждой записи в базе, даже тех, которые обновлять не требуется. Тут есть map-функция, которая просто возвращает переданное ей значение. Есть условные проверки переменных с очевидно одинаковым значением, просто поименованных в разных стилях (firstName и first_name). Для каждого UPDATE’а код отправляет сообщение в другую очередь, которая обрабатывается другой serverless-функцией, но которая выполняет всю работу для другой коллекции в той же базе данных. Я не упомянул, что эта serverless-функция из облачной «сервис-ориентированной архитектуры», содержащей более 100 функций в окружении?

            Как вообще можно было такое сделать? Я закрываю лицо и явственно всхлипываю сквозь смех. Мои коллеги спрашивают, что случилось, и я в красках пересказываю Worst Hits Of BulkDataImporter.js 2018. Все сочувственно кивают мне и соглашаются: как они могли так с нами поступить?
            Читать дальше →
          • Оценка сроков на разработку и тестирование задачи (не нужна)

              Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.


              После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.



              Оценка сроков в 95 % случаев. Спасибо, xkcd.


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

              Сейчас объясню, как это работает.

              Горькая правда
            • Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло


                Наш идеал почти 9 лет был такой: собрание стоя, 15 минут максимум, минимум людей. И лучше вообще в коридоре. Не можешь решить за 15 минут — значит, что-то пошло не так. Звучит круто, правда?

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

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

                Лучше пару часов потерпеть, но потом внедрить на месяц быстрее.
                Читать дальше →
              • Передаём проект: howto

                  Много в этом мире сказано, что код надо писать так, чтобы его было легко поддерживать любому другому разработчику и чтобы проект мог быть передан на поддержку другим людям в любой момент. Но каково это – передавать проект, с которым прожил несколько лет, в совсем другие руки? Кем окажется для проекта его новый руководитель – вторым отцом или злым отчимом (уважаемые читательницы, я помню о вашем существовании, но вы в меньшинстве)? Будет наше детище развиваться и набирать сил, или умрёт, уступив место чему-нибудь куда менее красивому, явно не столь качественному (мы-то понимаем, кто здесь самый крутой профессионал) и совсем чужому? Для тех, кого действительно волнует его будущее, и написана данная статья. Замечу, что в ABBYY я проработал в нескольких проектах, оставлял их по разным причинам. Большинство из проектов – задачи без чёткого решения (распознавание, поиск разных неформально описанных объектов и т.п.).
                  Читать дальше →
                • Как определить язык напечатанного текста? (Европейские языки)

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

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

                    Языков больше, чем типов письменности. Поэтому диаграмка получилась большая. Отличать языки друг от друга будем в основном по особенным буквам, в частности, по буквам с диакритическими значками (диакритикой). Диакритика бывает над гласной (в букве й), над согласной (буква č) или может как-то сопровождать букву (как в букве ç; строго говоря это не дикритика вовсе, но мы здесь будем придерживаться такого жаргона). Наиболее известные (с моей точки зрения) значки в Европе — это умляут (он же диаерезис: ü), гачек (č) и акут (é).

                    Тех, кто не испугался, прошу под кат
                  • Не бойтесь пробовать, или Как я стала программистом в возрасте далеко за 18

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

                      Вот на них я и попытаюсь ответить в этом посте.


                      Читать дальше →