• Стратегии выплаты технического долга

    • Перевод
    image

    Технический долг: он есть у всех, и каждый достойный своего звания разработчик хочет его выплатить, но как же организовать этот процесс?

    Реализуем севооборот


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

    Эта метафора остаётся подходящей и для разработки ПО; кроме того, она содержит в себе намёки на возможные стратегии, которые можно использовать для выплаты технического долга.

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

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

    • Перевод

    Время от времени я встречаю людей, пытающихся выразить API в терминах IQueryable<T>. Почти всегда это плохая идея. В этой статье я объясню почему. Вкратце, IQueryable<T> — это один из лучших примеров заголовочного интерфейса (Header Interface), предлагаемых платформой .NET. Его почти невозможно реализовать полностью.


    Эта статья о проблемах реализации API на основе интерфейса IQueryable<T>. Это не претензия к интерфейсу как таковому. Кроме этого, это не претензия к замечательным методам LINQ, доступным для интерфейса IEnumerable<T>.

    Можно сказать, что IQueryable<T> — это одно сплошное нарушение принципа подстановки Лисков. Я буду использовать закон Постела, чтобы объяснить почему это так.


    Принцип устойчивости, также известен как закон Постела в честь Джона Постела: «Будь либерален к тому, что принимаешь, и консервативен к тому, что отсылаешь (Be liberal in what you accept, and conservative in what you send)».
    Читать дальше →
  • Как Amazon тратил по $500 млн на разработку провальных игр и почему ничего не вышло



      В 2012 году в структуре Amazon возникла собственная студия по производству компьютерных игр. По замыслу Джеффа Безоса, Amazon Game Studios должна была стать успешной и эффективной частью корпоративной экосистемы. Однако за прошедшие восемь лет добиться этого, увы, так и не удалось. Как же так вышло, что богатейшая компания, у которой получалось практически всё, не сумела завоевать рынок геймдева?

      Ответы на этот вопрос нашел журналист Джейсон Шрайер (автор книги “Кровь, пот и пиксели”). Публикуем главные тезисы расследования.
      Читать дальше →
    • Как выбрать тимлида

        Будучи разработчиком, я выработал в себе привычку читать доки и мануалы систематически и в большом объеме. Сейчас я руковожу отделом iOS разработки в Cardsmobile и практически не пишу код, но привычка осталась. Статей про менеджмент написано не меньше, чем по программированию. И начитавшись публикаций на очередную такую тему, я кое-что понял: зря я не читал их, пока активно кодил. Ведь в моей команде всегда есть как минимум один менеджер и хорошо было бы разбираться в том, что он делает. Хотя бы немного. Ведь если он делает свою работу плохо, то лучше подыскать нового?       

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

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

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

        Читать далее
      • Как американцы становятся миллионерами: принципы FIRE

        Пару лет назад на Хабре уже была статья про движение FIRE (Financial Independence / Retire Early). Она хорошо описала суть явления, но мало углублялась в детали, поэтому у многих читателей сложилось впечатление, что это не применимо в российских реалиях, или же ведет к очень ограниченной и несчастливой жизни по мере достижения финансовой независимости. Эти аргументы регулярно используют и американцы, в том числе неплохо зарабатывающие, которые знакомы с FIRE лишь понаслышке. Поэтому мне кажется полезным рассказать о принципах и способах достижения финансовой независимости, используемых американцами, а дальше уже каждый сам решит что из этого инструментария им доступно в их ситуации и их стране.

        Один из частых мифов про последователей FIRE — это то, что они хотят бездельничать, и потому спешат “выйти на пенсию”. Как правило, это не так. Основное, чего стремятся избежать люди из этой группы — зависимость от работодателя. Одна из первых важных точек отсчета — это “fuck you money”. Такое количество денег, которое позволяет развернуться и хлопнуть дверью перед носом своего работодателя, если тот решит хамить или эксплуатировать зависимого (как ему кажется) сотрудника. Большинство людей любят работать и создавать, но хотели бы иметь возможность выбирать ту работу, что нравится, даже если там мало платят или не платят вообще. Многие “уволившиеся” создают свои подкасты, блоги, начинают консультировать, и иногда это довольно неожиданно превращается в успешный бизнес, позволяющий им перестать пользоваться своими накоплениями.

        Для некоторых профессий, включая программистов, стандартный возраст выхода на пенсию еще и слишком высок с учетом возрастной дискриминации при приеме на работу. Многие сталкивались с тем, что после 50 лет работу найти все сложнее, и решать задачи на leetcode при подготовке к интервью все труднее. Поэтому желание обеспечить себе пенсию на 10-20 лет раньше официального ее наступления вполне понятно.
        Читать дальше →
      • Как DDD помог нам построить новые ревизии в пиццериях

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

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


          Читать дальше →
          • +30
          • 11,3k
          • 6
        • Как приручить событийно-ориентированные микросервисы

          • Перевод
          Как приручить событийно-ориентированные микросервисы

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


          TL;DR: А вот и нет! Вы столкнетесь с препятствиями связанными с пониманием и управлением потоком событий.


          В этой статье я просуммирую свой опыт работы с хореографией микросервисов и укажу на различные препятствия и последствия данного подхода. Я использую типичный пример из бизнеса — процесс “клиентской адаптации” (в зависимости от отрасли, вы могли слышать о нем как об открытии счета). Для представленной очереди событий ниже, я использую Apache Kafka, но не беспокойтесь если используете другой стек, для него будут применимы все те же понятия.

          Читать дальше →
          • +11
          • 5,7k
          • 3
        • Почему в России почти нет гражданского/коммерческого высокотехнологичного производства?

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

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

            Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

            Сразу нужно отметить, что в связи с многогранностью проблемы объем статьи получился довольно большой, так что можно начать читать с резюме в конце, и затем прочитать лишь те разделы, которые вызовут интерес. Сразу хочу предупредить — повествование «нелинейное», соседние заголовки могут описывать разные аспекты проблемы и быть друг с другом практически не связанными.
            Читать дальше →
          • Поиск родственников через тест ДНК. Часть 4 – Расшифровка результата

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

              И вот спустя несколько недель мы получаем извещение на e-mail, что наш тест готов, результаты загружены на сайт и теперь можно ознакомиться с его результатом!



              Что мы увидим в результатах ДНК-теста на сайте лаборатории?


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

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

              Далее будут много картинок, т.к. без этого обзор будет неполноценным.
              Читать дальше →
            • Юрий Бушмелев «Карта граблей на поле сбора и доставки логов» — расшифровка доклада

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


                • как писать логи из приложения;
                • куда писать логи;
                • как доставлять логи для хранения и обработки;
                • как обрабатывать и хранить логи.

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


                Как раз об этом расшифровка доклада Юрия Бушмелева "Карта граблей на поле сбора и доставки логов"



                Кому интересно, прошу под кат.

                Читать дальше →
              • Как некорректное делегирование отравляет IT-индустрию



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

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

                  Наблюдая за работой десятков разных IT-компаний из разных сегментов я с уверенностью заявляю: так называемое «делегирование полномочий» в 90% случаев — фикция и способ самоутверждения менеджера. Потому что делегирование, это двунаправленный процесс, в котором должен быть не только сильный исполнитель (что очевидно), но и умный, со стальными нервами руководитель. И сейчас объясню, почему.
                  Читать дальше →
                • Кто там выше тимлида?

                    image

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

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

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

                      С разрешения Сергея мы публикуем все три видео и их текстовую расшифровку.

                      Читать дальше →
                      • +31
                      • 18k
                      • 7
                    • Реальная стоимость жизни в Кремниевой Долине для разработчика

                        Зачем это читать?


                        Всем привет! Меня зовут Винсент, и я с 2018 года живу в Кремниевой Долине со своей супругой и сыном.


                        Своим фильмом, Дудь хотел поднять стартапный ажиотаж в России, но в итоге возбудил всех моих товарищей гораздо больше здесь, в Silicon Valley.


                        Этот пост — расчет стоимости жизни "обычного разработчика" (не "стартапера"), который работает "на дядю". Все максимально честно и подробно.

                        Читать дальше →
                      • Детальный разбор структуры зарплат IT-специалистов в Кремниевой Долине

                        О чем пойдет речь


                        image

                        В рамках пятничного безумия, давайте представим, что у Вас волшебным образом появилось разрешение на работу в США, и Вы уже готовы после завтрака телепортироваться в самый центр Маунтин-Вью, чтобы моментально найти работу в крупной IT-компании и начать зарабатывать свой первый взнос на дом в Кремниевой Долине. Но прежде, давайте попробуем разобраться из чего состоит заработная плата разработчика программного обеспечения, что обычно включено в социальный пакет IT-специалиста, и какие дополнительные льготы получают сотрудники крупных технологических компаний в США. Все эти знания пригодятся Вам, чтобы продать себя дороже, жить комфортнее и быстрее заработать на сарайчик в пригороде Сан-Франциско.

                        Если Вам проще воспринимать информацию на слух или в режиме видео-ролика, то специально для Вас готово 28-минутное видео с тайм-кодами в комментариях.

                        Три главных компонента


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

                        Так вот, в первую очередь нужно понимать, что сумма, которую заплатит Вам работодатель
                        формируется из трех компонентов:

                        1. Сash — это деньги, которые Вы получаете непосредственно на карточку два раза в
                          месяц (или же их присылают Вам бумажным чеком, который потом можно либо обналичить, либо положить на Ваш банковский счет.
                        2. Non-cash — это акции в различных вариациях: RSA, RSU, PSU, PSA или ESPP.
                        3. Benefits — все косвенные затраты работодателя на Вас, с которых Вы также имеете
                          выгоду.

                        Когда речь заходит о зарплате, тут принято говорить о сумме за год до уплаты налогов. Эта сумма называется Total Compensation (TC) и включает в себя Cash и Non-cash компоненты.
                        Читать дальше →
                      • Как найти скрытую камеру в съемной квартире или номере отеля


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

                          Случаев, когда постояльцы обнаруживают в своих комнатах и номерах скрытые камеры, становится все больше. Согласно результатам исследования, скрытые камеры находит 1 из 10 пользователей Airbnb. Не меньше таких устройств в отелях и хостелах. Представим масштабы проблемы, если учесть, что постояльцы обнаруживают далеко не все камеры, а только те, что установлены небрежно. Как обезопасить себя от шпионажа? Как минимум можно внимательно обследовать помещение, прежде чем поселиться в нем. В статье мы расскажем, что, где и как искать.
                          Читать дальше →
                        • Разбиваем монолит на микросервисы

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


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



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

                            Читать дальше →
                          • Как Греф с программистами боролся

                              Наверное многие помнят скандальное заявление Грефа о том, что Сбербанку программисты не нужны: "У нас огромное количество программистов, с которыми мы боремся". Давайте проанализируем откуда такие заявления взялись и чем все это закончилось.


                              Читать дальше →
                            • Ты добавил всего две строчки. Почему на это ушло два дня?

                              • Перевод
                              На первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:

                              • строки кода = усилие
                              • строки кода = значение
                              • все строки кода равны

                              Ничто из этого не является истинным.

                              Почему исправление, которое кажется таким простым, заняло два дня?
                              Читать дальше →
                            • Генеральный конструктор vs Скрам-мастер

                                image

                                «Каспийский монстр» — советский экраноплан, который весил 544 тонны, что делало его самым тяжелым летательным аппаратом в мире. Сделан с нуля за два года. Думай об этом, закачивая лэндинг по продаже трусов «всего» за полгода.

                                Я бы хотел рассказать о некоторых приемах древнего(доскрамового периода) менеджмента, которые позволяли добиваться таких результатов. Поднять в воздух на новом принципе железную бандуру размером с хрущевку и разогнать ее до пятисот киломtnров в час, по мне — это более творческая и технически сложная задача, чем открытие очередного интернет магазина, поэтому возможно стоит перенять опыт предков.
                                Читать дальше →