![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Чувство прекрасного
Такая сложно формализуемая штука, особенно для айтишников. Лорд Кельвин говорил – “что нельзя измерить, то нельзя улучшить”. Не уверен, что каждый инженер эту фразу знает, но подспудно верит в неё, кмк, едва ли не каждый.
Вера эта ложная, и чем дальше в XXI век, тем всё сильней это проявляется. И дело тут вот в чём.
Задачки инженерные – те которые задачки, а не просто на движок картинку натянуть или придумать куда выключатель поставить – с каждым днём становятся сложнее. Мы очень круто научились не изобретать велосипедики – и хорошие решения запоминаем всем миром разом. И поверх них генерим новое.
С усложнением задач усложняются и метрики. У этого есть весьма неприятный побочный эффект – на метриках, собранных вчера, часто нельзя сделать никаких выводов о том, что будет завтра.
Хуже того, не вдруг поймёшь, какие из них “вчера”. Я думаю, многие сталкивались с тем, что всеобъемлющая память гугла стала доставлять проблемы – читаешь, бывает, какую-то инфу и только к концу понимаешь, что это старьё. Если вообще понимаешь.
По этой же причине стало практически бесполезно читать учебники по продвинутым развивающимся дисциплинам – за то время, что они писались и издавались, они безнадёжно устарели.
Как же быть? Как принимать решения без метрик или без веры в них?
Чувство прекрасного обладает серьёзной предсказательной силой. Не вообще везде, а нашем мире – потому что наш мир очень зависит от людей, вполне отличающих красивое от некрасивого. Понятие репутации – прямое следствие такого умения, например.
У меня есть наблюдение. Если программист одевается как чучело и в целом неухожен – это скорее всего пустышка. Исключение составляют “системщики” и “оптимизаторы” – но это очень редкие люди и их сияние сразу совершенно затмевает то, как они одеты.
Отличает ухоженных от неухоженных не наличие девушки, не перегруз работой, не ориентация наконец – а наличие или отсутствие чувства прекрасного. Таких людей сразу видно по их работе – это такие кадры, которые могут сказать, что чего-то не существует, потому что этого в задаче не написано или дизайнер не нарисовал.
Если вернуться к лорду Кельвину, понятно становится, в чём в его фразе подвох. Само понятие “улучшить” – двойственное. Улучшать можно количественно, а можно качественно.
И при качественном улучшении применять количественные метрики, основанные на старой модели – это просто самообман. Даже не подсказка, чаще предсказательная сила монетки получается.
С другой стороны это не всегда бессмысленно – хоть такой подход и загоняет неизбежно в тупик, он даёт возможность появляться редким “рекордным” зверушкам. Это когда вытягивали до предела одну-две какие-то метрики. Например SR-71 и U-2, рекордные самолёты – и нереально сложная посадка и пилотирование при дозаправке, даже в симуляторе.
Замечу, правда, что на них глядя моё чувство прекрасного от восторга верещит )
no subject
Проджект-менеджер (ПМ) согласовывает вопрос с заказчиком и далее выдает его дизайнеру в виде: "нужна страница логина с формой, логин, пароль, все стандартно".
Дизайнер, не грузясь, рисует страницу и форму с полями логина, пароля и кнопкой "Войти". Проявляет свое "чувство прекрасного" и добавляет в поле логина плейсхолдер, а поле пароля помечает звездочками. И передает макет программисту.
Опытный программист, увидев такую хуйню, первым делом поинтересовался бы у ПМ: а что там с сохранением сессии? а открытая регистрация будет? а каким образом происходит восстановление забытого пароля? Возможно, поинтересуется логином через OpenID или социалку. В общем, реализовав необходимый минимум, переведет таску на ПМ. А тот, в свою очередь, добавит эти моменты в список обсуждения с заказчиком на ближайшей встрече.
Чуть менее опытный программист, прокрутив все потенциальные геморрои в уме (сделаю по-своему, а вдруг потом переделывать придется, а платят мне сдельно...), просто реализует форму и отметит таску как выполненную.
Вся беда в том, что точно так же поступит и программист-пустышка, который работает "от забора и до обеда". Выполнит таску, ни о чем не задумываясь. А впоследствии огребет от ПМ: почему нет галочки "запомнить меня"? почему нельзя восстановить пароль? где твое чувство прекрасного?!
Во втором случае (с менее опытным программистом) оно никуда не девалось. Просто ПМ - дятел, и невдомек ему, что сохранение пользовательских сессий - это отдельный вопрос политики безопасности системы, а восстановление пароля - целый пучок таких вопросов. Про стороннюю авторизацию вообще молчу. Конечно, если юзать уже готовую CMS или компоненты авторизации, проблема становится менее актуальной, ну да это всего лишь кейс.
Чаще всего такое случается либо с неопытными ПМ, либо с ПМ, имеющими дизайнерский бэкграунд и не видящими внутренней разницы между просто формой и формой с галочкой "запомнить меня". Да, еще часто программист все же на свой страх и риск реализовывает некоторую функциональность самостоятельно. И все равно огребает от дизайнера или дизайн-ориентированного ПМ: как ты мог поставить такой ублюдский кегль? у тебя все окошко съехало на пару пикселей вправо! и т.д.
Программисту чаще всего абсолютно поебать и на кегль, и не на 100% pixel perfect верстку. Точно так же, как и подавляющему большинству других людей, не имеющих дизайнерского бэкграунда. Отхватив люлей, в следующий раз программист просто забьет на самодеятельность и таки обретет пресловутое звание пустышки.
Программисты не дизайнеры.
Если используемый фреймворк позволяет, то они с удовольствием добавят всякие ништяки, заранее не оговоренные в ТЗ, к любой форме. Хороший программист - ленивый программист, он добавляет ништяки в фреймворк так, чтобы они были из коробки. Если только дизайн-ориентированный ПМ не представит такой список взаимоисключающих характеристик к каждой форме, что унифицировать его станет невозможно. Этим страдают и ПМ, и рядовые дизайнеры тоже. Программист, ни разу не слышавший об унификации UX, интуитивно понимает, что выебоны идут во вред юзабилити, а пользователей лучше натаскивать на стандартизированный интерфейс, как мартышек.
Пример - посмотрите на Мегаплан, что программеры, вдогонку нагруженные версткой, сделали с оригинальным дизом от Лебедева :)
В общем, не все так однозначно. Если подобные недоразумения все же возникают, то чаще всего виноват оказывается сам ПМ.
no subject
В моей картине мира в примере мудак – дизайнер. Потому что это его работа – знать тонкие отличия между разными формами и уточнить задачу. Если он этого не делает – как вы пишете "не грузясь" – дизайнер мудак, потому что он впустую потратил как своё время, так и чужое. Чувства прекрасного этот деятель лишён. Потому что это всё равно что принять приглашение на праздник, а адрес забыть спросить.
Опытный программист в этом случае подстрахует мудака дизайнера – тут вы правы.
А если они оба – криворукое говно, ну чтож, значит они оба получат меньше денег, потому что их "делал" никому не сдалось и придётся делать повторно. Вот хорошее про это http://ksoftware.livejournal.com/202173.html
Это совершенно не значит всё, что виноват PM. Потому что разжёвывать дизайнеру форму авторизации – да ну его нахуй, такого "дизайнера".
Дизайн студии Лебедева для Мегаплана – говно полное, и не из-за программеров, а с рождения. Там просто а) неудобный для использования концепт, б) невероятно уёбищный и назойливый маркетинг без работающей обратной связи. Мегаплан – такое же программистское говно, как и 1С-бухгалтерия например. Сложная никому не нужная хрень – в два клика, ежедневные сценарии – в 10 кликов по трём разным экранам.
Про кегль и пиксель в пиксель – ну да ну да. Да только у программиста нет права голоса – пока он не научился пиксель в пиксель и нужный кегль, сам и без пиздюлины, он какбы профнепригоден. Вот как научился – так и появилось право голоса насчёт более высоких материй.
Насчёт "программисты не дизайнеры"... Уточните для себя понятие "дизайн" – http://en.wikipedia.org/wiki/Design. Говнокодеры и копипастеры на php – те да, "не дизайнеры". Они, правда, и не программисты. Любой инженер решает задачи дизайна – потому что есть ресурсы и ограничения, и всё это надо совместить так, чтобы работало. Это дизайн и есть.
no subject
Программист - это человек, реализующий [бизнес-]логику и интеграцию логики с внешней логикой, внутренним и внешним представлением. M и C из MVC - его вотчина. Ему нахрен не сдалось разбираться с V, что-то там доверстывать и продумывать элементы графического дизайна (именно графический я и имел ввиду). Просто хотя бы потому, что он может быть обделен талантом графического представления напрочь. Зато быть мощным алгоритмистом или аналитиком. Считать такого человека профнепригодным можно только в контексте микростудии. Откуда ему лучше съебаться побыстрее, факт. Туда, где больше ценят именно узкоспециализированные программерские навыки и бюджет проектов позволяет иметь специально обученных людей, предотвращающих подобные факапы.
С другой стороны, лучше бы о верстке какое-никакое представление таки иметь, ведь случаи, как мы все знаем, бывают всякие. И если ты гордо называешь себя веб-девелопером, но фейлишь таску из-за того, что вовремя "не доверстали", это, скорее, позор. Позор, что никак не проявил себя в смежной области. Позор, что даже не попытался проявить или, как минимум, заранее предупредить всех заинтересованных участников процесса. Но иногда и проявил, и предупредил, но все равно не сделал. По вполне объективным причинам, то есть, необязательно стал мудаком :)
Ну, а одеваться программер может реально совершенно как угодно. Ему может быть всего лишь несколько посрать на внешнее представление. Для программера V - это всего лишь "вьюшка".
no subject
no subject
no subject
Я думаю вы обломаетесь даже с одним контрпримером.
no subject
Возьмем Твиттер - внизу лежит сторадж (модифицированный InnoDB), разработчикам которого, подозреваю, глубоко пофигу, как выглядит веб-морда. Гораздо более важно то, что именно она отображает, какую функциональность несет и, значит, что в конечном итоге и будет требоваться от стораджа. Отладка взаимодействия стораджа с мордой, также подозреваю, ведется на совершенно схематичных отладочных макетах. Возможно, никто из С-программеров никогда в жизни не сверстает ничего более законченного.
Эти программеры говно? Вряд ли.
Два фронт-эндщика из Твиттера как-то раз решили унифицировать UI. В итоге мы имеем Бутстрап, который захавал половину сети. Хорошо это или плохо, вопрос другой, важно понимать, что эти двое, скорее всего, никогда не программили на сях. И не будут, это будет диким распылением их компетенции.
Эти чуваки, определенно, вовсе не говно.
Ни к тем, ни к другим не имеет отношения Вася Пупкин, который половину дня колбасит визитки и магазины на джумле в студии из 3х человек, параллельно выбивая из заказчиков предоплату (а с других - дебиторку), а вторую половину рисует флеш-баннеры по заказам с фриланс.ру.
Для студии он - находка, для Твиттера - компост.
И еще такой момент. Иногда программер просто не может доделать работу дизайнера, потому что, сука, ну вот вообще не умеет рисовать и даже как смержить слои в фотошопе не знает. Не умеет и все тут. А если бы умел, то получил бы херню. Потому что это тупо не его. Музыкального слуха, кстати, у него тоже нет, например. И получается, что для студии он говно, будь он хоть каким крутым. В более профессиональной и специализированной конторе - уже не говно.
Дизайнеры ведь зачастую сами не отличаются системным мышлением и набросать простейший алгоритм (даже не непосредственно запрограммить) нифига не в состоянии.
Момент номер два. Если ты программер, то тратить лишние 2-3 часа, например, на разборки с заказчиком или говноверстку - это просрать 2-3 часа своей компетенции. Раз, два, еще куда ни шло, на третий раз, если ты не Вася, пора валить.
no subject
Я не предлагаю программеру доделывать где дизайнер залажал – хотя обматерю каэш любого инженера, который мне скажет "я не знаю, как слои в фотошопе свести". Потому что гугл есть.
Но невозможно же между ними абсолютно чётко разделить работу (и ответственность). 5 лет назад можно было, а сейчас – никак.
Или сроки получаются непозволительные, или цена, или результат говно неживое. Это как офис 2007 – в 2003 начали, 2 года придумывали всеобъемлющий концепт юи, а потом 2 года его писали. И выпустили пузыри, которые в 2003 ещё ок были, а в 2007 – ну песец просто.
Хорошие дизайнеры как раз и отличаются от вась пупкиных именно системным мышлением. А вот умение программить – это вообще не показатель системного мышления. Причина простая – программят не для сферических коней в вакууме, а для людей. И значит с точки зрения системного подхода пользователи – вполне себе компонент системы. И коль скоро система проходит стадию создания и развёртывания, макеты тоже компонент системы, а их утверждение потребляет ресурс и это неплохо бы оптимизировать.
Я как раз и пишу про то, что человек лишённый чувства прекрасного из своей поделки людей исключает. То, что подаётся в таких случаях как "системное мышление" обычно банальная ограниченность и непонимание нужд реальных пользователей.