Penso che sia OK per uno sviluppatore senior suggerire quale sarebbe il posto migliore per le modifiche, se conoscono il codice abbastanza bene da farlo, e lo sviluppatore più giovane non conosce il codice bene.

Se si tratta di un cambiamento molto complesso che deve essere applicato in molte parti del sistema, tentare di micromannare tutti di esso renderà probabilmente tutti infelici. In tal caso, dovrebbero fornire una guida più generale e consentire allo sviluppatore junior di apprendere autonomamente.

Non aver mai paura di chiedere chiarimenti su qualcosa. CYA, sempre. Se è un lavoro troppo grande da comprendere, è probabile che non lo si debba fare. Chiedi allo sviluppatore principale "Capisco cosa devo fare, ma poiché non ho bisogno di lavorare sull'architettura, non so dove devo fare Per sicurezza, puoi aiutarmi a indicarmi almeno l'area in generale? "

Penso che dipenda dal livello di abilità degli sviluppatori. Fidati di me, di solito non è facile neanche per gli sviluppatori senior. Lo prendo come un complimento che si fida di te per determinare come vanno le cose. Assicurati solo di eseguire il tuo progetto passato a qualcun altro prima di eseguire il lavoro.

Come nota, non dovresti fidarti ciecamente di quello che ti dice il senior. Fai la tua analisi e se ciò che ti dice non ha senso, respingi e fai domande.

Quando ero un lead degli sviluppatori l'ultima volta (pieno di juniores, la maggior parte di loro erano studenti dell'anno scorso su CS MSc), ho avuto un terzo approccio:

1. Dai la storia allo sviluppatore junior
2. Digli di tornare con un piano su come sarebbe risolto
3. Dopo aver esaminato il piano, ma solo dopo, inizia a modificare i file.

Non dico che abbia funzionato abbastanza bene.

Per compiti semplici, come, aggiungere una nuova colonna a una tabella di report, hanno fatto un gran casino, modificando tutti i file, poi hanno detto "è già fatto", quindi lo abbiamo revisionato, è risultato che non è così avrebbe dovuto essere eseguito, dovevano ripristinare quasi tutto ( 1 ) e quindi ricominciare.

Sulle grandi attività (5+ classi coinvolte), era dall'altra parte: erano semplicemente in silenzio per un giorno o due, quindi dovevamo esaminarlo insieme, e in pratica ho disegnato un disegno che dovevano strumento.

Sebbene fossi lì e per ogni singola decisione l'ho spiegato a tutti, e avevano già le letture richieste, ed era più simile a una dimostrazione ( 2 ), alla fine del giorno, dovevano ancora implementare il mio design principalmente, e non ne erano così contenti come quando sono lasciati liberi.

So che è difficile differenziare la pianificazione dal fare, ma suppongo che si chiami ingegneria del software perché ci sono ancora poche persone che sanno cosa fanno, al contrario degli artigiani. Il mio compito come allenatore non era quello di creare un altro programmatore medio, ma qualcuno che eccelle nella sua professione. Fortunatamente, oggi, tutti questi sono team leader (o erano, ma si sono uniti a una società diversa, più "agile" senza alcuna leadership)

Quindi, tutto sommato, non so cosa sia meglio, so solo che la qualità del codice è più importante della praticità di un minore: sono lì per imparare, per non lasciare che alcun tipo di codice venga imputato a prod. ..

(1) ( "Perché? Funziona, no?" "Sì, ma stai interrogando il database dal livello vista o tale" )

(2) ( "vedi? abbiamo bisogno di questo, e di solito usiamo questo modello per questo come hai visto in questo altro modulo simile, qui, la nostra linea guida di codifica (che era lunga 2 pagine) dice, fai questo, quindi, facciamolo, e quindi, disegniamo un diagramma di sequenza su come funzionerebbe ... ok, ora disegnamo un diagramma di classe su di esso ")

Nessuno di essi

Idealmente, dovrebbe esserci un incontro di progettazione dei dettagli tecnici che è stato pianificato di implementare in un ambiente di squadra. Questo è il right place and time per identificare la maggior parte delle domande.

Un altro punto è - Comunicare chiaramente ciò che lo sviluppatore non sa è molto importante. Non aver mai paura di porre domande su dettagli e requisiti specifici del dominio. Questo assicurerà che sei sulla buona strada :)

In una cosa importante che i neofiti dimenticano di fare è, prima Google per problemi tecnici prima di chiedere l'aiuto di Team lead or Senior developer .

La squadra (o lead se la tua squadra è meno democratica) dovrebbe generalmente arrivare a una sorta di accordo sul design. Esistono altri modi per ottenere risultati, quindi immagino che varieranno a seconda di dove stai codificando.

Se hai difficoltà ad afferrare la struttura della base di codici o non sai come meglio progettare la nuova funzione, chiedi al tuo lead o ai tuoi colleghi. Parte del buon processo è la collaborazione con il tuo team.

Mi piace questa domanda. Come architetto di software, il mio manager mi ha portato nel suo ufficio per una "chat" di 1,5 ore su come è mia responsabilità garantire che ogni riga di codice che qualsiasi altro sviluppatore del team impegna sia conforme al 100% agli standard di codifica e all'architettura di l'applicazione, e fondamentalmente quella logica è nel posto giusto (cioè se un dev commette il codice che contiene la logica aziendale codificata in un gestore di clic del pulsante invece di un livello aziendale, quindi è colpa mia). Tuttavia mi è stato anche detto che a) non possiamo fare la peer programming, perché è inefficiente, e b) non ho tempo di fare recensioni di codice. (sì, sto cercando un nuovo lavoro ora).

Ad ogni modo, quello che gli ho detto è che no, NON è il mio lavoro per gli sviluppatori dire dove inserire esattamente il loro codice, ma è compito dell'architetto creare il framework e il layout dell'applicazione come intuitivo il più possibile per gli sviluppatori per determinare dove il codice dovrebbe andare, e per renderlo il più semplice possibile per metterlo lì.

Alcune architetture software possono fare un buon lavoro per guidare anche questo, ad esempio in una "architettura di cipolla", l'interfaccia utente non avrebbe un riferimento (a livello di progetto) al DB, quindi non è possibile inserire DB codice nel gestore di clic del pulsante dell'interfaccia utente (a meno che lo sviluppatore non aggiunga il riferimento mancante, cosa che di solito non è possibile impedire).

Ciò che considero una buona tecnica:

Programmazione peer. Soprattutto quando le persone di livello senior sono in coppia con persone di livello junior. Se una persona non sa dove va il codice, l'altra potrebbe. Oppure un peer potrebbe notare qualcuno scivolare codice in un luogo che non è conforme ai principi o ai modelli di buon artigianato del software.

Se non riesci a scrutare per codificare un'intera funzione, allora una buona strada da percorrere è quella di ottenere i requisiti (oi criteri di accettazione per una storia / funzione), e fare in modo che l'architetto e il programmatore di funzionalità visualizzino per un un paio d'ore e scrivi tutti i test unitari per coprire le specifiche. Sì, sto parlando di sviluppo basato sui test qui. Questi test unitari vengono solitamente impostati per indicare il design e il codice che dovrebbe essere necessario per eseguire il test. Quindi i test (spezzati) possono essere trasferiti al programmatore di funzioni per codificarsi da soli, ma il suo progetto sarà ampiamente guidato dai test, che l'architetto ha aiutato a organizzare. Funziona davvero bene quando non è possibile programmare a tempo pieno i peer e i programmatori hanno familiarità con o desiderano imparare il test dell'unità e TDD!

Dipende dall'architettura principale del sistema . Alcuni di loro (tra cui alcuni veramente grandi che ho visto dall'interno) non hanno una struttura interna, per me sono semplicemente raccolte di soluzioni parallele a una serie di compiti, che alla fine formano un sistema o una struttura. In questi casi, può essere una domanda aperta se l'anziano dovrebbe o non dovrebbe dire queste cose - e la risposta probabilmente dipende dal gusto e dalle abitudini. Preferisco un altro modo (che è un giudizio soggettivo, mi ci sono voluti diversi anni per creare questa architettura).

Ero un programmatore capo in un sistema di gestione dei dati a livello nazionale. Ciò significa una struttura applicativa piuttosto "orizzontale": molta gestione dei dati guidata su strutture gerarchiche di dati (come dati personali, informazioni sulle proprietà, ...) e azioni di livello superiore: applicazione di appalto e flusso di lavoro di avanzamento, archiviazione, lettere di notifica, ecc. I sono sicuro che senza una chiara struttura interna tali sistemi semplicemente crollano nel tempo a causa del loro stesso peso (conservano tutte le vecchie cose ma cambiano costantemente tutte le offerte esistenti, le lettere, aggiungendone di nuove, la maggior parte del tempo lavorano sotto una pressione irrazionale). / p>

Quindi abbiamo creato componenti di supporto ("toolkit") per l'accesso al database, schermate di manipolazione dei dati dirette, moduli, lettere, flussi di lavoro, ...; e servizi di alto livello, come un sistema di archiviazione in grado di raccogliere, visualizzare qualsiasi documento di qualsiasi tipo per un caso di un cliente, o il gestore di moduli che era responsabile di lasciare che il cliente riempia un tipo specifico di modulo, (e non il modulo business logic) ha gestito l'archiviazione, la memorizzazione, ecc.

Dietro questa struttura avevamo tabelle di configurazione in cui era necessario registrare la singola dichiarazione GUI, la logica aziendale associata, ecc. e se era presente, la funzione era integrata nel sistema. Ovviamente tutti i componenti avevano classi di base astratte intelligenti, quindi molti di essi erano pronti per l'uso (come la gestione del nuovo tipo di dati gerarchici a volte più tabelle di dati) per configurazione, senza alcuna codifica.

Conseguentemente, la domanda menzionata non è MAI apparso .

• NO, non ho mai detto a nessuno il nome delle classi (l'avrei fatto in caso di collisione di nomi tra più moduli - questo non è mai accaduto).
• NO, non ho mai detto dove metterlo (era responsabilità del team che lavorava su quella specifica area, progettando il proprio pacchetto e schema di protezione).
• SÌ c'erano impostazioni di configurazione esatte che dovevano fare per far funzionare i loro componenti e codici nel sistema.
• Sì, c'erano diverse classi base da cui derivare, con posizioni esatte in cui dovevano aggiungere il loro codice specifico e API per accedere ad altri componenti di sistema. Tutto è stato creato sulla base dell'esperienza degli sviluppatori che lavorano su quel campo per dire 5-10 anni (non sulle mie idee personali) e alla fine ha avuto decine o forse centinaia di esempi di lavoro per compiti simili nello stesso sistema.
• NO, non c'erano assolutamente "scorciatoie" consentite. Se erano davvero importanti (senza una soluzione accettabile), erano anche integrati al livello del toolkit. In alcuni casi, mesi o anni fa: -)
• e mi spiace, SÌ, la documentazione del wiki era sempre dietro le funzionalità, perché la maggior parte delle cose era progettata e implementata "all'indietro", afferrando le funzionalità iniziali dalle attività effettive e aggiungendo continuamente nuovi servizi, invece di pianificare in avanti.

Il sistema vive oggi, molti anni dopo che ho lasciato l'azienda (quindi questa è solo la mia opinione soggettiva, possono pensare in modo diverso), e per quanto ne so, riutilizzato in nuovi sistemi. L'unico problema è che lavorare in questo ambiente è noioso . (O sono troppo educati per dire la verità ... :-))

The latter job is hard, if the software I am working on is too big to grasp the structure. Should senior guys tell the place to add the code before coding?

Parte del lavoro è un vantaggio per far crescere le capacità di chi lo circonda. La crescita non è possibile se non hai mai avuto la possibilità di risolvere i problemi difficili. Il lead dovrebbe essere lì per aiutare, rispondere alle domande e rimetterti in carreggiata se ne hai bisogno. In generale non dovrebbero darti le soluzioni. Dovresti trovare le soluzioni, possibilmente con il loro aiuto, e certamente con la loro guida.