Современные инструменты разработки на SharePoint

Предисловие

В последнее время в среде разработчиков SharePoint наблюдается тренд перехода с классических сред и инструментов к более быстрым, универсальным и, зачастую, кроссплатформенным инструментам. Вспомнить даже последние технические видео от Майкрософт и сообщества, зачастую, на удивление, в качество операционной системы можно увидеть OS X.

Вскоре, возможно, что Вы поймаете себя на мысли, что для большинства задач разработки нет необходимости использовать устаревший SharePoint Designer или Visual Studio. Конечно, всегда будут задачи, где без Visual Studio и C# не обойтись, особенно в части провизии артефактов SharePoint (например, в этой задаче нет конкурентов у SPMeta2) и ряда других задач серверной разработки.

Но, лично в моих задачах клиентской разработки я уже начинаю забывать, когда реально нужно было открывать SPD или VS. При этом мне приходится писать порядочное количество кода для SharePoint. Я предпочитаю максимально автоматизировать и оптимизировать данный процесс. Идеальный сценарий – это когда после нажатия на «Сохранить» в среде разработки изменения моментально отображались на рабочем стенде SharePoint, желательно, чтобы процесс сопутствовался статическому анализу и преобразованию кода и, конечно же, чтобы эталонным источником версий был репозиторий Git.

Да, я говорю в первую очередь о разработке front-end составляющей. Но не обязательно только front-end, в моей статистике 20-30% кода все же должно выполняться не сервере. Правда, в моем случае серверный код является клиентским кодом по отношению к SharePoint. Так почему же не попробовать использовать одни и те же инструменты и технологии, когда это обосновано? К счастью для этого есть все предпосылки.

Итак, перейдем к предметной области.

Стек технологий и инструментов

Языки разработки

Большинство уже догадалось, без JavaScript тут не обойдется. При этом я не хочу ограничивать себя ES5. Иногда обосновано уже писать на ES2015 с использованием Babel или на TypeScript, последний отлично помогает уменьшить количество потенциальных ошибок и в целом улучшить кодовую базу.

Хотелось вынести за рамки статьи JavaScript фреймворки. Одной фразой, да, фреймворки надо использовать, особенно те, с которыми одну и ту же задачу Вы можете сделать быстрее и качественнее.

Еще хотелось бы отметить присутствие на проектах значительной составляющей CSS, иногда без использования специализированных метаязыков может быть тяжко, я предпочитаю Sass в совокупности синтаксиса Scss.

Система контроля версий

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

Редакторы кода

В части редакторов кода порой можно применить фразу «на вкус и цвет…». Однако, смею порекомендовать присмотреться к Visual Studio Code (кратко, VSC). Редактор очень быстрый, имеет встроенную интеграцию с Git, замечательный дебагер (для серверного JS) и огромное число расширений. Так же, как альтернатива, можно взглянуть на Atom. VSC лично я использую уже более года, являюсь свидетелем как проект развивался и обрастал функциональностью. Вот честно, с каждым релизом появляется что-нибудь, да полезное.

Статический анализ кода

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

Я уже не могу представить процесс написания кода без подключенного ESLint в случае JavaScript или TSLint для TypeScript. Даже если Вы компилируете JS у себя в голове, «линтеры» не будут лишними и устранят множество потенциальных проблем. 

Автоматизация задач

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

Кто-то уже использует аналоги, такие как, Webpack (не совсем аналог, но часть задач пересекается) или Grunt. Данные инструменты так же хороши. Мой же выбор пал на Gulp по причине того, что в нем используется управляемый код, а не конфигурационные настройки, а так же для Gulp существует масса модулей, упрощающих жизнь в связке с SharePoint.

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

Тестирование

Я не суперспециалист в автоматизированном тестировании, но понимание в необходимости последнего сформировалось уже давно, особенно это актуально на проектах с длительным жизненным циклом. В связке проектов клиентской составляющей SharePoint мой выбор пал на Mocha для юнит тестирования логики кода и Nightwatch для тестирования UI. Nightwatch использует драйвера Selenium, автоматизируя действия пользователя в браузере, при этом логика тестов пишется на JavaScript. Автоматизированное тестирование – это отдельная тематика, но в идеале, касательно инструментов, оно должно быть встроено в процесс сборки.

Пакетные менеджеры

NPM для Node.js и Bower для браузерных библиотек. Даже и не предположу, что еще добавить, с пакетными менеджерами все просто и понятно. И их надо непременно использовать! Зачем тратить время на вход на сайт библиотеки, поиска пункта «скачать» и копирование в проект? Если можно выполнить одну строку в консоли и добиться того же. Не, даже большего, пакетные менеджеры чудесно управляются с версионностью зависимостей. 

При этом у Вас может быть свой собственные репозиторий библиотек, написанных в компании и не доступным глобально. При этом разработчики могут подключать такие библиотеки из частного репозитория с помощью `git+[ссылка_на_git_репозиторий]#version`.

Node.js

О, Node.js, он потрясающий! Node лежит в основе задач автоматизации, пакетных менеджеров, большинства плагинов VSC и он открывает глаза на тот факт, что JavaScript – это не только то, что выполняется в контексте браузера, но и на сервере в процессе V8 или даже в виде десктопного приложения. Например, Visual Studio Code полностью написан JS.

Заключение

Вот мы и подошли к завершению.

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

В мире разработке SharePoint так же можно использовать современные инструменты и подходы, которые используются в современном мире JavaScript разработки. А сам SharePoint очень близок к тому, чтобы «назвать» JS технологией номер один для кастомизации решений. И мы являемся частью этого.

Одна из формул «счастливой» разработки для SharePoint: 
Git <---> VSC + Node.js + Gulp --> SharePoint