Каков профиль разработчика SharePoint

Question

У меня есть команда разработчиков, специализирующаяся на ASP.NET. Таким образом, предлагаемые нами решения основаны на веб-технологиях, работают на IIS и используют сервер MS SQL. Все в интранете компании. У команды есть этот опыт, и они превосходны в C # и .Net в целом.

Компания развертывает SharePoint MOSS 2007. Это развертывание является частью проекта, в котором я не участвую, и о котором у меня очень мало информации. Однако я знаю, что они создали уровень «мыслителей» (тех, кто скажет, что делать), уровень интеграции (кто будет настраивать, развертывать и управлять производством), и что им нужно установить так называемый уровень разработки ( те, кто будут делать то, что двое других не могут).

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

Однако в наши дни слово развитие может означать много вещей, и иногда я обнаруживаю, что конфигурация используется вместо разработки. У меня нет никаких возражений, чтобы развить команду, развивая новые знания, но я хочу быть уверен, что у моих разработчиков будет стимул. Во-вторых, я не хочу сказать, что у нас есть опыт разработки SharePoint, и на самом деле мы просто модифицируем файлы CSS или XML. Кроме того, я не думаю, что использование мастеров для создания решения - это лучший способ подтолкнуть разработчика на C #.

Сначала я задаю себе следующие вопросы: каков опыт разработчиков SharePoint? Что могут почувствовать разработчики .Net, если их попросят стать разработчиками SharePoint?

Любые мысли будут с благодарностью.

Answer 1

Я начал разработку Sharepoint более года назад, когда унаследовал решение WSS 3.0 в своей компании.

Лично я считаю, что для меня было отличным шагом немного познакомиться с разработкой Sharepoint, есть много проблем (например, безопасность, балансировка нагрузки, ореолы), и было приятно увидеть, как была решена команда WSS и помогает мне решать проблемы в других решениях, над которыми я работаю. Но я не работаю над решениями WSS полный рабочий день, поэтому другие должны задавать вопросы о том, как он работает с WSS каждый день.

WSS и Sharepoint являются расширением на платформе ASP.NET, поэтому любой опыт работы с ASP.NET и .NET в целом должен стать хорошей основой для разработчика, который начинает создавать решения Sharepoint. Я прочитал книгу Inside Microsoft Windows Sharepoint Services 3.0 , чтобы получить базовые концепции и архитектуру wss-решений перед тем, как начать работать над проектами WSS.

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

Я также рекомендую взглянуть на инструменты разработки, такие как stsdev и wspbuilder , чтобы помочь вам в создании вашего решения, они немного облегчат процесс разработки. В Интернете также доступно довольно много инструментов, например, codeplex , чтобы помочь вам.

Иногда разработка этих решений может быть затруднена, изменения могут потребовать повторного использования пула IIS или перебора IISReset, сообщения об ошибках иногда могут быть немного загадочными и так далее. Но вы быстро понимаете и знаете, где искать. Sharepoint также очень вам помогает, у меня миллионы вопросов от клиентов, которые можно решить с помощью стандартных готовых веб-частей, так что мне не нужно ничего кодировать, чтобы мои клиенты были довольны:)

Sharepoint также ожидает, что решения будут кодироваться определенным образом, например, 12 файловой структуры улья, которая помогает стандартизировать ваши решения.

Существует серьезная нехватка документации, так что вам приходится много полагаться на Reflector и такие инструменты, просто чтобы знать, что происходит внутри фреймворка, надеюсь, это станет лучше с 2010 года.

Начальная кривая обучения высока, и есть много новых концепций и технологий для изучения, например. Рабочие процессы в рамках sharepoint, featuers, ghosting и безопасности доступа к коду Существует множество конфигураций Xml, которые использует sharepoint, которым должны научиться разработчики, в том числе определение сайта, шаблоны списков и многое другое. Иногда бывают дни, когда я застреваю в режиме редактирования Xml и не могу понять, почему все работает не так, как должно

Это лишь некоторые из моих мыслей, я работал в основном над разработкой WSS, и было бы здорово, если бы кто-то мог прокомментировать настройку веб-части в Sharepoint, например, настройка поиска. Это то, чем я много не занимался.

Answer 2

Из того, что я слышал, SharePoint - популярная технология с точки зрения клиентов, но объект ненависти среди разработчиков.

Answer 3

Приятно видеть, что вы заметили, что Dev и Admin использовались "неправильно".

Хотя разработка для SharePoint может быть просто разработкой, такой как создание веб-частей и т. Д., Я настоятельно рекомендую вам и вашей команде освоиться с развертыванием, установкой и настройкой SharePoint. Я полностью сертифицирован по SharePoint (WSS Config / Dev и MOSS Config / Dev), и знание обеих сторон было для меня бесценным.

Знание того, что настроено, где поможет в процессе отладки и устранения неполадок. Я предлагаю пройти обучение по настройке MCTS WSS 3.0 / или обучение по MOSS Config как минимум для 1 или 2 членов вашей команды. Остальная часть команды будет подбирать все необходимое по мере продвижения, имея этих двух сертифицированных коллег, которые обращаются к парням, связанным с config и admin.

ИМХО, будучи консультантом sharepoint, необходимо знать, как создать функциональность в качестве разработчика, а затем иметь возможность развертывать, настраивать и поддерживать эту функциональность в качестве администратора (или, по крайней мере, информированного конечного / опытного пользователя).

Answer 4

Альберт, взгляните на этот другой поток под названием Является ли разработчик sharepoint технически «подготовленным» для разработки пользовательских приложений и наоборот . Там довольно много информации о том, что необходимо для перехода с чистого .NET на SharePoint.

Answer 5

Мой коллега в настоящее время изучает SharePoint. Смеяться над ним все время. Часто он таращит что-то вроде "что это такое? !!" А потом мне становится немного грустно, потому что я знаю - есть вероятность, что мне тоже придется изучить этот материал (я думаю, что сейчас не так легко получить проекты).

Я вижу это скорее как настройку и настройку, чем как разработку программного обеспечения (что-то вроде поиска флажка fing в течение 3 дней подряд). Вы берете немного глины с помощью этих сумасшедших дизайнеров sharepoint, а затем бесконечно настраиваете ее.

Для всего, что я уже знаю, есть новое имя (т.е. spGridView) и неожиданное поведение под ним.

HTML, который визуализируется, является причудливым (таблицы и куча сериализованных представлений повсюду).

Но эти настройки xml`s ... o_0
Теперь это препятствие, которое я не могу преодолеть. Даже хардкорный SQL-контент начинает казаться детской игрой.

Возможно, я ошибаюсь, но, как я слышал, Microsoft разработала «пространственные столбцы» (давайте увеличим количество столбцов для таблиц более чем на тысячу) для sql, главным образом из-за Sharepoint. Это пугает меня.

Конечно - мое мнение ВЫСОКО субъективно и немного оскорбительно. Но я надеюсь, что это поможет лучше понять, что я думаю и чувствую о Sharepoint.

Надеюсь, разработчики, с которыми вы работаете, видят это иначе.

---

Короче говоря:
Я бы не хотел становиться разработчиком sharepoint.

---

Edit:
Я мог справиться с этой первоначальной сложностью. Но главная причина, по которой я не хочу - я не думаю, что разработка в Sharepoint - это правильный путь. Я имею в виду - в последнее время люди обсуждают, что веб-формы предоставляют слишком много абстракций. Тогда что сказать о Sharepoint?

Answer 6

Чтобы быть успешным разработчиком SharePoint, вы должны иметь высокий порог боли и терпения Будды.

Answer 7

спасибо всем за ответы, все они очень полезны.

Из того, что я читаю здесь, я вижу две вещи для рассмотрения.

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

Во-вторых, это личная мотивация. Это действительно зависит от человека. Некоторые разработчики .Net с хорошим опытом предпочитают не идти в направлении, где они не будут кодировать «путь SharePoint», и им нравится писать код на C # или некоторых других языках. Однако будут другие, которые выберут этот путь и будут счастливы иметь такую ​​карьеру. Они будут мотивированы и предложат действительно хорошие решения.

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