Комментарии 2
Делаем похожую вещь у себя. Вот некоторые идеи, которыми можно дополнить пост:
1. Автоматическая генерация документации на основе unit-тестов. Тесты описываются в package.json и те, что помечены как «visible», выводятся как параметры к API компонента. Это позволяет сфокусироваться в первую очередь на тестировании главного (не проваливаясь в покрытие всех возможных и невозможных сценариев), во вторую очередь обязывает к написанию теста т.к. без него не появится пункт в документации и наконец решает главную проблему с поддержкой актуальности документации. Также изолированность блоков и unit-тесты дают возможность сделать прохождение тестов гораздо быстрее и глубже. Когда ставка в тестировании делается на приёмочные тесты, скорость разработки снижается, а инфраструктура по поддержке среды тестирования усложняется.
2. Взаимодействие с аутсорсом через базу наработок. Например верстальщику необязательно давать доступ ко всему репозиторию, достаточно дать возможность скачать компонент и загрузить его обратно на этой же странице. Когда новый компонент загружается, на основе его создаётся пулл-реквест и тикет в обычном хелпдеске. Программисты пишут комментарии на гитхабе и верстальщику приходят письма на почту. Его ответы на письма и загрузка исправлений появляются в пулл-реквесте. Таким образом мы можем подключать внешние силы без открытия доступа ко всей кодовой базе и инфраструктуре, как это обычно делается при найме нового программиста.
3. Вёрстка по БЭМ-у свободна от примесей js-кода. Всё обогащение вёрстки происходит через data-bem атрибут, который содержит параметры к компонентам (json). JavaScript компонента сам гуляет по DOM-дереву. Это позволяет держать рядом с компонентом чистый html и существенно снизить стоимость доработок т.к. править вёрстку в этом случае уже может тот, кто не знает JS. Также это спасает от усложнения и запутывания кода. Чистая вёрстка дисциплинирует и заставляет разрабатывать так, чтобы это мог подключить и улучшить верстальщик или веб-мастер без знаний js-а.
4. Брэндбук, это набор пресетов (описанных параметров к API компонента). Например набор кнопок для сайта представлен в виде вызовов компонентов с передачей им параметров (цвет, размер, стиль, ...).
5. API компонента вне технологий и фреймворков (D в SOLID). Между кодовой базой и возможностями какой либо внешней библиотеки или фреймворка, находится наш API. Мы сажаем свою кодовою базу на свой API а не на конкретное решение. Например в случае устаревания Backbone.js мы попали на большой объём работы по слезанию с этой иглы. Заменить решение, которое находится за нашим API гораздо дешевле, чем цепляться к этому решению нативно (напрямую).
1. Автоматическая генерация документации на основе unit-тестов. Тесты описываются в package.json и те, что помечены как «visible», выводятся как параметры к API компонента. Это позволяет сфокусироваться в первую очередь на тестировании главного (не проваливаясь в покрытие всех возможных и невозможных сценариев), во вторую очередь обязывает к написанию теста т.к. без него не появится пункт в документации и наконец решает главную проблему с поддержкой актуальности документации. Также изолированность блоков и unit-тесты дают возможность сделать прохождение тестов гораздо быстрее и глубже. Когда ставка в тестировании делается на приёмочные тесты, скорость разработки снижается, а инфраструктура по поддержке среды тестирования усложняется.
2. Взаимодействие с аутсорсом через базу наработок. Например верстальщику необязательно давать доступ ко всему репозиторию, достаточно дать возможность скачать компонент и загрузить его обратно на этой же странице. Когда новый компонент загружается, на основе его создаётся пулл-реквест и тикет в обычном хелпдеске. Программисты пишут комментарии на гитхабе и верстальщику приходят письма на почту. Его ответы на письма и загрузка исправлений появляются в пулл-реквесте. Таким образом мы можем подключать внешние силы без открытия доступа ко всей кодовой базе и инфраструктуре, как это обычно делается при найме нового программиста.
3. Вёрстка по БЭМ-у свободна от примесей js-кода. Всё обогащение вёрстки происходит через data-bem атрибут, который содержит параметры к компонентам (json). JavaScript компонента сам гуляет по DOM-дереву. Это позволяет держать рядом с компонентом чистый html и существенно снизить стоимость доработок т.к. править вёрстку в этом случае уже может тот, кто не знает JS. Также это спасает от усложнения и запутывания кода. Чистая вёрстка дисциплинирует и заставляет разрабатывать так, чтобы это мог подключить и улучшить верстальщик или веб-мастер без знаний js-а.
4. Брэндбук, это набор пресетов (описанных параметров к API компонента). Например набор кнопок для сайта представлен в виде вызовов компонентов с передачей им параметров (цвет, размер, стиль, ...).
5. API компонента вне технологий и фреймворков (D в SOLID). Между кодовой базой и возможностями какой либо внешней библиотеки или фреймворка, находится наш API. Мы сажаем свою кодовою базу на свой API а не на конкретное решение. Например в случае устаревания Backbone.js мы попали на большой объём работы по слезанию с этой иглы. Заменить решение, которое находится за нашим API гораздо дешевле, чем цепляться к этому решению нативно (напрямую).
полезные ссылки, спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Многократное использование UI-компонентов в масштабах организации