Рубрика «developer experience»

Чистый код — красивая архитектура. А работает ли это? - 1


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

Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать.

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

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

Давайте разберём, как превратить кошмар в конфетку — детали внутри.Читать полностью »

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe."

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

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

Личный проект

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

API Style Guide, или не заставляйте пользователей думать - 1

Привет! Меня зовут Лёша Руцкой, и я — продуктовый менеджер в компании Wrike. До этого работал в Adform и PandaDoc. Последние пять лет я занимаюсь всем, что связано с интеграциями и API.

Wrike — это SaaS продукт для совместной работы и управления проектами. Мы хотим, чтобы разработчики строили свои решения на базе Wrike, а для этого нужно, чтобы наш API был удобным. При этом у нас 9 офисов по всему миру, и 3 из них — офисы разработки. Довольно сложно создавать консистентный API силами распределённых команд, которые говорят на разных языках. Растёт вероятность того, что их решения начнут противоречить друг другу. В этом случае не обойтись без единого для всех набора правил.

Если вы тоже работаете распределённо и делаете свой API, то API Style Guide может вам помочь. Я хочу рассказать, какие распространённые проблемы он решает и как облегчает жизнь разработчикам. Также поделюсь своим опытом по написанию и внедрению собственного API Style Guide в компании.
Читать полностью »


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