Привет! Меня зовут Алексей Скоробогатый. В 2015 году я пришел в Lamoda на позицию разработчика. Сейчас я системный архитектор e-commerce платформы и по совместительству Technical Lead команды CORE. В этой статье хочу поделиться инсайтами, которые получил за эти 5 лет — в формате takeaways, с историями, мемами и ссылками на литературу.
Буду рад любой дискуссии в комментариях под статьей: вопросы, мнения, опровержения!
Читать полностью »
Данная статья посвящена разбору вопроса о том, какому именно объекту ООП должен принадлежать метод, осуществляющий взаимодейстие между несколькими сущностями.
Это распространённая тема для холиваров. Например:
Не используйте ООП. Никогда. Это ошибка.
На эту тему есть много материалов, к примеру: www.youtube.com/watch?v=QM1iUe6IofM
Если ООП все еще кажется вам хорошей идеей, то решите простую задачку.
Есть три объекта: кошка, кормушка и человек. Вам необходимо написать метод, который бы позволял человеку покормить кошку, воспользовавшись кормушкой.
Вопрос: методом какого класса будет являться метод.покормить()?
Просьба привести аргументированный ответ, в соответствии с иерархией классов, и другими лучшими практиками ООП.
Теперь сравните это с функциональной реализацией: у вас есть функция покормитьКошку() принимающая в качестве аргумента ссылку на кошку и кормушку.
Цитата из холивара
Как ответить на данный вопрос?
Читать полностью »
Программисты много говорят про сложность решений. Мы можем часами размышлять о правильных шаблонах, красивых абстракциях и цепочках зависимостей. Однако, давайте поговорим открыто, всегда ли сложность обусловлена решаемой проблемой? Не оказываемся ли мы в плену наших стереотипов и убеждений?
Если вы иногда задаете себе вопрос: «а всё ли хорошо мне в этот метод приходит?» и выбираете между «а вдруг пронесет» и «лучше на всякий случай проверить», то добро пожаловать под кат… Читать полностью »
Эта статья родилась в ответ на статью «Идеальная локальная сеть». Я не согласен с большинством тезисов автора, и хочу в этой статье не только их опровергнуть, но и выдвинуть свои тезисы, которые потом буду защищать в комментариях. Далее я расскажу о нескольких принципах, которых я придерживаюсь при проектировании локальной сети любого предприятия.
Первый принцип это — надежность. Ненадежная сеть всегда выйдет дороже за счет стоимости ее обслуживания, убытков при простое и убытков от постороннего вмешательства. Исходя из этого принципа всегда проектирую основную сеть только проводной, и при необходимости, дополнительную беспроводную (гостевая сеть или сеть для мобильных терминалов). Почему беспроводная сеть менее надежная? У любой беспроводной сети есть ряд проблем безопасности, стабильности и совместимости. Слишком много рисков для серьезной компании. Читать полностью »
Часть первая, в которой читатель познакомится с краткой историей появления внутренних продуктов 2ГИС и эволюцией системы доставки данных от нескольких скриптов до полноценного приложения.
Сегодня я расскажу вам историю, которая началась 9 лет назад в компании ДубльГИС.
Читать полностью »
Вот цитата из Линуса Торвальдса за 2006 год:
Я огромный сторонник разработки кода вокруг данных, а не наоборот, и я думаю, что это одна из причин, по которой git был довольно успешным… По сути, я утверждаю, что разница между плохим программистом и хорошим заключается в том, считает ли он более важным свой код или свои структуры данных. Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимоотношениях.
Что очень похоже на «правило представления» Эрика Реймонда от 2003 года:
Сверните знания в данные, чтобы логика программы стала глупой и надёжной.
Здесь просто резюме идей, подобных мысли Роба Пайка от 1989 года:
Доминируют данные. Если вы выбрали правильные структуры данных и всё хорошо организовали, то алгоритмы почти всегда будут самоочевидными. Структуры данных, а не алгоритмы, играют центральную роль в программировании.
Ни для кого не секрет, что аналитики — одна из самых свободно и многогранно трактуемых профессий. И, несмотря на наличие аж двух профессиональных стандартов, каждая компания индивидуально очерчивает круг задач, возлагаемых на специалиста, занимающего эту должность. В своей статье я хочу поделиться личным опытом и рассказать, какие роли способен совмещать аналитик на протяжении рядового проекта, какие задачи закрывать, а также куда развиваться, если основная проектная занятость становится совсем скучной.
Надеюсь, мой рассказ поможет вам с удивлением обнаружить, какими бывают ваши собратья по разуму, а также подсветит возможные точки роста и развития.
Всё, о чём дальше будет идти речь – сугубо личный опыт во вполне определённом виде деятельности, заключающемся в разработке и внедрении заказных решений на базе конкретной системы со своей платформой и своим языком программирования.
Более того, эта деятельность дополнительно ограничена предметной спецификой внедряемой системы, а также внутренними технологиями вендора, выступающими в роли локальных стандартов.
Ну и в качестве вишенки на торте – деятельность эта осуществляется на благо кровавого энтерпрайза. И когда я говорю о кровавом энтерпрайзе, я подразумеваю проекты в очень крупных компаниях – практически весь нефтегаз, крупнейшие банки, промышленники, ритейл и т.д.
Соответственно, аналитик, о котором пойдёт речь в статье – это человек, существующий внутри всей вышеозначенной парадигмы. Более того, это вполне реальный и живой человек, каким бы сферическим конём в вакууме он вам ни казался по ходу чтения.
В конце декабря 2008 года меня пригласили в одну из служб такси г.Перми с целью автоматизации существующих бизнес-процессов. В целом передо мной были поставлены три фундаментальные задачи:
На тот момент я не понимал, как устроен этот рынок и его нюансы, но тем не менее очевидными для меня были две вещи. Call центр необходимо строить на базе программной АТС asterisk с открытым исходных кодом. Обмен информацией между call центром и мобильным приложением по сути является клиент-серверным решением со всеми соответствующими паттернами проектирования архитектуры будущего проекта и его программирования.
После предварительной оценки поставленных задач, сроков выполнения и затрат на реализацию проекта, согласовав все необходимые вопросы с владельцем службы такси, в январе 2009 года я приступил к работе.
В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.
Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.
Снова и снова случается так, что многие бизнес-идеи на самом деле не превращаются в конечный, намеченный продукт. Зачастую это происходит из-за неспособности понять разницу между бизнес-требованиями и функциональными требованиями, что в конечном итоге, приводит к несоответствующему сбору требований, ненужной документации, задержкам проекта и крупным проектным сбоям.
Или иногда мы сталкиваемся с ситуациями, в которых, хотя окончательное решение отвечает потребностям клиентов, но каким-то образом бизнес-цели не достигаются.
Поэтому крайне важно разделить бизнес-требования и функциональные требования, до того момента, как вы начнете их определять. Давайте разберем пример.
