Архив от 2017

Всегда приятно начинать новый проект. Простые классы, четкие границы, ясная архитектура — все логично и красиво. Новая функциональность добавляется легко и быстро.

Идет время, проект развивается, поступают новые требования. Но приходит день, когда вы обнаруживаете в коде что-то плохое. Кто-то срезал угол и сделал небольшой костыль. Бывает, что вы сами делаете что-то на скорую руку, честно вставляя в код “todo” — просто потому, что эта функциональность нужна для ближайшего релиза, а времени сделать все правильно нет. “Это технический долг, который мы обязательно исправим после очередного релиза, но сейчас надо выдать версию” — произносим мы при этом.

Нет ничего более постоянного, чем временное — очень справедливые слова. Чаще всего бывает, что дальше технический долг будет только нарастать. Так же, как обслуживание долга в банке требует выплаты процентов, наличие технического долга забирает свой процент. Мы платим за это увеличивающейся сложностью внесения изменений, нарастающей неочевидностью и нелогичностью модели, изчезающим энтузиазмом команды.

В определенный момент становится понятно, что история повторилась и у нас в руках очередной “большой ком грязи”. Что же делать и можно ли этого избежать?

(далее…)

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

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

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

Естественный вопрос, который возникает — как разделить набор функций системы на обособленные куски, пригодные для вынесения в подсистемы и до какого размера следует производить дробление?

(далее…)

16 марта вышли новые версии php — 7.0.17 и 7.1.3. Это приятная новость для многих php разработчиков, но для нас она приятна еще и тем, что туда вошел наш патч, который чинит keep-alive соединения в php-fpm sapi.

Php-fpm появился сначала как отдельный патч для php 5.2, добавляющий менеджер fastcgi процессов, который позволяет организовать отдельные пулы, следит за временами выполнений рабочих процессов и много другое полезное. В ветке php 5.4 его приняли как официальный sapi и мы избавились от необходимости накладывать этот патч всякий раз, как выходит новая версия php с исправлением ошибок.

(далее…)

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

В первую очередь необходимо определиться с терминами. Если мы говорим о физическом расположении сотрудников и степени их вовлеченности в проект, возникают две основные дихотомии: «Договор-Штат» и «Офис-Удаленная работа».

remote-dichotomy

(далее…)

  • Sharing

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather