Ревью на книгу «Идеальная IT-компания. Как из гиков собрать команду»

Как и многие «управленческие» книги, «Идеальная IT-компания» почти не затрагивает тему технологий, а акцентирует внимание на важности soft-skills и командной работе. Но если большинство «управленческих» книг считают своим читателем прежде всего менеджеров, то авторы «Team Geek» ориентируются на участников команд — программистов — и формирование командной культуры и атмосферы изнутри (впрочем, не исключая и роста карьеры потенциального читателя :))

Несмотря на то, что книга очень молодая — оригинал вышел в 2012 году — в ней практически нет отсылок к Agile. Тем не менее, очень многое в книге перекликается с манифестами гибких методологий: это и принцип доверия команде, и важность технически сильной и мотивированной команды, и роль руководителя как «слуги команды» (скрам-мастер?), и многое другое.

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

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

Критика направлена не на человека (а на код), да и проблема вовсе не в «плохом коде» как таковом (код работает!), а в понимании этого кода в будущем.

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

Также любопытным мне показалась тема технического долга.

Команда никогда не должна тратить больше трети (максимум — половины) своего времени и энергии на «оборонительную» работу независимо от размера технического долга. Вложение большего количества времени в «оборонительную» работу — путь к политическому самоубийству.

Это, безусловно, связано с важностью создания правильного «visibility» — если команда перестает стабильно выдавать заказчику business-value (а исправление технического долга, в большинстве случаев, заказчиком не воспринимается, каким бы технически-продвинутым он ни был), то доверие команде будет резко падать.

В целом авторы не открыли Америки, но, на мой взгляд, подчеркнули очень важные детали, привели множество полезных практических примеров и, возможно, привлекут этой книгой новую аудиторию (кроме менеджеров, которые подобными книгами, конечно, уже зачитались :))

P.S. Купить книгу можно в издательстве «Питер».

Инъекция зависимостей и меняющиеся параметры в конструкторе

При использовании инъекции зависимостей у меня частенько возникают проблемы с конструкторами.
Посмотрим на простой пример класса — сервиса почтовой рассылки:

public class EmailSender
{
	public EmailSender(ISmtpClient smtpClient, string serverAddress)
	{
	}

	public void Send(string from, string to, string text)
	{
		
	}
}

Какие у класса есть зависимости? Ему нужен SMTP-клиент, чтобы осуществлять отправку писем, а также необходим адрес смтп-сервера, который будет отправлять корреспонденцию.

Допустим, что у меня в проекте полная Инверсия Зависимостей и активно используются IoC-контейнеры. Какая возникает проблема?
ISmtpClient зарегистрирован в моем контейнере с ним проблем нет, но как сконфигурировать EmailSender адресом сервера? Непонятно.
Continue reading

Только React.js, только хардкор (aka долой Angular и Knockout)!

Последние годы только ленивый не писал о javascript-фреймворках. AngularJS/KnockoutJS/Backbone/Ember — выбирай на вкус :) Но, озадачившись выбором фреймворка для небольшого веб-приложения с год назад, оказалось, что серебряной пули в мире js все еще не придумали.
Backbone и Ember слишком низкоуровневы и многословны, Knockout расстраивает постоянными конвертациями данных в observable, AngularJS.. да, почему бы не попробовать Angular, подумал я тогда. Энгуляр обладал приятным синтаксисом, структура Контроллеров была более менее близка и понятна и всё шло хорошо, пока.. пока мы не уперлись в довольно стандартную для Angular проблему произодительности.
Continue reading

Xamarin и Garbage Collector на Андроид

При тестировании Андроид-версии нашего мобильного приложения, мы неожиданно начали замечать ощутимые проблемы в производительности — время от времени (достаточно регулярно) приложение «подвисало» на несколько секунд, а в некоторых случаях и вовсе вызывало ANR (Application Not Responding — такое замечательное окошечко, которое говорит, что приложение не отвечает и предлагает его закрыть).

Гугл подобных ситуаций дает подробные рассказы о проблемах с Garbage Collector’ами, и даже о том, что все языки с GC прокляты :) А сама проблема, обсуждать которую мы начали на форуме Xamarin’a, проявлялась в довольно странном факте:
Continue reading