На данную статью меня сподвиг следующий пост “Как улучшить свой стиль программирования?” плюс недавний спор среди коллег.
Представьте себе такой диалог:

Админ: Господа, разработчики, ваш код на сервере стал поедать много оперативки. Сервер уже свопиться начинает. Сами понимаете, все может встать колом!
Представитель разработчиков (например, тимлид): Блин, беда. Сейчас займемся проблемой.
Эй, команда, нас тут админы стыдят за неоптимальный код. Нужно срочно все бросить и оптимизировать старый код.
Менеджер проекта: Эй, вы куда? Какая оптимизация? Пусть админы докупят памяти в сервера и проблемы нет. А у вас вон кучу нового функционала нужно разработать. Никакой оптимизации! Сосредоточьтесь на новом функционале. Нам нужно опередить конкурентов с новыми фичами. Потом как-нибудь оптимизируете свой код.

И кто по вашему прав? Что нужно сделать? Сделать апгрейд железа или заняться оптимизацией?
В конце статьи будет голосование.

Предлагаю в комментариях подискутировать на обозначенную тему. Только давайте не будем считать, что проблема исключительно в оперативной памяти. Вопрос на самом деле более общий: куда тратить деньги? Да да, все именно в них самых. Т.е. деньги можно потратить на новое оборудование либо на человеко-часы (зарплату) которые уйдут на оптимизацию кода.

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

Мысли Админов

Эти разработчики вообще ничего программировать не умеют. Их код все более прожорливый. Постоянно докупаем оборудование. Оно кушает электричество. Да еще и ломается и устаревает. Одни проблемы. Пусть научатся программировать и их творение будет работать на одном сервере. Вот будет счастье!

Мысли разработчиков

Замучали уже с этим новым функционалом. Когда же дадут время на рефакторинг? Вон, админы уже смотрят на нас косо. Код должен быть оптимальным. Легко читаемым. Быстрым и потреблять мало памяти. Мы же можем так программировать. Нам всего лишь для этого нужно на 30-50% больше времени.

Мысли менеджера проекта

Проект уже запущен и приносит прибыль. И вот список нового функционала, который нужно доработать. И сделать нужно это как можно быстрее, чтобы опередить конкурентов. Допустим, я одного разработчика выделю на оптимизацию старого кода, который стал потреблять много памяти. Итого я потрачу N рублей на зарплату за этот месяц на оптимизацию. Плюс потеряем в темпе, т.к. этот разработчик не будет участвовать в создании нового функционала.
С другой стороны за (N * 2) рублей я докуплю горку памяти в сервера.
А если через месяц еще повылезают скрипты (возможно вновь написанные), которые будут пожирать память, то скорее всего это не будет так критично, если в серверах памяти станет больше. И темп в разработке не упадет, т.к. все будут заниматься своим делом: админы апгрейдить сервера, а разработчики создавать новый функционал.
А что вообще нужно сделать чтобы программисты писали более оптимальный код? Они же не со зла так пишут: им либо не хватает знаний, либо времени на оптимизацию.

Как повысить знания? Потратить время на обучение. Или уволить этих и нанять более толковых, но на зарплату на 50% (а может и 100%) больше. Т.е. если команда сейчас не занимается вредительством, то добиться на выходе более оптимального кода — это дополнительные затраты либо по деньгам, либо по времени разработки. Чую, что проще докупить памяти в сервера.

Мысли владельца бизнеса (в игру вступает четвертый персонаж)

Так, менеджер проекта попросил выбрать:

• Потратить дополнительные деньги на разработку (тут возможны варианты: смена команды разработчиков на более дорогую; увеличение времени разработки текущей командой, т.к. она будет больше уделять времени на оптимизацию кода)
• Потратить дополнительные деньги на оборудование (проапгрейдить существующее железо, докупить новые ноды и т.п.)

При этом менеджер дал понять, не факт, что время, потраченное на оптимизацию приведет к цели. А вот дополнительное оборудование точно решит проблему на ближайшие пару лет.
Так же менеджер пояснил, что вложение в команду разработчиков — это скорее долгосрочное инвестирование. Отличный, оптимальный код будет в будущем “приносить дивиденды”.
А вложение в оборудование даст отдачу незамедлительно.
Так же оборудование — это имущество компании. Под него в перспективе, например, можно взять кредит. Или (не дай бог) продать, пусть и дешевле, если вдруг дела пойдут плохо и придется сворачивать бизнес.
(Дальше каждый сам додумывает, что выбрал Бос)

---

При обсуждениях в комментариях предлагаю отталкиваться от следующих предпосылок:

• Текущие разработчики имеют средний уровень. Т.е. они работают с тем качеством, которое могут выдать при том темпе разработки, которое от них требуется. Они могут повысить качество кода за счет дополнительно потраченного времени.
• Затраты на оборудование, например, в 2 раза больше, чем затраты на зарплату (или, например, премию за внеурочную работу) разработчику, который решит проблему с текущим высоким потреблением серверных ресурсов. Причем разработчики решат проблему только в текущем коде и раз уж они накодили “пожирателей” памяти, то скорее всего они продолжат в этом духе. И при текущем тренде роста потребления ресурсов, затраты на оборудование закроют данный вопрос на ближайшие 2 года.
• Речь не идет о баге из-за которого подскочило потребление памяти на 100%. Такое нужно фиксить незамедлительно. Речь идет о том, что увеличением функционала растет потребление ресурсов серверов.

Данные предпосылки — это ситуация, когда огрехи (спасибо за комментарий lolmaus) необходимость рефакторинга по сути дешевле “заткнуть” новым железом. А нужно ли это делать?
Нужно ли оптимизировать код и вылизывать его или проще разработать архитектуру, поддерживающую горизонтальное масштабирование и просто докупать оборудование или поднимать новые инстансы в облаке?

Я не стал делать вариант “докупим немного оборудования и дадим время на оптимизацию”, т.к. по сути — это все равно первый вариант.

P.S. В комментариях я буду подстегивать обсуждение и поддерживать позицию каждого из четырех виртуальных героев данного поста. Так что не считайте, что у меня расчетверение личности :)

Автор: Labutin

Источник