2009-10-11 3 views
6

Ho un team di sviluppo specializzato in ASP.NET. Quindi le soluzioni che forniamo sono basate sul web, in esecuzione su IIS e utilizzando MS SQL Server. Tutto all'interno della intranet dell'azienda. Il team ha questa competenza e sono eccellenti in C# e .Net in generale.Qual è il profilo di uno sviluppatore di SharePoint

La società sta implementando SharePoint MOSS 2007. Questa implementazione fa parte di un progetto per il quale non sono coinvolto e per il quale sono disponibili pochissime informazioni. Tuttavia so che hanno stabilito il livello "pensatori" (quelli che diranno cosa fare), il livello delle integrazioni (chi configurerà, distribuirà e gestirà la produzione) e che dovranno stabilire il cosiddetto livello di sviluppo (quelli che faranno cose che gli altri due non possono fare).

Mi viene chiesto di valutare la possibilità di aumentare l'esperienza del mio team aggiungendo lo sviluppo di SharePoint. Questa è la parte facile, devo solo trovare la formazione richiesta e inviare la mia gente.

Tuttavia in questi giorni lo sviluppo di parole potrebbe significare un sacco di cose e talvolta scopro che la configurazione è utilizzata al posto dello sviluppo. Non ho obiezioni per far evolvere il team sviluppando nuove competenze, ma voglio essere sicuro di mantenere le cose stimolanti per i miei sviluppatori. In secondo luogo, non voglio dire che abbiamo esperienza nello sviluppo di SharePoint, e in realtà ciò che facciamo è solo la modifica di file css o xml. Inoltre, non penso che usare le procedure guidate per produrre una soluzione sia il modo migliore per seguire uno sviluppatore C#.

Le domande che mi pongo prima sono: qual è lo sfondo di uno sviluppatore di SharePoint? come potrebbero sentirsi gli sviluppatori .Net se gli viene chiesto di diventare sviluppatori di SharePoint?

Ogni pensiero sarà molto apprezzato.

risposta

16

Ho iniziato nello sviluppo di Sharepoint più di un anno fa, quando ho ereditato una soluzione WSS 3.0 presso la mia azienda.

Personalmente penso che sia stato un grande passo per farmi conoscere lo sviluppo di Sharepoint un po ', ci sono molti problemi (ad esempio sicurezza, carico-bilanciamento, ghosting) che è stato bello vedere come è stato risolto dal team WSS e mi aiuta a risolvere i problemi in altre soluzioni su cui sto lavorando. Ma non lavoro su soluzioni WSS a tempo pieno, quindi altri devono sapere come funziona ogni giorno con WSS.

WSS e Sharepoint sono un'estensione della piattaforma ASP.NET, quindi qualsiasi esperienza in ASP.NET e .NET in generale dovrebbe essere una buona base per uno sviluppatore che sta iniziando a creare soluzioni Sharepoint. Ho letto il libro Inside Microsoft Windows Sharepoint Services 3.0 per ottenere i concetti di base e l'architettura della soluzione wss prima di iniziare a lavorare sui progetti WSS.

Ho scoperto rapidamente che è necessario disporre di un ambiente di macchina virtuale per lo sviluppo di Sharepoint, questo è perché è un problema lavorare su un client e collegarsi a un processo remoto sul server per entrare in modalità di debug. Pertanto, ti consiglio di creare una macchina virtuale MOSS con Visual Studio installato che abbia accesso al tuo sistema di controllo del codice sorgente. Sviluppa soluzioni su quella macchina e al termine, controlla nel controllo del codice sorgente.

Mi raccomando anche di guardare gli strumenti di sviluppo, come ad esempio stsdev e wspbuilder per aiutarti a costruire la tua soluzione, questo ti semplificherà un po 'il processo di sviluppo. Ci sono anche molti strumenti disponibili sul web, ad es. codeplex per aiutarti.

A volte può essere un problema sviluppare queste soluzioni, le modifiche possono richiedere il riciclo del pool IIS o un IISReset a forza bruta, i messaggi di errore a volte possono essere un po 'criptici e così via. Ma ti capita subito e sai dove guardare. Sharepoint ti aiuta molto, ho avuto milioni di domande da parte dei clienti che possono essere risolte con le parti web standard pronte, in modo da non dover codificare nulla per mantenere i miei clienti felici :)

Sharepoint prevede inoltre che le soluzioni vengano codificate in determinati modi, ad es. 12 strutture di alveare per aiutarti a standardizzare le tue soluzioni.

v'è una grave mancanza di documentazione, in modo da avere a fare affidamento su riflettore e questi strumenti molto, solo per sapere cosa sta succedendo nel quadro, speriamo che questo migliora con il 2010.

L'apprendimento iniziale la curva è alta e molti nuovi concetti sono tecnologie da apprendere, ad es Flussi di lavoro all'interno di sharepoint, featuers, ghosting e sicurezza dell'accesso al codice C'è molta configurazione Xml che sharepoint utilizza che gli sviluppatori devono imparare, inclusi la definizione del sito, i modelli di elenco e altro. Ci sono a volte giorni in cui sono bloccato in modalità di modifica Xml e non riesco a capire perché le cose non funzionano come dovrebbero

Questi sono solo alcuni dei miei pensieri, ho lavorato principalmente nello sviluppo WSS e sarebbe bello se qualcuno potesse commentare la configurazione della web part in SharePoint, ad es configurazione della ricerca. Che è qualcosa che non ho fatto molto.

+0

+1: sorprendente risposta, ty –

+0

Ottime informazioni lì. Ora, presumo che ci siano diversi sviluppatori che fanno un mix di applicazioni sharepoint (principalmente web part) e asp "tradizionali".sviluppo web in rete, per lo sviluppo di sharepoint ogni sviluppatore avrebbe il proprio server virtuale - Windows 2003 o 2008 - sulla propria workstation (stiamo lavorando con XP professional, passando presto a Windows 7). Quindi vengono caricati MOSS e VS 2008 (con eventuali estensioni necessarie). Sviluppare e testare sul server virtuale, quindi distribuirlo sul server sharepoint di produzione indipendente? –

+1

@Ken Sì, ogni sviluppatore ha il proprio ambiente di macchina virtuale che controlla il controllo del codice sorgente ogni volta che apporta le modifiche. Il risultato finale dovrebbe essere una funzionalità con un file di installazione che esegue i comandi di stsadm. Da lì abbiamo una macchina virtuale di test separata in cui i comandi vengono eseguiti e le soluzioni testate prima di essere consegnate al client – armannvg

6

Da quello che ho sentito in giro, SharePoint è una tecnologia popolare dal punto di vista del cliente, ma un oggetto di odio tra gli sviluppatori.

+0

Sono stato a classi di sviluppo sharepoint, e lo sviluppo sulla piattaforma è opaco, per non dire altro. Ma hai ragione, è un eccellente strumento pronto all'uso. –

5

È bello vedere che Dev e Admin vengono utilizzati "in modo errato".

Sebbene lo sviluppo di SharePoint possa essere puramente questo, sviluppo, come la creazione di componenti Web ecc., Incoraggio fortemente te e il tuo team a fare i conti con la distribuzione, l'installazione e la configurazione di SharePoint. Sono pienamente certificato SharePoint (WSS Config/Dev e MOSS Config/Dev) e la conoscenza di entrambi i fini è stata preziosa per me.

Conoscere cosa è configurato dove sarà utile nel debug e nella risoluzione dei problemi lungo la strada. Suggerisco di seguire un addestramento di configurazione MCTS WSS 3.0/o un addestramento MOSS Config per almeno 1 o 2 della tua squadra. Il resto del team raccoglierà gli elementi essenziali mentre procedono, con quei 2 colleghi certificati che vanno ai ragazzi riguardo a config e admin.

IMHO, essendo un consulente di sharepoint implica saper creare una funzionalità come dev e quindi essere in grado di distribuire, configurare e mantenere tale funzionalità come amministratore (o almeno un utente finale/esperto informato) .

+1

+1 La distribuzione è sicuramente la parte più difficile del sharepoint –

2

Il mio collega studia SharePoint al momento. Prendendolo in giro tutto il tempo. Frequentemente parla come "wtf is that ?? !!". E poi mi sento un po 'triste, perché lo so - c'è una probabilità che dovrò imparare anche quella roba (credo che non sia così facile ottenere progetti al giorno d'oggi).

Lo vedo più come configurazione e personalizzazione rispetto allo sviluppo del software (qualcosa come la ricerca della casella di controllo fing per 3 giorni di seguito). Raccogli un po 'di argilla attraverso quei pazzi designer di sharepoint e poi personalizzali all'infinito.

Per tutto quello che so già - c'è un nuovo nome (ad es. - spGridView) e un comportamento inaspettato sotto.

L'html che viene reso è bizzare (tabelle e un mucchio di viewstate serializzati ovunque).

Ma quelle configurazioni xml`s ...o_0
Questo è un ostacolo che non riesco a superare. Anche la roba SQL hardcore inizia a sembrare un gioco infantile.

Forse ho torto, ma come ho sentito - Microsoft ha sviluppato 'colonne spaziali' (espandiamo il conteggio delle colonne per tabelle su migliaia di punti) per sql principalmente a causa di Sharepoint. Questo mi terrorizza.

Naturalmente, la mia opinione è ALTAMENTE soggettiva e un po 'offensiva. Ma spero che questo aiuti a rivelare meglio ciò che penso sia la sensazione & di Sharepoint.

Speriamo che gli sviluppatori con cui stai lavorando vedano questo diverso.


In breve:
No. Non vorrei diventare uno sviluppatore di SharePoint.


Edit:
ho potuto gestire questa complessità iniziale. Ma la ragione principale per cui non voglio - non penso che lo sviluppo di Sharepoint sia la strada giusta da percorrere. Voglio dire - ultimamente le persone discutono che le webforms forniscono troppa astrazione. Quindi cosa dire di Sharepoint?

+0

Sembra che tu stia descrivendo la stessa (mancanza di) disparità tra "configurazione" e "sviluppo" in SharePoint. Nel caso dei progettisti, spesso sono lo strumento sbagliato per il lavoro, proprio come può essere la soluzione rolling-your-own del codice; il vero problema è che Microsoft rende difficile discernere il modo migliore per fare un sacco di cose nella piattaforma, e la maggior parte delle cose può essere raggiunta da entrambi i lati della medaglia. La versione 2010 sta cercando di indirizzare molti di questi problemi per gli sviluppatori, ma resta da vedere quale sia l'adozione. –

+0

Sto misurando internamente Sharepoint con Asp.Net Mvc. Preferisco scrivere i calcoli di impaginazione più che "personalizzare qualcosa" finché non si adatta alle mie esigenze. Sembra un gran casino. Troppe caselle di controllo e xml. Non mi sono mai piaciuti. –

0

grazie a tutti per le risposte, sono tutti molto utili.

da quello che ho letto qui, vedo due cose da considerare.

Il primo è il contesto di utilizzo che ritengo sia un fattore importante. In alcuni punti lo "sviluppo" di SharePoint potrebbe andare molto lontano e potrebbe comportare lo sviluppo di cose davvero eccitanti, al fine di soddisfare le esigenze dei nuovi clienti. potrebbe comportare la scrittura di codice e così via. E in altri posti potrebbe essere solo amministrazione e configurazione, al fine di mantenere soluzioni già consolidate.

In secondo luogo è la motivazione personale. Dipende molto dalla persona. Alcuni sviluppatori .Net con una buona esperienza preferiranno non andare in una direzione, dove non codificheranno il "modo SharePoint" e vorranno scrivere codice in C# o in altre lingue. Tuttavia ci saranno altri che sceglieranno questa strada e saranno felici di avere tali carriere. Saranno motivati ​​e quindi proporranno soluzioni davvero carine.

Ad esempio, dal mio punto di vista personale e se fossi rimasto nello sviluppo e nella programmazione, non sceglierei lo sviluppo di SharePoint utilizzando procedure guidate e menu di alto livello, come percorso di avanzamento per la mia carriera. Anche se non lo faccio in questi giorni, mi piace ancora scrivere codice, compilare, eseguire il debug ecc, ma questo è solo io.

1

Per essere uno sviluppatore di SharePoint di successo è necessario disporre di una soglia elevata per il dolore e la pazienza di un Buddha.