Jaki jest profil programisty SharePoint?

Question

Mam zespół programistów specjalizujący się w ASP.NET. Rozwiązania, które oferujemy, są oparte na Internecie, działają w IIS i korzystają z serwera MS SQL. Wszystko w intranecie firmy. Zespół ma tę wiedzę i są doskonali w C# i .Net w ogóle.

Firma wdraża SharePoint MOSS 2007. Wdrożenie to jest częścią projektu, że nie jestem zaangażowany w, i dla którego mam bardzo mało informacji. Wiem jednak, że utworzyli warstwę "myślicieli" (ci, którzy powiedzą, co robić), warstwę integracji (kto skonfiguruje, wdroży i będzie zarządzać produkcją) i że będą musieli ustanowić tzw. Warstwę rozwojową (tych, którzy będą robić rzeczy, których nie potrafią dwaj inni).

Zostałem poproszony o ocenę możliwości zwiększenia wiedzy mojego zespołu poprzez dodanie rozwoju SharePoint. To jest łatwa część, po prostu muszę znaleźć wymagane szkolenie i wysłać moich ludzi.

Jednak tych dniach rozwój słowo może oznaczać wiele rzeczy i czasami odkrywam, że konfiguracja jest używany zamiast rozwoju. Nie mam żadnych obiekcji, aby rozwinąć zespół poprzez rozwijanie nowych umiejętności, ale chcę mieć pewność, że rzeczy będą stymulować moich programistów. Po drugie, nie chcę powiedzieć, że mamy specjalistyczną wiedzę programistyczną SharePoint, a właściwie to, co robimy, to modyfikowanie plików CSS lub CSS. Ponadto, nie sądzę, że używanie kreatorów do tworzenia rozwiązania jest najlepszą drogą do popchnięcia programisty C# do śledzenia.

Pytania, które zadaję sobie najpierw to: jakie jest tło programisty SharePoint? jak mogliby programiści .Net zapytać, czy zostaną deweloperami SharePoint?

Wszelkie przemyślenia zostaną docenione.

Answer 1

Zacząłem w rozwoju SharePoint ponad rok temu, kiedy odziedziczyłem rozwiązanie WSS 3.0 w mojej firmie.

Osobiście uważam, że był to dla mnie świetny krok do poznania małego rozwoju SharePoint, jest wiele problemów (np. Bezpieczeństwo, obciążenie - równowaga, efekt duchów), które dobrze sprawdziły się, gdy zespół WSS rozwiązał i pomaga mi rozwiązywać problemy w innych rozwiązaniach, nad którymi pracuję. Ale nie pracuję nad rozwiązaniami WSS w pełnym wymiarze czasu, więc inni muszą wiedzieć, jak to działa z WSS każdego dnia.

WSS i SharePoint są przedłużeniem na platformie ASP.NET, więc każde doświadczenie w ASP.NET i .NET w ogóle powinien być dobrym fundamentem dla dewelopera, który rozpoczyna tworzenie rozwiązań SharePoint. Przeczytałem książkę Inside Microsoft Windows Sharepoint Services 3.0, aby zapoznać się z podstawowymi koncepcjami i architekurą rozwiązania wss, zanim rozpocząłem pracę nad projektami WSS.

Szybko odkryłem, że musisz mieć środowisko Virtual Machine do rozwoju Sharepoint, ponieważ jest to ból działający na kliencie i dołączanie do zdalnego procesu na serwerze, aby przejść do trybu debugowania. Dlatego zalecamy utworzenie maszyny wirtualnej MOSS, która ma zainstalowane Visual Studio, które ma dostęp do Twojego systemu kontroli źródła. Rozwijaj rozwiązania na tym komputerze i po zakończeniu sprawdź w kontroli źródła.

Polecam również zapoznanie się z narzędziami programistycznymi, takimi jak stsdev i wspbuilder, które pomogą Ci zbudować rozwiązanie, ułatwi to ci proces rozwoju. Istnieje również wiele narzędzi dostępnych w Internecie, np. codeplex, aby ci pomóc.

Czasami może to być ból rozwijający te rozwiązania, zmiany mogą wymagać recyklingu puli IIS lub brutalnego zestawu IISReset, komunikaty o błędach mogą czasami być trochę tajemnicze i tak dalej. Ale szybko łapiesz i wiesz, gdzie szukać. Sharepoint również bardzo pomaga, mam już miliony pytań od klientów, które można rozwiązać za pomocą standardowych, gotowych do użycia części internetowych, dzięki czemu nie muszę kodować niczego, aby zadowolić klientów :)

Sharepoint oczekuje również, że rozwiązania będą kodowane w określony sposób, np. 12 gałęzi gałęzi, dzięki czemu pomaga standaryzować rozwiązania.

Istnieje poważny brak dokumentacji, tak że trzeba polegać na reflektor i takich narzędzi dużo, żeby wiedzieć, co dzieje się w ramach, mam nadzieję, że to staje się lepsze z 2010.

Początkowe nauki Krzywa jest wysoka, a wiele nowych koncepcji i technologii do nauki, np Przepływy pracy w ramach sharepoint, featuers, ghosting i zabezpieczenie dostępu do kodu Istnieje wiele konfiguracji Xml, których programista musi się nauczyć, takie jak definicja witryny, szablony list i wiele innych. Czasami zdarza mi się, że utknąłem w trybie edycji Xml i nie potrafię zrozumieć, dlaczego coś nie działa tak, jak powinno.

To tylko niektóre z moich myśli, pracowałem głównie w rozwoju WSS Byłoby świetnie, gdyby ktoś mógł skomentować konfigurację webpart w Sharepoint, np konfigurowanie wyszukiwania. To jest coś, czego nie robiłem dużo.

Answer 2

Z tego co słyszałem wokół SharePoint to popularna technologia z punktu widzenia klienta, ale obiektem nienawiści wśród deweloperów.

Answer 3

Miło zauważyć, że zauważyłeś, że Dev i Admin są "niewłaściwie".

Chociaż program Developing for SharePoint może być wyłącznie projektem, takim jak tworzenie stron internetowych itp., Zdecydowanie zachęcam Ciebie i Twój zespół do poradzenia sobie z wdrażaniem, instalacją i konfiguracją SharePoint. Mam pełne uprawnienia SharePoint (WSS Config/Dev i MOSS Config/Dev), a znajomość obu celów jest dla mnie bezcenna.

Znajomość skonfigurowanych warunków pomoże w debugowaniu i rozwiązywaniu problemów po drodze. Proponuję wziąć udział w szkoleniu konfiguracyjnym MCTS WSS 3.0 i/lub Szkole konfiguracji MOSS dla co najmniej 1 lub 2 zespołu. Reszta zespołu będzie podchodzić do najważniejszych rzeczy, mając na uwadze, że ci dwaj certyfikowani koledzy poszli do facetów dotyczących konfiguracji i administratora.

IMHO, jako konsultant programu sharepoint, wymaga wiedzy o tworzeniu funkcjonalności jako deweloper, a następnie jest w stanie wdrożyć, skonfigurować i utrzymywać tę funkcjonalność jako administrator (lub co najmniej poinformowany użytkownik końcowy/zasilający) .

Answer 4

Mój współpracownik uczy się SharePoint w tej chwili. Wyśmiewając się z niego przez cały czas. Często żartuje coś w stylu "wtf jest to ?? !!". A potem czuję się trochę smutny, ponieważ wiem - istnieje prawdopodobieństwo, że będę musiał się tego nauczyć (chyba nie jest łatwo zdobyć projekty w dzisiejszych czasach).

Widzę to bardziej jako konfigurację i personalizację niż tworzenie oprogramowania (coś jak polowanie na palec przez 3 dni z rzędu). Podnosisz trochę gliny za pośrednictwem tych szalonych projektantów SharePoint, a następnie bez końca dostosowujesz.

Wszystko, co już wiem, jest pod nową nazwą (tj. - spGridView) i nieoczekiwanym zachowaniem.

HTML, który jest renderowany, jest bizzare (tabele i pęczek serializowanych stanów wyświetlania wszędzie).

Ale te konfiguracyjne xml`s ...o_0
Teraz to przeszkoda, której nie mogę pokonać. Nawet ostre rzeczy SQL zaczynają być dziecinną grą.

Może się mylę, ale jak słyszałem - Microsoft opracował "kolumny przestrzenne" (pomnóżmy liczbę kolumn dla tabel ponad tysiąc) dla sql głównie z powodu Sharepoint. To mnie przeraża.

Oczywiście - moim zdaniem jest WYSOCE subiektywne i nieco obraźliwe. Ale mam nadzieję, że pomoże to lepiej zrozumieć, co myślę o odczuciu w SharePoint.

Mam nadzieję, że programiści, z którymi pracujesz, widzą to inaczej.

---

W skrócie:
Nie Nie chciałbym stać się programista sharepoint.

---

Edit:
mogę poradzić, że wstępna złożoności. Ale główny powód, dla którego nie chcę - nie sądzę, że rozwój w Sharepoint jest właściwą drogą. Mam na myśli - ostatnio ludzie dyskutują, że webformy dostarczają zbyt wiele abstrakcji. A co powiesz o Sharepoint?

Answer 5

Albert, spójrz na inny wątek pod tytułem Is a sharepoint developer technically “equipped” to do custom app dev and vise-versa. Jest tam sporo informacji na temat tego, co jest zaangażowane w przejście od czystego .NET do SharePoint.

Answer 6

dziękuję wszystkim za odpowiedzi, wszystkie są naprawdę pomocne.

z tego, co tu przeczytałem, widzę dwie rzeczy do rozważenia.

Pierwszym z nich jest kontekst wykorzystania, który moim zdaniem jest ważnym czynnikiem. W niektórych miejscach "rozwój" programu SharePoint może zająć bardzo dużo i może obejmować tworzenie naprawdę ekscytujących rzeczy, aby zaspokoić potrzeby nowych klientów. może wymagać napisania kodu i tak dalej. A w niektórych innych miejscach może to być tylko administracja i konfiguracja, w celu utrzymania już ustalonych rozwiązań.

Po drugie jest motywacja osobista. To naprawdę zależy od osoby. Niektórzy programiści .Net z dużym doświadczeniem wolą nie podążać w kierunku, w którym nie będą kodować "sposobu SharePoint", i będą lubić pisać kod w C# lub w kilku innych językach. Będą jednak inni, którzy wybiorą tę drogę i będą szczęśliwi, że będą mieli taką karierę. Będą zmotywowani, a przez to proponują naprawdę fajne rozwiązania.

Na przykład z mojej osobistej perspektywy i gdybym pozostał w rozwoju i programowaniu, nie wybrałbym rozwoju SharePoint za pomocą kreatorów wysokiego poziomu i menu, jako ścieżki postępu w mojej karierze. Mimo że ostatnio tego nie robię, nadal lubię kodować, kompilować, debugować itp., Ale to tylko ja.

Answer 7

Aby odnieść sukces jako programista SharePoint, musisz mieć wysoki próg bólu i cierpliwości Buddy.