| |
Все статьи с тегом ”Программирование”
Приходит Петька к Василию Ивановичу: «Васильываныч, хочу быть тимлидом!..»
Неоднократно мне приходилось читать (например, на DOU), как при обсуждении той или иной IT-компании, люди хвалят или ругают работодателей за их отношение к профессиональному росту персонала: «Отличная компания, я пришел сюда разработчиком, а недавно стал тимлидом!» или «Лучше сюда не идите, в компании стараются брать руководящие кадры со стороны вместо того, чтобы повышать своих рядовых сотрудников».
Я успел побывать как в роли повышаемого, так и в роли повышающего. Потому уверен, что подобные заявления достаточно наивны. На самом деле, в большинстве IT-компаний (кроме самых маленьких) проблема состоит не в том, что расти программисту некуда, а в том, что «двигать» некого. РаботодателиВ принципе, любой работодатель заинтересован в продвижении проверенных сотрудников, а не в приглашении на руководящие посты людей со стороны. Притом, исходит он не из этических соображений, а из очень даже меркантильных: новый человек в команде — это отчасти «кот в мешке» — до конца не знаешь, что он собой представляет (в отличие от проверенного своего сотрудника) — вот почему и существует испытательный срок. Недобросовестный руководитель проекта или тимлид может нанести бизнесу гораздо большие убытки (даже в течение испытательного срока), нежели рядовой сотрудник. Именно потому, ради уменьшения рисков, стараются повышать своих, а не приглашать новых. Если же руководящие кадры приглашаются со стороны — это, скорее всего, означает, что руководство компании не видит достойных претендентов среди собственного персонала. Что делать?Итак, вы все-таки хотите стать тимлидом:
- Для начала подумайте, нужно ли вам это? Если вы очень любите программировать — знайте, что на программирование у вас останется гораздо меньше времени. С расширением полномочий уровень ответственности тоже увеличится: придется отвечать не только за себя, но и за всех членов своей команды. Стрессов станет побольше, особенно, в первое время и при сдаче проектов. А зарплаты тимлидов, замечу, не выше обычно, чем у ведущих специалистов.
- Вам придется научиться говорить «нет», проявлять твердость характера: кому нужен тимлид, которому сотрудники «садятся на голову»?
- Беритесь за организационную деятельность: неважно — будет ли это нечто связанное с текущими проектами, общим рабочим процессом компании или банальной организацией «пьянок» для сотрудников. Главное — чтобы это приносило пользу компании.
- Необходимо не только проявлять активность, но и брать на себя ответственность: подход «все пидорасы — один я д’Артаньян» вряд ли приблизит вас к поставленной цели.
- Помните, что ваше руководство — не телепаты: сообщите им о своем желании стать тимлидом. В этом нет ничего зазорного или унизительного. Зато руководство будет знать о вашей цели и может посодействовать — подсказать, чему стоит подучиться.
- Необходимо качественно выполнять свою текущую работу: если вы регулярно нарушаете дисциплину, срываете сроки и недобросовестны — вас скорее уволят, чем повысят.
- Постарайтесь заслужить уважение коллектива: если «коллеги по цеху» не считают вас профессионалом и приятным человеком — не воспримут и как реального руководителя.
- Очень важно хорошо говорить и писать. Как правило, в полемике выигрывает лучший оратор. Руководитель, слабый в дискуссиях и спорах, легко может растерять авторитет.
- Учитесь не только программированию, но и методам управления. Для этого придется штудировать, кроме книг по «паттернам» проектирования и языкам программирования, также книги и статьи по менеджменту, методологиям разработки, работе с рисками, несомненно, по человеческому фактору…
- Тимлиду в аутсорсинговой компании может понадобиться и свободное владение английским.
Такого набора качеств и действий, в принципе, достаточно, чтобы вас заметили и повысили. Дерзайте!
О книге «Building Scalable Websites» Кэла Хендерсона (ведущий разработчик Flickr) я узнал из рецензии на сайте developers.org.ua. Сразу загорелся и, спустя несколько месяцев, достал и прочитал книгу.
Впечатлений от книги осталось много, в основном — плохих. Кэл, похоже, не знает о существовании технологий вне PHP-мира, да и писатель из него странный. Давайте рассмотрим книгу по главам.
Краткое содержание книгиПодводя итогиКнига рассчитана на специалистов интернет-разработок настолько же, насколько книги Дейла Карнеги рассчитаны на профессиональных психологов, а книга «бизнес в стиле фанк» — на бизнесменов… то есть, вообще ни разу не рассчитан! Профессионалы, скорее всего, не найдут в книге ничего нового. Новичкам книгу тоже не порекомендуешь: общие темы рассмотрены поверхностно(зато впечатляет их количество: тут упомянули использование 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, заботьтесь о том, чтобы этот код был покрыт автоматическими тестами.
|