Опыт работы: зачем нужен С++?

Недавно составляли вакансию. Необходимо нанять человека, основным занятием которого будет написание пользовательского интерфейса при помощи C# и WPF. В черновике вакансии я написал, помимо всего прочего - опыт работы на C++ - от 2-х лет. При обсуждении требований сразу же возник вопрос: а причём тут собственно опыт работы на C++? Мы ведь проект пишем на C#! И С++ в нем в ближайшее время скорее всего не понадобится. Так зачем же в вакансии требовать опыт работы на C++, отсекая тем самым многих специалистов?

Ну я дал какой-то ответ в тот момент, а сейчас пытаюсь более развёрнуто обосновать свое мнение.

Дело в том, что опыт работы на C++ - это некоторый показатель опыта и уровня человека. Сразу оговорюсь - не таланта, способностей к программированию или "крутизны", а именно уровня.

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

Кроме того, C++ - это "чистый" язык, язык в котором нет "заточенности" на ту или иную библиотеку или стиль программирования. Много ли людей пишет на C#, не используя Framework Class Library? Много ли людей пишет на Java не пользуясь библиотеками от Sun? .NET Framework + C# и Java - это платформы, а не языки.

С++, в отличии от многих, не привязан ни к чему. Это дает программисту на С++ поразительное, я бы даже сказал, иногда угнетающее, количество возможностей и вариантов запрограммировать даже самое простое действие. Как прочитать строчку из файла на C#? 99% ответов, как мне кажется будет выглядеть примерно так:

Textreader tr = new StreamReader("file.txt");
Console.WriteLine(tr.ReadLine());
tr.Close();

А как сделать это в C++? Есть тысяча разных способов - функции Win32, семейства _open, семейства _fopen, функции MFC, ATL, boost, стандартной библиотеки, собственные "единственно верные" функции. 99% ответов будет наверное такими - надо посмотреть что используется в той программе которую мы пишем и постараться использовать то же самое.

С++, кроме того, поддерживает мультипарадигменное программирование, то есть возможность пользоваться при написании программ многими стилями программирования.

Все это приводит к тому, что программисту на С++ приходится много работать. Больше наверное, чем программисту на любом другом из широко распространённых нынче языков. Иногда это работа является рутинной, технической - С++ не освободит за нас выделенную память. Но при выполнении этой работы, программист понимает как должны быть устроены механизмы автоматического освобождения памяти. Программист проникает во внутренности, причём невольно - ему просто приходится, иначе программа не работает как положено. Программисту приходится разбираться во внутренностях работы функций операционной системы, других библиотек. Ему приходится понимать то как устроен экспорт функций в DLL И тысячу других вещей, которые программисту например на C# понимать не нужно. Но ведь бьют то все эти вещи по обоим! Пока что операционные системы написаны большей часть на C/C++.

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

Disclaimer:

1. Я понимаю что ассемблер в этом смысле ещё лучше чем С++. А машинные коды ещё лучше чем ассемблер. На самом деле строчку про опыт программирования на ассемблере я бы тоже вписал, только вот боюсь что это отсечёт слишком много кандидатов. А чувство меры терять тоже не следует.
   
2. Конечно, все вышесказанное не значит что кто на С++ не писал, тот "жизни не нюхал". И конечно есть огромное количество программистов, вполне квалифицированны и способных, но не имеющих опыта работы на C++. Просто помните - мы писали вакансию. Мы звали к себе незнакомого человека, и всего лишь пытались оценить его и уменьшить количество времени, проведённого на собеседованиях.
3. И наконец, я не считаю С++ лучше или хуже какого-либо из упомянутых или не упомянутых языков программирования. Я считаю, что С++ это ... как бы сказать, ну скажем как механическая коробка передач на автомобиле. Кто на механике ездил, тот сможет ездить на автомате очень легко. А вот обратное - верно не всегда. При этом, заметьте, на чем ездить лучше - вопрос не рассматривается.

Ну и напоследок. После того как я объяснил свою позицию, другой участник обсуждения текста вакансии сказал: "Да, мне тоже не очень нравится это предложение - опыт работы на С++ от 2-х лет ... не маловато ли?".

Оценка сроков

Почему большинстов проектов не укладываются в срок? Практически все известные методики оценки времени, которое будет затрачено на разработку проекта аппелируют к "экспертным" оценкам и к обратной связи.

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

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

Всегда, в процессе разработки, выясняется что исходное разбиение на задачи и подзадачи было не совсем верным. Что не приняли во внимание то-то и то-то. Что есть другой способ, который позволяет эту и эту подзадачи не делать, но требует сделать некую новую подзадачу и так далее. Все зависит от количества этих изменений. Если их слишком много, то проект в конце будет совершенно не похож на то, чем он являлся в начале. Обратная связь пропадает и не с чем оказывается сравнить первоначальные сроки. А значит говорить об рациональном, происходящем с "открытыми глазами" улучшении качества оценки собственной работы говорить не приходится. Если программист давал оценку, что для выполнения задач A, B и С ему потребуется месяц, то что ему дает знание о том что для выполнения задач D, E и F ему потребовалось полтора? Насколько точно были оценены A, B и С? это остается неизвестным. А значит, обратная связь становится "слабым" игроком, не очень помогающим в оценке будущих проектов.

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

Стадии разработки программ

В процессе прочтения замечательной книги Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People обнаружил описание процесса разработки в Microsoft. Спешу поделиться, но заранее предупреждаю, что книга вышла в 1995 году, так что описание имеет скорее исторический и "общекультурный" интерес.

Итак, сам процесс разбит на три основные фазы: Планирование, Разработка и Стабилизация.

1. Планирование
   В результате выполнения фазы планирования должны образоваться следующие материалы:
   
• vision statement
• спецификация
• описание функциональных возможностей продукта (product features)
• приоритет каждой из функциональных возможностей
• прототипы различных частей продукта, пользовательских интерфейсов
  
• план проекта, включающий в себя календарный план
2. Разработка
• состоит из нескольких milestones
• "Замораживание" пользовательского интерфейса
• Завершение добавления всех функциональных возможностей
  
• Окончание кодирования
  
3. Стабилизация
• Тестирование
• Исправление найденных ошибок
• Проведение оценки проекта (post-mortem)

Согласитесь, ничего такого особенно нового в таких этапах нет. Все примерно таким образом и делают. Тем не менее, хочу отметить несколько моментов, которые отличают именно Microsoft:

• Чрезвычайно активное использование "буферного" времени, причём исключительно для неопределённых вещей. Часто бывает так, что буферное время используется в качестве дополнительного времени для проведения инспекций кода, unit-тестирования, планирования и тому подобного. В Microsoft же для всей этой активности выделяется отдельное специальное время. А буферное время - это именно буферное время.
  
  
• Для продуктов разрабатываемых в Operating Systems Division, его начальник, Brad Silverberg, требовал не менее 50% буферного времени. (то есть если оценка времени на задание была 1 месяц, то Silverberg требовал 2 месяца)
  
  
• Концепция "milestone 0". Время, между окончанием работы над одной версией продукта и началом разработки следующей, в течении которого разработчики "подчищают хвосты" - исправляют то, что они хотели исправить в только что вышедшей версии, но не успели.
  
  Например, между окончанием работ над Excel 4.0 и началом работ над Excel 5.0 на это было потрачено 2 месяца.
  
  
• "Поддержкой" предыдущих версий (починкой ошибок в них) занимаются те же самые
  разработчики, что и разрабатывающие новую версию
  
  
• Принцип "бездефектных" milestones - идея состоит в том, что по достижении milestone - продукт не содержит дефектов и (относительно того, что было запланировано для данного milestone) является готовым чуть ли не к выпуску

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

Думайте о безопасности

Вот здесь находится очень поучительный рассказ про то, как человек получил Platinum Pass на выставку MacWorld, из-за того что организаторы не очень сильно задумывались о том, как обеспечить безопасность сайта регистрации.

Пара замечаний:

1. Platinum Pass давал возможность занимать лучшие места, а также доступ на выступление Steve Jobs
2. John The Ripper - программа подбора паролей

Я узнал про эту статью из блога Michael Howard, который является одним из основных "security guys" в Microsoft, автором книги о написании безопасного кода: Writing Secure Codeи всемирно известным экспертом в этой области.

[Карьерная] Лестница в небо

Добрый день,

Сегодня хочется поговорить о так называемых "карьерных" лестницах. В приложении к разработчикам программного обеспечения, а также компаниям, в которых они работают.

Очень часто и в форумах, и просто в разговорах приходится обсуждать вопрос о том что кто-то там стал "Senior Developer", а кто-то даже "Team Lead", а некоторые вообще "Ахитекторами" ((с) Матрица). Тут же кто-то обязательно выскажется по поводу того, что формальные названия должностей не имеют значения, а важно что за человек и как он делает свою работу. И что уж лично он-то, ну тот который высказывается хоть и является простым программистом, но получает больше любого другого. Вот об этом и будет разговор.

Во всех фирмах, компаниях, организациях, конторах - называйте как хотите - существует штатное расписание. Иногда все красивые названия в нем прописаны, иногда (в основном по разного рода бухгалтерским соображениям) - нет. Что же там написано и зачем все это нужно? Я буду смотреть на вопрос НЕ с точки зрения конституции, трудового кодекса и бухгалтерии. Я буду смотреть на вопрос примерно так как вроде бы надо расследовать преступления - пытаясь ответить на вопрос "Кому это выгодно?".

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

Немного демагогии

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

1. Управленческий
   
   Ну то есть те, кто проявляет склонность к управлению людьми становятся начальниками небольших групп, потом больших групп, потом отделов и так далее. Их деятельность становится деятельностью управленческой.
   
   
2. Технический
   
   Это и есть собственно наша тема. Существует ли карьерный путь у людей, которые не хотят заниматься управлением другими людьми? Не хотят быть "начальниками" в классическом смысле этого слова?
   

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

С другой стороны, отсутствие подобного пути может стать серьёзной отталкивающей силой, поскольку часто бывает так что управленческие позиции уже заняты, а значит отсутствует ЛЮБАЯ возможность "карьерного" продвижения, чтобы в это понятие не вкладывалось.

Примеры

Рассмотрим теперь несколько примеров лестниц. Очень во многих фирмах есть специальные технические лестницы.

• В статье Fog Creek Compensation Joel Spolsky описывает техническую лестницу, которая существовала на тот момент в его компании Fog Creek Software.
  
  
• На самом деле, и в этом признается сам Joel, его система была позаимствована у компании Construx (основанной, кстати известным автором многих бестселлеров, посвященных программированию и управлению проектами, таких как Code Complete или Software Project Survival Guide ). В Construx есть собственная лестница, описанная подробно на web_сайте компании.
  

• Компания Microsoft также использует "лестницу" оценки разработчиков. К сожалению у меня нет информации про современное состояние их лестницы, но есть данные из замечательной книги Microsoft Secrets. Лестница состоит из 5 ступеней - начиная с 9 и 10 уровней для выпускников колледжей и заканчивая 15 уровенем, который получают только люди, чья высокая компетентность лично отмечена Биллом Гейтсом
  

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

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

А зачем она нужна?

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

Внедренцы лестниц чаще всего мотивируют необходимость их наличия следующим:

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

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

1. Я работаю лучше всех, делаю всю работу, но платят мне меньше потому что я не успел прочитать какую-то книжку, которая требуется для перехода с уровня на уровень. Я читал другую книжку, которая в сто раз лучше этой, но это никого не волнует!
2. Начальство заводит любимчиков
3. Вот приняли только что человека - за что ему дали сразу более высокий уровень?

Мне кажется, карьерная лестница должна существовать, и в первую очередь потому что это отличная мотивация. Однако, для её успешного внедрения требуется как минимум:

• Внедрить "справедливые" и формализованные правила перехода с уровня на уровень.
• Внедрить методики оценки вновь приходящих сотрудников для их адекватного позиционирования по уровням
• Обязательно создать "лестницы" для не-разработчиков - тестировщиков, технических писателей и других специалистов. А также установить соответствие уровней в разных лестницах (например - 10 уровень разработчиков это примерно тоже, что 11 уровень тестировщиков). Кстати говоря, в Microsoft это сделано.
• Предусмотреть возможность смены правил перехода. Те, кто составляет критерии перехода - тоже совершают ошибки. Более того, технологии меняются, пишутся новые книги и так далее. Необходима возможность смена правил перехода с уровня на уровень
• Знать меру - не всегда те методики, что хороши для компаний в которых работают сотни человек, хороши для компаний где работают 10 человек. Не стоит позволять процессам и формальным методам подменять собой саму работу.
  

TotalCommander 6.56 - bugfix release

Добрый день,

Вооще-то у меня не новостной блог, но случилась важная новость - вышла новая версия моего любимого файлового менеджера - TotalCommander 6.56.

Смысл её в том, что она лечит неприятный баг:

Total Commander 6.56 corrects a major problem with re-
packing of RAR archives directly to another archive,
using external RAR for unpacking. Under very special
conditions, it can lead to data loss anywhere on the
harddisk. We strongly recommend that you update
immediately, and do NOT try to reproduce this error.

Я сам, честно говоря, давно пользуюсь 7.0 public beta 2, но и в ней, и в предыдущей бете, также присутствует этот баг. Так что будьте бдительны!