Самый большой бред — когда в журналах, газетах или блогах на выносках пишут то, что есть в основном тексте. Ну как так, ты заметил выноску и хочешь узнать, что-то уникальное, а потом это уникальное встречается в статье слово в слово. Не надо так. На выносках, фактойдах и подписям к фотографиям напишите или новое, или сделайте акцент на числе.
Меня, бывает, спрашивают о том, как что-то реализовать, когда элементов очень много.
Например:
На странице отображены 100 000 товаров и у каждого есть кнопки действий. Как указать обработчик событий для этих кнопок так, чтобы не множить функции? Постраничного листания нет, подгрузки при прокрутке тоже.
или
На странице отображаются 5 000 товаров с партиями, остатками, необходимо изменять эти данные. Что бы вы стали делать, если бы страница стала тормозить? Как бы вы искали источник проблемы?
Да никак бы я не искал источник проблемы. Потому, что источник уже найден — это вывод на экран тысяч экземпляров данных.
В этом нет никакой необходимости. Никакой человек не может управлять данными, когда их тысячи. Нашему мозгу уже и 30 штук — довольно много. Правильное решение: сделать так, чтобы на фронтенде не отображались, не хранились, и не обрабатывались тысячи элементов. Тогда и не нужно будет решать эти надуманные задачи.
Я много лет занимался чем-то в небольших группах. Дольше и плодотворнее всего в музыкальных группах и на работе (на работе я делаю интерфейсы к программам). И я давненько открыл один секрет, смотря, как работают другие, и как работаем мы, и к чему это всё приводит.
Так вот, секрет такой: нельзя ничего решать голосованием, нужно выбрать человека, который будет принимать решения и довериться ему.
Голосования приводят к спорам над каждой проблемой, длинным обсуждениям, уговорам сомневающихся, закулисным интригам, когда кто-то договаривается проголосовать так, как нужно одному из них. И каждое решение принимается через боль и через вечность. Так каши не сваришь.
В подходе с выбором ведущего важно, что у него появляются не только право принятия решений, но и обязанности: учитывать мнение каждого и нести ответсвенность за решения. Короче, процесс принятия решений происходит следующим образом:
Здесь не нужна какая-то формальность в пунктах и последовательности, нужно просто примерно понимать процесс.
А у всех других ребят остаётся право сменить этого человека на другого, если что-то раз за разом не нравится.
Ещё очень круто, если такими лидерами становятся все в группе, но только в своей сфере: кто-то отвечает за одно, а кто-то за другое. Особенно это круто тогда, когда нужно принимать много решений, а ещё хорошо потому, что каждый чувствует и личную ответственность тоже.
Короче, никакой прямой демократии, только представительная. Думаю, что и в больших группах всё так же.
P.S. На всякий случай отмечу, что я много раз был как и тем, кто принимает решения, так и тем, к мнению которого просто прислушиваются.
Разберём случай, когда до дизайнера или разработчика доходит какая-то задача, сформированная цепочкой менеджеров и аналитиков по чаяниям заказчика на конкретном примере.
Возьму пример из области медицины, в которой проработал несколько лет. В общем смысле задача обычно звучит как-то так: «Отобразить список свидетельств о рождении, которые регулярно приходят из медицинских организаций.»
Обычно до разработчика доходит какая-то такая задача:
«Необходимо создать страницу с отображением всего списка свидетельств, с возможностью изменения набора столбцов и фильтров. Изначальные наборы столбцов такие-то, наборы фильтров такие-то. Обеспечить разный уровень доступа для разных пользователей, возможность создания и подписания новых документов, выгрузки в EXCEL, XML, CSV, PDF, Word сохранения истории изменений. Ктопку такую-то разместить здесь, такую-то здесь, вот эту сделать зелёной. Набор полей документа формируется с учётом ФЗ № такой-то такой-то, ...»
И так ещё 10 страниц. Это совершенно ужасная постановка задачи, которая одновременно подразумевает, что дизайнер или разработчик тупой, как дрова, и может действовать только по алгоритму. И с другой стороны, она перекладывает на разработчика самые ресурорсоёмкие операции, как, например, поиск набора полей в каком-нибудь приложении к федеральному закону.
Разработчику говорят, что делать, но не говорят, почему. Нет ответов на следующие вопросы:
Ну и так далее. Зато есть ненужные подробности о расположении кнопок и перечисления «как бы» форматов файлов выгрузки. Конечно, здесь очевидно, что менеджеры не смогли узнать реальную проблему заказчика и как решить именно её имеющимися средствами.
Неопытный разрабочик просто возьмёт это в реализацию не думая и начнёт программировать шаг за шагом. Задача окажется трудновыполнимой даже за несколько месяцев (что его тоже не побеспокоит), всё будет тормозить потому, что для такого общего решения недостаточно просто добавить индексы в БД, чтобы всё работало быстро, и в конце концов, когда задачу покажут заказчику, у него полезут глаза на лоб и он удивится, как такую неповоротливую махину можно было делать несколько месяцев, когда она всё равно не работает, потому, что оттестировать все варианты поведения и отображения такой махины невозможно.
Если же пообщаться с заказчиком, слушая не только предложенное решение, а ещё его проблемы, то всё станет на свои места. Окажется, что с этим списком должны работать такие-то врачи и работники загса. Что права на изменение и добавление такие-то. Что любые поля нужно отображать, чтобы было видно, отфильтровалось или нет (конечно, здесь нужно придумать другое решение), что вывод всех документов сразу не нужен, а нужен в разрезе по медицинской организации.
Такую задачу уже можно сделать за неделю, и, даже если какие-то из требований были описаны неверно, у нас есть ещё много времени, чтобы это исправить.
А может оказаться, что сегодняшнего списка документов любых типов с фильтрацией по типу уже достаточно для решения этой задачи и нам не нужно делать ничего, кроме настройки шлюза для получения этих документов от медицинских организаций. Вот и экономия месяцев труда команды на пустом месте.
Короче, Варламов топит за мангал в каждый двор, а я буду топить за турник и ровную площадку в каждый двор.
Серьёзно, для обывателя не нужно ни рукоходов, ни брусьев, ни лестниц, а достаточно одной загогулины и поверхностью под ней, чтобы отжиматься и всякое такое делать не пачкаясь.
Короче, вот такая штука, как у Лебедева, только с одним турником.
А ещё в подъезде нужно между 4 и 5 этажом турник на стене повесить на зимнее время.
P.S. За картинку спасибо Рите.
Когда люди начинают играть на гитаре, они много задумываются над постановкой пальцев, над тем, чтобы нужные нотки звучали, о том, как издавать звук медиатором. И некоторые остаются на этом этапе, не сумея сыграть ни одной песни потому, что там нужно быстро аккорды менять.
Поэтому нужно идти играть в группу, а в группе вводить правило, что если ты ошибся, нельзя останавливаться. Останавливаться можно, если появилась отличная идея, но основная задача — сыграть всю песню. Конечно, по-началу ты ошибаешься постоянно и ничего не получается, но со временем образуется навык, и ты играешь уже не задумываясь о постановке рук и так далее. И это очень пригождается на концертах, когда тебе нужно общаться с залом, а не смотреть на гриф.
То же самое с разговором на иностранных языках. Пока ты учишься, ты допускаешь много ошибок. Если ты будешь задумываться о каждой ошибке, то ты не сможешь говорить. Поэтому и переезд к носителям помогает очень быстро — ты вынужден доносить свою мысль несмотря на ошибки, а их сможешь исправить уже после.
Вероятно, подобные вещи можно уловить и в отношениях — пока ты переживаешь о каждом неправильном слове, отношения целиком строятся очень медленно.
Но есть и следующий этап.
Даже если ты выработал навык, но стал снова на новом уровне задумываться о том, как именно это делать, ты можешь снова потерять возможность играть или говорить.
Поэтому задумываться, конечно, очень важно, но важнее — делать, и начинать раньше, чем ты со всем разобрался (потому, что невозможно со всем разобраться).
Когда я собрался увольняться из компании, в которой вёл большой проект со стороны интерфейса, к нам пришёл молодой разработчик сразу после университета. Он не знал конкретных библиотек, которые мы использовали.
За этот месяц я рассказал ему, что необходимо, и он довольно быстро включился в процесс. По прошествии нескольких месяцев, бывшие коллеги рассказали мне, что так получилось, что сейчас он единственный поддерживает разработку интерфейса этого большого проекта. И что разработка идёт вполне себе устраивающими темпами.
У него есть мои контакты, но он ни разу мне не писал. Конечно, он может спросить что-то у коллег, но и они говорят, что он не так часто это делает.
И это комплимент для меня. Если большую систему с сотнями представлений и страниц можно успешно поддерживать не имея большого опыта, то это значит, что та архитектура, те принципы, которые были использованы были правильными.
Однажды ко мне пришёл менеджер и сказал, что нужно сделать развёрнутую систему прав. Я был ведущим разработчиком на проекте, у меня оставалось два дня до отпуска, а систему прав нужно было выпускать через 2 недели, когда я ещё буду в отпуске.
Я задумался. К тому времени у нас была очень простая система прав. У нас было что-то вроде 7 разделов и если кто-то имел доступ к разделу, то мог делать в нём всё. Теперь требовалось сделать так, чтобы для разных пользователей были доступны или нет конкретные действия и кнопки: просмотра, редактирования, удаления.
Но были и плюсы:
Я написал за несколько часов заглушку бибилиотеки, проверяющей права. Договорился с бекэндером о том, в каком формате он будет присылать список прав для каждого пользователя. И рассказал своей команде, что именно нужно делать для того, чтобы всё заработало.
И пошёл в отпуск.
Когда я вернулся, система была готова и выпущена, в отпуске меня никто не тревожил, а ребята смогли придумать пару вещей, о которых я не успел подумать до отпуска, но которые несколько улучшили систему.
Я обрадовался. Если ребята могут это сделать без меня, то значит, что код, который я написал понятен, подход, который я предложил тоже, подготовка ребят достаточная, а я могу не тратить время на такие задачи и переходить на ещё более сложные.
А вот если бы мне каждый день звонили в отпуске, то это бы значило не то, что ребята не знают границ, а то, что я недостаточно хорошо объяснил и подготовил работу.
Меня часто спрашивали что-то такое: «А не боишься ли ты, что если автоматизируешь свою сегодняшнюю работу, то тебя просто уволят за ненадобностью?» И я видел, как много людей топчатся на месте, лишь бы этого не случилось.
Мне всё время это казалось ересью. Наоборот, если ты автоматизируешь то, что уже умеешь делать или отдашь это молодому коллеге, то у тебя освободится время для того, чтобы делать что-то на уровень выше или просто другое. Например, если ты автоматизируешь создание новых страниц и на каждую страницу станет уходить два часа, а не три дня, то после этого можно будет провести исследование, какие именно страницы удобнее: ведь менять их вариации теперь легко. Или, можно будет остановиться на скорости работы программы, посмотреть на нёё в комплексе. Если бы автоматизации не было, то и времени бы на это не осталось.
Конечно, такими путями через несколько лет ты и вправду может упереться в потолок внутри конкретной компании: все необходимые для роста продукта вопросы уже решены. Ну что ж, в таком случае, можно либо придумать, что ещё полезного ты можешь сделать, чтобы приподнять этот потолок, или найти компанию, где твой сегодняшний опыт будет началом пути.
Сделали мы новый проект и пришло время его тестовой эксплуатации.
В компанию приехал технический пециалист заказчика и стал задавать всякие каверзные вопросы. Сначала с ними справлялся менеджер, но в какой-то момент перестал и в кабинет позвали меня, как ведущего разработчика проекта.
Представитель заказчика задал какие-то вопросы, о которых мы подумали и на которые я знал ответ и вот прихоло время следующего вопроса. Он говорит:
В моей голове завертелось следующее:
И я сказал: я думаю, что нам не нужно будет ничего программировать. Мы сможем вынести таблицу с историей на другой сервер посредством возможностей СУБД.
Представитель удивился, сказал, что хорошо, если так и я пошёл на рабочее место. Там я спросил у бекэндера, был ли я прав. Он ответил, что да, и что это называется «внешние таблицы».
Мораль в том, что проспо подумав и прикинув вероятность того, что что-то работает так, как тебе нужно, ты можешь придумать решение для разных ситуаций. Правда для этого нужен какой-никакой кругозор.
Поэтому я и трачу существенную часть рабочего времени на то, чтобы этот кругозор нарасти и не потерять.
