Category: технологии

Category was added automatically. Read all entries about "технологии".

Про новых сотрудников

Обычно в наших краях львиная доля внимания в HR отводится поиску кандидатов и проведению собеседований, а что потом с человеком происходит — про это как-то не принято говорить. И если речь идёт о крупной аутсорсинговой компании, то за 2 недели, пока человек дорабатывает на предыдущем месте, всё может радикально поменяться. Более того, если компания по каким-то высшим соображениям решила создать кадровый резерв, то можно вообще год просидеть на внутренних проектах и заниматься саморазвитием.

Но даже если компания делает собственный продукт, то часто никто не думает о новичках и весь процесс разработки построен так, что чтобы новичок начала работать, кто-то должен потратить день, чтобы объяснить ему, как и что запускать. Если люди культурные, то они сделают страничку в wiki, но она со временем наверняка устареет. На нынешнем этапе развития технологий, по крайней мере если речь идёт о разработке веб-сервисов, запуск проекта на локальной машине разработчика должен быть тривиален. Если это не так — это технический долг и его надо гасить. Не стоит поддерживать архаичную инфраструктуру только потому, что здесь так принято.

Если используемые в проекте технические решения сильно сложнее, чем требуется, то это приводит к трудностям при оценке результатов испытательного срока. Возможно, через 3 месяца у тимлида появится подозрение, что программирует новичок не очень хорошо, но уже столько сил потрачено на его обучение... И где гарантия, что получится найти человека, который справится лучше? А ещё новичок может уйти сам, потому что заниматься археологией ему неинтересно. Разумеется, даже если вы никого не собираетесь набирать, но у вас везде лежат уровни абстракции штабелями, то разрабатывать вы будете медленно и печально. Можно приучить руководство, что спринты по 2 месяца — это нормально, но мир вы так не завоюете.

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

Поддерживайте свой проект в таком состоянии, чтобы к его разработке легко мог присоединиться другой человек. Это поможет вам держаться на современном уровне. Но если вы вдруг думаете, что уникальная экспертиза в местных технологиях даст вам что-то похожее на job security — берегите себя, это так не работает.

Технологическое банкротство

Есть такое понятие - технический долг. А если есть долг, то должно быть и банкротство. Термин "техническое банкротство" уже используется со своим особым смыслом, поэтому будем говорить "технологическое банкротство". Если по техническому долгу нужно платить проценты в неявной форме в виде лишней инфраструктуры и низкой производительности разработчиков, то технологическое банкротство - это полноценное финансовое банкротство, когда отсталость в технологиях приводит к краху компании. Возможно, именно это произошло недавно с Thomas Cook.

1. Как появляется технический долг

Часто бывает, что IT-проекты не идут дальше прототипа. Но если нет пользователей, то можно просто списать убытки. Можно сказать, что наличие технического долга является приятной проблемой.

Конечно, есть программисты, которые всё время производят технический долг. Паттерн на паттерне и паттерном погоняет. Не удаляют ненужный код и исправляют баги при помощи костылей.

Часто технический долг возникает просто с течением времени. Например, с выходом Java 5 появилась возможность значительно улучшить весь ранее написанный на Java код. А по мере распространения Python 3 весь код на Python 2 постепенно устаревал, причём в данном случае миграция является серьёзной проблемой. Если когда-то Oracle использовали почти все, то теперь есть много гораздо более дешёвых баз данных.

Когда-то у всех бизнес-приложений были свои клиенты, но потом они массово мигрировали в браузер. А сейчас уже многие хотят использовать облачную версию. Распространение новых технологий заставляет переделывать старые технические решения.

2. Технический долг и человеческий фактор

Часто разработчики даже не осознают проблему с техническим долгом: все привыкли к существующему порядку, знают имеющиеся баги и как их обходить. Обучили поддержку, написали инструкции, вырастили экспертизу по каким-то древним технологиям.

Эта проблема решается новыми людьми, которые могут посмотреть свежим взглядом. Конечно, это должны быть хорошие программисты и они должны быть настроены много работать. Если на добавление ешё одного поля в форму у нового человека уходит весь весь день, потому что нужно поменять код в 10 местах, то нужно найти силы, чтобы выкинуть 3-4 уровня абстракции, чтобы в следующий раз было проще вносить изменения.

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

3. Трудности найма

Если компания исторически всегда набирала хороших программистов, то скорее всего у неё просто нет проблем с техническим долгом. Но если люди из бизнеса уже понимают, что дальше так жить нельзя, то скорее всего ситуация довольно тяжёлая. Во-первых, найти хорошего программиста всегда было тяжело. И совершенно точно, что он попросит большую зарплату. Во-вторых, как компания сможет найти в потоке кандидатов более квалифицированных людей, чем у неё есть сейчас?

Третий уровень проблемы я вижу исходя из своего собственного жизненного опыта. Так получилось, что почти вся моя карьера связана с погашением технического долга. И нельзя сказать, что это плохой опыт. Зарплату в верхнем сегменте рынка я обычно получал сразу при приёме на работу и после успешных изменений старой системы её всегда повышали. Но потом, когда основной технический долг погашен, то что дальше? В лучшем случае выходное пособие, иначе - просто компенсация за неиспользованный отпуск и иди ищи другую работу.

Прямо скажем, не так часто встретишь программиста, который с энтузиазмом готов делать из чужого кода конфетку. И мне уже тоже кажется, что лучше работать в небольшой компании, которая захватит мир за счёт использования современных технологий, чем продлить жизнь какому-нибудь динозавру ещё лет на 10.

4. Кто следующий?

Рискну предположить, что наиболее громкие закрытия бизнеса ждут нас в банковской сфере. Многие банки традиционно несут на себе груз старых технологий и по крайней мере в России в розничных финансах есть конкуренция. Собственно, количество банков у нас и так постоянно снижается, но мой прогноз в том, что с рынка будет уходить не только мелочь. И не только из-за общего спада экономики, но и непосредственного из-за плохого программного обеспечения. Может показаться, что у крупных банков есть деньги и они могут в любой момент написать всё, что угодно. Но когда понадобятся радикальные изменения, то окажется, что делать их просто некому. Кто-то просто закроет розничный бизнес, а кто-то может и до банкротства довести.

Субботний МегаФон

Зашёл сегодня в ближайший офис МегаФона показать паспорт по новому законодательству — оказалось, что делать этого было не нужно, но пока стоял в очереди проверил счета. Оказалось, что в августе у меня появилась новая услуга «Кто звонил+». Наличие пустого контент-счёта от неё не защищает, подключилась сама при смене тарифа в мае. На требование вернуть деньги мне выдали вот такую бумажную форму для заполнения:



Это просто издевательно и так как в приложении теперь приходится разговаривать с роботом, то предъявлять претензии МегаФону теперь стало тяжеловато.

А вот так выглядит VIP-сервис:

Какой рефакторинг нам нужен

Я давний адепт рефакторинга и много лет успешно его практикую (в своей интерпретации). Например, на предыдущей работе мы переписали десятки тысяч строк PL/SQL на Java. Начинали мы с того, релизы мы делали по 4 месяца и включали они в себя по 5-6 изменений, которые вносились через боль и страдание. Через 3 года мы легко могли сделать релиз за 3 месяца и включить в него 15-20 новых фич, потому что код стал понятным, а инциденты в боевой системе сошли на нет.

Однако, мой опыт ограничен узким кругом моих работодателей, а cartmendum   обобщил свои наблюдения и тут получается, что рефакторинг — это такое страшное проклятие. У меня есть теория, как получаются такие экспериментальные данные. Многие команды любят делать новые системы на основе модного стека технологий. Через несколько лет боли и страданий они внезапно осознают, что технологии у них уже совсем не модные и переходят к решительным действиям. Но так как корпоративная культура не изменилась, то на выходе снова получаем боль и страдание. Превышение срока разработки в 4 раза, да ещё без достижения нужного результата, говорит о том, что команда просто некомпетентна и не понимает, что делает и где находится.

Давайте вернёмся к рефакторингу с позитивной стороны. Система является проблемной, если разработчики не успевают вносить требуемые изменения за комфортное время, эту формулировку можно считать определением. Рефакторинг — это процесс улучшения системы, то есть после него внесение изменений должно проходить проще. Итак, если система проблемная, то разработчик вынужден задерживаться на работе, пусть у него уходит по 9 часов в день на выполнение поставленных перед ним задач. Если разработчик не любит плохой код, то он дополнительно тратит какое-то время на приведение его в порядок, допустим, это ещё 1 час в день. Итого, новый хороший разработчик в проблемном проекте работает по 10 часов в день. Но так как система становиться проще, изменения вносятся легче, то срочные задачи делаются всё быстрее, поэтому на рефакторинг остаётся больше времени и потребность в переработках отпадает. Заметим, что при таком подходе нет нужды спрашивать разрешения у начальства, можно просто хорошо работать и от этого появятся основания попросить прибавку к зарплате. Минус здесь в том, что чем больше времени остаётся на рефакторинг, тем быстрее система перестаёт быть проблемной и пропадает необходимость в хорошем программисте, я сам несколько раз проходил через это.

Однако, иногда рефакторинг действительно заключается в глобальных изменениях, масштаб которых исключает постепенную работу по часу в день. Обычно это вызвано тем, что поддержка одной из сторонних систем прекращается или становится слишком дорогой, то есть требования приходит от бизнеса. В этом случае необходимо понимать, что должно получиться в итоге и составить план, как двигаться к этой цели, как проводить тестирование, как внедрять. Пожалуй, тут нет универсальных рецептов, но хорошо бы разбить весь путь на этапы не длиннее 3 месяцев, причём после 1 месяца хорошо бы уже понимать, что ещё через 2 месяца основные цели данного этапа будут достигнуты. Если вы планируете добиться чего-либо через год, не намечая промежуточных контрольных точек, то есть риск, что через 11 месяцев вы окажетесь примерно там же, где и начинали.

Очевидно, что для решения стратегических задач требуются специальные навыки, но систематическое применение рефакторинга на ранних стадиях позволит вам избежать получения проблемной системы. Понятно, что всегда есть соблазн сделать по-быстрому, а со всякими шероховатостями разобраться потом. Но идеи рефакторинга призывают поддерживать ясность кода с самого начала и таким образом снизить риски в будущем.

Google Code Jam

Поучаствовал в Google Code Jam, теперь рассказываю. Задача максимум — съездить в Штаты, выиграть кучу денег уже совсем не реально. Если в Турции успею за день разобраться с Интернетом и не вылечу в предыдущих раундах, то можно побороться за участие в соревнованиях в местном офисе Гугла, боюсь для меня это будет питерский офис.

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

Первая задача была лёгкой, но сначала я ступил: пронумеровал ответы начиная с нуля, а не с единицы, хорошо, что смог найти ошибку. Вторую сделал без проблем. Третья задача была немного муторной геометрией, я её немного поковырял, но так как был уже третий час ночи, то принял стратегическое решение пойти спать. Как оказалось, совершенно правильно — обе первых мне засчитали, а для квалификации хватило бы и одной.

Общее впечатление, что отказавшись от услуг TopCoder Гугл просто сэкономил денег, ничего впечатляющего я в упор не вижу. Вроде бы квалификация давно закончилась, а мне на главной странице упорно про неё рассказывают и пишут большими буквами, что я уже зарегистрирован.