sompylasar

Фреймворки нужно учить после того, как будете знать и ПОНИМАТЬ этот перечень пунктов:

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

Также мы всё собираемся настроить Continuous Integration. Jenkins может прогонять по коду проверку на соблюдение стандартов и покрытие тестами, а затем показывать результаты в красивом виде. Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление.

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

Ещё пара идей.

• можно отправить разработчиков на какой-нибудь онлайн-курс по чистому коду, хотя я таких даже не знаю, но наверняка должны быть
  
• или устраивать "хакатоны чистого кода", на коих команда разбивается на пары-тройки, каждая из коих пишет какую-нибудь маленькую, но полезную, а главное чистую и оттестированную штуковину, причём тема - по собственному выбору. Потраченное время - оплачиваемое, разумеется. Это уже зависит от руководства фирмы, согласится ли оно на такие развлечения.
  

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

Ну и важно, чтобы у самих разработчиков была установка на хороший код, профессиональная гордость. У фрилансеров её, бывает, нет, а есть отношение "тяп-ляп, лишь бы работало и лишь бы часы оплатили, а там хоть потоп". Учитывая, что их заказчики занимаются code review нечасто, развитие такого отношения закономерно. Но всё-таки хочется писать красивые программы. Такое желание обязано быть.

Я, конечно, сам не волшебник, я только учусь, и работа с командой - такая штука, которой надо постоянно учиться. Видимо, вы тоже учитесь; успехов в этом.

React это не фреймворк, а лишь либа для view
1. Никто не запрещает использовать lodash\underscore для работы с данными. Для фильтрации\поиска используйте селекторы.
2. Используйте webpack для сборки проекта, в настоящее время это единственное рабочее решение, так же в webpack есть асинхронная загрузка модулей - require.ensure, так что вы спокойно можете разбивать свое приложение на чанки и подгружать их в нужный момент.
3. По-моему сейчас очень, очень много плагинов адаптированных под реакт, за не большую практику работы с этим стеком у меня ни разу не возникло необходимости писать что-то самому с 0, всегда можно найти какое-то решение, форкнуть и допилить под себя.

По поводу backbone, честно не знаю - на мой взгляд React более лаконичен и на нем можно быстрее начать писать уже готовое приложение + при правильной архитектуре проекта поддержка в будущем будет без боли.

DevOps расшифровывается как Development Operations.
В повседневные задачи DevOps инженера входит управление инфраструктурой приложений (в основном веб).
Что должен знать и уметь такой инженер - например по клику кнопкой в нужном датацентре произошел деплой приложения. DevOps должен суметь создать этот интерфейс с кнопкой и автоматизировать процесс приобретения инстанса (например в AWS), установки операционной системы и необходимых пакетов, доставки приложения на этот инстанс, прописывания всех настроек в приложении и приведение приложения в полную боевую готовность, т.е. состояние, в котором к приложению можно пускать пользователей.

По пунктам, что нужно знать и уметь:

• неистово учиться и гуглить
  
• сетевые технологии, на уровне маршрутизации, TCP/IP, DNS, SMTP и остальных протоколов начиная с 3 уровня модели OSI
  
• сетевые операционные системы (преимущественно семейства Linux) на уровне автоматизирования установки, обновления, настройки безопасности и мониторинга
  
• системы виртуализации (Xen, OpenVZ) и контейнеризации (Docker, Vagrant)
  
• настраивать сервера и мигрировать конфигурации, например перейти с Apache на Nginx, или с PHP на HHVM
  
• Chef
  
• Puppet
  
• Ansible
  
• Capistrano
  
• VCS
  
• AWS/OpWorks/CloudFormation/CodeDeploy, OpenStack
  
• Munin/Logstash/Kibana и другие связки для мониторинга
  
• Continuous delivery
  
• Программировать на Bash, Ruby, Python, Go, Perl, уметь понимать конфиги на самых экзотических языках, например YAML
  
• TDD
  
• продукты hashicorp
  
• автоматизировать создание и восстановление бэкапов баз данных
  
• масштабировать приложения по горизонтали (настраивать балансировщики, реверс-проксирование, шардинг и репликацию в базах)
  
• рассчитывать и оптимизировать издержки на поддержание инфраструктуры приложений
  
• видеть будущее инфраструктуры приложения и компании, двигать инфраструктуру в это будущее
  

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

(кратко про себя)
Все лежит в папках: компонент + стиль. Собирается webpack'ом. Но у меня react-проекты.

(длинно, но вроде бы по делу)
Если относительно долго занимаетесь - у вас скорее всего уже выработались части, которые похожи - их выносите. Так же скорее всего у вас есть одинаковая структура (обычно это js/css/images и html, либо как вы пишите компонентами (отдельными папками) внутри котороых html + стили и может js ). Делайте шаблон для будущих проектов, в первую очередь удобным для себя - ведь вам с ним работать, а в нем реализуйте то что умеете по-максимуму (жмите картинки, оптимизируйте js и т.д)

Плагины, которые используете для Gulp, просто проверьте в блэклисте, а так же можете посмотреть новые версии. Вообще, хорошо если вы знаете все свои плагины, в таком случае - вам и этот пункт можно не выполнять.

кажется, что не использовал это все на 100%

Всем так кажется, поэтому когда не хочется заниматься работой, идем в гугл и смотрим опен-сорс проекты других людей: gulp, wepback, затем если нашли что-то любопытное идем в npm/github читаем доку. Пытаемся применить в работе.

Что имеем в итоге?
1) если все работает и вас устраивает (скорость сборки, удобство проверки в разных браузерах ...) - "работу работать";
2) если есть время и желание - гуглите опен-сорс решения, читайте твиттер интересных людей / новостную подписку;
3) если хочется услышать мнение коллег, но при этом коллег рядом нет - пишите статью на хабр. Просто статья: я использую такие-то плагины в своем "шаблоне" - вряд ли получит лестные отзывы, но возможно кто-то напишет: вот в этом месте у вас плохо, сделайте иначе. Возможно, вы придумаете, как написать статью интересно - тогда честь и хвала. И критика. А обоснованная критика всегда хорошо.

P.S. если используете Jade и следуете BEM-методологии, то я бы порекомендовал посмотреть на этот проект

В PHP отсутствует Double Dispatching и перегрузка методов

Double Dispatch в PHP:

class Foo {
    // ...
    public function makeSomeStuff(Bar $bar)
    {
         $bar->doStuff($this->someData); // double dispatch!
    }
}

Перегрузка методов:

class Foo {
    public function foo() {}
}

class Bar extends Foo {
    public function foo() {} // перегружен!
}

и в ответ на отличающуюся от базового класса/интерфейса сигнатуру он вывалится с ошибкой

то что вы хотели сделать называется ad-hoc полиморфизм, и он есть из коробки в любом языке программирования с динамической типизацией. Достаточно просто не указывать явно сигнатуру, все довольно просто) Ну и да, минус этого то что это не явно и в рантайме. Для языков со статической типизацией явная "перегрузка" нужна только для того что бы компилятор мог построить таблицы диспетчеризации вызовов.

Но решить проблему как-то нужно

Перегрузка методов в наследниках с изменением сигнатуры это как раз таки нарушение принципа подстановки барбары лисков (LSP для сокращения).

> Сервисы должны имплементировать какие-то общие методы, но помимо этого у них есть и специфичные методы.

выносите "общие методы" в отдельный сервис и шарьте его как зависимость. Тогда у всех сервисов будут только специфичные методы и тогда будет достигаться принцип единой ответственности (который характеризуется как "у каждого объекта должна быть только одна причина для возможных изменений").

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

Однако каждый из хендлеров может не работать с конкретной реализацией сервиса.

Значит полиморфизм в нашем случае пошел погулять. Есть куча решений данной проблемы, в частности Chain of responsibility.

> Visitor. Предполагает наличие в каждом из хендлеров методов типа handleService1(Service1 $service) и handleService2(Service2 $service), при этом один из методов остается пустым

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

> Массив маппинга, который говорит, какой хендлер может обрабатывать какой из сервисов.

Опять же излишнее усложнение.

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

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

- Dev & Production сервера понятно. Нужно ли делать локал-сервер у разработчика? Стоит ли физически разделять дев и продакшен или достаточно разных виртуал-хостов и баз данных?

Зависит от масштаба проекта. На начальном этапе у разработчика всегда должна быть возможность проверить написанное локально -- это быстро и удобно. Как, например, в моем случае встроенный сервер Django. В будущем, когда проект становится большим -- можно прибегнуть к автоматизации этого процесса через среды сборки на тестовые стенды.

Физически (как я понял по разным железкам) разделять dev и prod имеет смысл только тогда, когда это требуется для правильного функционирования системы (т.е. prod занимает ресурсы физического сервера на 70-80%).
Когда дойдете до таких масштабов -- решение само придет. Сейчас идите по пути максимального сокращения расходов (VPS или один выделенный сервер в ДЦ).

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

А в качестве выделенного сервера хорошо подойдет https://www.soyoustart.com/ie/essential-servers/ с установленным VMware ESXi. Дальше уже крутите виртуалки какие хотите.

- Где и какие делать репозитории кода? Никаких серверов у нас в офисе не будет и собственно самого офиса тоже ;)

Путь 1: Github/Bitbucket в облаке
Путь 2: GitLab/Bitbucket Server у себя на сервере.

- Нужна ли специализированная task management (типа, Jira)? Сейчас используем для управления задачами WorkSection. Стоит ли для разработки использовать что-то отдельное специализированное? Я так понимаю, что та же Jira может отслеживать коммиты в git как процесс выполнения задач - это было бы круто!

Нужна! И это должно быть с нулевого дня начала вашей работы. Иначе, когда зашьетесь в тоннах переписок в месенджерах и Google Docs'ах, будете вспоминать тот день, когда было лень потратить время на организацию работы.

- нужен ли отдельный баг-трекер? Выделенных тестировщиков пока не предвидится.

Для кого? Для пользователей вашим софтом? См. ответ выше.

- Стоит ли использовать Scrum? Или просто тупо идти по задачам?

Тупо идти по задачам никогда не получится. Нет такой самоорганизации у людей. Получите гораздо больше головной боли в решении косяков других людей в своей роли ПМ. Изучите методологии. Мы используем Scrum + TDD.

- Нужна ли какая то вики для отдела разработки? Что туда записывать, чтобы это не было большим оверхедом для разрабов и имело реальную пользу.

Нужна! Вот прям как трекер задач. И привычка туда записывать все по проекту тоже нужна. Разрабатываете API -- супер! Сначала опишите его в Вики, потом начинайте кодить. И все в таком духе. Все полезные ссылки по проекту, доступы к стендам и пр. -- все надо хранить не в переписке или облаках, а и именно в единой отправной точке.

Еще удобно использовать тот же Confluence для проведения встреч. Там есть готовые шаблоны для этого. Позволяет легко фиксировать все вопросы и принятые решения.

- Что еще забыл?

Способы ведения проекта в Git забыли, такие как GitFlow.
Контейнеризация от Docker для упрощения/ускорения работы разработчиков/тестеров/админов.

PS. Еще один вопрос не могу понять: должны ли запросы на доработки софта идущие от других отделов проходить через меня как управляющего разработкой (я оцениваю целесообразность и ставлю задачу разрабам)

Должны.

или лучше чтобы они напрямую контачили с разработчиками?

Напрямую с разрабом -- только для обсуждения уже поставленной в план задачи, а для постановки задачи -- с ПМ и всей командой (если Scrum)

Не будет ли это с моей стороны лишней тратой времени?

Это -- ваша непосредственная работа.

Жесть. Посмотрел гифку на Гитхабе, там, где весь процесс наглядно показан, код даже не смотрел.

Ну вот смотрите, ясно же, что информация о маршрутах, вот все эти текстики, типа, «Из Стокгольма на пароме до Риги, каюта 6a…», это всё должно генерироваться из данных, а не ручками в textarea писать :)

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

Из {откуда} на {транспорт} до {докуда}, {тип_места: каюта, сиденье, место и т.п. в зависимости от типа транспорта} {номер_места} и прочие данные… — и еще для всего этого нужна локализация (не только же на русском тексты будут), и еще всё это нужно просклонять, если уж вообще перфекционистски делать — согласитесь, «Из Стокгольм до Рига…» звучит ужасно.

А у вас просто всё это пишется в текстовом поле — тогда уж вообще нужно одно текстовое поле вместо всей вашей формы и кнопочек, и там оператор напишет кучу текста сам, с кучей ошибок, несистемно :)

Вот сейчас возьмите всё, что вы сделали, и представьте, что номер рейса изменился, или номер сиденья изменился (вас поменяли с кем-то, и у вас изменилось место и у другого человека) — как вы это обрабатывать будете? Заходить в каждый маршрут и ручками править текст в textarea?

А насчет данных и сортировки, элементарно — данные самые обычные, обычный жисончик, массив из объектов. Сортировка по левому и правому ключу, nested sets, чтобы можно было создавать маршруты любой глубины, например, не просто Рига → Стокгольм, а между ними маршруты по Риге и маршруты по Стокгольму... ну, как дерево, можно раскрыть один маршрут, а там подмаршруты.

Ну давайте я покритикую:

возьмем файлик

1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

class Travelsort {
    constructor() {}
    sortTickets(tickets) {}
}

2) вы не умеете пользоваться исключениями.

if (!Array.isArray(cards)) {
    throw new ValueError('Wrong input');
}

3) использование let там где должен использоваться const

4) в принципе использование переменных там где их быть не должно

5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

Далее... берем следующий файлик

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

2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

3) очень много дублирования.

4) очень плохо с protected variations.

Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.

Посмотрите динамические роутеры: https://github.com/rackt/react-router/blob/latest/...
И динамическую загрузку в webpack https://webpack.github.io/docs/code-splitting.html