Олег Максименко

Интерфейс нужно будет указывать как параметр функций, которые будут уметь работать с вашим интрейфейсом.
Например.

func Process(device test123.Command) {
    device.Open()
    device.Close()
}

dev1 := a123.A123struct{параметры...}
Process(dev1)

dev2 := b123.B123struct{параметры...}
Process(dev2)

// или с перечислением
devices := []test123.Command{dev1, dev2}
for _, device := range devices {
    Process(device)
}

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

package main

import (
    "fmt"
    "os"
)

// Logger интерфейс логгера.
type Logger interface {
    Error(msg string)
}

// StdoutLogger реализация интерфейса Logger для вывода сообщений в консоль.
type StdoutLogger struct{}

// NewStdoutLogger конструктор (возвращаем структуру, не интерфейс)
func NewStdoutLogger() *StdoutLogger {
    return &StdoutLogger{}
}

// Error добавляет в лог сообщение с уровнем error
func (l *StdoutLogger) Error(msg string) {
    fmt.Printf("ERROR: %s\n", msg)
}

// FileLogger реализация интерфейса Logger для вывода сообщений в файл.
type FileLogger struct {
    FileName string
    Fh       *os.File
}

// NewFileLogger конструктор.
func NewFileLogger(fileName string) *FileLogger {
    logger := &FileLogger{
        FileName: fileName,
    }
    fh, err := os.OpenFile(fileName, os.O_RDWR|os.O_CREATE, 0664)
    if err != nil {
        panic(fmt.Sprintf("FileLogger: can't open log file: %s: %s\n", fileName, err))
    }
    logger.Fh = fh

    return logger
}

// Error добавляет в лог сообщение с уровнем error.
func (l *FileLogger) Error(msg string) {
    l.Fh.WriteString(fmt.Sprintf("ERROR: %s\n", msg))
}

// ProcessData какая то функция, которая использует логгер и которую не должна беспокоить реализация логгера.
// Тут тип параметра должен быть интерфейс.
func ProcessData(logger Logger) {
    logger.Error("Data process some error happened")
}

func main() {
    var logger Logger

    // если лог файл не указан - используем StdoutLogger, если указан - используем FileLogger
    logFile := os.Getenv("LOG_FILE")
    if logFile != `` {
        logger = NewFileLogger(logFile)
    } else {
        logger = NewStdoutLogger()
    }

    ProcessData(logger)
}

После запуска go run main.go вы увидите сообщение в консоли:
ERROR: Data process some error happened
а если запустите вот так LOG_FILE=test.log go run main.go
или

export LOG_FILE=test.log
go run main.go

То будет создан файл test.log и туда будет добавлено тоже сообщение, что вы видели в консоли.

Если понятнее не стало - пишите, будут рад помочь.

В самую первую очередь - это будет документация языка. Ее очень удобно использовать как справочник. Это - твой самый первый источник информации по любому вопросу.
isocpp поддерживается создателем языка и содержит море полезной информации.
C++ Core Guidelines является манифестом пользователя C++. Его знать обязательно. Документ регулярно дополняется.

More C++ Idioms. Шаблоны проектирования имеют свою собственную многомерную классификацию. Идиомы - это функциональные шаблоны проектирования, применимые, как правило, или для конкретного языка, или для некоторого семейства языков. Эта открытая книга помогает ориентироваться в некотором начальном наборе идиом конкретно для языка C++.
C++ Patterns - еще один полезный ресурс для изучения применимых к C++ шаблонов проектирования.
С Fluent C++ ты уже знаком.
Безусловно, блог создателей PVS-Studio.
Habr, конечно же.
Блогов очень много, их можно просто найти по релевантной фразе "C++ blog".

Помимо этого есть большое количество каналов от разных конференций, доклады на которых всегда помогают понять язык лучше.
С++Russia,
C++Now,
Pacific C++,
CppCon,
code::dive,
Meeting C++.

Так же будет полезно изучить книги авторов:
Андрея Александреску,
Герба Саттера,
Девида Вандервуда,
Скотта Мейерса,
Роберта Мартина.
Есть и другие очень полезные авторы. Тут у меня, пожалуй, только самый основной список.

Последим, и самым важным, источником будет текущая рабочая версия стандарта языка, а так же пара лабораторий для практики: Compiler Explorer и C++ Insights.

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

Для того, чтобы упростить управление системой, её надо усложнить.
Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.

Нужно ли выносить в отдельный компонент это?

Да. Рекурсивный компонент. Для вложенных данных компонент создаёт экземпляры самого себя. Условие продолжения рекурсии (рендеринга конкретного экземпляра компонента) - корректность данных, надо проверять, что в компонент был передан массив ненулевой длины. Например:

name: 'v-tree',
props: [ 'items' ],

<ul v-if="Array.isArray(items) && items.length">
  <li v-for="n in items">
    {{ n.name }}
    <v-tree :items="n.children" />
  </li>
</ul>

Дело в том, что когда selected возвращает ложь, элемент удаляется из древа DOM и, следовательно, перестаёт работать jquery плагин инициализированный на нём. Чтобы это избежать, необходимо научиться понимать жизненный цикл Vue компонента. К тому же следует выделять код работающий с DOM но не являющийся неотъемлемой частью компонента в директивы. Например (для однофайловых компонентов):

<template>
  <div v-fancy-plugin="{ argumentObjectKey: 'value' }"></div>
</template>
<script>
import $ from 'jquery'
import fancyPlugin from 'fancy-plugin'

export default {
  directives: {
    fancyPlugin: {
      inserted (element, argumentObject) {
        $(element).fancyPluginInit(argumentObject)
      }
    }
}
</script>

Таким образом jquery код будет инициализирован в момент помещения элемента в DOM древо.

Смотря зачем)). Я когда делаю 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

Крупные ежегодные (некоторые еще не анонсированы на следующий раз):
www.highload.ru
ritfest.ru
whalerider.ru
https://devconf.ru/ru
2015.russianinternetforum.ru
www.spmconf.ru/ru/index
msk16.agiledays.ru
www.msdevcon.ru

Списки:
runet-id.com/events/2015/9 - не все, в основном мелкие но бывает интересные
https://events.yandex.ru/ - проводит яндекс, но иногда бывает интересно и остальным
rusbase.com/calendar

PS disclaimer: именно по дизайну я затрудняюсь назвать конференции, несколько далек от этой области. Но потоки по UX бывают регулярно.

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

В начале xml объявляются все свойства. Если у вас Привязка к элементу к другому инфоблоку вы увидите примерно такое содержимое:

<Свойство>
<Ид>246</Ид>
...
<БитриксСвязанныйИнфоблок>82b1bdcf-be01-49ca-bba8-b57a6050ed06</БитриксСвязанныйИнфоблок>
...
</Свойство>

<БитриксСвязанныйИнфоблок> - это символьный код инфоблока "Автор".
Ну и уже конкретно для элемента идет такое:
<ЗначенияСвойства>

<ЗначенияСвойства>
<Ид>246</Ид>
						<Значение>35175</Значение>
						<ЗначениеСвойства>
							<Значение>35175</Значение>
							<Описание></Описание>
						</ЗначениеСвойства>
						<Значение>35173</Значение>
						<ЗначениеСвойства>
							<Значение>35173</Значение>
							<Описание></Описание>
						</ЗначениеСвойства>
						<Значение>35178</Значение>
						<ЗначениеСвойства>
							<Значение>35178</Значение>
							<Описание></Описание>
</ЗначениеСвойства>

Где Ид это иди свойства инфоблока ссылающееся на инфоблок с авторами.
Лучше всего - создайте все нужные инфоблоки. Заполните один элемент так как он должен для вас быть на сайте. И сделайте экспорт данных в xml главного инфоблока. Вы получите такой код который нужен для программиста 1С.
И удачи вам с настройкой обмена =)

Подойдет, а лучше найдите нормальную веб студию, заключите договор и работайте по договору.