Рубрика «управление разработкой» - 2

(Хабр-Статья представляет собой авторский перевод доклада, представленного автором на Scheme Workshop 2020, проводившегося в рамках Международной Конференции по Функциональному Программированию, 28 августа 2020 года)

Эта статья -- своего рода "отчёт" по самому большому проекту, который я сделал в своей жизни по собственной инициативе. Я сделал полное и всеобъемлющее решение всех задач из одной из самых извесных книг по программированию в мире "Структура и Интерпретация Компьютерных Программ" (Structure and Interpretation of Computer Programs -- SICP), за авторством Абельсона, Сассмана и Сассман.

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

Культ лучших практик - 1

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

Почему лучшие практики могут быть вредны? Почему мы любим им следовать? Когда и как они мешают? Чтобы ответить на эти вопросы, нужно понять, откуда берутся эти практики и как они распространяются в программировании.
Читать полностью »

Ежедневные сложности сениор-разработчика - 1

Больше десятка лет я работал на одну из крупнейших в мире компаний по разработке ПО. Выполняя множество задач, я видел многие аспекты бизнеса: от быстрого «ковбойского» кодинга до серьёзных покупок конкурентов и стартапов.

1. Планёрки

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

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

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

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

И знаете что? Эти знания в основном передаются на совещаниях. Поймите меня правильно, само по себе это хорошо.

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

Настала пора ещё одного совещания.Читать полностью »

Docs as Code. Часть 2: получаем документацию из кода - 1

Продолжаем рассказывать о применении на практике принципа работы с документацией как с кодом. В этот раз разберём получение спецификации Swagger напрямую из комментариев к коду API. В статье рассматривается роль технического писателя в процессе адаптации команды к использованию нового инструмента, а также приводятся конкретные инструкции по применению swagger-php в реальном проекте.
Читать полностью »

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

  • Обучение и онбординг новичков.
  • Шеринг кода/процессов и обмен опытом.
  • Пара решает проблему быстрее и реже обращаются за помощью.
  • Повышение производительности.
  • Сплочение коллектива.
  • Увеличение скорости ревью.

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

Но давайте начнем с грустного и поговорим о том, что может помешать начать внедрять парное программирование в своей команде.
Читать полностью »

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

Можно спросить, а причем здесь техдолг, если конференция DevOps? Холиварить об этом можно, например, в рамках DevOps-фуршета, но настолько ли это широкое понятие? Мы узнали, что Артем относит к техдолгу все изменения и доработки, инфраструктурные модификации и изменения процессов, изменения структур команд, направленные на устранение гэпов — которые были допущены (осознанно или нет) в рамках запуска продуктов и фич, и которые со временем сильно мешать жить.

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

Техдолг. Все говорят: «невозможно», а я говорю, что буду - 1
Читать полностью »

А что, если я скажу вам, что линтеры для Go можно создавать вот таким декларативным способом?

func alwaysTrue(m dsl.Matcher) {
    m.Match(`strings.Count($_, $_) >= 0`).Report(`always evaluates to true`)
    m.Match(`bytes.Count($_, $_) >= 0`).Report(`always evaluates to true`)
}

func replaceAll() {
    m.Match(`strings.Replace($s, $d, $w, $n)`).
        Where(m["n"].Value.Int() <= 0).
        Suggest(`strings.ReplaceAll($s, $d, $w)`)
}

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

Основные нововведения:

Релиз ruleguard v0.3.0 - 1Читать полностью »

Сервисы падали, падают и будут падать

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

Трассировка и логирование в микросервисах: как мы втаскивали единый стандарт на 30 независимых команд - 1

Например, наша команда сопровождения маркетинга в Skyeng знала: пользователь с таким-то айдишником нажал в личном кабинете кнопку «Сменить преподавателя» — постучался в наш сервис, дальше ушло три сообщения, в очереди было 2 вызова сервисов и эти сервисы ответили 200. Но на самом деле, что было у команд сопровождения учителей или биллинга, к которым мы стучались, не знал никто…

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

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

Каково работать вместе с очень ужасным разработчиком - 1

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

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

Если я скажу, что тот или иной член команды халтурит, и даже объясню всё вежливо и с техническими подробностями, менеджеры воспримут это как «ссору» и сосредоточат всё своё внимание на сплочённости коллектива, подразумевая, что проблемы создаю именно я.
Читать полностью »

Бывает, что посмотрев на старый код, мы говорим: «Его проще переписать, чем поменять». Печально, если речь идет о нашем собственном коде, с такой любовь написанном несколько лет назад. Head of Developer Relations в Evrone Григорий Петров в своем докладе на TechLead Conf 2020 разобрал проблемы, которые приводят к такой ситуации, и рассказал, как бороться с Software complexity problem.

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

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

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