Come gestire la mentalità ad hoc?

Question

Come gestire la mentalità ad hoc?

#1 da (10 voti)
#2 da (1 voti)

12

Sono entrato in un team di sviluppo di sei due mesi fa. Le persone sono belle, tutto è buono. Ma sempre più osservo una mentalità ad hoc. Le cose si risolvono rapidamente, a scapito dell'utilizzabilità futura, ci sono pochi test e due persone ammettono felicemente, che a loro piace portare le conoscenze in testa, piuttosto che scriverle.

Come affrontare questo? Mi piacerebbe dare l'esempio, ma il tempo è limitato - mi piace che architetti e implementino effettivamente le cose. Ma temo che la mentalità ad hoc mi infetti e piuttosto che cercare chiarezza e semplicità nel design e nel codice - che non è semplice da stabilire - vengo trascinato in una spirale infinita di hack sugli hack - che no l'estraneo può sganciarsi - solo per scopi di programmazione e gestione.

management coding-style architecture technical-debt

posta Rotian 06.06.2012 - 21:02

fonte

2 risposte

Leggi altre domande sui tag management coding-style architecture technical-debt

Quanto è stato progettato prima? [duplicare] Posso usare la struttura del database di un progetto open source?

score 10 · Answer 1

Conosci già parte della risposta: devi dare l'esempio. Devi anche sentirti a tuo agio con il fatto che la tua "leadership" potrebbe essere ignorata, che i tuoi colleghi continueranno a fare le cose come sempre hanno fatto loro - sia perché rende felice il capo o perché essi stessi valutano convenientemente manutenzione a lungo termine.

Alla fine, devi lasciare che i tuoi risultati parlino da soli. Ti sei perso una scadenza di tre giorni ma hai risparmiato al team addetto al QA almeno tanti giorni di test programmati perché hai testato il tuo sviluppo e funziona in gran parte come progettato? Questa è una vittoria.

Alla fine, comunque, se non hai almeno un certo grado di management buy-in per quel tipo di trade-off, sei semplicemente nell'ambiente sbagliato, e devi trovare uno più favorevole al bene pratiche. Le cattive abitudini sono abitudine, quindi prima puoi trovare un modo per difendere la tua posizione o passare a un ambiente di lavoro con pratiche migliori, meglio è.

score 1 · Answer 2

Niente?

Voglio dire, esistono vincoli di tempo di lavoro. Il tuo potrebbe essere uno scenario in cui il time to market è più prezioso della futura facilità d'uso.

Se sei un programmatore di file e di file, quindi definire gli standard e preoccuparti dell'architettura del prodotto non è esattamente il tuo lavoro (in particolare 2 mesi). dovresti cercare di migliorare il prodotto come puoi (compreso il cambio di cultura), ma non a costo di alienare la tua squadra e / o il tuo capo. Essere il nuovo ragazzo che pensa di conoscere meglio è un modo semplice e veloce per farlo.

Vorrei chiederti perché stai facendo tutte queste correzioni rapide? È dovuto a precedenti soluzioni rapide? E 'abbastanza facile quindi precisare che se le cose fossero state "giuste" in primo luogo ...

Alla fine, le cattive pratiche di programmazione portano a dolore concreto. Se le persone pensano che non lo faranno, tutto ciò che devi fare è aspettare.