• Проект со сложной логикой на Symfony – как проектировать? Примеры?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Как хранить бизнес-логику чтобы модели не превратились в монстров из десятков тысяч строк?

    Тут не совсем модели. Entity - это просто объект данных, умеет хранить их в себе и бросать исключения, если не правильные данные вставляете, все. Repository - умеет работать со своим Entity И БД.

    БЛ находится в классах сервисах.

    Читал про Command Bus где, если правильно понял, на каждое действие в системе – свой класс?

    Вообще под каждое дествие - не обязательно, тут нужно руководствоваться здравым смыслом.

    Как их организуете (их тогда будут сотни)?

    Иерархически. Путь к классу должен быть "понимаем".

    Есть ли смысл выносить каждую доменную модель в модуль/микросервис, хранить всю связанную логику где-то там внутри, а с остальными общаться по внешнему API?

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

    За ответы в клиентскую часть – отдельный сервис-фронтенд?

    Если в "сервис" вы вкладываете понятие простого класса, умеющего форматировать ответы вашего проекта - мысль здравая.
    Если ответы будут асинхронными (от сервера к другому) - имеет смысл выностить в отдельный клиентский класс.

    Каков оверхед?

    Ничтожный.

    Используют ли такое на практике?

    Да

    Какие подводные камни?

    Следствием серьезной декомпозиции в любом случае будут лишние сущности, чем раньше от них будете избавляться - тем лучше.

    Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

    Если есть возможность отказаться от событийной модели - часто лучше отказаться.
    Листнеры доктрины конечно штука мощная, но работает не всегда очевидно.

    Функционал "PostBeforeEdit/PostBeforeEditHandler" часто дешевле и проще вынести в сервис, но опять же руководствуйтесь здравым смыслом.

    ACL Где храните указанную логику?

    Если ACL будет не тривиальный - готовьте себя к тому, что он будет размазан по уровню контроллеров.

    Какие структуры для описанного выше – best practice?

    Если есть возможность привести к одноуровневому виду - сделайте. Если с точки зрения бизнеса может потребоваться иерархическая (не фиксированной вложенности) ACL - до последнего убеждайте, что это плохая идея, не повторяйте чужих ошибок.

    В моём понимании это выглядит как куча трёхмерных кубов доступа "crud – group – entity – field", как это сделать более плоским пока только одна идея – делать кучу таблиц many-to-many.

    Гибкая настройка вплоть до каждого поля 90% что не нужна. Если можно свести к понятию скопов прав - сделайте это.
    Структуру можно предлагать только зная ваш проект.

    Версионирование. Как вы версионируете подобные проекты?

    Semver.

    А если нужна "N-1" рабочая версия на продакшене?

    Значит на прод попадает ваша версия с тегом "N-1"))

    Есть ли смысл разделять версии в рамках единой кодовой базы проекта и как (неймспейсы, конфиг, модуль, что-то ещё)?

    Храните яйца в отдельных корзинках. Если модуль развивается полностью отдельно и может быть вынесен как зависимость проекта в vendor - делайте.

    И, самое главное – как всё это совместить?

    • РУКОВОДСТВУЙТЕСЬ ЗДРАВЫМ СМЫСЛОМ
    • Принимаете жесткие соглашения по правилам написания кода, например такие
    • Постарайтесь убедить бизнес в том, что без покрытия кода автотестами будет дороже, нестабильней и дольше. + Пишите тесты. Если объем тестов в 4 раза больше кода, который они тестируют - это норм. У меня бывали случаи, когда для критичного функционала тестов было в ~16 раз больше, чем кода.
    • Жесткие, обязательные кодревью.
    • Если задача крупная - декомпозируйте ее.
    • Технический долг - возвращайте обязательно И как можно скорее.
    • Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
    • Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
    Ответ написан
    6 комментариев
  • Правильно ли я понял философию Docker?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Контейнеры данных


    Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

    Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять


    Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

    На файловой системе хоста


    Ничего.

    Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

    Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.
    Ответ написан
    21 комментарий
  • Попросили проверить код, на что смотреть нужно?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Смотря зачем)). Я когда делаю Code Review критерии следующие:

    * Безопасность:
    - Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
    - Никаких trigger_error, только исключения.
    - Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
    - Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
    - За eval как правило шлю на **й.
    - @ допускается только в безвыходных ситуациях, например проверка json_last_error.
    - Перед работой с БД - обязательная проверка данных.
    - Никаких == и !=. Со swtich - единственное исключение, по ситуации.
    - Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
    - Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
    - Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
    - Конкатенации в sql - только в безвыходных ситуациях.
    - Параметры в sql - ТОЛЬКО через плейсхолдеры.
    - Никаких глобальных переменных.
    - Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
    - Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

    * Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
    - В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
    - Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

    * Организация кода:
    - Никаких глобальных функций.
    - Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

    * Тестируемость (в смысле простота тестирования) кода должна быть высокая.
    - Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

    * Принципы MVC:
    - Никаких обработок пользовательского ввода в моделях, от слова совсем.
    - Никаких ***ть запросов в БД из шаблонов.
    - Никаких верстки/js/css/sql-ин в контроллерах.
    - В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
    - В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

    * Принципы SOLD:
    - Никаких божественных объектов умеющих во все.
    - Если метод для внутреннего пользования - private, никаких public.
    - Статические методы разрешаются только в случае безвыходности.

    * Принцип DRY разрешено нарушать в случаях:
    - Явного разделения обязанностей
    - В тестах (каждый тест должен быть независимым, на сколько это возможно)

    * Работа с БД:
    - Запрос в цикле должен быть РЕАЛЬНО обоснован.
    - За ORDER BY RAND() - шлю на***й.
    - Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
    - Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
    - SELECT * - запрещен.
    - Денормализация БД должна быть обоснована.
    - MyISAM не используется (так уж)) )
    - Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
    - БД не должна содержать бизнес логики, только данные в целостном виде.
    - Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

    * О людях:
    - "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
    - "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
    - "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
    - "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
    - "У меня все работает!" - рад за тебя, а как на счет продакшна?
    - "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

    * Всякое:
    ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
    То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

    UPD

    Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions
    Ответ написан
    55 комментариев
  • В чем различия этих конструкций в JavaScript?

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    Краткий ликбез по JS: Как работает прототипное наследование: при обращении к свойству оно ищется сначала в самом объекте, потом, если не найдено, в том объекте, который указан как прототип (скрытое свойство [[Prototype]]) для исходного, потом в прототипе прототипа и так далее, пока прототип не null. Что происходит, когда мы вызываем new SomeFunction(): создается новый объект у которого [[Prototype]] ссылается на SomeFunction.prototype, в контексте этого нового объекта вызывается SomeFunction (как если бы через apply или call), полученный объект возвращается.

    1) В первом варианте у вас в конструкторе лишняя операция. А если таких методов 10? А если надо создать 10000 таких объектов?
    2) Во первом варианте у вас каждый инстанс будет непосредственно иметь ссылку на getName. Во втором — каждый инстанс будет иметь ссылку на прототип, в котором уже будет ссылка на getName. Значит, первый вариант будет жрать поболе памяти (однако обращение к методу getName будет работать чуточку быстрее).
    3) Можно так делать, если очень надо переопределить getName для данного объекта. Но с точки зрения архитектуры — не стоит, лучше создать отдельный класс или фабричную функцию, которая будет возвращать объект с нужным getName. Причина: black magic, который задолбаешься искать по коду.
    4) На данный момент времени, можно, наверное, начинать писать на ES2015 с нативными классами, чтобы не придумывать велосипеды с колесами из костылей:)
    Ответ написан
    6 комментариев
  • Bootstrap какой из сервисов для быстрого прототипирования лучший?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    pingendo.com
    бесплатный, приложения под все ОС, не браузерный
    Ответ написан
    4 комментария
  • Как правильно читать книги по программированию?

    saboteur_kiev
    @saboteur_kiev Куратор тега Книги
    software engineer
    сперва были вопросы "как стать программистом"
    затем вопросы "что читать"
    теперь уже "как читать"
    может скоро будет "как учить алфавит, а то за меня родители пишут на тостере".

    Для книг - читайте простейшие туториалы и сразу практика. Сложные книги - потом, когда в голове уже будет база.

    Добавлю еще момент:
    Почитайте статью megamozg.ru/post/10126
    Там очень понятно указано, что профессиональный навык и боль программиста - гиперконцентрация, которая необходима, чтобы освоить понятия и вещи для профессиональной работы. 40 минут это как-то несерьезно.
    Ответ написан
    3 комментария
  • ReactJS где же лучше применять?

    smanioso
    @smanioso
    Отмечайте ответы на свои вопросы!
    Рекомендую посмотреть:
    isomorphic.net
    davidchang.github.io/ngReact
    https://github.com/facebook/react/wiki/Complementa...
    https://andywalpole.me/#!/blog/142134/2015-the-end...
    После этого уже самому принимать решение, основываясь на личных предпочтениях.

    ЗЫ: если уж так нравится Angular, то может стоит обратить внимание на его логическое продолжение в виде Angular 2.0? ЕМНИП, в нем View основан на более корректной концепции WebComponents.
    Ответ написан
    Комментировать
  • Где найти рецепты сложных архитектур?

    @RokkerRuslan
    Комментировать
  • Где найти рецепты сложных архитектур?

    @cthulhudx
    1)Yakov Fain, Victor Rasputnis, Viktor Gamov "Enterprise Web Development"
    enterprisewebbook.com (Разбирается обширное количество тем, в том числе SPA)
    2)Catalog of Patterns of Enterprise Application Architecture
    martinfowler.com/eaaCatalog
    3)Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Шаблоны интеграции корпоративных приложений) Мартина Фаулера
    4)Паттерны для масштабируемых JavaScript-приложений:
    largescalejs.ru
    Ответ написан
    Комментировать
  • Куда двигаться в веб-разработке?

    @rsi
    software engineer
    Перво наперво определитесь, хотите ли вы стать профессионалом или просто хорошо делать сайты. Я бы предложил выбрать путь профессионала.

    Во вторых определитесь, каким именно профессионалом вы хотите стать:
    1. web - мастером
    2. Front end
    3. Back end
    4. Desktop
    5. Другого направления


    Как только вы определитесь с направлением, делайте основной упор на изучение тонкостей свойственных именного этого направления.

    Здесь вам советовали сменить язык, не слушайте этих советов. Да Ruby имеет некоторые преимущества перед php, но имеет и недостатки. Не думайте, что если вы выберите Ruby (python) ваша жизнь измениться, вы не получите ничего, что не может вам дать php и на оборот, эти увеличенные зп и прочее миф, язык не важен. Помните, ЯП это всего лишь инструмент, вы конечно должны иметь инструмент, и должны знать свой инструмент в совершенстве, но умение программировать заключается не в этом. Да, плотник алкоголик, который зарабатывает на жизнь забивая гвозди, может хвалить свой молоток и всем рассказать, что молоток его кормилец, но согласитесь настоящий строитель умеет не только гвозди мотком забивать, не говоря уже об архитекторе, который молоток и в руках мог вообще не держать.

    И так предположим, вы выбрали свой путь, вы выбрали направление и выбрали инструмент. Теперь вам нужно работать в этом направлении (как над собой, так и в буквальном смысле работать). Читайте статьи, читайте книги (я всегда рекомендую только одну книгу - "Совершенный код", ее без преувеличивания должен прочитать каждый программист), изучайте новые фреймворки, технологии, отрасль постоянно движется вперед, вам нужно двигаться вперед еще быстрее, что бы хотя бы не стоять на месте. В процессе работы над проектами вы будете чувствовать нехватку знаний (вы упоминали js, ООП), устраняйте эти пробелы книгами (не стоит бояться 900 страниц, книги вы ничем не замените, их необходимо читать), статьями и конечно практикой. Не переживайте по поводу отсутствия высшего образования, оно не дает глубокого знания, никто не расскажет вам ни каких трюков, если у вас не будет толкового преподавателя. Но толковый преподаватель, это не обязательно учитель в универе, это может быть автор книги (например Макконел), автор хорошего инструмента (например Taylor Otwell), большинство очень известных и авторитетных людей генерирует тонну информации, книги, статьи, записи в соц. сетях, код, все это можно читать и это даст вам куда больше чем ВО. И да, мы с вами живем в уникальное время, время интернета, где нет расстояний, и это дает намного больше возможностей, чем нагуглить очередной костыль для jquery от школьника, вы можете общаться лично например со Страуструпом или тем же Тейлором, ни в одном учебном заведении России у вас не будет возможности поговорить с такими людьми.

    Подведя итог:
    1. Определите путь (хотя бы примерно)
    2. Определите специализацию (хотя бы примерно)
    3. Выберите инструмент (один основной язык, один основной фреймоврк, одну основную cms и тд)
    4. Изучите свой инструмент в совершенстве
    5. Пробуйте другие инструменты (да я сказал один яп, один фреймворк, но один вы должны знать в совершенстве, остальные должны попробовать)
    6. Расширяйте кругозор
    7. Работайте над собой
    8. Работайте
    9. Выберите наставников и учитесь у них


    Следуя этим советам вы увеличите свой скилл, сможете сами отвечать на вопрос заданный в заголовке и станете профессионалом. И помните путь профессионала, это постоянная работа (как буквально работа, так и работа над собой, если просто писать сайты 24/7 вы тоже профессионалом не станете), гораздо больше чем 8 часов в день, 5 дней в неделю.
    Ответ написан
    Комментировать
  • Проект с высокой посещаемостью - архитектура. Фреймворк или самопис?

    SamDark
    @SamDark
    Yii2 core team
    Yii подходит для такого проекта.

    Как уже было отмечено, если выводить по 100 записей на страницу и для каждой по 10—20 связанных записей, будет кушать память. Ну и ещё момент, не стоит увлекаться event-ами и сильно слоить view через renderPartial.

    Чат между пользователями можно реализовать поверх XMPP. Нагрузку такое решение держит отменно.

    MySQL может, при грамотной настройке, выдержать очень много. У нас, например, есть в проекте боевом JOIN по таблице с 200 млн. записей. Нормально бегает.

    PHP вполне себе справится.
    Ответ написан
    5 комментариев