Подписаться на RSS

плюс

Получать обновления на email:



Мои любимые книги:

М. Руссинович, Д. Соломон. Внутреннее устройство Microsoft Windows

Майкл К. Физерс. Эффективная работа с унаследованным кодом:

Стив Макконнелл. Совершенный код

Мартин Фаулер Рефакторинг. Улучшение существующего кода

Бьерн Страуструп. Язык программирования С++.

Андрей Александреску Современное проектирование на С++. Серия С++ In-Depth

Том Демарко, Тимоти Листер Человеческий фактор: успешные проекты и команды

Посмотреть весь список книг для программистов...

О вреде общения

Если вы работаете в средней или крупной компании, то вам наверняка знакомо ощущение беспомощности, когда куча входящих емейлов, постоянные митинги, обсуждения, согласования и т.п. ерунда просто мешает выполнять реальную работу. Когда за несколько дней не получается написать ни строчки кода, зато получается отправить 20-30 емейлов и посетить 5-10 бесполезных по сути митингов и докладов. Когда (при достаточной вовлеченности) берешь домой ноутбук и начинаешь работать дома, чтобы хоть что-то сделать.
Эта проблема существует везде и многими даже не осознается, как проблема. Например, я встречал команды, которые в свои планы просто забивали “30% оверхед от митингов”, но даже этого оказывалось мало, т.к. программист - существо тонкое и, вырвав его из контекста, вернуть его обратно иногда не получается аж до конца рабочего дня. Так что “30% оверхед от митингов” превращался в “40% оверхед от митингов” через месяц, а потом и в 50%. И это, естественно, не решало никаких проблем, а только позволяло закрывать глаза и узаконить чудовищный under commitment (under commitment - это когда человек или команда обещает сделать заведомо меньше, чем может).


В чем же проблема? Зачем компании сами себе создают эти проблемы, устраивая по нескольку важных митингов в день и рассылая письма сотрудникам о каждом чихе компании?
Всё дело тут в общении, в коммуникации.
Читать дальше О вреде общения…

Надежность

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

Итак, что же такое “надежность” и каким приложениям она нужна?
Большинство людей воспринимает надежность, как синоним “времени бесперебойной работы до первого глюка” - есть такая метрика. Для разных систем требования к этой метрике разные, например, если игра работает 5-6 часов в среднем без падений, то обычно этого уже более чем достаточно для того, чтобы признать ее качественной. Если же медицинский прибор перезагружается раз в неделю - это уже может быть критичным. Ну, а для ракеты, летящей к Юпитеру, даже 1 глюк за 2 года критичен.
Все мы в принципе умеем достигать требуемого уровня качества программы в виде этой метрики - для игр это сделать проще, для ракет сложнее, но все это делают и никакого таинства тут нет.

Но в погоне за метрикой многие забывают один ключевой момент - сколько бы часов ваша программа не наработала бесперебойно, в итоге она всё же заглючит. Упадет или зависнет, или испортит данные, или начнет делать что-то неожиданное и т.п. Нет исключений из этого правила. Глючат и спутники, и марсоходы, хотя и пишутся по супер дорогим и строгим стандартам НАСА.
И настоящая система “надежности” включается именно в этот момент - в момент возникновения нештатной ситуации. Все, что было до этого - это работа в штатном режиме, который вы можете контролировать, и которым вы можете управлять. А все, что просходит после глюка - это область чистого искусства, когда вы должны предугадать и среагировать на что-то, о чем вы не имеете никакого понятия (ведь если бы имели - это было бы уже исправлено, так?).
Если вы достигнете хорошей метрики “часов до первого глюка”, но не создадите никакой системы восстановления после того, как глюк случился - клиенты вас проклянут!


Читать дальше Надежность…

Канбан в IT: Ответы

Достаточно давно уже написал статью Канбан в IT (Kanban Development) и обещал в ней продолжить серию статей про Канбан.
Сегодня публикую вторую статью про Канбан - ответы на вопросы, которые я получил к первой статье.
Было очень интересно прочитать ваши отзывы и подискутировать на тему этой новой методологии, а самое интересное (на мой взгляд) из комментариев и обсуждений я собрал в этой статье.

Читать дальше Канбан в IT: Ответы…

Программирование и литература

Tolstoy
Задумывались ли вы когда-нибудь о том, как программисты создают программы?
Если говорить кратко и банально - они их пишут!
Пишут также, как авторы книг пишут свои сочинения - набирают текст, любуются им, читают его, думают об эффекте, который вызовет каждое слово в тексте.
По сути между литературой и программированием есть одно очень важное отличие - у программиста есть компилятор (или интерпретатор) и четкая задача (ну, это уже как повезет). Автор книги же не имеет практически никаких способов проверить “правильность” своей “программы”-книги.
Как же авторы книг тогда пишут свои произведения и чему мы - авторы-программисты, можем и должны научиться у литературных авторов?


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


Читать дальше Программирование и литература…

Православный Геймдев во всей его красе


Среди программистов, да и не только, ходят слухи, что разработка игр - это жутко интересное, да еще и прибыльное занятие.
Что разработчики игр - счастливые люди, занимающиеся с удовольствием любимым делом и периодически срывающие большой денежный куш, выпустив хорошую игру.
Что тот инвестор, который рискнет вложить в игры 5 млн., получит 10млн. уже через полгода и уж точно как минимум 20млн. через год-два.

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

Один мой друг сегодня прислал мне свою статью про интересный опыт работы в одной из Питерских геймдев компаний-стартапов. Прочитайте эту статью, чтобы понять, как работает 80-90% людей в российском геймдеве сейчас и попробуйте найти там “фан, славу и деньги”.

Читать дальше Православный Геймдев во всей его красе…

Закон Паркинсона и менеджеры в IT

Прочитал, наконец-то, книгу “Закон Паркинсона”. Ту самую, на которую любят ссылаться менеджеры, ничего не понимающие в менеджменте, но пытающиеся доказать свою важность.
Еще бы, ведь в этой книге сформулирован ГЛАВНЫЙ ЗАКОН МЕНЕДЖМЕНТА: Любая работа имеет тенденцию занимать всё время и ресурсы, на нее выделенные.
Я много про эту книгу слышал от разных людей, которые цитировали её и строили свою работу с подчиненными, опираясь на эту книгу. И теперь я ее прочитал. И мне жалко этих людей. Дествительно жалко - насколько же ограниченным человеком надо быть, чтобы всерьез её воспринять?


Забавно, что люди видят в книге то, что хотят видеть, а не то, о чем писал там автор. Например, на озоне у книги такая краткая аннотация:
” “Закон Паркинсона”, излагающий многие актуальные проблемы менеджмента и теории бюрократии простым, ясным и общедоступным языком с традиционным английским юмором, в течение полувека остается одной из наиболее популярных книг, посвященных проблемам управления.”


Примерно такое впечатление о книге было и у меня перед тем, как я начал ее читать - что это серьезный и важный труд. А что это такое на самом деле?
А на самом деле это просто книга, наполненная отличным английским юмором и сатирой и ничего более.
Паркинсон высмеивает современную ему политику и английских чиновников, а заодно и ученых, которые пытаются все объяснить. Ну скажите мне, как можно всерьез воспринимать формулы или исследования и их выводы в этой книге? Это же ЮМОР. Если человек не может отличить сатиру от серьезной научной книги, то чего он добьется в менеджменте? Зачем ему вообще быть менеджером?


Паркинсон - историк, а не менеджер или ученый. Он изначально опубликовал в журнале “The Economist” именно сатирическую статью про свой “закон” в применении к чиновникам и врядли кто-то воспринял это серьезно. Но статья была достаточно популярной и Паркинсон написал целую книгу по мотивам той статьи. А вот книгу уже некоторые недалекие люди восприняли, как истину в первой инстанции.


Мало того, менеджеры начали применять “законы” из этой книги в совершенно разных отраслях, хотя даже в книге четко сказано, что это применимо только для чиновников.


В том числе отголоски этих “законов” добрались и до IT, где некоторые менеджеры пытаются объяснить нереально малые сроки на работу именно тем, что если их не установить слишком маленькими, то “работа займет все выделенное время по закону Паркинсона”. Так что они предпочитают не выделить чуть больше времени, чтобы учесть риски, а выделить меньше, чтобы не сработал пресловутый закон Паркинсона. Эти менеджеры может быть даже не читали саму книгу (я надеюсь, что не читали, иначе они совсем плохи), но они применяют сам “закон”, получая абсолютно неработоспособные процессы.


Так что в следующий раз, когда вы услышите ссылки на закон Паркинсона - вспомните эту статью и посоветуйте говорящему прочитать эту книгу. Если же он ее уже читал, но продолжает утверждать, что этот “закон” - это фундаментальный ЗАКОН, то вам не о чем с ним больше говорить…

Исключения и goto

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


Разбирался я недавно в очередной раз с кодом, в котором было много исключений. Весь механизм обработки ошибок был построен на исключениях. Причем, не только критических ошибок, но ВСЕХ. Это ведь считается правильным подходом - если ты выбрал один из методов обработки ошибок, то его и применяй везде - либо исключения, либо возврат кодов ошибки. Вот некоторые и применяют…
Хочешь проверить наличие файла на диске - генери исключение, если файла нет.
Хочешь проверить, создан ли уже эвент - попытайся его создать и лови исключение, если он уже создан.
Не смог выделить 10 байт памяти - генери исключение, что память кончилась.
Любая вызванная WinAPI функция вернула ошибку - генери исключение типа “внутренняя ошибка Windows”.
В итоге, код весь получается усеян операторами throw, try и catch в перемешку с кучей операторов if, которые никуда при этом не деваются. Практически в каждой функции можно найти 2-3 блока обработки ошибок, которые обычно ничего не делают, кроме как пишут что-то в лог и иногда удаляют выделенную память (опять же, сначала проверив парой if-ов наверняка, а была ли она выделена).
При этом многие из исключений кидаются во вполне безобидных ситуациях, когда никаких критических ошибок нет и это нормальный путь выполнения функции. То есть, если ты поймал исключение в дебагере, то это не ошибка - они генерятся постоянно во время работы программы.


И вот, разбираясь с очередным багом в таком коде, я вдруг осознал, что исключения на самом деле недалеко ушли от оператора goto. Да, не надо мне напоминать, зачем ввели исключения в язык, что они позволяют автоматически удалять переменные и т.п. - это я всё знаю, конечно. Но посмотрите на это с другой стороны. Со стороны того, кто поддерживает такой код и должен его понять и исправить.
Итак, я открываю функцию и смотрю, что она делает. Я вижу throw. Я должен понять, что произойдет. Я должен просмотреть глазами всю функцию до конца и найти catch. Я не могу сразу смотреть в конец, т.к. catch может быть посередине. Если я нашел catch, я должен сравнить типы исключения и его ли вообще ловит этот catch. Если совпало - слава богу. Можно вернуться обратно в середину функции и изучать код дальше.
А если в функции нет catch? Тогда это исключение заставляет меня изучать все места, откуда зовется эта функция и искать catch там. А если и там нет catch? Тогда все места вызова всех тех функций!!!
Мягко говоря, это раздражает побольше, чем goto - там хотя бы можно по имени метки найти, куда будет осуществлен переход. А в случае с исключениями, ты теряешь контекст и долго ищешь, куда перейдет контекст исполнения. Но даже когда ты нашел, уверен ли ты, что это единственный путь исполнения или что, например, вся нужная память освободится? А фигушки.
В C++ гарантируется только освобождение созданных локальных переменных. Если ты вдруг использовал new - это уже опять же твоя проблема, как подчистить за собой. То же самое, что и при применении goto.
В итоге, каждый встреченный тобой при анализе функции оператор throw превращается в ненавистного врага. Ты боишься их, т.к. знаешь, сколько кода придется изучить из-за этого одного безобидного оператора, чтобы понять логику работы программы.


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

Software Engineering is Dead?!

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


Для таких людей я не поленился перевести новую статью Тома Демарко, одного из основоположников инжиниринга ПО, разработчика метрик для ПО и соавтора книги “Человеческий фактор: успешные проекты и команды”.
Эта статья сильно провокационная и сейчас широко обсуждается в англоязычных блогах и странно, что я еще не встречал ее переводов на русский. Но, несмотря на провокационность, в ней есть несколько очень правильных идей, которые могут изменить у кого-то представление о важности и возможности контроля за разработкой.
В общем, читайте статью под катом.


Том ДеМарко. Инжиниринг ПО: Идея, время которой ушло?

Читать дальше Software Engineering is Dead?!…

Канбан в IT (Kanban Development)

Я сегодня обещал написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) и вот публикую первую из них.
Основная задача первой статьи - это описать основы Канбан, что это такое и зачем нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Читать дальше Канбан в IT (Kanban Development)…

Scandinavian Agile Conference 2009

Сегодня вышел на работу после отпуска и с удивлением узнал, что меня записали в докладчики на конференцию Scandinavian Agile Conference 2009, которая пройдет в Хельсинки 15-16 октября.
Лекция будет называться Implementing Kanban by mistake и, к счастью, я буду не единственным докладчиком. Название не очень верно отражает то, о чем мы будем говорить, ибо никакой ошибки не было. Мы просто ушли от классического SCRUM и придумали свой набор правил, а через несколько месяцев оказалось, что наш подход очень похож на Kanban, про который мы ничего не знали до недавнего времени.
Собственно, идея лекции - это рассказать про наш путь к Канбану и обменяться опытом с другими командами, использующими эту методологию.
Приходите послушать и пообщаться кто может - конференция большая, интересная и серьезная.
Главный гость конференции, как водится - Mary Poppendieck.


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