Не ждите, пока кто-то другой найдет ваши ошибки
Я ненавижу ошибки в моем коде. Они не дают мне спать по ночам и мешают мне продолжать работу. Одни баги сталкивают меня с недостатком внимания, другие озадачивают. Некоторые доказывают, что я не все знаю. Некоторые баги откровенно раздражают. Ошибки отстой. Я знаю, что ты тоже ненавидишь ошибки в своем коде.
Есть разные виды ошибок. Иногда с вашей логикой что-то не так. В определенных случаях ваш код не работает должным образом. Эти ошибки легко обнаружить с помощью модульных тестов. Используйте свое воображение и подумайте, как люди могли бы использовать ваш код. Вы даже можете попросить друга помочь вам с этим. Вы когда-нибудь думали заказать пиво -1?
Но есть и другие виды ошибок. Иногда ваш код будет нормально работать неделю или месяц. Время от времени возникал сбой, который вы отбрасывали как не относящийся к делу. Только когда будет слишком поздно, вы заметите, что с вашим кодом что-то не так с самого начала.
Мы все были там. Вас попросили создать приложение. Возможно, это была настройка SharePoint или одностраничное приложение Angular. Вы стремились использовать новейшие функции и попробовать кое-что, что вы не использовали раньше. По пути вы столкнулись с некоторыми проблемами, но ведь это процесс обучения, верно? В итоге вы предоставили рабочее решение. По крайней мере сначала работало, потому что потом вдруг сломалось.
SharePoint — зверь. Он существует уже давно и способен на многое. Это продукт для конечного пользователя, но также и платформа для разработки. То, как вы его настраиваете, менялось с годами: от кода .NET, работающего на сервере, до JavaScript, работающего в браузере. Но создание решений SharePoint — нетривиальная задача. SharePoint развивался годами, в течение которых накопилось множество тонкостей, о которых нужно знать, чтобы избежать ошибок. Должны ли вы избавиться от Web из SPLimitedWebPartManager? Можно ли использовать декларативную подготовку? Будет ли поддерживаться ваше решение, если вы используете внутренний REST API управляемых метаданных? А как насчет остальных 900 вещей, которые могут пойти не так?
Однако это не относится к SharePoint. Чем мощнее платформа, фреймворк или библиотека, тем больше требуется знаний о том, что вы делаете. Чем дольше он существует, тем больше в нем исправлений. Иногда ваш выбор не имеет никакого значения. И иногда за это могут наказать так же жестко, как и весь сервер. Так много для производительности. У каждой технологии есть свои передовые методы, и вам лучше знать их все. Это зависит по какой-то причине.
Раньше у вас было время учиться. Каждые три года выходила новая версия SharePoint. Вы бы купили книгу, прочитали ее от корки до корки и узнали бы солидный кусок. В наше время не так уж и много. Каждую неделю Microsoft обновляет SharePoint Online, а каждые несколько недель Google выпускает новую версию AngularJS. К тому времени, когда вы узнали, что нового, уже был выпущен еще один релиз. Как только вы поняли, как использовать новейшие функции, мир изменился, и вы можете начать все сначала. О, и удачи в поисках хорошей книги.
Поэтому вы продолжаете делать все возможное, доверяя своей интуиции, надеясь, что вам не позвонят посреди ночи. Когда вы слышите о серьезной проблеме, вы молитесь, чтобы ее причиной был не ваш код. Вы никогда не можете быть уверены, не так ли?
Знание всего этого имеет свою цену. Чтобы разобраться во всех тонкостях, нужно много времени. И все тоже меняется. И даже если вы все это знали, вам все равно нужно убедиться, что все, что построили вы и ваши коллеги, вы построили правильно. Проверка кода вручную не масштабируется. К счастью, вам это не нужно. Слышали ли вы о SPCAF и его базе данных почти 1000 вещей, которые могут пойти не так в настройках SharePoint? Давай, попробуй и проверь свои решения с ним. Не ждите, пока кто-то другой найдет ваши ошибки.
