Саша Зверев planerist

На днях я прочитал прекрасный текст "Я видел халтуру в лицо" про whiteboard interview (это когда перед кандидатом ставят доску или кладут листик бумаги и говорят: "напиши на доске вот такую программу"). В статье все по сути правильно, только немного в стиле плача царевны по утраченной молодости, ну, и главные дураки, конечно, – кандидаты. Но открою секрет: те, кто нанимают, тоже часто дураки, ведь кандидаты сами рано или поздно оказываются в позиции нанимающих, а дурость-то никуда не уходит.

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

Некоторое время назад я писал о новой фиче «Поиск и замена кода по паттерну», которая появилась в ReSharper 5.0.

Вчера на сайте JetBrains появился набор из 17 наиболее полезных паттернов. Вы можете свободно скачать эти паттерны. Для установки их в R# надо выполнить следующие действия:

1. Открыть меню «ReSharper | Tools | Pattern Catalog.»
2. Выбрать «Import», затем указать на XML-файл извлеченный из скаченного архива.

Этот набор может быть полезен не только как легкое расширение к R#, но и как набор учебных примеров для тех, кто хочет начать создавать свои паттерны.

С сегодняшнего дня ReSharper PoweToys (набор бесплатных плагинов к R#) доступен на CodePlex. В ближайшее время мы (команда R#) надеемся настроить инсталляцию TeamCity, чтобы постоянно были доступны билды последних версий.

Приглашаем всех желающих подключиться к этом проекту и поделиться своими наработками. Так же надеемся, что CodePlex станет местом, где будет появляться актуальная информация о ReSharper API. Со своей стороны, мы будем оказывать всестороннюю помощь плагинописателям при возникновении проблем и при миграции на новую версию R#.

Есть два вида поиска, которые вы часто используете: «Find Text» и «Find Usages». Но ни один из них не позволяет искать сложные языковые конструкции, например, все места в вашем коде, где используется выражение "s == null || s == String.Empty". Вы можете воспользоваться регулярными выражениями и попытаться сделать Find Text, но такие регулярные выражения будут выглядеть монструозно и, наверняка, содержать много ошибок (например, не будут учитвать возможность комментариев в почти каждой точке программы). Очевидно, что для решения этой задачи нужен какой-то другой вид поиска, который бы знал о синтаксисе языка, системе типов и не заставлял бы разработчика изучать какой-то новый синтаксис языка запросов.

Еще в 2007 году я понял чем меня раздражают модные книжки по менеджменту, нахождению пути в жизни и зарабатыванию миллиона. Эти книжки не оставляют мне права на ошибку. Они не признают за мной этого права.

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

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

К счастью, люди в этом мире очень разные. Разные по своим способностям и возможностям. И нет ничего стыдного в том, что ты не лучший сотрудник, нет ничего стыдного даже в том, что ты худший. Ты такой какой ты есть. Место вы жизни есть у каждого. Быть идеальным и успешным — это по-моему единственное право, в котором я хочу отказать людям. Хочу отказать по одной простой причине: люди намного лучше, чем они о себе думают в те моменты, когда ощущают себя успешными.

Я уже писал о новой фиче 5-го Решарпера Call Hierarchy. Логичным развитием Call Hierarchy является Value Tracking. Value Tracking создан для того, чтобы помочь разработчику понять, как в конкретную точку программы могли придти неверные данные или куда эти данные могли уйти. Как следствие, становится легче расследовать причины NullReferenceException или неправильное поведение и вывод.

Я опять же не буду глубоко теоретизировать, а обзорно покажу как и в каких сценариях работает Value Tracking.

Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.

LOH обладает некоторыми особенностями:

• Объекты в LOH никогда не перемещаются
• LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
• Хип LOH освобождается только тогда, когда LOH полностью пуст

Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:

• Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
• Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.

Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.

В ReSharper 5.0 появилась новая функция Call Hierarchy. В сущности, она представляет собой удобный UI для массовых Find Usages или Go To Declaration.

Первоначально в статье я хотел сделать сравнительный анализ этой фичи в R# и в VS 2010, но в процессе написания обнаружилось, что Call Hierarchy в VS 2010 не выдерживает никакой критики (не работает с events, интерфейсами, замыканиями и проч.) и на примерах из статьи вообще не показывает ничего полезного и разумного. Поэтому я просто расскажу об интересных штуках, которые умеет Call Hierarchy в R#.