понедельник, 11 мая 2015 г.

Майкрософт, часть 2. Карьерная лестница

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

С момента начала работы в Майкрософте уже прошло 8 месяцев, а значит уже можно сравнить местную внутреннюю кухню с кухней отечественной.

Киевские софтверные «гиганты» и общая культура IT компаний очень сильно отличаются от американских. Прежде всего, это связано с культурными отличиями, средним возрастом сотрудников и размерами компаний. Средний возраст влияет на то, как ведут себя люди в офисе, как они одеваются, и о чем говорят на кухне или в курилке. Средний возраст сотрудников киевской IT компании существенно ниже, чем в американской или европейской. Этот показатель у нас тоже начинает расти, но разница все еще остается очень существенной. Прибавьте сюда наш менталитет и общительность, и получите довольно большую разницу в том, как проходит неформальное общение. В киевском офисе ржачь стоял с завидным постоянством, ничего подобного в Штатах я не видел. Хотя вру, в нью-йорской конторе такое было, прямо перед тем, как ту команду разогнали;)

Средний возраст и размер компаний очень сильно влияют на карьерный рост. В украинской компании, если тебе 25 и ты не синьер, то ты явно что-то делаешь не так. Это же приводит к определенным проблемам, когда тебе тридцать и у тебя есть амбиции расти в техническом плане. У нас (да, я все еще отношу себя к «нам») относительно легко продолжить расти в тим-лидах или ПМ-ах, но чисто техническая лестница оказывается довольно короткой. Есть позиция архитектора, но архитектор в 30 – это все же вынужденная мера отечественного аутсорса для выделения касты «продвинутых синьеров», их нельзя сравнивать с архитекторами МС-а или Гугла. Поверьте.

четверг, 16 апреля 2015 г.

Разница между шаблонами и паттернами

Выбор правильного термина – дело непростое. Выбор русскоязычного варианта – еще и неблагодарное. Занимаясь научным редактированием переводов книг по IT-тематике я всегда сталкивался с проблемой выбора правильного русскоязычного варианта. Сложность заключается в отсутствии единого мнения по поводу перевода некоторых важных терминов, что приводит к проблеме выбора «наименьшего зла» между распространенным, но неточным термином и более емким, но никому неизвестным вариантом.

С термином “pattern” тоже была интересная история. Изначально, этот термин был переведен как «шаблон», и в первых книгах начала нулевых использовался в основном этот термин, а спустя некоторое время, все больше стал набирать популярность вариант «паттернов проектирования».

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

среда, 8 апреля 2015 г.

Как правильно развиваться?

Это несколько расширенная версия ответа на похожий вопрос, который был задан в русскоязычном ru.stackoverflow.com. А поскольку повторное использование – это наш все, к тому же, этот вопрос мне задают с завидным постоянством, то я решил оформить свои мысли отдельным постом.

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

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

  1. Хорошие источники
  2. Упор на получение стабильных знаний
  3. Итеративность обучения и практика
  4. Относительно четкий план развития
  5. Разнообразие тем
  6. Мотивация

Теперь по порядку.

понедельник, 6 апреля 2015 г.

Кэширование объектов StringBuilder

В текущем проекте народ очень серьезно подходит к вопросам производительности: куча структур, кастомный внешний кэш, и свой собственный object pool для хранения тяжеловесных объектов. Одним из типов объектов, которые хранятся в пуле и используются повторно являются объекты StringBuilder. И я задался вопросом, насколько это полезно.

Начиная с .NET 4.0 реализация StringBuilder-а была существенно переработана. В первых версиях реализация напоминала классический вектор – для хранения создаваемой строки использовалась изменяемый объект System.String (*), размер которой увеличивался вдвое при ее полном заполнении.

(*) Строки являются неизменяемыми лишь с точки зрения внешних кода, но с точки зрения внутреннего (internal) кода pre-.NET4.0 строки были очень даже изменяемыми.

вторник, 31 марта 2015 г.

Предусловия в конструкторах наследников

Существует одна типичная проблема с проверкой аргументов в конструкторах классов-наследников, которые должны передавать «куски» своих аргументов базовому классу. Простой пример этой проблемы выглядит так:

abstract class Base
{
   
private readonly int _length
;

   
protected Base(int length
)
    {
       
if (length <= 0) throw new ArgumentOutOfRangeException("length"
);

       
_length = length
;
    }
}

internal class Derived : Base
{
   
public Derived(string s
)
        :
base(s.Length
)
    {
       
// Проверка бесполезна!
        if (string.IsNullOrEmpty(s
)) throw new ArgumentNullException("s");
    }
}

Проблема в том, что конструктор базового класса вызывается до тела метода конструктора Derived (*). В результате, если конструктор наследника принимает составной объект и «выкусывает» часть, которая нужна конструктору базовому классу, то нормально проверить валидность составного объекта не получиться.

понедельник, 23 марта 2015 г.

Простой Syntax Highlighter на базе Roslyn

Roslyn – очень классная штука, с помощью которой можно не только анализаторы делать, но и много других интересных штук.

Вот, например, сколько потребуется усилий, чтобы сделать раскрашиватель синтаксиса, который будет печатать C#-файл в консоль и подсвечивать ключевые слова, строковые литералы и т.п вещи?

Вот как это можно сделать.

пятница, 20 марта 2015 г.

О разработке ПО и книге Крега Лармана “Applying UML and Patterns”

DISCLAIMER: это моя типичная рецензия, в ней больше рассуждений на тему книги, чем информации о самой книге! Так что, не проходите мимо!

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

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