Юзабилити и дизайн для программистов

1. Не говорите с пользователями на языке гиков

Обычные пользователи не технари и могут просто не знать, что вы хотите им сказать. Не нужно им показывать сообщение, например, что какая-то DLL библиотека отсутствует или же что COM-объектне может зарегистрировать свойство. Как это поможет им понять и исправить эту проблему? Для большинства пользователей интернета слова как Javascript, CSS и HTML не значат ровным счетом ничего. Они примерно понимают идею браузеров, страниц и этого вашего интернета как-то все этого соединяющего. Сообщение «Ошибка HTTP 404» будет являться для них бесполезной информацией. Лучше сделать что-то типа «Страница запрашиваемая вами не найдена», это объяснит намного больше пользователю. Всякий раз, когда вам нужно сообщить пользователю что то, старайтесь думать о том, как большинство пользователей это поймет. Никто не будет вызывать DllRegisterServer вручную, чтобы исправить вашу проблему с недостающим СОМ-объектом. Но если вы сообщите пользователю, что одна из компонент программы отсутствует (и скажете какой именно), они смогут понять, что возможно нужно вставить диск с этой программой или компонентой и установить её.

2. Не пишите длинные тексты

Потому, что их все равно никто не читает. Да, да вспомните лицензии к программам. Если в Windows + Linux + MacOS добавить строчку, что вы бесплатно отдаете свою душу сатане, 99,9% все равно нажмут кнопку далее. Чем больше текста, тем больше шансов, что пользователь его не прочтет. Эмпирически нечто большее, чем полторы строки будет рассматриваться как длинный кусок текста, а не короткое сообщение и, следовательно, будет игнорироваться. Причиной является то, что пользователи нетерпеливы. Интернет пользователи потратят максимум 5 секунд, чтобы взглянуть впервые на вашу страницу, прежде чем их отпугнет куча текста на ней.

Пользователи заинтересованы только в решении своих задач. Придерживайтесь политики 2–3 слов для заглавия и 5–8 для описания. Используйте так же методы для группировки нескольких объектов интерфейса вместе с помощью цвета или разделяя группы пробелами. Так же очень хорошим решением может послужить наличие специального знака вопроса, на который пользователи могут навести и получить развернутое описание элемента, если оно им понадобится.

3. Забудьте про документацию

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

4. Не перегружайте пользователей множеством элементов

Не используйте на экранах пользователей десятки элементов и средств управления только потому, что вы думаете, что они могут нуждаться в одном из них прямо сейчас. Это приведет к тому, что пользователь будет недоумевать глядя на все это и пытаясь понять, что же ему нужно использовать для того чтобы реализовать задуманное. Определите самые необходимые опции для действий пользователя, все остальное можно скрыть и отображать при нажатии кнопки «Опции». Пользователь в таком случае будет меньше отвлекаться и выполнять свои задачи быстрее. Простота это хорошо. Для более продвинутых пользователей или просто любопытных будет окно с опциями.

5. Один экран — одна задача

Дизайн каждого окна программы, страницы или окна диалога должен быть сосредоточен на одной конкретной задаче. Если есть диалоговое окно, чтобы загрузить фотографию, не добавляйте параметры для удаления пыли и царапин или печати фото. Это может быть полезно позднее, но прямо сейчас пользователь хочет только загрузить фото. Когда пользователь видит большое количество возможностей для своих действий, он может отвлечься от своей задачи и начать изучать эти возможности, с легкостью забыв о том, что хотел сделать.

6. Создавайте простой и интуитивный интерфейс

Ничто не может раздражать пользователей столь же сильно, как понимание, что есть какая-либонеобходимая им функция, но они не могут найти её в ваших меню и диалоговых окнах. Это сильно раздражает. Пользователи чувствуют, что они не могут управлять программой. Это как одна шутка на темувеб-дизайна: «Знайте, вы потерпели неудачу с дизайном, если пользователям нужно использовать поиск браузера (Ctrl+F), для того, чтобы найти вашу панель поиска». Очень важно чтобы идея программы была простой и логичной, и тогда дизайн навигации будет отражать эту модель. Объединяйте функционал в логические группы. Давайте пользователям подсказки как они могут изменить стандартные настройки. Постарайтесь сделать так, чтобы пользователь мог легко догадаться, где он может найти необходимый ему функционал, конечно если он реализован.

7. Выделяйте важные элементы

На экране или странице должны выделяться элементы, которые имеют решающее значение для выполнения основных функций. Эти элементы должны быть легко различимы как основные элементы управления. Вспомогательные элементы должны так же просто идентифицироваться как таковые. Они должны легко находиться пользователем на странице, но в, то, же время четко воспринимаемыми как вспомогательные. Это может быть реализовано с помощью, приглушенных (затемненных или осветленных) цветов, меньшего размера шрифта, или просто быть отделены от основных элементов. Когда пользователь знает, что важно, а что нет, он сможет быстрее выполнить задуманную задачу. Если все элементы выглядят одинаково, это может запутать пользователя. Пользователь должен либо попробовать их все, или же попытаться понять, какие элементы более важны, а какие нет. Это замедляет работу и требует дополнительных усилий от пользователя. Одно очень важное правило в дизайне интерфейсов гласит: «Не заставляй меня думать». Это следует принимать во внимание во время работы над интерфейсами.

8. Сфокусируйтесь на действиях пользователя, а не на возможностях программы

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

9. Перенесите часто используемый функционал на первое место

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

10. Минимизация кликов

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

11. Избегайте не привычного поведения интерфейса

Одна из ошибок, которая точно смутит пользователей — это использование не стандартных элементов интерфейса с не стандартным видом и что ещё серьезней с не стандартным поведением. Обычно такое можно увидеть на сайтах с оригинальным дизайном, где веб-мастера могут дать выход своему креативу. В результате получается отличный дизайн, и красивый и функциональный. Но иногда креатив берет на себя функции по юзабилити и этим создает барьер между пользователем и программой. Примеры легко найти. Например, ссылки без подчеркивания или когда они имеют цвет, слабо отличающийся от цвета остального текста. Или, например области экрана выглядящие как большинство других, но реагирующих на нажатие или открывающих другое окно. Вот один из примеров с сайтом Flickr. Когда вы хотите изменить заголовок фотографии, вы можете потратить много времени чтобы понять, как вам это сделать. Я потратил немало времени, прежде чем случайно нажал на текущий заголовок. Этот текст выглядел обычным, как другой на странице, но при нажатии превратился в поле ввода. Это не интуитивно, и пользователю сложно догадаться о таком поведении. Таких случаев стоит избегать. Когда интерфейс реагирует по-другому, чем ожидает от него пользователь, это плохо. Зная это, вы должны с осторожностью объединять креатив и юзабилити, стараясь не навредить удобству пользователя.

12. Создавайте единообразное оформление

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

13. Уберите ненужные элементы

Взгляните с практической стороны на свой интерфейс и спросите себя, все ли эти элементы нужны для эффективной работы пользователя. Объясняет ли текст функционал, который может использовать пользователь или он, чтобы пользователю было не скучно? Чем меньше ненужных и вспомогательных элементов будет на экране, тем более простым и открытым он будет выглядеть. Все ли элементы должны быть видны сразу? Если нужны только некоторые из них, возможно, стоит перенести редко используемые элементы в диалоговое окно «Дополнительно». Чем меньше ненужных элементов будет видеть пользователь, тем легче ему будет работать над своими задачами.

14. Не задавайте уйму вопросов

В процессе общения с пользователем постарайтесь свести к минимуму количество запросов, где пользователь должен сделать выбор. Если это момент когда пользователь должен ответить на заранее определенные вопросы, дайте возможность выбрать оптимальный ответ по-умолчанию. Иногда, программы просят сделать выбор во время первого запуска. Это неправильно, так как в большинстве случаев пользователь ответит на поставленные вопросы неверно, особенно если ответы требуют специфических знаний, которые пользователь сможет получить только после опыта работы с программой. Поэтому если вам необходимо определить какие-либо настройки до старта программы, предлагайте пользователю стандартные настройки и если он уже имел опыт работы с программой, он изменит необходимые свойства, а если нет, это не введет его в тупик, и он сможет использовать определенные вами настройки. При создании таких вопросов, попробуйте посмотреть на них глазами пользователя. Думаю не стоит в самом начале спрашивать насчет форматов данных, синхронизации и функций с которыми пользователь ещё не сталкивался. Определите настройки так, как это было бы полезно начинающему пользователю (скажем включение максимального количества подсказок и советов) и дайте возможность пользователям со временем изменить данные настройки.

17. Используйте небольшой набор цветов

В своем интерфейсе постарайтесь не использовать много цветов, 2–3 будет вполне достаточно. В основном это касается веб-страниц. Определите цвета для основного текста и пользовательского ввода. Используйте эти цвета на всех страницах или окнах вашего приложения. Если вы используете оранжевые кнопки с красным текстом, используйте их везде. Если вы посмотрите на продукты больших компаний, то сможете увидеть, что в основном во всем продукте используется 2–3 цвета (черный и белый не учитываются). Если же вам нужен плохой пример посмотрите на сайты интернет магазинов, там будет много ярких цветов, чтобы привлечь внимание. С точки зрения маркетинга, возможно, это и хорошо, но с точки зрения юзабилити — это ужасно.

16. Адаптируйтесь к мышлению пользователей

Вне зависимости, какой концепции дизайна вы придерживаетесь, оцените его критически. Посмотрите на него глазами пользователей. Представьте себе обычного пользователя, со знаниями работы в таких же программах как ваша. Смогут ли они сразу понять идею вашего дизайна, если они не являются ни разработчиками, ни дизайнерами и не обладают обширными знаниями работы с компьютерами? Смогут ли они догадаться, что делает та или иная функция или стоит добавить небольшое объяснение? Смогут ли они найти какие-нибудь настройки, только представляя где они должны находится? Поведение вашего интерфейса похоже на поведение других программ или отличается и потребуется время на адаптацию? Похож ли ваш интерфейс и поведение на другие схожие продукты? Чем больше будет разница, тем больше потребуется времени на изучение (пример — Ribbon в MS Office). На веб-сайтахс высокой конкуренцией, пользователь может просто закрыть браузер, если не поймет, как с ним обращаться, и перейти на другой схожий сайт всего за пару кликов. Для большинства пользователей оформление вашего продукта определяет его суть. Не сложные алгоритмы, совершенные структуры данных или отличная архитектура, а простой интерфейс, его вид и поведение. Именно это. Это то с чем столкнутся пользователи, прежде чем узнают о ваших отличных алгоритмах и возможностях программы.

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

Что такое ООП?

ООП
Принцип объектно-ориентированного программирования (или просто ООП) - относительно новый и очень эффективный подход к программированию.
Раньше разработчики писали программы, в которых весь код умещался в одном файле. Это могли быть как маленькие программы, так и довольно крупные проекты. Со временем программы становились все крупнее и крупнее, что очень сильно мешало разработчикам, ведь крайне сложно вносить какие-то изменения в этот один огромный код. Особое неудобство создавала проблема с использованием большого числа похожих объектов - написать программу для работы с 50 палитрами, в каждой из которых по 12 цветов - самоубийству было подобно. Проблема требовала решения - и оно пришло в виде ООП.
Так в чем же оно заключается? Основная идея ООП - объединение данных и обрабатывающих их процедур в единое целое - объекты. Программа представляет из себя совокупность объектов, каждый из которых является реализацией определенного класса (особый тип данных), а классы образуют иерархию, которая может быть унаследована от других классов.

Пример
Проще всего понять этот принцип можно на примере транспортного средства. В мире есть огромное количество самых разных транспортных средств - автомобили, самолеты, гужевые и т.д. Что общего у них всех? Они позволяют перевозить людей и грузы на дальние расстояния. Больше у них нет практически ничего общего. В данном случае, классом будет являться "Транспортное средство" с одним данным(полем данных класса) "Возможность перевозить на дальние расстояния". Заметьте, что "Транспортное средство" мы не сможем использовать, пока не уточним что именно оно из себя представляет! А вот если взять уже конкретный автомобиль - его можно назвать объектом, потому что он готов к использованию и у него есть свои особые свойства: форма, цвет, количество колес и т.д.
Допустим, что мы купили 1 красный BMW, 1 белый самолет и 1 синий мотоцикл. Итого у нас есть целых 3 объекта - наследника базового класса "Транспортное средство" (о наследовании написано чуть ниже). Но при этом класс у нас остается всего 1! Внеся изменения в этот базовый класс, мы изменим все 3 наших объекта сразу!
Возможно, что вы еще не знакомы с принципом ООП, поэтому вам кажется, что это все жутко сложно. Поверьте, это не так. Без ООП нам пришлось бы создавать эти 3 объекта вручную, что при малейших изменениях приводило бы к ужасной головной боли!

Основные понятия ООП
Объектно-ориентированное программирование базируется на нескольких понятиях. О них вы сможете узнать из других статей на сайте студентов-партнеров Microsoft, но краткое описание стоит прочитать уже сейчас.
Абстракция данных. Можно делать упрощенные классы, в которых не вся информация конкретизирована, но с которыми легче работать. Это позволяет очень просто создавать нужные классы при наследовании.
Наследование. На базе одного класса, создается другой класс, содержащий свойства и методы базового класса, его называют потомком. Пример из жизни - я потомок моих родителей, при этом у меня есть все их свойства с некоторыми дополнениями/изменениями.
Инкапсуляция. Чтобы пользователь наших программ не мог изменить что-то важное внутри программы, классы строятся таким образом, что напрямую работать с внутренними данными нельзя - только через специальные методы.
Полиморфизм. Функции(методы) с одинаковыми именами будут обрабатываться по-разному при их вызове из разных классов.

ASP.NET MVC шпаргалки

Думаю, многие из вас уже нераз встречали шпаргалки и постеры по различным технологиям или языкам. Помните, как порой просто необходимо хоть глазком взглянуть на шпору, чтобы вспомнить ответ на билет? Так и тут, чтобы не лезть в MSDN или Google иногда проще взглянуть на постер и вспомнить необходимую вам вещь. В этом посте хочу поделиться шпаргалками по ASP.NET MVC. Надеюсь они помогут вам так же как и мне.

ASP.NET MVC: The Request-Handling Pipeline

Показано, какие основные архитектурные компоненты ASP.NET MVC Framework используются при обработке запроса. Описаны общие функции маршрутизации, контроллеров, действий и представлений.

ASP.NET MVC: Framework

Показана общая архитектура фреймворка, структура папок, процесс выполнения и т. д.

ASP.NET MVC: Controller

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

ASP.NET MVC: View

Показаны различные HTML и URL помощники (helpers), а так же все, что поможет при работе с представлениями.

ASP.NET MVC: Proven Practices

Ну и напоследок несколько полезных практик при работе с ASP.NET MVC. Хотя они явно не претендуют на полноту.

Визуализация AJAX запросов

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

Держите пользователя в курсе событий

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

Простые индикаторы

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

• Если в текстовом виде, то не забудьте указать соответствующее смысловое сообщение, например, "Отправка электронной почты ...". Сообщения типа "Ожидание ..." может запутать пользователей. Чего я жду? Что-то случилось с системой?
  


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

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

Индикаторы выполнения

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

Dropbox предоставляет графический индикатор статуса, а также текстовые сообщения о состоянии.

Расположение индикатора

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

Отключайте элементы пользовательского интерфейса во время Ajax запроса

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

Выделяйте обновленные области

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

Заключение

Чтобы сделать Ajax функциональность более понятной пользователю, вы должны предоставить информацию о состоянии системы во время запроса и после завершения запроса. В общем, это можно свести к нескольким пунктам:

• Использовать текстовые и(или) анимационные индикаторы;
  


• При длительных запросах использовать показатели прогресса;
  


• Отключать элементы интерфейса во время запроса для предотвращения возможных ошибок;
  


• Выделять области, обновленные Ajax;
  


• В некоторых случаях рекомендуется показывать сообщение с указанием статуса проведенной операции.
  

UPD: добавил еще один ресурс ajaxload

Программисты

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

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

А в это время, в соседних четырех кубиках, будет ни на секунду не утихать работа китайских программистов, непостижимым образом умудряющихся прийти раньше русского программиста, уйти позже, и при этом сделать примерно втрое меньше. Эта четверка, давно не пишет никакого кода, а только поддерживает код написанный, в свое время индусом и дважды переписанный двумя разными русскими. В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии реиспользования кода — copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных переданных по ссылке (поскольку, китайский программист не может смириться с неудобствами вызванными тем, что он не может изменить значение внешней переменной переданной в его функцию модулями, которые переписывает русский программист).

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

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

О, канадский программист это особый тип. Он ни на минуту не задумываясь, как рыцарь без страха и упрека, бросится фиксить самый свирепый баг китайского кода. Этот Баг живет там уже три года, и китайцы уже четырежды (каждый по разу) сообщали начальству, что он пофиксен. Но Баг каждый раз возвращался, как Бетмен в свой Готхем. Итак, канадский программист сделает то, чего китайцы не рисковали делать в течении трех долгих лет. Он, при помощи дебагера, отследит место, где статическая переменная приняла значение -1 вместо правильного 0, и решительным движением заведет рядом вторую переменную с правильным значением. Баг погибнет в неравной схватке с канадским программистом.

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

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

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