Buone pratiche che ogni avvio dovrebbe seguire [chiuso]

Naviga le tue risposte
8

Un paio di amici al lavoro e io istituiremo una piccola startup / creeremo il nostro software, probabilmente al primo posto, dal momento che non possiamo ancora permetterci di lasciare i nostri lavori giornalieri.

Nessuno di noi ha questa esperienza, prima abbiamo lavorato per altre società, dove è stata stabilita una serie di linee guida, e penso che questo sia il momento di stabilire buone pratiche da seguire (come evitare incontri-itis).

Per le persone che sono andate in questo modo, quale pezzo / i di consigli vorresti darci?

Cerco di più per il lato tecnico delle cose, cose come:

  • Vale la pena avere qualche tipo di Costruisci server o sta andando lontano avanti?

  • Faresti un TDD approfondito o no? penso che sarebbe troppo sovraccarico per una piccola squadra che non è troppo con esperienza?

Ma non mi dispiacerebbe ascoltare il lato gestionale delle cose.

Il progetto è un'applicazione web fatta in ASP.NET MVC, sto pensando di usare Mercurial e BitBucket o Kiln + FogBugz o qualche altro strumento di monitoraggio dei progetti online, visto che lavoreremo in remoto.

    
posta Francisco Noriega 04.11.2010 - 00:52
fonte

2 risposte

14

  1. Rilascia il più velocemente possibile . È probabile che il 90% del codice che inizi con non supererà i primi 6 mesi. Quindi non ha senso ingegnerizzarlo come un matto. Codice il più rapidamente possibile per arrivare al mercato, quindi lascia che i tuoi utenti decidano come svilupparlo ulteriormente. Se TDD è la modalità di codifica più rapida, usa TDD. Altrimenti, basta hackerarlo. Gli utenti early-adopter perdonano alcuni bug quando il tuo prodotto è in beta.

  2. Non perdere tempo con gli amministratori di sistema. Hai l'idea giusta con piattaforme ospitate per il bug tracking (ad esempio FogBugz) e il controllo del codice sorgente. Utilizza un repository di documenti online come Google Documenti . Se si memorizza qualcosa a livello locale, utilizzare un servizio di backup cloud online come Carbonite . Nel tuo ambiente live, affitta una soluzione di hosting completamente gestita se puoi permetterti. Cerca di evitare di dover mantenere i tuoi server.

  3. Concentrati su ciò che ti rende unico . Se ti ritrovi a scrivere codice che sembra debba essere stato fatto prima, usa quello che c'è già. Diventa esperto nel risolvere i tuoi problemi aziendali e non farti distrarre da problemi esterni al tuo dominio.

risposta data 04.11.2010 - 02:03
fonte
4

Se la squadra è più di solo te, gli standard sono importanti. Non devono essere complicati ("usa nomi di variabili significativi, CamelCase e non rompere la build"). TDD oscilla perché funziona, usalo. I test che crei sono anche una grande base per le dimostrazioni alla caduta di un cappello. Un server di compilazione può essere fuori bordo, potrebbe non farlo; iniziare senza uno e vedere come va. Strumenti di tracciamento allo stesso modo; può aggiungere in seguito, se necessario.

Supponendo che questo prodotto sia venduto, fai qualche ricerca di mercato ora , per assicurarti di costruire qualcosa che le persone effettivamente vogliono. Delinea un piano aziendale per passare dallo zero al mercato, dividere responsabilità e equità, e considerarsi reciprocamente responsabili.

Buona fortuna!

    
risposta data 04.11.2010 - 01:50
fonte

Leggi altre domande sui tag

È una cattiva pratica che i test unitari siano dipendenti l'uno dall'altro? Quali sono i buoni motivi per usare l'implementazione esplicita dell'interfaccia al solo scopo di nascondere i membri?