Рубрика «рефакторинг»

Сложности с отображением иконок рабочего стола - 1


Последние три недели я работал над рефакторингом и исправлением легаси-кода (самые старые части которого были написаны в 2013 году), отвечающего за позиционирование иконок в KDE Plasma, а также сохранение и загрузку этих данных.

Вот мой запрос на внесение изменений: plasma-desktop: Refactor icon positioner saving and loading.

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

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

Бывало у вас такое, что провода наушников спутываются, когда вы убираете их в шкаф или кладёте ненадолго в карман? И с базами кода происходит нечто похожее, когда множество людей записывают в них изменения, исправляя баги друг друга. Каждый мыслит по-своему, поэтому вполне естественно, что всё со временем запутывается.

В итоге периодически кому-то нужно разгребать такую запутанную базу кода и подчищать её.Читать полностью »

Как внедрение CI-CD превратилось в эпопею с рефакторингом - 1

Всем привет меня зовут Роман. Я CTO компании LikeSoft и сегодня я хочу поделиться кейсом как я переводил LMS платформу на облако.

О проекте 

LMS платформа для обучения детей. Существующая архитектура была на базе PHP/ Laravel, MySQL, код крутиился на VPS сервере и все деплоилось по команде git pull. 

Основная задача

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

Привет, друзья!

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

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

Если вам это интересно, поехали.

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

Python постоянно развивается: с каждой новой версией появляются различные оптимизации, активно внедряются новые инструменты. Так, в Python 3.8 появился моржовый оператор (:=), который стал причиной бурных споров в сообществе. О нем и пойдет речь в этой статье.

А начнем мы с истории о том, как моржовый оператор довел Гвидо ван Россума, создателя Python, до ухода с должности "великодушного пожизненного диктатора" проекта по разработке языка.

PEP 572

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

TL;DR:
— в Rust намного больше достоинств, чем просто скорость и безопасность;
— в Rust по умолчанию CDD (compiler-driven development, разработка через компилирование). Это как TDD, только CDD;
— Rust — не сложный язык, особенно если не гнаться за максимальной производительностью.

На Rust можно смотреть с разных углов. Например, можно на него смотреть как на безопасную замену для C или C++. Многие говорят, что ниша Rust — это "mission critical" программы, а все, кто использует его для других целей — безумцы (Читать полностью »

Делаем код-ревью правильно - 1


В начале своей карьеры я как-то работал над одним заказом, создавая платформу сентимент-анализа для социальных сетей. В то время Twitter ещё был Twitter’ом. Наша команда состояла из семи человек, среди которых я был джуниором. Мы были молоды и полны энтузиазма. Наш девиз можно было описать как: «Мы гибкие, быстрые и всё ломаем!». Да, мы действительно гордились своей скоростью. Код-ревью? Я вас умоляю. Мы считали эту практику бюрократическим пережитком корпоративного мира.

И что вы думаете? Через несколько месяцев наша база кода стала подобна минному полю. Причём баги нас волновали меньше всего, хотя их была уйма. Реальная проблема заключалась в том, что никто не мог понять код, написанный другими. У нас во многих местах дублировалась логика, и в модулях использовались разные стили кода. Всё было очень печально.

Тогда до нас дошло! Нужно взять всё под контроль. Код-ревью реально помогают сохранять код читаемым, обслуживаемым и масштабируемым.

Итак, в двух словах: если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно. Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.Читать полностью »

Штурмовики наигрались и теперь разбирают любимый монолит

Штурмовики наигрались и теперь разбирают любимый монолит

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

Итак, вы унаследовали старую кодовую базу на C++. Что дальше? - 1


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

Теперь вы отвечаете за кодовую базу на C++. Она большая, сложная и своеобразная; достаточно слишком долго на неё посмотреть, как она начинает разваливаться разными интересными способами. Иными словами, это легаси.

Но баги всё равно как-то нужно устранять, а ещё добавлять новые фичи. То есть вам нельзя просто закрыть на неё глаза или что ещё лучше, взорвать её динамитом. Она важна для компании. По крайней мере, для тех, кто платит вам зарплату. А значит, важна для вас.

И что делать теперь?

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

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

Становится ли ПО хуже? - 1


Недавно я наткнулся на пост Никиты Прокопова Software disenchantment. Он заставил меня вспомнить пост Мацея Цегловски The Website Obesity Crisis и множество других статей подобного типа. Среди людей, пишущих о разработке ПО, возникает всё более широкий консенсус о том, что приложения становятся больше, медленнее и забагованнее. И это в эпоху, когда оборудование должно позволить нам писать быстрее, меньше и надёжнее. DOOM, вышедший в 1996 году, можно запустить в тесте на беременность и на сотне других неожиданных устройств. Тем временем, современные чат-приложения, работая в фоновом режиме, занимают полгигабайта ОЗУ (или больше), а иногда полностью зависают даже на самом мощном ПО.

Вышеупомянутые посты по этой теме состоят примерно на 80% из справедливой и разумной критики, а на 20% из оторванного от реальности ворчания.

Большинство разработчиков понимает, что глупо спрашивать «это ОС для смартфонов, что в ней может быть сложного?» или «моё приложение для работы с электронными таблицами в 90-х занимало 10 килобайт, тогда почему Factorio весит целый гигабайт?» Если вы не присутствовали при разработке, то не сможете оценить все её проблемы и сложности.

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

Почему же мы этого не делаем?Читать полностью »

Озадаченный краб

Озадаченный краб

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

С тех пор мы с ещё несколькими потрясающими разработчиками создали Читать полностью »


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