Кто такой “хороший программист”?

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

Что отличает хорошего программиста от посредственного? И как самому стать хорошим программистом и заслужить среди друзей и коллег «почет и уважение»?

Идеальная архитектура

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

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

Observable.Generate и перечисление списков

В библиотеке реактивных расширений (a.k.a. Rx – Reactive Extensions) существует вспомогательный метод Observable.Generate, который позволяет генерировать простые observable-последовательности.

IObservable<string> xs = Observable.Generate<int, string>(     
     initialState: 0, // начальное значение
     condition: x => x < 10, // условие завершения генерации
     iterate: x => x + 1, // изменение значения
     resultSelector: x => x.ToString() // преобразование текущего значения в результат
     );
 
xs.Subscribe(x => Console.WriteLine("x: {0}", x));

Повторная генерация исключений

Обработка исключений появилась в mainstream языках программирования вот уже более трех десятилетий назад, но сегодня все еще можно встретить разработчиков, которые боятся их использовать. Некоторые считают, что генерация исключений в конструкторе повредит их хрупкой карме и их настигнет кара в виде поддержки кода двадцатилетней давности, написанного стадом безумных индусов. Некоторые все еще застряли в эпохе языка С и даже в языке C# интенсивно используют коды возврата в виде магических чисел или даже строк, считая, что исключения придумали трусы, а настоящие самураи могут обойтись и без них. (Хотя мы-то с вами знаем, что настоящие самураи следуют “Принципу самурая” и никаких кодов возврата не используют).

Дополнительную сложность добавляют конкретные платформы и языки программирования. Сегодня на собеседовании C# разработчика, когда речь заходит об обработке исключений, обязательно прозвучит вопрос: “А в чем отличие “проброса” исключения с помощью конструкций throw; и throw ex;?”. И хотя, это страшный баян и большинство разработчиков давно знают правильный ответ на этот вопрос, в реальном коде встретить “некошерный” вариант очень даже просто.

Особенность платформы .NET заключается в том, что в ней не существует (а точнее, как мы вскоре увидим – не существовало) способа перехвата исключения в одном месте и последующего его генерирования в другом. Если разработчик бизнес-приложения или библиотеки сталкивался с такой задачей, то решалась она очень простым способом: исходное исключение заворачивалось в другой объект в виде вложенного исключения и пробрасывалось уже новое исключение.

Проблемы передачи списка перечислений или Почему абстракции «текут»

Все нетривиальные абстракции дырявы
Джоэл Спольски – Закон дырявых абстракций

А иногда дырявятся и довольно простые абстракции
Автор этой статьи

Большинство современных разработчиков знакомы с «законом дырявых абстракций» по знаменитой заметке Джоэла Спольски с одноименным названием. Заключается этот закон в том, что как бы ни был хорош протокол взаимодействия, фреймворк или набор классов, моделирующих предметную область, рано или поздно нам приходится спускаться на уровень ниже и разбираться с тем, как же эта абстракция устроена. Внутреннее устройство абстракции должно быть проблемой самой абстракции, но возможно это только в наиболее общих случаев и лишь до тех пор, пока все идет хорошо (*).

Когда-то давно, в «небольшой» мелкомягкой компании решили, а почему бы нам не «абстрагироваться» от местоположения объекта и сделать сам факт того, является ли объект локальным или удаленным, лишь «деталью реализации». Так появились технологии DCOM и ее наследник .NET Remoting, которые скрывали от разработчика, является ли объект удаленным или нет. При этом появились все эти «прозрачные прокси», которые позволяли работать с удаленным объектом, даже не зная об этом. Однако, со временем выяснилось, что эта информация архиважна для разработчика, поскольку удаленный объект может генерировать совершенно другой перечень исключений, да и стоимость работы с ним несравнимо выше, чем взаимодействие с локальным объектом.

Доклады по асинхронному и реактивному программированию

На следующей неделе я проведу два семинара (или доклада, если хотите) в Киеве.

• 20.10.11 Библиотека реактивных расширений. Киев, Радищева 10/14, начало в 17-00 (это четверг)
• 21.10.11 Асинхронное программирование в .NET. Kiev ALT.NET, Киев, Амосова 12, 19-й этаж, начало в 18-15 (а это – пятница)

Dispose pattern

“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано”
Мысли автора статьи во время чтения и рефакторинга чужого кода

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

А как же финализаторы? – спросите вы. Ну, да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.