All streams
Search
Write a publication
Pull to refresh
29
0
Пётр Грибанов @ghost404

Symfony professional developer

Send message
И, да, не считаю нужным вводить в модель кто и когда её создавал и модифицировал, если это делается только для административных целей

Согласен с вами. Об этом я и написал в статье. В данном случае лучше использовать лог-файл и вынести логирование за пределы сущности, например в обработчики доменных событий. Я привел это только как пример.


Но, как я уже говорил, логирование на уровне сущностей может быть нужно для голосований, если мы хотим ограничить количество голосов от одного пользователя. Если голосовать могут только авторизированные пользователи, то мы привязываем голос к пользователю по его ID, а если могу и анонимные, то нужно генерировать GUID на основе IP и User-Agent.


Еще дата создания сущности может быть нужна для применения миграций, когда нам нужно например, изменить что-то в записях которые были созданы после 2017-01-01. Можно конечно извлечь эту информацию из лога, но это очень трудоемко.


А вот еще один реальный бизнес-процесс: удалять из бд все записи старше 6 месяцев. Без знания даты создания сощности это сделать невозможно.


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


Ну и на последок, приведу пример использование DTO на примере счетчика просмотров:


class Video
{
    public function view(ViewRequest $request)
    {
        if ($request->getVideo() !== $this) {
            throw new \InvalidArgumentException();
        }

        $this->total_views++;

        return new View($request);
    }
}

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


Эти навороты делаются для сохранения консистентности данных, то есть чтобы нельзя было в любом месте программы инкрементировать просмотр без реального просмотра.

Мой комментарий получился немного великоват и я оформил его в виде отдельной статьи:
https://habrahabr.ru/post/321892/

Хорошо, пусть будет vagrant. У вас в виртуалке рабочая копия, снимок репозитория или хостинг?

У меня в vagrant все. База, исходники, репозиторий и тд. Это не точная копия прода, так-как отличаются некоторые параметры окружения, но в остальном копия, максимально приближена к прод.

Если говорить вашим языком:
Вы сами заявляете, что у вас есть кожух на циркулярке, но ваши люди продолжают резать руки. Значиь либо кожух плохой и не защищает, либо людей нужно учить им пользоваться.
У меня нет кожуха на циркулярке. Я и мои коллеги не режем руки. Может не в инструменте дело?


PS: не смотря на мои критические заявления, я не хочу сказать что git лучше hg. Вам он больше нравится и лучше подходит. Окей. Рад за вас. Я не хочу оспаривать ваш выбор. Я лишь хочу донести мысль, что hg не серебрянная пуля. Он не решает ваши проблемы в полной мере, как и не будет их решать git.

Это как? Рабочую копию в контейнере держать? Хостить в нём репозиторий?

Я с контейнерами не работал. Если верить статьям по работе, то это можно сделать. Я же имел дело с использованием такого подхода в vagrant.

Вы, фактически, описали то же, что и я, перечитайте мои 8 пунктов. :-)

Да, фактически я скопиравал, переупорядочил и переформулировал ваш список, так же как и вы мой до этого)))

Мне это нужно, но я не могу настраивать хуки на машинах других разработчиков. Со своими коммитами я сам разберусь, но копаться мне нужно в чужих.

Есть такая штука, называется: Внутренний регламент разработки ПО.
Документ в котором описано что и как нужно писать, а что писать не надо, code style и т.д. В него также входит описание настройки окружения и работы с ним. Каждый разработчик обязан ознакомится с регламентом и подписать его. В документе можно описать установку хук для гита.


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


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


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

Перечитал еще раз ваш комментарий


решение о том попадёт ли фича в релиз может быть принято только после полного её тестирования и в том числе тестирования совместимости её с другими фичами релиза

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


Тестирование на совместимость в идеальном мире должно происходить многосторонне. В вашем примере получается, что группа разработчикав работавшая над фичей А должна проверить все ли у них работает после объединения с фичей Б, а разработчики фичи Б должны проверить весь свой функционал после мерджа с фичей А. Тестирование должно повторится после добавления фичи С и еще раз после добавления фичи Д и т.д.


Да, мы можем тестировать ветку на совместимость с другими ветками которые должны попасть в релиз. Но пока релиз не создан это просто висячие в воздухе ветки. Их список знает только тимлид и нет гарантии что пока вы тестируете ветки на совместимость не изменится список веток и сами ветки. На мой взгляд это перебор. Тестирование ради тестирования. Если фич всего 2-3, то еще можно жить, а если 30-40, то уже проблема тестировать все это у себя.


Потому я и говорю что нужна ветка с релизом чтоб не делать одну и туже работу многократно:


  1. Мерджмастер создает ветку релиза (это может быть develop, release-678, issue-123 и тд. Название в данном случае не столь важно).
  2. Мерджит туда все фичи и баги которые должны попасть в следующий релиз.
  3. Если есть конфликты, то релиз отменяется и тикеты возвращаются разработчикам для доработки. Возвращаемся к п. 1
  4. Если все смерджилось нормально, то ветка отправляется на тестирование на совместимость.
  5. Каждая команда проверяет работу того куска за который отвечает она.
  6. В случае проблем с совместимостью релиз отменяется и задачи возвращаются на доработку. Возвращаемся к п. 1
  7. После успешного завершения тестирования релиз выкатывается.

Идея с feature-123.api-345.example.org моя голубая мечта и я пытался такое внедрить, но у меня еще не было ни одного проекта и компании которые могли себе такое позволить, а я работал над очень крупными hl проектами с милионами пользователей. Проблема же не только в доменах и автоматическом развертывании фич. Проблема еще в том что фичи зачастую завязаны на базе и для каждой фичи нужна своя копия базы, может и урезанная, но своя. Тоже может касаться NoSQL и ElasticSearch. Фактически, окружение для фичи должно быть максиму приближено к прод, но должно быть изолировано от других фич. А это уже совсем не детские ресурсы. Может в mail.ru или яндекс такое есть)))


PS: мне немножко странно почему вы релиз тестируете на проде и сливаете его в местер только после завершения тестирования. Мастер должен быть всегда эквевалентен проду. А для фиксации статуса используются теги, они же релизы в большинстве случаев. Если на проде баг то мы откатываем как прод, так и мастер. Не должно быть разделения. А то у вас получается мастер вообще как-то отдельно от всего, в воздухе висит. Ну это уже ваше дело. Я не критикую.

hg из коробки может добавлять номер тикета в коммит?
Именно номер тикета, а не название ветки?
И hg из коробки привязывает коммит к тикету?
Похожу вы просто не понимаете о чем говорите.


Да, git не добавляет название ветки из коробки, потому что это просто не нужно. А тем кому это нужно могут настроить хук.
Проблема то не в инструменте, а в умении им пользоваться.

Ну это уже савсем идеальный мир. Я с таким не сталкивался и необходимости в такой идеалезированности не было.
Но я учту вашу мысль на будущее

Цель статьи — дать понимание, что мы используем Dependency Inversion, чтобы разделить модули асбтракцией, Dependency Injection, чтобы избавиться от инстантинации вручную, а реализуем это посредством фреймворка, построенного по принципу Inversion of Control. И ничто из этого не является синонимом друг друга.

Вот это стоило написать в статье, а то лично я понял всё только после вашего комментария.
И да, фраймворки, как правило, реализуют IoC по средствам Service Locator у себя в недрах.

По правильному никакого develop быть не должно.

Спорное утверждение. Ветка develop по сути содержит ветки которые попадут в следующий релиз. Можно ветку назвать release или release-1.2.3 по номеру версии следующего релиза. Можно для релиза создать отдельный тикет и соответственно ветку назвать по номеру тикета как и все обычные ветки.


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


Если в качестве пререлизной ветки использовать master, то будут проблемы с выкатыванием хотфиксов без фич которые уже смерджены в master


Также частым решением бывает создание сайта разработки dev.example.com. Если example.com эквивалентен ветке master, то для сайта dev.example.com выбирают эквивалентом ветку develop. Если мы будем называть ветку release-1.2.3 или issue-123, то будут проблемы с настройкой автодеплоя сайта dev.example.com так как ветка постоянно меняется.


Это что касается web. Для других проектов это может быть не актуально и там возможно и правда не нужна ветка develop.
Из собственного опыта скажу, что при разработке библиотек, ветка develop действительно только мешает, а при разработки крупных сайт-проектов сильно спасает.

Если вы ну совсем никак не можете разобраться в своих коммитах, пропишите хук в PROJECT/.git/hooks/prepare-commit-msg.


Этот добавит #<BRANCH_NAME> в конце коммита.
Называйте ветки по номеру задачи или по номеру задачи с префиксом issue- и будет вам счастье.


#!/bin/sh
#
# Automatically adds branch name to every commit message.
#
BRANCH_NAME=$(git symbolic-ref --short HEAD)
BRANCH_NAME=${BRANCH_NAME/issue-/}
if [ -n "$BRANCH_NAME" ] &&
    [ "$BRANCH_NAME" != "master" ] &&
    [ "$BRANCH_NAME" != "develop" ];
then
    sed -i.bak -e "1s/$/ #$BRANCH_NAME/" $1
fi

GitHub, GitLab и Bitbucket автоматом подцепят тикеты


Ну и не забываем про


git config --global --add merge.ff false

А в чем проблема?


  • Есть задача, должна быть и ветка.
  • Нет ветки — нарушил регламент.
  • Есть ветка — смотришь в схему.
  • Если там бардак, то задаешь вопрос разработчику.
  • Либо он нарушил регламент, либо git так слил ветки.
  • Если первым коммитом в ветке будет не мердж, то в схеме все будет нормально.
  • Если бардака в схеме нет, то регламент не нарушен.

Не сталкивался с таким и даже слабо себе это представляю.


Протестировал немного.
Да, сделать такое можно.


Получается если создать ветку Б из ветки А, то они будут эквевалентны и будет сложно понять что это ветка Б сделана из А или А из Б. То есть какая из веток является изначальной и соответственно к какой ветке относятся сделанные ранее коммиты. Но если ветки эквевалентны, то какая принципиальная разница какая из них изначально созданная?


Что вы в корзину положите одно яблоко, что одно яблоко положите в корзину, все равно в корзине будет одно яблоко.


То же самое происходит если создать ветку Б из корня ветки А и смерджить в нее ветку А, но при условии что ветка А не участвовала в других мерджах. В моем случае это ветки issue-345 и issue-456 с общими коммитоми 916908b и 4310c9e. А вот с веткой issue-3 это уже не работает так как ветки issue-1 и issue-2 уже участвовали в мерджах.


У меня нет под рукой SVN чтоб проверить, но думается мне что там будет похожая картина

Забыл сказать. Проблемы есть только с тестированием, когда нужно отдать задачу на тестирование тестировщикам.


По правильному нужно тестировать задачу сначала отдельно (как отдельную ветку), а потом сливать в develop и тестировать еще раз на совместимость с другими задачами в develop.


У нас тестировщики были ленивые и тестировали сразу develop что изрядно усложняло разработку и ветвление в git.

Вы что, не читали статью по ссылке?


После удаления ветки удаляется только метка ветки, а коммиты никуда не деваются. Они все еще висят в истории как отдельная ветка (если конечно ветку смерджили куда-то с флагом --no-ff). Я даже больше скажу. Можно восстанавить ветку после удаления и начать работать с того же места на котором остановился (доводилось такое делать). И все ветки прекрасно видно в истории даже после их удаления. Сами полистайте историю.


Если вам лень читать статью, то объясню все на пальцах:


  • Ветка master всегда эквевалентна продакшену
  • Ветка develop предназначена для разработки.
    Перед релизом обязательно сливаться в master.
    Также полезным будет слить master в develop.
    Если develop не сливать в master, то через несколько итераций расхождение веток может стать критическим (сталкивался с таким).
  • Ветка issue-123 создается по тикету #123.
    Создается из master и мерджится в develop.
    Если ей для работы нужны другие задачи, то они мерджатся в нее.
    Ни в коем случае нельзя в нее мерджить develop ибо может потребоваться выкатить эту задачу до полного релиза с мерджем develop в master, а в этот момент в develop может быть еще не доработанная или не до тестированная фича.
  • Ветка fix-456 hotfix по тикиту #456 со срочными правками.
    Создается из master и мерджится в master, develop и другие активные ветки по необходимости.
    Далее выкатывается master с hotfix-ами.
    Ветку develop не трогаем.

Работаю по этой схеме уже несколько лет в разных компаниях и ни каких проблем.

Начнем с того что у нас 48000 пользователей и 3000 каналов. Это 16 пользователей на канал :)

Я так понимаю что зарегистрированных пользователей 48к, а устройств (тоесть реально пользующихся) 33к. А так как ваше решение мультиплатформенное и продвигается именно как такое, то количество реальных пользователей значительно меньше чем устройств.


А и еще не ответил по поводу фразы «либо свое приложение либо никакое» для охвата всех платформ нужно нанять штат программистов и платить им деньги чтобы они все это поддерживали, купить сервера для отправки и тд.

Естественно дороже, но и профит не 200 человек, а тысячи или даже милионы пользователей. Пользователей с которыми мы имеем двустороннюю связи и на которых мы можем раельно зарабатывать.


Я не просто так упомянул другие приложения. Как вы думаете, почему у приложения YouTube или Facebook пользователей больше чем у вас? Ладно, возмем для урощения новостные приложения: РБК, RT, РИА и т.д.
Почему у них пользователей больше чем у вас? Да потому что не PUSH-ем единым живы.


Ваше решение хорошо подходит для блогеров у которых нет денег, которым плевать не пристиж и для которых PUSH это только дополнительная плюшка как RSS.

Порадовала запись на сайте:


Все уведомления — одно приложение!

И ниже пачка ссылок.


Какое же это одно приложение? Это целый зоопарк приложений. Платформа конечно одна, но чтобы ей пользоваться нужен зоопарк. Это савсем не здорово.


Если пользователю нужно что-то ставить чтоб пользоваться сервисом это уже плохо. С таким же успехом можно разработать приложение на дисктоп. А лучше вообще, выдать каждому пользователю брендированные, персональные телефоны, которые только и делают что показывают наши замечательные push уведомления. Я утрирую конечно, но суть вы уловили?


Пользоваться нужно либо нативными уведомлениями либо никакими. А для мобильных устройств нужно разрабатывать полноценное персональное приложение, которое кроме всего прочего ещё и уведомления отправляет. Пример тот же Вконтакте, Файсбук, Ютуб и т.д.


Ещё хорошей практикой является не рассылка спам уведомлений всем и все без разбора, а отправка персоналезированных сообщений, а они завязаны на бизнеслогике проекта. Ваш проект позволяет такое?


Ах, да. Савсем забыл. Если верить вашей же статистике то у вас в среднем 10 человек на канал. Это савсем не вдохновляет.

Information

Rating
Does not participate
Location
Россия
Registered
Activity