Блог Сергея Копылова

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура фронтенда: смена фреймворка

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

У этого подхода есть ещё один прекрасный плюс: смена фреймворка перестаёт быть невыполнимой задачей.

Если вы используете конфигурации, то компоненты страницы внутри шаблона могут быть написаны на любом фреймворке: AngualrJS 1.x, Angular, Vue.js, React, Svelte и так далее. Вы даже можете их смешивать, и переписывать пошагово, когда часть компонентов использует один фреймворк, а часть — другой.

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

Как начинать решать задачи

Самый первый вопрос, который нужно задать себе, когда приходит новая задача, неважно по работе или нет: «Как не делать задачу, но чтобы результат был?» Часто кажется, что это глупо и вообще нереально, но это только первое впечатление.

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

Скорее всего это бьётся с ТРИЗ, где есть Идеальный конечный результат:

  • «Система сама выполняет данную функцию»;
  • «Системы нет, а функции ее выполняются (с помощью ресурсов)»;
  • «Функция не нужна».

Но близко с ТРИЗ я не знаком, поэтому предлагаю ознакомиться самостоятельно.

Про терминологию

Казалось бы, что специальная техническая терминология должна помогать пониманию ситуации между специалистами. Ну когда не нужно говорить: «вот эта хреновина», и с помощью простого словосочетания становится понятнее, и легче.

Но на деле к этому примешивается другое:

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

Из своего опыта могу вспомнить, когда люди говорили мне: «о, ну нет, это же плохо, у нас нет Третьей нормальной формы в БД!» или «А это точно MVC?». На поверку оказывалось, что ребята сами плохо понимали, что же это такое, когда я просил объяснить своими словами. Хотя, конечно, MVC и Третья нормальная форма — это крутые идеи сами по себе.

Так и с речью вообще. Например, документация к AngularJS 1 написана сухим техническим языком, а к Vue.js — для всех в стили «ну смотри, здесь как-то так работает». И пытаясь научиться чему-то с первым ангуларом, ты чувствуешь себя самозванцем постоянно, а пытаясь сделать что-то на вью — исследователем. И когда я после вью вернулся на первый ангулар, я обнаружил, что там всё так же просто, хотя документация пытается убедить в обратном. Да вы и сами сравните, статью из документации об одном и том же (по смыслу и предназначению) механизме:

Слоты во Vue.js
ngTransclude в AngualarJS 1.x

Да там даже одна и таже штука называется простым словом Слот и сложным Трансклюд!

У вас нет энтерпрайза

Программисты знают, что есть как бы настоящие языки программирования C++, Go, программы на которых компилируются и выполняются очень быстро, и ненастоящие Python, PHP, JavaScript, программы на которых интерпретируются и выполняются медленно. Ну ещё особняком стоит Java, которая вроде и интерпретируемая, но и не совсем.

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

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

Подробнее об этом в статье «Когда не хочется переделывать».

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

Переключись на то, что рядом

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

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

Ранее Ctrl + ↓