Привет!
Меня зовут Вьет, и больше 10 лет я с любовью пишу код. В прошлом году меня пригласили в программный комитет, в котором большие фанаты качественной разработки делали конференцию QualityConf. Мы верим, что качественная разработка не ограничивается вопросами тестирования, поэтому собрали под одной крышей доклады про различные аспекты качества продуктов.
Но нашу команду поджидали две серьезные проблемы.
Людей, которые разбираются в работе программиста, можно встретить, где угодно. А заодно — и в работе бухгалтеров, менеджеров, кассиров, конструкторов и даже переворачивателей пингвинов. Эти парни любят абстракции даже больше, чем сами программисты.
Например, есть такая абстракция, как KPI. Еще Scrum. Канбан. Корпоративная культура. Soft skills. И т.д.
Понять работу программиста, а главное — пути повышения ее эффективности — эти люди пытаются через абстракции. Не изнутри профессии, а снаружи. Натягиваем сову на глобус Адаптируем абстрактную модель к профессии, и пытаемся чего-то понять и улучшить, исходя из правил модели.
Чтобы повысить эффективность работы программиста через Scrum, надо заставить его клеить стикеры и вставать на митапах. Так в методичке написано. В Канбане — переклеивать стикеры почаще. Чтобы сработала корп.культура, надо заставить программиста выучить гимн. Через soft skills — пусть учится говорить. И т.д.
Особо популярны три группы абстракций. Первая — методы серийного производства, вроде Канбана или даже конвейера. Рабочий, который годами точит одинаковые детали — тот же программист ведь, правда?
Вторая — методы проектного управления, вроде Scrum или Waterfall. Понятно, что вмешательство метода выглядит мягким — вроде, задачу ты решай по-программистски, а между задачами веди себя по-скрамовски. Но диффузия есть, в обе стороны. Что водопадный лозунг «уложись в срок», что скрамовский «а-а-а, херачим-херачим-херачим!» влияют на программирование «магически».
Третья — э-ге-гей-методы. Надо просто всех подружить, как в детском саду, шарики развесить, и код напишется. Ну а чё.
Давайте с другой стороны зайдём. Не снаружи, из далеких галактик непонятных абстракций, а изнутри. Программистским умом поймём, как повысить эффективность работы программиста, и чем он должен заниматься. Это ненадолго, слишком всё просто, если ты изнутри.Читать полностью »
Бывает нужно оставить отзыв об исходном коде в репозитории в целом, например при приемке кода на поддержку от других разработчиков или подключаясь к новому проекту.
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
В общем суть метода уже изложена, ниже лишь немного подробностей.
В первой части материала были освещены аспекты стандартов код-ревью и моменты, на которые необходимо обращать внимание в первую очередь. В заключительной части поговорим о:
Работа игровой студии невероятно объемная и сложная. Процедура разработки и выпуска готового продукта проходит множество этапов. И получить прибыль с проекта не так и просто, и точно это не одномоментный процесс. Даже с помощью издателей.
У тех, кто пробует себя в игрострое, возникает ряд вопросов. Как разработчикам показать себя с лучшей стороны и представить свой проект? Как выгодно представить игру издателю и убедить его в будущем успехе? Как затем продать игру?
Мы в Слёрме любим пробовать и узнавать новое. И нам близка тема образовательных проектов.
Тем интереснее было заглянуть на территорию геймдева благодаря управляющему директору направления премиум игр в компании 101XP Ольге Макушенко. Перед вами лекция Ольги, которая которую она прочитала в Высшей школе бизнес-информатики НИУ ВШЭ в рамках образовательной программы Менеджмент игровых проектов, и родилась эта статья.
Так, собираем истории самых шизанутых собеседований, приемов на работу и компаний, где вам приходилось бывать. Мне как-то везло обычно, сильно больших отклонений от нормы не встречал. Ну там полиграф бывал, посылать интервьюера приходилось, однажды даже устроил обратное собеседование – начальник ИТ, узнав мою зарплату на текущем месте, захотел ко мне работать пойти, даже простым программистом.
Но самый выдающийся случай произошел несколько лет назад, когда впечатлений от первого дня работы было столько, что к вечеру я слёг с высокой температурой, несмотря на прекрасную майскую погоду за окном.
Итак, я, по политическим соображениям (обидели меня, чё уж там), увольнялся с должности начальника ИТ агрохолдинга (курицы, свиньи, колбаса, шашлыки и т.д.). На резюме откликнулся аналогичный работодатель – тоже колбасу делают и свиней выращивают, только без куриц. Вроде, всё один к одному. К тому же, на этом предприятии работал знакомый. Я ему звякнул, узнал – он достаточно лаконично ответил, что всё нормально, работа как работа.Читать полностью »
Привет, за минувший год мы сделали 5 разных докладов про работу в распределенных командах — и поняли, что не покрываем и десятой доли вопросов, которые возникают у людей при слове «удаленка». И хотя с каждым годом все больше компаний и специалистов продолжают делиться опытом в статьях, подкастах и выступлениях, кажется, и этого мало. Ведь любая статья или выступление — это ограниченное время, объем и фантазия докладчика. Да и опыт у всех субъективен: кайтсёрфер с пляжей Пангана расскажет не то же, что человек, работающий с родного дивана в Калининграде.
Поэтому мы попросили нескольких коллег с совершенно разным опытом рассказать о себе и поотвечать на ваши вопросы. Надеемся, к ответам также подключатся ребята из телеграм-чата удаленщиков* — и получится тред, который прослужит не одному поколению даст ответы на конкретно ваш вопрос и подскажет конкретные инструменты и практики.
Человек веками мечтал о небе. Братья Уилбур и Орвилл Райт, Альберто Сантос-Дюмон и братья Вуазен подарили его людям. И человек с каждым десятилетием поднимался всё выше и выше, увеличивал скорости, манёвренность, предельные перегрузки, преодолевал звуковой барьер, сталкивался раз за разом с труднейшими инженерными вызовами.
Авиация изменила мир — и его современный облик во многом сформировался за счёт быстрых авиасообщений, когда достижение другого континента или удалённой страны перестало быть трудным и опасным путешествием длиной в несколько недель, а то и месяцев.
Но с ростом скоростей и расстояний повысились требования к управляющим системам летательных аппаратов — микроконтроллерам, прошивкам, автопилотам.
Мне повезло познакомиться с отечественным разработчиком Владом Гордеевым, который занимается как разработкой систем дистанционного управления полетом самолётов, так и систем автоматического управления полетом ЛА. Я задал ему несколько вопросов — и оказался на пару часов в мире, где всё решают миллисекунды, такты, алгоритмы и нет права на ошибку.
Представим команду, где не проводится Code review. Разработчики пишут код и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда при любом мало-мальском нововведении проект начнёт разваливаться: в лучшем случае, увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.
Как этого можно избежать? Читать полностью »
Если ваша компания только внедряет DevOps или инструменты CI/CD, вам может быть полезно познакомиться с самыми распространенными ошибками, чтобы не повторить их и не наступать на чужие грабли.
Команда Mail.ru Cloud Solutions перевела статью Avoid These Common Pitfalls When Transitioning to CI/CD by Jasmine Chokshi с дополнениями.
Читать полностью »
