Знание английского для ИТ специалиста — это одно из важнейших профессиональных качеств. Поэтому процесс изучения английского языка должен быть непрерывным. Для изучения рекомендую сайт Common Errors in English Usage, где собрано много типичных ошибок использования различных слов и выражений.

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

Тема DI/IoC достаточно простая, но в сети очень сложно найти хорошее описание того, как это работает и зачем это нужно. Вот моя попытка, с использованием Unity. Хорошо ли объяснена тема – судить вам.

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

Проблема

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

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

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

В статье «Обзор C# 4.0» я обсуждал некоторые из новых особенностей четвертой версии языка C#. Так получилось, что я не рассмотрел одно из самых важных нововведений: ключевое слово dynamic.

Небольшой отчет o конференции AgileDays Екатеринбург ‘2010, я уже публиковал. Теперь ScrumTrek выложили слайды презентаций и видео докладов.

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

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

Вольный перевод статьи Азы Раскина How To Critique An Interface.

Людей далёких от дизайна часто просят высказать своё мнение об интерфейсе. Быть может вы директор компании, а исполнитель просит оценить ваш новый сайт. Или вы руководитель проекта и недоумённо смотрите на макеты вашего дизайнера. Как вы оцениваете дизайн? На что обращаете внимание? И как вам ответить что-то более внятное, чем «Вот выглядит клёво!» или «Убери это с глаз долой!».

Сложно ответить на эти вопросы в такой короткой статье, но я приведу хотя бы несколько советов:

Кто заинтересован в ИТ-стартапах?

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

Фактически же мы видим огромное количество новых ИТ-компаний, с разным размахом (зависит от объема инвестиций) стартующих, но крайне редко достигающих результатов. И даже самые успешные проекты очевидно достигают менее значимых в финансовом плане результатов чем строительство, торговля, работа в госорганах и т.д. Четкой статистики не имею (да и нет ее), но сами решите — когда у Вашего дома паркуется автомобиль за 100-150 тысяч у.е. — какие первые десять профессий приходят на ум? а еще десять? а еще?… когда в списке тех кто потенциально может позволить себе такую машину появится владелец ИТ-компании?

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


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

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

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

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

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…

Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
— А как тебе новые версии поставлять?
— Можешь как все остальные на проекте, через SVN.
— То-есть ты сама билдить будешь?
— Да нет… Бинарники оттуда беру.

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

Слово «виртуализация» в последнее время стало какой-то «модой» в ИТ-среде. Все вендоры железа и ПО, все ИТ-компании в один голос кричат, что виртуализация – это круто, современно, и нужно всем. Но, давайте, вместо того, чтобы идти на поводу у маркетинговых лозунгов (а иногда бывают такими, что сам Геббельс умер бы от зависти), попытаемся посмотреть на это модное слово с точки зрения простых «технарей» и решить, нужно нам это или нет.

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

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

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

Думаю не ошибусь, если напишу, что каждый программист когда-либо пользовался отладчиком, отлаживал программу пошагово, устанавливал брейкпойнты и т.п. При этом некоторые программисты не любят отлаживать. Другие — обожают. А большинство просто использует отладчик не задумываясь о любви и ненависти, ведь это просто еще один удобный инструмент для работы.
Для многих программистов отладчики — это черный ящик. Они умеют с ним обращаться, но не знают, как он работает. Я не говорю, что это плохо — в подавляющем большинстве случаев можно легко отлаживать программу без знания устройства отладчика.
А для тех, кто хочет заглянуть внутрь черного ящика, я написал эту небольшую статью.
Тут я расскажу про одну из самых загадочных (по крайней мере для меня) возможностей отладчиков — про работу с брейкпойнтами. Я постараюсь рассказать это максимально просто и без лишних деталей. Однако я пишу эту статью для тех читателей, который уже знают что такое брейкпойнты и умеют их использовать.

Вы когда-нибудь задумывались, что происходит, когда вы нажимаете «Вставить брейкпойнт»? Или о том, как отладчик может добавлять брейкпойнты в код на лету и удалять их? О том, как работают брейкпойнты с условиями? О том, тормозят ли множественные установленные брейкпойнты выполнение программы?

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.

Боритесь со сложностью

Как известно, мозг человека может одновременно рассматривать 7±2 элемента. Поэтому очень важно стремиться к снижению сложности ПО. Вот некоторые конкретные рекомендации:

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