Позднее Ctrl + ↑

Про уверенность

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

К тому времени текущие продукты были сделаны на смеси Java + Spring + Angular 1 + JQuery. То есть на сервере хранились .jsp-странички к которым были подключены JS-библиотеки, лежажие прямо здесь, устаревших версий, в которых предыдущие программисты ещё что-то меняли руками, поэтому обновлять их не было никакой возможности.

К тому времени я начитался в интернете о том, что существует какой-то npm-репозиторий с библиотеками, что есть React.js и какие-то другие фреймворки, что есть какой-то компонентный подход, который используется в новом Angular 1.5 в том числе. Ещё мне откровенно не нравилась Java на бекэнде. Мне представлялось, что у нас вырос какой-то невероятный энтерпрайз-монстр, который в первую очередь обслуживал сам себя, а не мифическую высокую нагрузку.

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

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

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

Всё закончилось хорошо. Продукт мы разработали в срок, на его основе выросли огромные проекты.

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

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

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

Можно делать меньше

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

На работе мы часто обмениваемся скриншотами, на которых помечено куда смотреть. Часто люди ставят специальные программы и следят за тем, чтобы их подчёркивание или выделение были ровненькими. А нужно так:

Притом так даже лучше, чем когда ровненько: ты сходу понимаешь, что выделение — часть скриншота, а не самого интерфейса.

Или, например, при работе над дизайн-проектом можно сначала сделать коллаж из мебели, а не 3D-визуализацию. Прикинуть, как будут сочетаться цвета и мебель по нему можно, исправить будет легко, а силы на визуализацию не будут потрачены.

Так что не только можно, а нужно делать меньше.

Про курсы обучения чему-нибудь

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

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

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

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

В общем-то то же самое, касается и университета. Самое крутое в нём — возможность общаться с однокурсниками и преподавателями. Ну ещё диплом и допуск к чему-то такому, что так просто не попробовать, если это важно в вашей сфере.

Меняться местами

Когда мы играли в музыкальной группе, то часто через час репетиции менялись местами. Гитарист — за барабаны, вокалист — за бас, басист за гитару и барабанщик на вокал. Ну или как-нибудь по-другому.

И так мы играли пару песен. Получалось, конечно, паршиво, но суть не в этом. А в том, что в такие моменты можно лучше понять, что именно делает другой человек в группе, как он это делает, что важно и что нет, а ещё понять, что другие-то тоже нехило так стараются.

И так, конечно, стоит делать в любом коллективе.

Архитектура: скорость работы

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

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

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

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

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

  • Сделали индексы в БД
  • Запрашивали столько информации, сколько нужно отобразить сразу
  • Кешировали запросы

Со временем, когда документов и таблиц стало очень много, мы всё таки вернулись к лоадеру, только системному. Мы меняли курсор мыши на курсор с загрузкой, если загрузка идёт больше половины секунды. Это решение хорошо тем, что для него не нужно что-то серьёзное программировать отдельно, что оно будет естественным образом работать на любом ПК (мы разрабатывали только дескопные версии продуктов), но оно всё равно говорит только о том, что мы недостаточно хорошо решили задачу.

К примеру, можно было бы:

  • Разделить данные в БД на актуальные и нет и хранить их в разных таблицах
  • Хранить копию БД в оперативной памяти и получать данные из неё
  • Осуществлять кеширование на уровне NGINX, не обращаясь к бекэнду и к БД
  • Хранить редкоменяющиеся данные в хранилище браузера

и наверняка ещё множество манипуляций, которые хорошо известны ребятам из ВК или Ютьюба, у которых есть по-настоящему много данных и много пользователей

Как сделать, чтобы на общественном транспорте ездили вечером

Стоишь ты такой на остановке в 22:50 и стоишь уже 10 минут. И думаешь: хм, а ходят ли вообще троллебусы и автобусы? И даже если ты найдёшь расписание в интернете, задумаешься, правдиво ли оно. И приложение с отображением транспорта на карте работает непонятно как, и вот ты уже вызываешь такси.

А какому-нибудь троллейбусному управлению достаточно сделать вот так:

С сегодняшнего дня последний троллейбус с каждой конечной станции отправляется в 23:00 или позже, что бы ни случилось.

И рассказать об этом во всех местных СМИ и на сайте администрации. С этого момента, встав на любой остановке в 23 часа ты будешь знать, что уедешь домой.

Дизайн счетов

Мы с Ритой Коржавиной запилили новый дизайн счетов за квартиру.

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

Мы решили начать с главного: написать крупным кеглем сумму счёта, месяц и за что ты платишь. Тут же разместили QR-код, как самый удобный способ оплаты. Этого уже достаточно для того, чтобы оплатить счёт.

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

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

В особенности интересно, что та сумма, которую ты должен заплатить по счёту в текущих квитках называется «Долг». Формально это верно, и даже в каких-нибудь бухгалтерских документах так и называется, но в мире клиента — это когда ты должен что-то за что-то из прошлого, ведь как ты мог заплатить до получения счёта? Мы избавились от этого слова.

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

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

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

Кто скажет, о чём мы не подумали?

Помыть руки при входе

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

Понятный интерфейс

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

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

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

P.S. Ну и дети, которые не умеют читать, тоже смогут им пользоваться.

Как считать, хорошо ли работает разработчик?

В первый год своей работы разработчиком в компании я сильно переживал, что не могу состредоточиться и программировать целый день, 8 часов. Я от силы мог программировать часов 6, и кое-как писать что-то в оставшиеся часы. На следующий день я приходил и переделывал тот ужас, что написал вчера вечером. Я вечно отвлекался, открывал Хабр, ВК, что-то ещё и боялся, что разработчик из меня так себе.

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

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

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

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

Так что рецепт простой:

  • Спрашивать результат не чаще, чем в несколько дней;
  • Ставить чёткие дедлайны по группе задач;
  • Не контролировать число часов или строчек кода.
Ранее Ctrl + ↓