2009-05-07 3 views
6

Un progetto su cui stavo lavorando è terminato, quindi sono stato trasferito a un nuovo incarico presso il mio datore di lavoro. Il lavoro precedente era molto agile, piccolo team, progresso sulla procedura, ecc.Come gestire la gestione inetta

Quindi, in ogni caso, il nuovo progetto su cui mi trovo - mi ritrovo confuso su come gestire la gestione. Non hanno una reale comprensione della programmazione orientata agli oggetti, delle tecnologie attuali o delle metodologie. Sembrano temere il cambiamento e recentemente ci siamo trasferiti all'ultimo JRE

Facciamo queste revisioni di codice e devo ascoltare "barbe grigie" dicendo quanto è meglio in ADA o come facevano le cose in C Ma poi quando provano a revisionare il codice, non hanno nemmeno la più elementare comprensione del design e dello sviluppo di OOP. Si concentrano maggiormente sullo stile del codice; spaziatura; nomi dei metodi; ecc

Una delle persone di livello alto dire che dovremmo scrivere la nostra logger invece di utilizzare log4j a causa di una recensione negativa di log4j in un PDF accademica età scritti fa.

Come mi occupo di questo? Come posso spiegare loro che il loro design è difettoso o che sono davvero indietro nel tempo, senza imbattersi in un coglione. Sono stato con questa organizzazione da circa un anno - quindi non so quanta credibilità avrò.

+2

Capisco che la formattazione statisticamente incoerente sia correlata a un elevato numero di errori. Il che è ovvio, perché se non riesci nemmeno a formattare correttamente, allora non c'è speranza. –

+0

Questa domanda sembra essere fuori tema perché riguarda l'ambiente di lavoro. È troppo vecchio per essere migrato su [workplace.se]. –

risposta

11

Per quanto riguarda la revisione del codice, direi che li rendono felici. Nome e spazio le cose nel modo che preferiscono. Concentra il tuo tempo sul design migliore, ovviamente, e goditi il ​​ricordo dell'ADA, ma può darti un po 'di informazioni su dove sono le cose oggi e come sono arrivate.

In altre parole, non prendere la parte troppo sul serio. Preoccupati di ciò che è importante per portare a termine il lavoro. Il lavoro in questo caso sta rendendo coloro che contano di aver dato un contributo positivo al progetto.

Per quanto riguarda Log4j, vorrei solo suggerire un quadro diverso. Sia la registrazione JDK integrata (non si può lamentare di ciò, è un'API integrata) o qualcosa come SLF, che ti permette di collegare qualunque cosa tu voglia (inclusa la tua, suppongo, che puoi poi gettare via e sostituire con qualcosa di reale quando capiscono che è stato un errore, e devi solo cambiare il percorso di classe).

Ora ci saranno momenti in cui è importante. In tal caso, fai sembrare il più possibile che sia la loro idea. Ad esempio, nel logging, affermare che ci sono molti framework di logging che rappresentano molte linee di codice, e ti stavi chiedendo se ci sono altri modi per sfruttare quel lavoro per questo progetto, e poi lasciarli "capire" la soluzione.

Ci saranno momenti in cui devi spingere qualcosa come idea - non ci sarà altro modo. In tal caso, attenersi il più possibile alle prove, alleati marziali, mantenendo rapporti con coloro che hanno influenza in regola, e rendersi conto che ogni battaglia che combatti, perdi posizione, anche se vinci (forse specialmente se vinci) .

3

Consiglierei di affrontare le vostre preoccupazioni come "suggerimenti". Fai un suggerimento e chiedi la loro opinione su di esso, in questo modo si sentono come se avessero ancora il controllo anche se hai seminato il seme e stai dirigendo la conversazione.

Indipendentemente da quanto tempo sei stato con un'organizzazione, sei lì e sei lì per un motivo (ti hanno assunto per il tuo contributo). Trova la tua voce e come affrontare al meglio i membri del tuo team con suggerimenti e/o dubbi. Questa è una parte cruciale dell'essere un membro del team e aumenterà il tuo valore.

1

Ottieni un buon formattatore e crea dei nomi di metodi di cui non possono lamentarsi, quindi la tua discussione può passare a problemi reali.

Alcune persone non riescono a superare questi piccoli dettagli durante le recensioni, quindi è necessario renderlo un non-problema.

0

Non sono d'accordo con la raccomandazione di un altro framework di registrazione oltre a log4j. Citare una vecchia recensione, senza alcun tipo di esperienza personale, non dovrebbe vincere la giornata qui.

Tuttavia, potrebbe esserci un modo per renderlo vantaggioso. Se siete d'accordo e raccomandate la registrazione integrata nel logging JDK o Apache Commons, troverete che entrambi sono abbastanza simili e possono effettivamente utilizzare log4j come implementazione sottostante.

Se il tuo avversario non sta prestando molta attenzione, puoi vincere punti per arrendersi ed evitare un argomento di deposito di biciclette e ANCORA ottenere quello che vuoi.

+0

Sono certamente d'accordo che non dovrebbe (uso Log4J regolarmente, funziona bene - e comunque, tale attenzione al framework di registrazione è un po 'ridicola nella maggior parte dei casi). Ma questa non è la sua realtà. – Yishai

-9

Il mio ospite, si sbaglia. Sbagliato fin dall'inizio.

Il mio ospite di nuovo: non esitate ad ACCETTARE le reazioni!

Può darsi che tu abbia superato quel grado: principiante.

Nota: la direzione è il nostro datore di lavoro. Ci pagano finché possiamo aiutarli. Se non ti vogliono, hai torto, e hanno ragione visto che ci parlano di quei soldi. Se hai diritto solo nel tuo libro, hai un problema ...

+0

Cosa? Penso che l'inglese non sia la tua prima lingua, quindi fai attenzione alla scelta delle parole e all'ortografia, in modo che possiamo capire. – thursdaysgeek

+0

Hai ragione, sono francese e non parlo inglese. Vale a dire, il tuo commento non porta nulla alla discussione. – SRO

+0

Perché questa è la risposta accettata? Non capisco. – Parappa

1

Il tuo lavoro deve acquisire credibilità prima che ti ascolteranno. Quindi sì, fai come altri hanno raccomandato, e assicurati che le leggi sulla formattazione non importanti siano rispettate. Ma fai anche un lavoro di alta qualità che non possono ignorarti o emarginarti. Cerca di guidarli in un modo che li faccia pensare che le idee provengano da loro.

1

Rispetta i tuoi anziani! :)

Davvero, però, ricorda che molte di queste barbe grigie probabilmente stavano programmando mentre eri in pannolini. Ciò non li rende esperti delle ultime tecnologie, ma dovrebbe almeno guadagnarci il rispetto. E a volte, se riesci a trovare un modo per guardare oltre le cose di orlatura e di masticazione e "indietro ai miei tempi", puoi raccogliere alcune perle di saggezza da quei vecchi cani!

Ora dal punto di vista della programmazione, sembra che Yishai abbia ragione. Dovrebbe essere abbastanza semplice conformarsi agli stili di codifica che vogliono, e una volta che li hai resi felici, puoi eseguire il codice nel modo desiderato.

E se devi presentare un controprogetto, esegui il backup. Se vuoi usare qualcosa come log4j, parla di progetti SPECIFICI del tuo passato in cui lo hai usato e ha funzionato bene e offri di aiutare chiunque a superare i problemi che hanno con esso, ecc. Ecc.

Ricorda , mentre guardi le vecchie barbe grigie come se non sapessi come fare una nuova fantastica programmazione, probabilmente ti vedono come un giovane whipper snapper con un sacco di idee pazze per cambiare il mondo. Un'oncia di pazienza ti farà guadagnare un chilo di rispetto.

1

Io sono una vecchia barba grigia, ma ho abbandonato COBOL 35 anni fa e codice in dotNET C# e ho tenuto il passo con i giovani tennisti e cerco di mentore anche loro. Detto questo vedo molti manager e programmatori che sono ancora nell'età oscura come VB6 e non possono accettare web farm, servizi web alcune di queste barbe grigie e giovani wippersnapper non possono normalizzare una tabella di database a 3NF e tanto meno codice nTier, WCF o avere un indizio. Peggio ancora, alcuni manager hanno 30 anni di ritardo e si affidano al VB6 al massimo e un file flat che utilizza Access97.