Все статьи с тегом ”Программирование”

Приходит Петька к Василию Ивановичу: «Васильываныч, хочу быть тимлидом!..»

Неоднократно мне приходилось читать (например, на DOU), как при обсуждении той или иной IT-компании, люди хвалят или ругают работодателей за их отношение к профессиональному росту персонала: «Отличная компания, я пришел сюда разработчиком, а недавно стал тимлидом!» или «Лучше сюда не идите, в компании стараются брать руководящие кадры со стороны вместо того, чтобы повышать своих рядовых сотрудников».
Я успел побывать как в роли повышаемого, так и в роли повышающего. Потому уверен, что подобные заявления достаточно наивны. На самом деле, в большинстве IT-компаний (кроме самых маленьких) проблема состоит не в том, что расти программисту некуда, а в том, что «двигать» некого.

Работодатели

В принципе, любой работодатель заинтересован в продвижении проверенных сотрудников, а не в приглашении на руководящие посты людей со стороны. Притом, исходит он не из этических соображений, а из очень даже меркантильных: новый человек в команде — это отчасти «кот в мешке» — до конца не знаешь, что он собой представляет (в отличие от проверенного своего сотрудника) — вот почему и существует испытательный срок. Недобросовестный руководитель проекта или тимлид может нанести бизнесу гораздо большие убытки (даже в течение испытательного срока), нежели рядовой сотрудник. Именно потому, ради уменьшения рисков, стараются повышать своих, а не приглашать новых. Если же руководящие кадры приглашаются со стороны — это, скорее всего, означает, что руководство компании не видит достойных претендентов среди собственного персонала.

Что делать?

Итак, вы все-таки хотите стать тимлидом:

1. Для начала подумайте, нужно ли вам это? Если вы очень любите программировать — знайте, что на программирование у вас останется гораздо меньше времени. С расширением полномочий уровень ответственности тоже увеличится: придется отвечать не только за себя, но и за всех членов своей команды. Стрессов станет побольше, особенно, в первое время и при сдаче проектов. А зарплаты тимлидов, замечу, не выше обычно, чем у ведущих специалистов.
2. Вам придется научиться говорить «нет», проявлять твердость характера: кому нужен тимлид, которому сотрудники «садятся на голову»?
3. Беритесь за организационную деятельность: неважно — будет ли это нечто связанное с текущими проектами, общим рабочим процессом компании или банальной организацией «пьянок» для сотрудников. Главное — чтобы это приносило пользу компании.
4. Необходимо не только проявлять активность, но и брать на себя ответственность: подход «все пидорасы — один я д’Артаньян» вряд ли приблизит вас к поставленной цели.
5. Помните, что ваше руководство — не телепаты: сообщите им о своем желании стать тимлидом. В этом нет ничего зазорного или унизительного. Зато руководство будет знать о вашей цели и может посодействовать — подсказать, чему стоит подучиться.
6. Необходимо качественно выполнять свою текущую работу: если вы регулярно нарушаете дисциплину, срываете сроки и недобросовестны — вас скорее уволят, чем повысят.
7. Постарайтесь заслужить уважение коллектива: если «коллеги по цеху» не считают вас профессионалом и приятным человеком — не воспримут и как реального руководителя.
8. Очень важно хорошо говорить и писать. Как правило, в полемике выигрывает лучший оратор. Руководитель, слабый в дискуссиях и спорах, легко может растерять авторитет.
9. Учитесь не только программированию, но и методам управления. Для этого придется штудировать, кроме книг по «паттернам» проектирования и языкам программирования, также книги и статьи по менеджменту, методологиям разработки, работе с рисками, несомненно, по человеческому фактору…
10. Тимлиду в аутсорсинговой компании может понадобиться и свободное владение английским.

Такого набора качеств и действий, в принципе, достаточно, чтобы вас заметили и повысили.
 Дерзайте!

О книге «Building Scalable Websites» Кэла Хендерсона (ведущий разработчик Flickr) я узнал из рецензии на сайте developers.org.ua. Сразу загорелся и, спустя несколько месяцев, достал и прочитал книгу.
Впечатлений от книги осталось много, в основном — плохих. Кэл, похоже, не знает о существовании технологий вне PHP-мира, да и писатель из него странный. Давайте рассмотрим книгу по главам.

Краткое содержание книги

• Глава об архитектуре приложений свелась к тому, что приложение должно иметь слои, а логика представления должна отделяться от логики приложения. В этой же главе рассказано, что «взрослые системы» работают, как правило, в условиях сильно отличающихся от большинства shared hosting’ов. При этом, о шаблонах проектирования таких приложений не сказано вообще. А очень стоило бы сослаться на Мартина Фаулера.
• В главе 3 (Development Environments) рассказывается, для чего нужна система контроля версий (говорится о них очень мало, недостаточно для нормальной работы, о распределенных системах контроля версиями не сказано вовсе), система сборки проекта (в один шаг) и система учета задач. Также сказно, что без общих конвенций кодирования далеко не уедешь. И все!
  У Джоэля Спольски эти же вещи описаны значительно лучше, без воды и, всего, в нескольких параграфах!
  Убивает рассказ о юнит-тестах, сводящийся к тому, что тесты существуют в природе. Масштабные интернет-системы делаются, как правило, не маленькими командами, потому я бы в главу добавил информации про Continuous Integration. Без CI-систем довольно быстро разработка превращается в вопли разработчиков «Бляяядь, после апдейта снова все сломано!»… С CI же на смену такому режиму приходит «Блядь, я сломал билд, надо срочно откатить код, пока никто не заметил!». Но, ведь, в PHP нету своих CI-систем (на самом деле можно использовать джавовский CruiseControl с PHP-проектами), откуда же о них знать Кэлу Хендерсону?
  Удивительно, как можно писать о стандартах кодирования, в то время как книга кишит примерами кода вроде этого:

  
  function store_file_2($host, $filename){
          ...
          if ($connection_failed){
                  return 0;
          }
          ...
          if ($operation_failed){
                  return 0;
           }
           return $result;
  }
  

  Что такое store_file_2()? За такие имена методов, вообще-то нужно по рукам бить. Делать логику метода нечеткой и отдавать либо результат операции, либо ноль (хотя операция совсем не обязательно должна возвращать Integer) — один из любимых приемов быдлокодеров. Как правило, он лечится, когда такой разработчик сталкивается со строгой типизацией в других языках, либо с веб-сервисами.
• Главу об интернационализации и юникоде безболезненно можно ужать до одной страницы, где будет сказано, что может быть одна кодировка — UTF-8 и будет рассказано, как с ней работать в PHP и MySQL, а также в JavaScript и при отправке писем. Автор ухитрился растянуть эту информацию на 20 страниц.
• В главе о безопасности написано о всяких разных XSS-хаках, SQL-injection’ах и способах фильтрации контента. В общем, о том, чем кишат всякие говнограммы вроде PHPBB, Joomla, PHPNuke. Я считаю, разработчик масштабных интернет-систем заведомо обязан это знать. В книге о масштабировании подобная тема нужна, явно, с одной целью — набить килобайтов текста, за которые автору платит издатель.
• Глава об электронной почте — самое ценное, что есть в книге, говорю это без всякого сарказма. На тему мобильной загрузки, мобильного постинга в блоги и методов разбора электронных писем толковых материалов существует не так уж много. Уверен, эту часть Flickr’а Хендерсон сам и разрабатывал… иначе, почему в этой главе много полезной информации и мало воды, а не как в остальных?
• Глава про «remote services», естественно, свелась к перечислению реализаций этих самых сервисов (старичка CORBA, конечно же, не упомянули… ведь в PHP нету его реализаций). Какой-то аналитики на тему «чем сервис X лучше сервиса Y в условиях Z» ожидать не стоит.
• Глава «bottlenecks» написана неплохо, однако ее практическая часть полезна исключительно PHP-разработчикам.
  В то же время, презентация Бреда Фицпатрика «Inside LiveJournal’s Backend» гораздо лучше отображает проблему «узких мест».
• Главу «Scaling Web Applications» можно считать в книге главной и написана она вполне прилично: тут и теория и практика с примерами из жизни. Нареканий только два: во-первых мало, а во-вторых описан, опять же, исключительно LAMP-стек.
• Затем идут водянистые главы про мониторинг серверов и построение API (эту главу можно рассматривать как продолжение главы о remoting’е).. все, Книга окончена!

Подводя итоги

Книга рассчитана на специалистов интернет-разработок настолько же, насколько книги Дейла Карнеги рассчитаны на профессиональных психологов, а книга «бизнес в стиле фанк» — на бизнесменов… то есть, вообще ни разу не рассчитан! Профессионалы, скорее всего, не найдут в книге ничего нового.

Новичкам книгу тоже не порекомендуешь: общие темы рассмотрены поверхностно(зато впечатляет их количество: тут упомянули использование wiki для документации и, даже, итеративные методологии разработки), наверняка, о них уже написано в более простых книгах. А на основной вопрос «Как строить масштабируемые веб-приложения?» книга так и не отвечает.

Впрочем, книга не такая плохая, как могло показаться из моего описания. Она тянет на уверенную троечку по пятибалльной системе. От того что почитаете эту книгу хуже наверняка не станет, просто, то же время можно потратить с куда большей пользой и почитать High Scalability.
Книгу стоило бы переименовать, скажем, в «Scaling PHP applications in a nutshell» и сократить в 3 раза, стало бы значительно честнее, но за что тогда брать $26.39?

Выводы

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

Для себя я сделал следующие выводы:

• Для желающих разобраться в масштабировании веб-приложений лучшими вариантами остаются High Scalability, общение с коллегами, посещение семинаров вроде Exception и практика-практика-практика.
• Издательство O’Reilly менее добросовестное чем Addison Wesley. Оно вполне может выпускать низкокачественные книги, потому что их раскупят благодаря имени автора.
• Многие готовы купить книгу просто из-за ходового названия и приписки «От создателя Фликра». Мало кто знает, что Flickr не блестал изяществом архитектуры и с машстабированием у него были серьезные проблемы перед продажей гиганту Yahoo.

В некоторых языках программирования (Python, Ruby, JavaScript и некоторые другие) есть возможность переопределять атрибуты и методы классов во время исполнения программы. На этой возможности была построена целая техника программирования, она называется Monkey Patching.

Откуда взялось такое название?

Изначально термин назывался guerilla patch (партизанский патч): разработчик незаметно добирался до чужого кода, изменял на лету поведение этого кода, не заботясь о соблюдении каких-либо правил, установленных создателем, а потом так же незаметно исчезал, оставив создателю порцию говна, в виде кода не работающего, как надо, без видимых на то причин. Поскольку, слова Guerilla и Gorilla звучат очень похоже — вскоре эту технику стали называть «горилла патч», что в конце концов трансформировалось в monkey patch. Именно этот термин прижился, поскольку лишен негативной окраски предшественников.

Практическое применение

Думаю, главное практическое применение техники обезьяних патчей — расширение функционала чужих продуктов (фреймворков, библиотек) без непосредственного вмешательства в их код, а также, т.н. security patches. Хотя, как инструмент террора, эта техника не менее хороша.

Пример из жизни

Существует замечательный, но не лишенный недостатков, фреймворк для веб-приложений — Django. В нем уже существует модель пользователя (User), используемая для авторизации, разграничения прав доступ, хранения самих пользователей… Естественно, эту модель нужно использовать. На практике оказывается, что у пользователя могут быть дополнительные атрибуты (не предусмотренные фреймворком), например, пол или телефон. Первое, что хочет сделать здравомыслящий разработчик, — написать новый класс пользователя, унаследовав его от джанговского. Увы, один из главных минусов django — его ORM не поддерживает наследование моделей, то есть модель то создастся… но она всего лишь продублирует все поля родителя в новую таблицу базы данных, создав тем самым избыточность.
В нашем случае можно сделать дополнительный класс UserProfile для дополнительных полей и связать его с классом User отношением один-к-одном,. но признайтесь, это, явно, не самое красивое решение, тем более, когда-нибудь в django доработают ORM. Патчить исходные коды django — вариант еще хуже, так как все нормальные разработчики пользуются его версией из репозитория (SVN), которая обновляется почти каждый день… выход один — monkey patching!
В любом файле (желательно в моделях) пишем слудующее:

from django.contrib.auth.models import User

GENDER_CHOICES = (
        ('M', 'Male'),
        ('F', 'Female'),
)
User.add_to_class('gender', models.CharField(max_length=1, choices=GENDER_CHOICES))
#Вцелом, этого уже достаточно, но для самой админки django добавим следующее:
User._meta.admin.fields += (
('Additional', {'fields': ('gender',)}),
)
User._meta.admin.list_display = User._meta.admin.list_display + ('gender', )

Все, отныне, никаких бесполых пользователей!Точно так же можно расширять функционал встроенного в django модуля FlatPages, представляющего из себя простейшую CMS-систему и многое-многое другое.

Меры предосторожности

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