Год назад я начал вести этот блог в его современном виде 🎉

Хочется делать это лучше. Напишите мне, пожалуйста, что вы думаете о контенте, какие темы вам инетересны, а какие совсем нет. Что из постов радует, что раздражает. Мне очень важно это знать.

@igorkamyshev

Красивый код — не рюшечки

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

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

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

#архитектура #проектирование

Красивый код — не рюшечки

Окей, для длинных проектов важна чистота кода. Как определить, что проект длинный?

Все просто. Есть два признака.

1. Проект длится больше месяца. Обычно известно заранее, сколько есть времени на проект. Если проект должен занять больше, чем 4 недели — он длинный.

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

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

#проектирование #архитектура

Фронтенд

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

Нужно эту ситуацию как-то исправлять. SkillFactory очень вовремя запускает специализацию «Frontend-разработчик». Учат с самых основ — CSS/HTML, потом расскажут про JavaScript, принципы работы веб-приложений.

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

#фронтенд #партнерский_материал

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

Недавно они опубликовали документ с основными принципами, на которых основана работа — Принципы разработки Амплифера

#softskills

Реакт-нейтив

Я не трогал реакт-нейтив с 2017 года. И тогда с ним было все очень плохо. В начале августа временно присоеденился к команде мобильной разработки и вернулся с этому прекрасному фреймворку. На первый взгляд, за эти два года ничего не изменилось.

Во-первых, сохранились главная (для меня) проблема — сложности с подключением нативных модулей. Нужно поставить пакет через npm, потом через react-native-cli пролинковать его, исправить какие-то gradle-файлы, pod-файлы. Это никогда не работает нормально сразу на двух платформах. Если завелось на iOS, значит будут проблемы на Android. Отвратительно.

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

В-третьих, приложение не получается одинаково хорошо работающим на iOS и на Android. Эти системы устроены по разному и там где на одном устройстве прдполагается свайп влево, на другом нужно нажать кнопку "Назад". Это дополнительно нагружает и дизайнеров и разработчиков. Из-за ограниченности ресурсов, часто одна из платформ становится доминирующей.

Но! В целом разработка на реакт-нейтве не вызывала у меня такой оторопи, как в 2017. Есть полноценные инструменты разработчика, даже дебаггер почти работает. Появились удобные абстракции над родной стилизацией. Поддерживается современная версия реакта.

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

#фронтенд

Экспертиза умерла

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

С одной стороны, это больной подход. Хороший специалист не обязан вести блог, не обязан выступать на конференциях.

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

Научить хард-скиллам легко. Научить софт-скиллам — сложно. Качайте софт-скилы, чтобы оставаться актуальным на рынке.

Правда, я не знаю как это делать. 😢

#softskills

Solid

ООП — это сложно. Но именно с помощью объектно-ориентированного дизайна приложение можно сделать надежным, расширяемым и поддерживаемым.

Способ писать хорошой объектно-ориентированный код описан в принципах SOLID, котроые сформулировал и описал в "Чистой архитектуре" Дядя Боб. Это прекрасная книга, которую должен прочесть каждый программист. Но она достаточно теоретическая, в ней мочти нет примеров хорошего кода.

Саша Беспоясов и Артем Самофалов сделали интерактивный курс про принципы SOLID, с примерами на TypeScript, тестами и автоматическими проверками. Если вы не чувствуете себя уверенно при проектировании приложений — пройдите этот курс.

https://ota-solid.now.sh/

#проектирование #архитектура

Последние два месяца я занимаюсь исключительно фротнендом. Когда планировал менять работу, немного преживал — я очень люблю писать на Node.js. Но, как оказалось, это позволяет сконцентрироваться, решать фронтовые задачи быстрее и качественнее.

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

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

#фронтенд #партнерский_материал

Процессы

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

Крутой доклад Александра Феоктистова — Направляем снежный ком задач в нужное русло.

#процесс #softskills

​​Алгоритмы

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

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

OTUS запускает курс «Алгоритмы для разработчиков». Научат использовать готовые алгоритмы и проектировать решения на основе базовых подходов , расскажут про оценку сложности и структуры данных. Обратите внимание, для участия в курсе нужно знать Java, C++ или Python.


#общие_знания #алгоритмы #партнерский_материал

Есть несколько технологий, используя которые я получаю удовольствие.

Flutter — одна из них. Завтра весь день буду на DartUp 2019 в Питере. Пишите (@igorkamyshev), встретимся.

Справка. Flutter — фреймворк для разработки мобильных приложений на Dart.

Послушал очень хороший доклад про #ddd от Маджита Хаджиана.

Strategic Domain-Driven Design for Improving Flutter architecture

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

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

Во-первых, иногда проект состоит из систем на разных языках. Бекенд на Java и фронтенд на TypeScript. Придется делать две разные команды, запускать их последовательно и держать в памяти как это все нужно делать. Не очень хорошая идея.

Во-вторых, кроме сборки у вас может быть еще много разных задач. Нужно запустить набор разных тестов (юниты, интеграционные, из-конца-в-конец). В JS-мире эту задачу обычно решают npm-скрипты. Это не самый удобный инструмент. В других экосистемах тоже есть свои решениях разной степени удобства.

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

Теги нужны?
anonymous poll

да – 156
👍👍👍👍👍👍👍 92%

нет – 13
👍 8%

👥 169 people voted so far. Poll closed.

Несколько месяцев назад я пришел в Самокат делать внутренние продукты. У таких приложений есть несколько специфичных требований. Первое и самое серьезное — они должны быть блейзинг фаст. Поэтому, при планировании нового приложения я сразу заложил время на работу с перфомансом. Самое очевидное решение — уменьшить время загрузки приложения. Так я заменил React на Preact (фреймворк с совместимым API, но меньшего размера). Не все прошло гладко, но результат отличный.

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

- подходить продукту;
- быть простой в освоении или популярной;
- быть поддерживаемой.

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

#softskills #общие_знания

В хорошей команде должно быть много коммуникации. Смотрите:

— Когда нужно закончить?
— Хм... 25 ноября.
— Ок, делаем.

Или:
— Когда нужно закончить?
— Хм... 25 ноября.
— Стой, 25 мы должны закончить разработку или выпустить релиз?
— Да, конечно релиз.

Недавно я оказался чуваком из первого диалога. Услышав дату окончания проекта принял ее за дату завершения разработки. Мне повезло — через неделю в разговоре с QA ошибка вскрылась.

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

#процесс #softskills

Сейчас занимаюсь разработкой UI-кита для набора разных веб-приложений. Большая часть интерфейсов этих приложений написана на React, но есть одно очень важное на Angular.

Делать клон библиотеки слишком дорого. Значит, нужно использовать React‑компоненты в Angular-приложении с минимальными затратами. Написал небольшую заметку на Хабр — Angulareact / Хабр.

#фронтенд

До недавнего момента я работал только в аутсорсинге. Тогда я был уверен, что главный продукт компании — приложения или сайты, которые мы делаем. Сейчас я пришёл в продуктовую команду и понял, что ошибался.

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

Часто слышу вопрос: «Где лучше работать: в аутсорсе или в продукте?». У меня нет однозначного ответа, но теперь я понимаю — это работа для разных специалистов.

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

#softskills

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

В JavaScript очень интересно устроен сборщик мусора. Посмотрите доклад об этом — garbage.collect().

#фронтенд #языки