суббота, 15 мая 2010 г.

Работа в команде

В большинстве случаев программист трудится в команде. Три человека, пять, десять и более- команды разного размера, специализации, профессионального уровня и т.д. Надо научиться "вписываться" в команду, принимать ее правила игры. Вот несколько советов от меня:
  1. "Не лезь в чужой монастырь со своим уставом." Если в проекте используются коды ошибок, а не исключения (exception), то используйте коды ошибок- "брезгливо морщить носик" не надо. Соблюдайте code guide. Это очень просто- смотрите на соседний код и делайте так же.
  2. При возникновении спорных ситуации или выяснения кто виноват, не становитесь в непримеримую позу "у меня все ОК, это вы- козлы, ищите ошибку в своем коде". Давайте слабину: "Может быть и мое, давайте вместе попробуем воспроизвести баг. Если он мой, я его, конечно же, устраню." Если баг действительно окажется ваш, то вы ничего не теряете. Но вот, если вы от него отмахнулись, а баг таки оказался вашим, то вы "теряете лицо".
  3. Неформальное общение. Даже если вы не общительны, все равно принимайте участие в организации "корпоративов", ходите на обед с коллегами и т.д.
  4. Используйте защитное программирование. Когда код пишут разные люди, то гарантировать единообразное использование кода невозможно. Наверняка найдется рано или поздно кто-то, кто вызовет вашу процедуру с недопустимыми параметрами. Программа "упадет" и call stack покажет на нутро вами написанного класса. Да, в конечном итоге вы разберетесь, что, например, кто-то тупо забыл создать класс перед его использованием, и перенаправите баг кому надо, но время на выяснение этого потеряете. Конечно, далеко не все можно проконтролировать, но вот проверить корректность входных параметров, возвращаемых параметров из других функций можно. Давным давно, я помню, как работал в команде, в которой был один замечательный программист. Программировал он очень быстро, но крайне неаккуратно. Его код постоянно падал и глючил. Я программировал медленее, но мой код был надежнее и безглючнее. Пока тот программист с "высунутым языком" бегал и правил свои баги, я неторопливо "серфил" в интернете, т.к. мое все работало. Со временем наши подсистемы сильнее интегрировались друг с другом, и мои процедуры стали падать из-за его кода. Его головная боль стала и моей. Пользователи кидали мне баги пачками. Тогда я стал проверять все входные параметры и выходные параметры вызываемых в моем коде функций. Проверял, буквально, маниакально. Даже самые очевидные вещи (например, id>0). Кидал ошибку с пояснениями. Это помогло быстрее выяснять причину бага и аргументированно перекидывать его на другого. Это не сложно, прекрасно для этого подходят Assertion.
  5. Жесткий каркас архитектуры. Это сделать очень сложно- надо быть невероятным ассом, чтобы получилось так. Но оно того стоит. Речь о том, чтобы спроектировать архитектуру подсистемы так, чтобы сама структура препятствовала ее неправильному использованию, и даже более того- изменению в архитектуре! Если "перегнуть палку" в проектировании жесткого каркаса, то получиться не масштабируемая архитектура, что тоже плохо. Даже использование паттернов тут не всегда помогает- всегда найдется программист, который, например, попытается "пролезть" за фасад (имеется ввиду соответ. паттерн), чтобы получить напрямую доступ к скрытым за фасадом классам. Как? Да, например, через глобальную переменную! О, ужас, ужас! Но это жизнь, и так бывает (лично сталкивался). Как можно от этого защититься? Но, только, чтоб это была не просто защита, а и достаточно полезная функция или "фича" архитектуры. Можно использовать отложенное создание класса, находящегося за фасадом (по первому обращению к нему), сам класс генерировать из фабрики и удалять его, если к нему долго не обращались (т.е. за фасадом основное время ничего нет- никакого класса). В этом решении мы экономим память, увеличиваем скорость загрузки приложения. Да и к тому же "портим карму" тому "плохому" программисту. Он то, наверняка, либо в коде не разберется, либо, если в конструкторе будет ссылку на объект присваивать глобальной переменной, то падать у него все будет. В конце концов, либо дурь свое возьмет- и он таки сделает свое "грязное дело", либо лень свое возьмет- и он за "ЦУ" прибежит к вам. Вот тут-то вы ему мозги и вправите.
Конечно же, советов можно написать кучу- слепо следовать им все равно не получится. Основная цель- дать общее представление о том, как надо надо вести себя в команде. Приведенные выше советы- только то, что у меня "всплыло" в памяти. Хотелось бы в комментариях услышать ваши советы.
PS: Напоминаю, что я выясняю полезность сервиса редиректа URL. Если вам он интересен, то вместо e-mail просто впишите "да", если хотели бы им пользоваться, то оставьте свой e-mail для получения уведомления, когда сервис будет запущен. Адрес для голосования:
http://spreadsheets.google.com/viewform?formkey=dGxaeDlYNmdsNDBKSnprcE80Qkd4Umc6MQ
Оставленный вами адрес будет использован только один раз для уведомления Вас о запуске сервиса, после этого список с адресами будет удален. Третьим лицам адреса передаваться не будут.

четверг, 13 мая 2010 г.

Сервис маршрутизации URL

Полгода назад я перевел свой сайт на Google Sites, а блог на blogger.com. Я предупреждал о том, что переезжаю, и давал новый адрес. Но, понятно, никто не собирается напрягаться, чтобы перепроверить свои ссылки и заменить их на новые. Например, на ITBlogs, просил Михаила изменить адрес моей ленты, но даже ответа не было. Поэтому я ручками копировал RSS-ленты из blogger'a на Google Sites.
И вот, чтобы не напрягать других, и не напрягаться самому, я придумал такую штуку: беру свой исходный адрес alvosoft.com и перенаправляю его в CNAME http://www.alvosoft.com/ на Google App Engine. А на App Engine делаю простой сервис, который, получив на входе ссылку, перенаправляет ее по введенным правилам на другой адрес. В конечном итоге, я думаю, пользователю все равно, что в итоге он окажется на sites.google.com/site/alvosoft, хотя изначально он ввел http://www.alvosoft.com/. Аналогично и RSS-ленты перенаправляются по их новому адресу. Таким образом, надеюсь, что если все правильно сработает, то мне уже не придется ручками копировать ленты между сайтами.
В сервисе, что я написал, можно использовать регулярные выражения, выделять по шаблону группы и подставлять в перенаправляемый адрес. Например, все, что соответствует адресу www.alvosoft.com/itlife* (старый адрес блога) будет перенаправляться на itspeciality.blogspot.com/* (новый адрес).
Это похоже на таблицу маршрутизации по IP-адресам: исходный адрес с маской, целевой адрес. Я подумал, что такой сервис может быть полезен не только мне и готов предоставить к нему общий доступ. Если вам интересен этот сервис и вы им будете пользоваться, то скажите мне об этом:


Если интерес будет- сделаю общий доступ и уведомлю желающий о его запуске.

пятница, 7 мая 2010 г.

Web Office

Получил приглашение от facebook'a на docs.com. Попробовал, реально прикольно! Это вам не Google Docs, регулярно мною ругаемый. Пользовательский интерфейс удобный, аккуратный. Кто работает с MS Office, тому все будет там знакомо. И, при том, бесплатно!
А доменное имя какое отхватили: docs.com! А? ;)
Молодцы, молодцы. Все никак руки не дойдут написать о наблюдаемой мною стратегии развития крупных игроков на ИТ-рынке. Напишу/нет- не знаю, но выскажу одну мысль из этой темы: считать мобильный рынок для Microsoft потерянным- весьма наивно. Поспорим? ;)