Metodi per gestire / documentare i report "una tantum"

Onestamente, sembra che tu sia sulla strada giusta con quello che stai facendo.

Cose che farei per "portarlo al livello successivo":

• implementa un sistema di controllo del codice sorgente leggero (svn, git, Hg ecc ...) in cui mantieni tali cartelle. Ciò renderà anche più facile vedere cosa è cambiato nel tempo.
• ha una cartella documenti relativa per la documentazione di terze parti, se presente.
• crea un set di documentazione standard da applicare ai mini-progetti. Un documento di tipo README o START_HERE è sempre un buon primo passo. Ciò consente alla povera anima che viene dopo di sapere dove iniziare a cercare informazioni.
• avere un documento standard che dice come eseguire XYZ per generare il rapporto.
• identifica le cose che desideri siano state lasciate indietro e assicurati che i mini-progetti abbiano quell'aspetto disponibile.

Hai bisogno di una risposta alla domanda, "Ricorda quel rapporto che mi hai fatto l'anno scorso?"

In primo luogo, prenditi cura del servizio di pulizia ed essere in grado di monitorare:

• Chi ha effettuato la richiesta?
• Quando è stata effettuata la richiesta e la soluzione è stata fornita?
• Come è stato fatto? codice, script e qualsiasi altra documentazione.

In secondo luogo, formalizza il processo di richiesta. So che è più facile a dirsi che a farsi. Cerca almeno di evitare la richiesta "Drive By". Qui è dove qualcuno letteralmente supera la tua scrivania o ti ferma nel corridoio / macchina per il caffè e chiede un rapporto. Usa il tuo capo o la paura di dimenticare come scusa, quindi invieranno un'email.

Terzo, controllo del codice sorgente. Non lasciarti ingannare da queste piccole richieste una tantum. Possono avere ancora più richieste di modifica rispetto a un'applicazione di produzione. "Puoi rimettere quella colonna che ti ho fatto escludere ed escludere la Filiale di Honolulu solo per il quarto trimestre?"

Ci sono molti strumenti là fuori per gestire alcune di queste cose. Ho sempre preso l'abitudine di creare un nuovo database con ogni nuovo lavoro che ricevo e buttare il più possibile. Non solo la segnalazione, ma la nuova persona potrebbe voler sapere per cosa è usato quel database AccountingMonth7?

Un anno o due fa stavo testando un cambiamento che avevo fatto e mi sono infastidito dal dover fare un calcolo manualmente più e più volte. Volevo scrivere un'utilità grafica per fare questo calcolo per me. Dal momento che scrivo software incorporato, non avevo alcun ambiente di programmazione già impostato per la programmazione della GUI, quindi per nessun altro motivo di quanto fosse prontamente disponibile, l'ho implementato in JavaScript in un singolo file HTML.

Quando ho terminato la funzione e l'ho sottoposta a test, il tester mi ha chiesto come eseguire questo calcolo. Era più difficile da spiegare che dargli solo l'utilità, quindi è quello che ho fatto, dopo aver aggiunto un po 'di lucido. L'ha messo su un web server interno che i tester usano e ho subito dimenticato tutto. Un paio di settimane fa qualcuno in un reparto completamente diverso mi ha inviato una patch per quell'utilità. Si era diffuso con il passaparola e non avevo idea che nessun altro lo stesse usando.

Ti racconto questa storia per illustrare come mettere su un server web ha reso banale la condivisione e il riutilizzo di uno script "una tantum", anche se all'inizio non era questo l'intento. La mia raccomandazione è di dedicare un po 'più di tempo a rendere i report in grado di essere eseguiti da una pagina Web e di metterli su un server Web interno da qualche parte.

Il controllo del codice sorgente è ovvio. Ti suggerirei git, o forse hai un server VSS o TFS da qualche parte sulla tua rete visto che sei un negozio di MS.

Un'altra opzione è la creazione di una wiki nella tua rete - abbastanza facile da aggiornare e non può battere la facilità d'uso. Questo ti farà guadagnare dei punti per i brownie con i boss per l'iniziativa:)