Здравствуйте, меня зовут Сергей и я боюсь зомби.
Мне был 21 год, когда я устроился на свою первую работу. Предствьте себе, свой первый проект я написал на classic ASP. Это было классическое произведение быдлокодера:
— бизнес-логика? нет, не слышал
— в базе не было индексов
— ID генерился рандомно и проверялся селектом в таблице на уникальность
— монстроидальные ASP файлы, HTML вперемешку с VB Script
Правда, он работал и приносил заказчику деньги. Самое мое большое достижение на этом проекте — процедура обновления списка пользователей. В силу специфики проекта, эти списки предоставлялись каждый день в файле в формате EBCDIC, причем не указывалось, кто был удален/добавлен. Казалось бы, в чем проблема? Перебрал, проверил, добавил/удалил. Ан нет, в среднем в файле всегда было 500 тыс записей. Простой перебор работал со скоростью 10-30 записей в секунду. После долгих мытарств я родил хранимую процедуру, состоящую из 5ти строк, в которой не было ни цикла ни курсоров, и которая обрабатывала порядка 1000 записей в секунду на моем тогдашнем P3-800. Вин? Вин.
Мой второй серьезный проект был на VB.NET — система управления проектами и задачами. Говнокод был, но я учился. На этом проекте я обкатывал те знания, которые черпал из литературы. Мы выпустили две версии продукта, которые приносили компании стабильные деньги, а я продолжал заниматься самообразованием, по ходу делая проекты на VB6 и VC++, фикся баги в чужом коде, общаясь с клиентами, обучая джуниоров. Копал, в общем.
Первым серьезным изменением в понимании того, как надо писать код, для меня стала книга Фаулера Patterns of Enterprise Application Architecture. Я читал ее и понимал, насколько убого было все то, что я писал до этого. Мне очень хотелось применить на практике все эти новые знания. Ах, золотые времена data mapper'ов, coarse grained locking, implicit transactions и конечно-же самописных unit of work'ов.
Тем временем мы выпустили 3-ю версию продукта. Она была просто нечеловечески медленная, и я понимал, что если я что-то не сделаю, то клиенты уйдут и продукт умрет. Я принял решение написать для системы свой ORM, чтобы развести то переплетение UI, business и data логики, в которое я и моя команда превратили продукт за пару лет, и переписать продукт с нуля.
Я думаю, не будет секретом, что мне было адски сложно убедить босса в жизненной необходимости тотального рефакторинга: никто не любит за него платить. Поэтому я начал это делать в свободное от основных задач время.
Версия 3.1 писалась с нуля, параллельно с фиксом багов в 3.0. Я занимался этим все свободное время — днем на работе между фиксом багов, вечером и на выходных дома. Это был самый кайфовый период в моей программерской жизни: я творил. Потом я показал полуфабрикат боссу и сказал — «давай зеленый свет, чтобы этим занималась вся команда и за пару месяцев мы выпустим конфетку». И так оно и было потом, еще полтора года на основе, которую я тогда заложил, выпускались минорные релизы.
Следующий рефакторинг команда делала уже без меня, потому что появились клиенты с тысячами проектов и десятками тысяч задач, и моя архитектура уже не справлялась с такими объемами. А я уволился, потому что настолько глубоко погрузится в тему менеджмента проектов, что хотел заниматься им в чистом виде — то, чего в той компании, где я работал, делать возможности не было.
Любой проект переживает те стадии, о которых я рассказал:
— Усложнение требований усложняет разработку
— В какой-то момент вносить изменения становится очень дорого
— И только в руках программеров дальнейшая его судьба — плодить говнокод и костыли или думать хотя бы на полшага вперед
Сейчас ситуация на рынке совсем не такая, как в начале 2000-ых. 100500 компаний рассказывают о том, какие у них интересные проекты, красивые эйчары и зовут всех «хавать печеньки» (кстати, кто придумал эту хрень?). Есть выбор, который каждый программист делает сам.
Можно пойти «простым» путем и найти «интересный проект». Ну то есть как это бывает? Пишем резюме, в котором заслуги команды выдаем за свои. Указываем зарплату на 30+% выше, чем на текущем месте работы. Приходим, лениво отвечаем на вопросы работодателя, СМОТРИМ КОД (если он есть). Интересно? Тогда хорошо, приходим работать. По прошествии года повторяем процесс с 1го пункта. PROFIT.
Можно пойти «сложным» путем — путем, которым я прошел, от джуниора до менеджера проектов; сложным и долгим путем взятия на себя ответственности за результат и доказательств того, что ты достоин полномочий, путем, который через 10 лет вывел меня на новый виток спирали понимания окружающей действительности.
Сейчас индустрия уже не торт. Огромный спрос на IT-специалистов породил поколение похуистов — «я работаю с 9 до 18, час на обед, мои обязанности — программировать то, что скажут; все что вне моего рабочего Фокуса — меня не интересует». Есть фраза, которая хорошо характеризует то, о чем я тут говорю: «18.55 у вас интеграция срывается? ладно, я домой пошел».
Ребята, друзья, коллеги — не превращайтесь в заводских зомби. У вас же есть УНИКАЛЬНАЯ возможность — создавать новое, творить. В любой задаче можно найти челлендж. А тем, где челленджа нет — можно его создать себе самостоятельно и расти над собой, принося пользу своей компании.
Мне был 21 год, когда я устроился на свою первую работу. Предствьте себе, свой первый проект я написал на classic ASP. Это было классическое произведение быдлокодера:
— бизнес-логика? нет, не слышал
— в базе не было индексов
— ID генерился рандомно и проверялся селектом в таблице на уникальность
— монстроидальные ASP файлы, HTML вперемешку с VB Script
Правда, он работал и приносил заказчику деньги. Самое мое большое достижение на этом проекте — процедура обновления списка пользователей. В силу специфики проекта, эти списки предоставлялись каждый день в файле в формате EBCDIC, причем не указывалось, кто был удален/добавлен. Казалось бы, в чем проблема? Перебрал, проверил, добавил/удалил. Ан нет, в среднем в файле всегда было 500 тыс записей. Простой перебор работал со скоростью 10-30 записей в секунду. После долгих мытарств я родил хранимую процедуру, состоящую из 5ти строк, в которой не было ни цикла ни курсоров, и которая обрабатывала порядка 1000 записей в секунду на моем тогдашнем P3-800. Вин? Вин.
Мой второй серьезный проект был на VB.NET — система управления проектами и задачами. Говнокод был, но я учился. На этом проекте я обкатывал те знания, которые черпал из литературы. Мы выпустили две версии продукта, которые приносили компании стабильные деньги, а я продолжал заниматься самообразованием, по ходу делая проекты на VB6 и VC++, фикся баги в чужом коде, общаясь с клиентами, обучая джуниоров. Копал, в общем.
Первым серьезным изменением в понимании того, как надо писать код, для меня стала книга Фаулера Patterns of Enterprise Application Architecture. Я читал ее и понимал, насколько убого было все то, что я писал до этого. Мне очень хотелось применить на практике все эти новые знания. Ах, золотые времена data mapper'ов, coarse grained locking, implicit transactions и конечно-же самописных unit of work'ов.
Тем временем мы выпустили 3-ю версию продукта. Она была просто нечеловечески медленная, и я понимал, что если я что-то не сделаю, то клиенты уйдут и продукт умрет. Я принял решение написать для системы свой ORM, чтобы развести то переплетение UI, business и data логики, в которое я и моя команда превратили продукт за пару лет, и переписать продукт с нуля.
Я думаю, не будет секретом, что мне было адски сложно убедить босса в жизненной необходимости тотального рефакторинга: никто не любит за него платить. Поэтому я начал это делать в свободное от основных задач время.
Версия 3.1 писалась с нуля, параллельно с фиксом багов в 3.0. Я занимался этим все свободное время — днем на работе между фиксом багов, вечером и на выходных дома. Это был самый кайфовый период в моей программерской жизни: я творил. Потом я показал полуфабрикат боссу и сказал — «давай зеленый свет, чтобы этим занималась вся команда и за пару месяцев мы выпустим конфетку». И так оно и было потом, еще полтора года на основе, которую я тогда заложил, выпускались минорные релизы.
Следующий рефакторинг команда делала уже без меня, потому что появились клиенты с тысячами проектов и десятками тысяч задач, и моя архитектура уже не справлялась с такими объемами. А я уволился, потому что настолько глубоко погрузится в тему менеджмента проектов, что хотел заниматься им в чистом виде — то, чего в той компании, где я работал, делать возможности не было.
О чем это все?
Любой проект переживает те стадии, о которых я рассказал:
— Усложнение требований усложняет разработку
— В какой-то момент вносить изменения становится очень дорого
— И только в руках программеров дальнейшая его судьба — плодить говнокод и костыли или думать хотя бы на полшага вперед
Сейчас ситуация на рынке совсем не такая, как в начале 2000-ых. 100500 компаний рассказывают о том, какие у них интересные проекты, красивые эйчары и зовут всех «хавать печеньки» (кстати, кто придумал эту хрень?). Есть выбор, который каждый программист делает сам.
Можно пойти «простым» путем и найти «интересный проект». Ну то есть как это бывает? Пишем резюме, в котором заслуги команды выдаем за свои. Указываем зарплату на 30+% выше, чем на текущем месте работы. Приходим, лениво отвечаем на вопросы работодателя, СМОТРИМ КОД (если он есть). Интересно? Тогда хорошо, приходим работать. По прошествии года повторяем процесс с 1го пункта. PROFIT.
Можно пойти «сложным» путем — путем, которым я прошел, от джуниора до менеджера проектов; сложным и долгим путем взятия на себя ответственности за результат и доказательств того, что ты достоин полномочий, путем, который через 10 лет вывел меня на новый виток спирали понимания окружающей действительности.
Сейчас индустрия уже не торт. Огромный спрос на IT-специалистов породил поколение похуистов — «я работаю с 9 до 18, час на обед, мои обязанности — программировать то, что скажут; все что вне моего рабочего Фокуса — меня не интересует». Есть фраза, которая хорошо характеризует то, о чем я тут говорю: «18.55 у вас интеграция срывается? ладно, я домой пошел».
Ребята, друзья, коллеги — не превращайтесь в заводских зомби. У вас же есть УНИКАЛЬНАЯ возможность — создавать новое, творить. В любой задаче можно найти челлендж. А тем, где челленджа нет — можно его создать себе самостоятельно и расти над собой, принося пользу своей компании.
