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


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

В этой статье я хочу поделиться своим личным опытом, связанным с правильной организацией кода (архитектурой). Правильная архитектура существенно упрощает долгосрочную поддержку.
Это очень философская тема, поэтому я не могу предложить ничего более, чем мой субъективный анализ и опыт.

Проблемы, симптомы

Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.

Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.

У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.

Drupal 8 – это самый свежий релиз CMS Drupal. Varnish – это HTTP reverse proxy cache, надстройка над вебприложением, которая позволяет кешировать HTTP ответы в ОЗУ сервера.

Когда мы ставим Varnish перед Drupal’ом (либо любым другим вебприложением), схема обработки входящего HTTP запроса трансформируется следующим образом.



Еще во времена Drupal 6 и 7 с помощью Varnish’а было очень удобно кешировать статические ресурсы (рисунки, CSS, JavaScript файлы). Но были пробемы с кешированием HTML страниц – не существовало удобного механизма выборочной инвалидации кеша. Оставалось только либо сознательно отдавать устаревший кеш, либо полностью очищать кеш в Varnish при каких-либо изменениях в Drupal. Оба подхода имели свои недостатки.

Много пик сломано в мире на тему того, можно ли и как создавать многопоточность в PHP. Чаще всего все сводится к тому, что так делать нельзя или дискуссия материализуется в какие-то ужасные костыли (ох, сколько я их уже повидал). Я хочу изложить свою точку зрения на этот вопрос. Легко догадаться, что если бы моя позиция была “так нельзя” или “это зло”, то я бы не писал эту статью. Вот только погодите, не спешите доставать тухлые яйца и вооружаться мелкими бытовыми предметами для рукопашной схватки. Я постараюсь дипломатично изложить тему и максимально объективно раскрыть ситуацию. Так что самые смелые из моих читателей могут прочитать молитву от ереси и открыть статью.

У меня появился Linux на домашнем компьютере, и я поспешил обжиться в новой ОС. Она была установлена с systemd init process. Это было мое первое знакомство с этим новым инструментом. Cвой ноутбук я использую для каждодневной жизни и для программирования. Мне хотелось включать рабочие программы (Apache2 и MySQL) только на время, пока я их использую, чтобы не тратить впустую ресурсы своего компьютера. Дополнительно, для тестирования я написал bash скрипт, который выгружает содержимое одной из MySQL БД c жесткого диска в ОЗУ (в tmpfs) – так тесты выполняются значительно быстрее. По идее, я мог бы начинать свой рабочий день вот так:

systemctl start apache2.service
systemctl start mysqld.service
/root/scripts/mysqld-tmpfs start

И заканчивать его:

systemctl stop apache2.service
systemctl stop mysqld.service
/root/scripts/mysqld-tmpfs stop

Но мне хотелось сделать вещи “как надо”.

Предположим, у нас есть 1 нормальный программист и 1 хороший программист (в 2 раза опытнее и с зарплатой в 2 раза больше). Значит ли это, что хороший программист напишет туже самую программу в 2 раза быстрее? Или что имея бюджет в 1000 долларов, не важно какому программисту мы отдадим работу, мы получим такую же программу? А может быть, если мы наймем 2 нормальных программистов, то они будут работать так же качественно и быстро, как 1 хороший программист? Нет — к сожалению, линейная алгебра не применима к программистам. В этой статье я попытаюсь рассказать почему нельзя складывать и вычитать линейно опыт программистов.

Я часто ловлю себя на мысли, что наличие сроков при написании software может давать негативный эффект, хотя многие считают, что сроки – это полезно. Мне кажется, что их нужно применять все-таки с осторожностью (как и любую другую таблетку счастья). Я попытался проанализировать, как же сроками можно навредить проекту, а как сроками можно улучшить будущий результат.
Для тех, кому лень читать всю статью: я считаю, что сроки нужны, но менеджеры и программисты должны понимать, что иногда сроки проваливаются, и что в этом нет большой трагедии. Иногда в проваленных сроках виноваты обстоятельства, а не конкретные люди.

Когда над одним и тем же проектом (кодом) работает несколько людей, процесс разработки ПО начинает значительно отличаться. С этим фактом нельзя не согласиться. Вступает в действие целый ряд дополнительных факторов. Общим результатом является понижение скорости разработки, а иногда может понизиться и качество разрабатываемого ПО.

Как же быть тогда? Ведь есть проекты, которые в одиночку написать невозможно. В этой статье я попытаюсь показать один психологический аспект работы в команде программистов. Я вас вооружу некоторыми теоретическими знаниями, благодаря которым вы сможете повысить эффективность программистов и их общий эмоциональный фон.