Mi sono recentemente laureato all'università e ho iniziato a lavorare come programmatore. Non trovo così difficile risolvere problemi "tecnici" o fare il debug con cose che direi avere 1 soluzione.

Ma sembra esserci una classe di problemi che non hanno una soluzione ovvia: cose come l'architettura software. Queste cose mi confondono e mi causano grande angoscia.

Passo ore e ore a cercare di decidere come "progettare" i miei programmi e sistemi. Ad esempio: divido questa logica in 1 o 2 classi, come posso nominare le classi, se dovessi renderla privata o pubblica, ecc. Questo tipo di domande occupa così tanto tempo e mi frustra enormemente. Voglio solo creare il programma - l'architettura sia dannata.

Come posso superare la fase dell'architettura più rapidamente e passare alla fase di codifica e debug di cui mi diverto?

Perfetto è il nemico del bene.

Detto questo, non dovresti tagliare gli angoli. La progettazione del software avrà un impatto più duraturo e farà risparmiare a te (e ai tuoi colleghi) tonnellate di tempo e sforzi in futuro. Ci vorrà più tempo per avere ragione. La maggior parte del tempo speso a programmare non è martellare su una tastiera, ma da una lavagna per capire come risolvere un problema.

Ma non dovresti preoccuparti della perfezione. Se due progetti combattono contro una situazione di stallo, significa che probabilmente hanno la stessa bontà. Basta andare con uno. Non è come se non fosse possibile cambiare le cose una volta individuati i difetti di quel disegno.

(E si spera che ti aiuterà anche quando scoprirai che non c'è solo un modo per eseguire il debug / risolvere problemi tecnici.)

Per programmi semplici e di piccole dimensioni (ad esempio con meno di diecimila righe di codice sorgente), è possibile progettarli durante la scrittura del codice. Se adotti un approccio di sviluppo iterativo e incrementale , prenderai progressivamente decisioni architettoniche lungo la strada: quindi scrivi qualche dozzina di righe di codice (aggiungendo qualche singola micro funzionalità), migliorale fino a quando non vengono restituiti avvisi dal tuo compilatore, testalo in il tuo debugger e ripeti.

faccio a dividere questa logica in 1 o 2 classi, come posso nominare le classi, dovrei renderla privata o pubblica, ecc. Questo tipo di domande occupa così tanto tempo

Non dovrebbero. E non contano molto per un piccolo programma (perché i programmi piccoli e semplici sono più facili da migliorare, ad esempio per cambiare i nomi, ecc ...). Devi solo essere coerente e dare priorità alla leggibilità del tuo codice sorgente. Di tanto in tanto potresti trovare la necessità di riformattare leggermente alcune piccole parti del tuo programma (e questo non è un grosso problema).

Confronta questo con molti progetti di software libero (anche grandi come il kernel Linux). Gli sviluppatori non hanno dedicato grandi sforzi all '"architettura" nelle prime fasi. UML non è quasi mai usato nel software libero . Inoltre, imparerai un po ' studiando il codice sorgente di diversi progetti di software libero.

Come principiante, lavorerai su un grande progetto software in un team, dove puoi semplicemente fidarti dello sviluppatore senior (che prende le decisioni sull'architettura), o lavorerai da solo su piccoli progetti (in genere, meno di qualche dozzina di migliaia righe di codice sorgente). In quest'ultimo caso, prenderai decisioni architettoniche incrementali, riformattando di tanto in tanto la tua applicazione, dopodiché il "progetto architettonico" si evolverà naturalmente.

Come posso superare più rapidamente la fase dell'architettura e la fase di codifica e debug, che mi piace?

Per piccoli progetti software, che richiedono meno di un anno di lavoro, molto facilmente: non fare architettura. Trascorri forse mezz'ora a fare brainstorming sul design generale. Quindi iniziare a scrivere il codice, con un approccio di sviluppo iterativo e incrementale : scrivere alcune dozzine di righe, compilarlo (con tutti gli avvisi e le informazioni di debug abilitate, ad esempio g++ -Wall -Wextra -gcon GCC per C ++) fino a quando non si ottengono avvisi (e passarlo in qualche semplice fonte statica analizzatore di codice, se ne hai uno, ad esempio clang-analizzatore ), prova quel codice con un debugger , affidalo al controllo della versione (ad esempio git), risciacqua e ripeti. Tuttavia, assicurati di evitare il debito tecnico: quando qualcosa ha un cattivo odore, lavora (riformattando e reimplementando) per migliorarlo.

D'altra parte, in un ambiente di squadra, il lavoro di architettura implica la discussione iniziale per definire la responsabilità di ogni membro della squadra. Tale discussione è guidata dallo sviluppatore senior (che non è un principiante). Leggi lo sviluppo di software agile e The Mythical Man-Month .

Voglio solo creare il programma, l'architettura deve essere bloccata.

Ottima intuizione (almeno per piccoli progetti). Quindi pensa qualche minuto al tuo programma e inizia a codificarlo con un approccio di sviluppo iterativo e incrementale : codifica alcune decine di righe e assicurati che funzionino bene, quindi ripeti. Prima di ciò, studia il codice sorgente (e osserva l'architettura) di simili progetti di software libero e più in generale fai un lavoro bibliografico e di ricerca.

In alcuni casi, pensa a un approccio di metaprogrammazione : ci sono situazioni in cui vorresti generare qualche "file sorgente" (esempi includono l'uso di generatori di parser come bisonte , generatori di codici di colla come SWIG , Google protobuf , e talvolta potresti voler scrivere un script semplice - oppure usa un preprocessore generico come GPP - per emettere parte del tuo codice C ++ o Java per evitare codifiche ripetitive).

PS. Sono un ingegnere di ricerca, ho un dottorato di ricerca in informatica e 40 anni di esperienza e non ho mai fatto "architettura" come suggerisce la tua domanda, pur avendo lavorato con successo su diversi progetti di medie dimensioni e alcuni grandi progetti (lo stesso compilatore GCC ). Per me "l'architettura" è solo la fase di pianificazione del lavoro dei prossimi giorni o settimane (e di solito lo faccio mentre sogno o dormo e certamente senza computer, e di solito senza nemmeno una matita). Inoltre, quando scrivo borse di ricerca , sto progettando in qualche modo e in modo incompleto un'architettura.

NB: alcuni progetti software richiedono molta più architettura di altri. Ad esempio, se si scrive il sistema di controllo di un cuore artificiale o di un robot neurochirurgico, non si funzionerà allo stesso modo di quando si scrive l'applicazione per telefono cellulare media. Vedi anche Norvig's Teacharsi nella programmazione in dieci anni .

Ci sono tre motti che mi piace ricordare.

• "Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice"

  Per prendere il tuo esempio di "una classe o due?", Chiederei, "qual è la soluzione più semplice?"

• "Nessun bug evidente" rispetto a "Ovviamente nessun bug"

  Quest'ultimo è preferibile!

  E questo è il motivo per cui deve essere semplice, cioè in modo da poter ragionare su di esso. Una grande classe potrebbe essere (o potrebbe diventare) troppo grande e troppo complicata per ragionare, nel qual caso la dividi in più classi più piccole, dove puoi dire "Ogni classe è piccola e fa quello che dice che farà - e le loro interfacce sono semplici e si combinano nel modo giusto ".

  1. Il codice dovrebbe essere eseguito in teoria (cioè nella tua testa).
  2. Quindi se non funziona in pratica puoi eseguirne il debug fino a quando la pratica non corrisponde alla teoria.

  Un principiante a volte non si preoccupa del passaggio 1, ovvero eseguendolo nella tua testa (ad esempio perché è troppo complicato) - ma in quel caso corre solo "per caso" piuttosto che "in teoria", forse perché non hai " t testato abbastanza per trovare bug non ovvi.

• Legge di Gall

  Questo è noto anche come "refattore".

  In pratica questo significa:

  1. Inizia con un [ny] sistema semplice che funziona
  2. Ora è il momento di aggiungere una nuova funzionalità
  3. Rifattorizzare il sistema esistente in modo che (cioè fino a) la nuova funzionalità sia facile da aggiungere

  4. Aggiungi la nuova funzionalità

  5. ... e ripeti come sopra

  Questo corrisponde a motti come YAGNI, cioè non rifatturare (preoccuparsi dell'architettura) prima che tu abbia bisogno di ... ma crea l'architettura giusta appena in tempo, cioè quando ne hai bisogno per uno scopo specifico.

Quello che puoi fare è iniziare con il numero minimo di astrazioni di cui hai bisogno. Ad esempio, una classe Person in un file. Mentre continui ad aggiungere codice e funzionalità, inizi a vedere cose che devono essere spostate su un'astrazione diversa. Ad esempio, il principio di responsabilità singola (S di SOLID) ti dice di non avere metodi relativi all'analisi dell'indirizzo nella classe Person. Quindi ora sai che hai bisogno di una classe Address.

Ma è sempre bene dedicare un po 'di tempo a pensare a quale "numero minimo di astrazioni" assomigli al tuo sistema. Inizia da un'architettura abbastanza buona e migliorala mentre procedi.

modifica: la risposta @Basile fornisce un esempio di come è possibile iterare e migliorare la propria architettura minima.

Il tempo trascorso a pensare all'architettura di un sistema non è tempo perso.

Credo che la tua domanda possa essere riformulata come "come posso essere più efficiente nel prendere decisioni sull'architettura?".

La mia breve risposta sarebbe: devi scoprire i principi fondamentali che ti permetteranno di prendere decisioni in modo affidabile ed efficiente e quindi dovrai effettivamente uscire e modellare un software reale. Questo sarà un lungo viaggio alla ricerca di conoscenza, prove ed errori e sviluppo personale.

-

E per una risposta più lunga ...

Dovrei prima chiarire i concetti: uso la parola architettura per descrivere la struttura di un sistema software complesso quando lavoro con processi, servizi, API e database. Uso la parola design per descrivere la struttura di un solo pezzo di un sistema più complesso, quando lavoro con classi, funzioni e librerie. Queste sono le mie definizioni, alcune persone hanno definizioni diverse. Ma in questo contesto, credo che tu stia parlando di design .

Penso che ci siano 3 cose importanti da tenere a mente quando si discute di questo argomento:

• l'architettura e il design esistono senza che siano esplicitamente descritti tramite diagrammi o documentazione, anche senza che siano gestiti da un team o da una persona (un architetto ). Ogni sistema ha un'architettura intrinseca e un design intrinseco che può essere descritto dopo il fatto.

• lo sviluppo del software non sta programmando, sta programmando nel tempo. Sto facendo questa distinzione perché penso che sia uno dei più grandi punti ciechi per le persone che arrivano nel settore (me compreso, ad un certo punto nel tempo). Ciò significa che, rispetto ai progetti universitari o ai progetti secondari personali, lavorare su un sistema software del mondo reale è esponenzialmente più complesso, perché qualsiasi decisione architettonica avrà un grande impatto sullo sviluppo del sistema, con il tempo. Le tue decisioni ora torneranno a perseguitarti, garantito.

• poiché l'architettura e il design esistono in modo istruttivo e poiché la base di codice è una cosa vivente che si evolve nel tempo, anche l'architettura e il design devono evolversi. O si evolveranno in modo controllato attraverso decisioni consapevoli prese al momento giusto, oppure si evolveranno caoticamente, guidati dalla codifica. Questo è fondamentale da capire, perché significa che l'approccio tradizionale di "architetto prima e scrivere il codice secondo" è imperfetto. Naturalmente, quando si avvia un progetto da zero, alcuni lavori di architettura e design devono essere eseguiti in anticipo. Oltre a ciò, ci saranno ancora molte decisioni di architettura e design da prendere durante lo sviluppo del sistema.

Per distillare quanto sopra ulteriormente, è molto importante essere consapevoli del fatto che si sarà essere fare scelte di progettazione durante la scrittura di codice, consciamente o no. Dovresti impegnarti a prendere quante più decisioni consapevolmente e criticamente, poiché qualsiasi decisione presa alla leggera può avere un grande impatto sul lavoro futuro (questo impatto si manifesta di solito nella base di codice diventando molto difficile da modificare per correggere bug o implementare funzionalità). Robert C. Martin lo illustra magnificamente, con dati, nel suo libro "Clean Architecture" (che consiglio vivamente a proposito).

Quindi, ora che sappiamo perché l'architettura e il design sono importanti, quali sono i principi fondamentali che possono darci un quadro adeguato per un buon processo decisionale? Ho avuto questa domanda all'inizio della mia carriera, mi sembrava che mancasse qualcosa nel mio set di strumenti, ma non sapevo cosa, non sapevo come descriverlo o cercarlo. Condividerò alcuni di questi principi che ho scoperto con il tempo e spero che renderanno la tua vita leggermente più semplice:

• un insieme di trucchi di codifica molto semplici ma potenti può essere raccolto leggendo il libro di Martin Fowler "Refactoring: migliorare il design del codice esistente". Ce ne sono troppi da elencare qui, ma si tratta di decisioni a basso tempo di codifica che puoi prendere per migliorare notevolmente la struttura del codice e aiutarti a prendere le decisioni di progettazione. Il libro è anche un buon esempio per l'integrazione di unit test nel flusso di lavoro personale e su come scrivere codice testabile.

• specificamente per OOP, dovresti guardare ai principi SOLIDI . All'inizio sono un po 'astratti e difficili da avvolgere, ma molto potenti. Ti suggerisco di iniziare con i primi 2 per ottenere rapidamente il massimo beneficio:

Principio di responsabilità unica : una classe dovrebbe avere una sola responsabilità (cioè solo le modifiche a una parte delle specifiche del software dovrebbero essere in grado di influenzare le specifiche della classe).

Principio aperto / chiuso : "le entità software ... dovrebbero essere aperte per l'estensione, ma chiuse per modifica".

• il concetto di composizione sull'eredità

  il principio secondo cui le classi dovrebbero ottenere comportamenti polimorfici e riutilizzo del codice in base alla loro composizione (contenendo istanze di altre classi che implementano la funzionalità desiderata) piuttosto che l'ereditarietà da una classe base o genitore.

• i concetti di accoppiamento ("il grado di interdipendenza tra i moduli software") e coesione ("il grado in cui gli elementi all'interno di un modulo appartengono insieme").
• il concetto DRY (Don't Repeat Yourself)
• il concetto di separazione comando / query ("ogni metodo dovrebbe essere un comando che esegue un'azione o una query che restituisce dati al chiamante, ma non entrambi")
• il concetto di stato con sistema senza stato (la mia regola empirica è: evitare di gestire lo stato; costruire il più possibile sistemi senza stato).

Certo, questi sono solo concetti, non regole. Il primo passo è comprenderli ed esserne consapevoli. Il prossimo arriva in realtà usandoli nella pratica e costruendo esperienza su quando dovresti seguirli e quando non dovresti. E poi c'è un processo continuo per affinare la comprensione di questi concetti, i loro lati negativi e le loro complesse interazioni tra loro.

Penso che il consiglio più prezioso che posso darti sia: abbi pazienza con te stesso. Hai appena iniziato una strada lunga ma appagante. Continua a praticare e sperimentare, prendi nota di ciò che funziona e cosa no e migliorerai solo con il tempo.

La maggior parte di ciò che descrivi non è veramente (importante) architettura - una buona denominazione e un buon design di classe sono qualcosa che dovrebbe essere una seconda natura per te. Questo semplicemente migliorerà quanto più codice. Il più utile per tali preoccupazioni è di solito la coppia di programmazione: aiuta a chiarire tali problemi e ti aiuta a imparare in modo efficiente.

Dove l'architettura è necessaria PRIMA del progetto:

1. Raccogli i requisiti esatti e i requisiti non funzionali (quante richieste / secondo devo supportare?). Qualsiasi mancata corrispondenza in questa fase porterà alla codifica dell'inferno - l'integrazione di idee mancate dopo che il fatto è dispendioso in termini di tempo, fastidioso e talvolta impossibile. So che questo non è divertente come codifica, ma cercare di ottenere il codice per fare qualcosa per cui non è stato progettato è ancora meno divertente.

2. Se appropriato, definisci i contesti limitati del tuo sistema e assicurati di avere il tuo vocabolario dritto, ad esempio se l'azienda parla di "Frobbels" assicurati di nominare classi / interfacce ecc. Con "*** Frobbels". Sembra banale, ma se parli di flussi di lavoro, mentre l'azienda parla di operazioni, la traduzione diventa fastidiosa molto velocemente.

3. Se lavori con più persone / team descrivi le tue interfacce in anticipo e assicurati che tutti i presupposti e i problemi siano compresi da tutti - se non hai un contesto condiviso, l'integrazione sarà "divertente". Ad esempio, costruisci un generatore di immagini a banana, ma il tuo sviluppatore frontend ha bisogno di un generatore di immagini Apple. Oppure costruisci qualcosa che può rispondere a 100 richieste / secondo, ma sono necessari 10000 r / sec.

Nota: questo è fortemente influenzato dal mio lavoro su un'architettura a microservizi. Il modo in cui i servizi vengono creati internamente, PUO 'anche essere progettato, ma il più delle volte è molto meno importante che ottenere il quadro generale giusto.

Non ho intenzione di lanciarti un mucchio di termini e abbreviazioni (la maggior parte dei quali difficilmente è concordata dalla maggior parte dei programmatori / ingegneri del software). Invece, considera quanto segue:

1. Stai imparando: non stai perdendo tempo, stai provando approcci diversi e imparando cosa funziona. Puoi farlo senza pianificare molto in anticipo, immergendoti in un problema con la prima soluzione che mi viene in mente e cambiandolo se o quando non funziona. Se funziona bene, fantastico! Hai trovato una soluzione semplice a un problema. Le soluzioni semplici vanno bene se funzionano bene e a volte sono abbastanza buone .

2. Tutto è un compromesso: puoi progettare lo stesso sistema in molti modi diversi, scambiando tempo e spazio, complessità e flessibilità, astrazione e leggibilità, o uno qualsiasi dei tanti compromessi possibili. Nessuna soluzione è perfetta in ogni modo e nessuna regola è senza eccezioni nell'ingegneria del software. Chiunque ti dica altrimenti è ingenuo o vende qualcosa.

3. Come neolaureato, la codifica e il debug possono essere molto eccitanti, ma questo si esaurirà con il tempo e le abilità che stai imparando ora ti serviranno bene quando lo fa.

4. Direi che costruire software è più arte / artigianato che ingegneria. La grande arte non riguarda solo la pennellata individuale, ma piuttosto le decisioni e i compromessi di alto livello presi dall'artista / artigiano.

Cercherò di rispondere a questa domanda proveniente da un punto di vista dello sviluppo web (significato: proveniente da un campo in cui le persone si agitano molto per l'architettura). Inizierò con la spiegazione del perché le persone si preoccupano dell'architettura e poi descriveranno i modi per superare la parte dell'architettura più rapidamente.

L'architettura fa due cose per il tuo codice:

1. Semplifica la comprensione del codice per te e gli altri.
2. Aiuta a strutturare il codice in modo da semplificarne l'estensione e l'integrazione.

Uno stile di codice semplifica la lettura di una parte specifica del codice, fornendo convenzioni che è possibile riconoscere e utilizzare per esplorarlo. Allo stesso modo una buona architettura ti aiuta a identificare dove troverai effettivamente il codice che gestisce una specifica funzionalità. Ad esempio, nella maggior parte dei progetti Web l'architettura è strettamente correlata al modo in cui le cartelle e i file sono ordinati. D'altra parte, una buona architettura dovrebbe effettivamente aiutarti a pensare meno al codice, perché dovrebbe già avere un posto intuitivo a cui appartiene qualsiasi parte di codice.

Inoltre, una buona architettura fornisce una scorciatoia per evitare molte delle insidie ​​che potrebbero impedire un facile utilizzo del codice. Ancora una volta, se prendi una decisione sull'architettura, dovrebbe impostare una convenzione che ti aiuti a pensare meno a come scrivere il codice.

Ora la parte in cui sei effettivamente qui per:

Cosa puoi fare per superare la parte dell'architettura più rapidamente:

1. Non farlo

Come molte risposte hanno già sottolineato. Prima chiediti se hai davvero bisogno di architettura. Se non avrai molto codice (e puoi essere ragionevolmente sicuro che il progetto non crescerà nel prossimo futuro), puoi semplicemente saltare la parte dell'architettura e mettere insieme qualcosa che semplicemente funziona. TUTTAVIA, se sei all'inizio della tua carriera, sfrutterei l'opportunità per esercitarmi ogni volta che puoi. Ad un certo punto farai progetti più grandi, e a quel punto probabilmente è troppo tardi per imparare.

A parte questo, cosa puoi fare per rendere l'architettura meno dolorosa:

1. Fallo presto
2. Rubare
3. Impara / attenersi ad esso
4. Non esagerare

Decidere su un'architettura dovrebbe essere una parte iniziale del processo di pianificazione. Non appena avrai un'idea di quale tipo di app / programma / sito web realizzerai, dovresti pensare a quale tipo di architettura lo sosterrebbe.

A questo punto è tempo di rubare senza vergogna. C'è molta letteratura là fuori su come impostare correttamente un'architettura di programma e una quantità sorprendente di casi d'uso è coperta da questi prototipi di architettura esistenti. Dovresti imparare una visione generale di che tipo di architetture esiste là fuori, anche se non sai come implementarle.

Se hai optato per un tipo di architettura, allora atteniti ad esso. Per la maggior parte, la decisione sull'architettura dovrebbe essere intuitiva e richiedere solo pochi secondi dopo l'installazione iniziale. Molto di questo si riduce all'esperienza.

Infine, non pensare troppo alle cose. Dai l'esempio del fatto che qualcosa dovrebbe essere pubblico o privato, e la verità è che probabilmente non importa se rendi tutto pubblico. Sì, non dovresti farlo in questo modo, e molti di questi piccoli errori si accumuleranno dopo un po ', ma alla fine probabilmente non ucciderà nemmeno il tuo progetto. Innanzitutto creare software funzionante!

(PS: quest'ultima frase non è una scusa per essere pigri. Dare priorità al software di lavoro non significa che un giorno non dovrai imparare un buon codice.)

La risposta è molto semplice

• Crea un prototipo (Time boxed)
• Refactor (passa tutto il tempo che vuoi o hai basato su un'ampia gamma di fattori)

Quando si crea un prototipo, l'attenzione dovrebbe essere focalizzata sul prodotto minimo praticabile e, quando si esegue il refactoring, l'attenzione dovrebbe essere rivolta a rendere scalabile il progetto o la soluzione.

Come posso superare più rapidamente la fase dell'architettura e la fase di codifica e debug, che mi piace?

Relegando questo compito (o chiedendo aiuto) ai tuoi colleghi più esperti.

Ti manca semplicemente l'esperienza necessaria per prendere rapidamente tali decisioni. Uni ti ha fornito un buon background teorico, ma ti porta solo su una linea di partenza. Non esiste altro modo per giudicare una determinata architettura in una data situazione se non sapere come architetture simili si sono comportate in situazioni simili in passato.

Lavorare con persone più brave al lavoro di te è il modo più veloce per imparare le cose. Se non hai nessuno a cui rivolgersi, hai bisogno di un lavoro migliore. "Meglio" come in "soddisfare meglio le tue esigenze". Il bisogno di conoscenza ed esperienza è il tuo bisogno più terribile in questo momento, come dimostrato dal tuo dilemma. Ti piace la fase di codifica e debug? Sembra un junior perfetto. Ma un junior ha bisogno della guida dell'anziano. Questo è il punto di quelle descrizioni di lavoro. Gli estranei su Internet possono aiutarti solo finora, hai bisogno di un mentore.

Vedo alcuni seri problemi con questa domanda. Iniziamo.

Come smettere di perdere tempo nella progettazione di architechture

Questa domanda è piuttosto carica. Inoltre, non si progetta architettura. Tu architetto . Architettura e design sono attività complementari e correlate, ma non sono le stesse, anche se potrebbero sovrapporsi.

Allo stesso modo, allo stesso modo è possibile perdere tempo a fare architettura (sovra-progettando), si può anche perdere tempo a progettare eccessivamente e sovracodificare (codificando le cose in un modo molto più complesso del necessario, o non riuscendo a codice per le cose che sono richieste.)

La corretta architettura mira a prevenire tale spreco nella codifica. Lo fa limitando, restringendo e documentando i possibili modi in cui un sistema complesso deve essere 1) progettato, 2) codificato e testato, 3) consegnato, 4) mantenuto, 5) recuperato da un guasto e 6) alla fine messo fuori servizio.

La mia esperienza è stata che le persone a cui piace semplicemente programmare, semplicemente programmano senza pensare a come un sistema debba funzionare e mantenere a lungo termine, passando alla patata bollente successiva lasciando qualche povera anima per mantenere un brutto golem.

Ma sto divagando ...

Questo è il punto: per i sistemi abbastanza semplici, l'architettura è evidente ed emana da solide pratiche di progettazione e implementazione.

È solo per sistemi di grandi dimensioni che coinvolge un numero piuttosto elevato di persone o software a livello di sistema che esegue operazioni molto complesse che richiedono un'architettura esplicita.

Mi sono recentemente laureato alla uni e ho iniziato a lavorare come programmatore. Non trovo così difficile risolvere problemi "tecnici" o eseguire il debug, cose che direi avere 1 soluzione.

Questo è il minimo richiesto per questa professione e sono contento che tu non abbia problemi a svolgerli (sarei preoccupato se lo facessi.)

Ma sembra esserci una classe di problemi che non hanno una soluzione

Questi sono il pane e il burro della nostra professione, il tipo di problemi per i quali i datori di lavoro sono disposti a pagare i nostri stipendi (in genere) molto al di sopra della media.

È un dato di fatto, i problemi che vale la pena risolvere sono quelli che possono avere più di una soluzione. Problemi del mondo reale, sono così. E il mondo richiede la nostra esperienza, come sviluppatori di software, di trovare compromessi accettabili.

- cose come l'architettura software.

L'architettura delle cose è una caratteristica inevitabile di sistemi complessi, siano essi virtuali / software o nel mondo concreto. Ogni sistema che opera, che accetta input e produce output, sarà complesso e avrà un'architettura.

Quando sviluppiamo software per tali sistemi (un sistema bancario, un sistema di monitoraggio dell'alimentazione, un sistema di vendita dei biglietti, ecc.), Miriamo a produrre un software che imiti le funzioni e i requisiti di tale sistema.

Non possiamo semplicemente alaarlo e codificarlo in stile cowboy. Abbiamo bisogno di una sorta di architettura. Ciò è particolarmente vero se il progetto richiede dozzine di ingegneri, se non di più.

Queste cose mi confondono e mi causano grande angoscia.

Va bene. Non è una materia facile da imparare o da insegnare, non senza molta pratica.

Passo ore e ore a cercare di decidere come "progettare" i miei programmi e sistemi. Ad esempio, divido questa logica in 1 o 2 classi, come posso nominare le classi, se dovessi renderla privata o pubblica, ecc. Questo tipo di domande occupa così tanto tempo e mi frustra molto. Voglio solo creare il programma, l'architettura sia maledetta.

Sfortunatamente, questa non è architettura software.

Non è nemmeno design, ma solo codifica. Fornirò alcuni suggerimenti in fondo a questo post.

Come posso superare più rapidamente la fase dell'architettura e la fase di codifica e debug, che mi piace ?

Sto facendo fatica a trovare un modo per rispondere a questo, perché è piuttosto emotivo.

Stiamo cercando di fare un lavoro, o stiamo solo cercando di goderci la pratica? È bello quando entrambi sono la stessa cosa, ma nella vita reale, molte volte non lo sono.

È bello fare cose che ci piacciono, ma in una professione complessa come la nostra, concentrarsi solo su ciò che ci piace, non è conduttivo avere una carriera fruttuosa.

Non progredirai, non maturerai o acquisirai nuove conoscenze.

C'è questo detto nell'esercito: "abbraccia la schifosa".

Altre frasi hanno consigli simili. "Se non fa schifo, non ne vale la pena" e il mio preferito, "Se fa schifo (ed è importante), fallo fino a quando smette di succhiare."

I miei consigli:

Mi sembra che stai ancora lottando per capire le differenze tra

1. codifica (come codificare classi, moduli o altro, convenzioni di denominazione, visibilità dell'accesso, ambito di applicazione, ecc.),

2. progettazione (quanti livelli, front-end / back-end / db, come ciascuno comunica, cosa va dove) e le decisioni implicite sull'architettura che derivano dalla progettazione di sistemi semplici,

3. architettura (come si trova in sistemi complessi che richiedono migliaia, se non centinaia di migliaia di ore-uomo).

Quindi suggerirei di approfondire la prima materia (codifica) per portarla al livello successivo.

Codice pulito

"Clean Code" di Robert "Zio Bob" Martin è un buon punto di partenza.

Coesione del software

Inoltre, ti suggerirei di familiarizzare con una specifica metrica software orientata agli oggetti chiamata LCOM o piuttosto LCOM4.

Può diventare piuttosto matematico e non a prova di proiettile, ma il tuo obiettivo dovrebbe essere quello di capire e rilevare empiricamente (o il bulbo oculare se lo desideri) se una classe è coesiva o se manca di coesione.

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

Principi del software

Ciò è strettamente correlato al "Principio della singola responsabilità" o SRY con cui tutti dovremmo avere familiarità. SRY è uno dei 5 "SOLIDI" di cui tutti abbiamo bisogno per acquisire familiarità se vogliamo diventare esperti nella codifica.

Mentre passiamo attraverso i principi SOLIDI, dobbiamo anche familiarizzare con i principi "GRASP" , che regolano o piuttosto guidano il modo in cui codifichiamo le classi.

Libri aggiuntivi

Infine, suggerirei anche quanto segue:

• "Refactoring" di Martin Fowler e Ken Beck sarebbe il prossimo libro che avrei letto in questa lista.

• "Design by Contract, by Example" di Richard Mitchell, Jim McKim e Bertrand Meyer (l'ultimo della fama di Eiffel.) Questo libro è esaurito, ma è possibile trovare copie usate a basso costo in Amazon.

Con questo, dovresti avere una buona conoscenza di come iniziare a programmare e progettare, e con la pratica, di spostare e padroneggiare (o almeno afferrare) l'architettura del software.

Sono sicuro che ci saranno altri professionisti che aggiungeranno, sottrarranno o obietteranno a questi suggerimenti. Verranno forniti altri suggerimenti, probabilmente convalidati dalla propria esperienza.

Tutto quello che posso dire è questo: non ci sono scorciatoie.

Ti auguro il meglio.

Ci sono molte informazioni qui e francamente TL; DR. C'è una cosa principale secondo cui le persone si sbagliano quando provano a imparare a progettare un sistema: provano a pensarci nell'ordine in cui il lavoro verrà svolto. Invece, devi lavorare all'indietro. Cioè, l'obiettivo principale del design / architettura è determinare quale dovrebbe essere il risultato finale.

Come analogia, considera l'architettura di una casa. Un architetto non inizia a porsi domande del tipo: "quante finestre dovrebbe avere questa casa?", "Dove dovrebbe essere collocato il primo mattone?". Quei dettagli di implementazione non sono il design, sono derivati ​​dal design. L'architettura inizia con una visione, forse uno schizzo di come potrebbe essere la casa finita. È una casa unifamiliare, un duplex? È una casa di lusso o facilmente accessibile? Allo stesso modo, se le variabili sono private e se si divide una classe ha poco a che fare con l'architettura.

Inizia prima a capire quali sono gli obiettivi del tuo design. Ad esempio, si tratta di una soluzione unica? Sarà ampliato, rivisto e mantenuto per decenni? La risposta a ciò indicherà progetti molto diversi e questo è il punto dell'architettura. Una volta che hai capito cosa devi fare, i dettagli del design seguono naturalmente. Non che questi dettagli siano ovvi o facili, ma è il piano di alto livello su cui si basano queste scelte.

Come giudicare quanto tempo dovresti dedicare all'architettura di qualsiasi pezzo di software prima di ottenere un ciclo di test di scrittura-compilazione di qualche tipo è abbastanza semplice: abbastanza informazioni per adattarti alla tua testa e niente di più. A meno che il progetto su cui stai lavorando imponga una metodologia più rigorosa. Nel qual caso come principiante molto probabilmente dovresti leggere un documento di architettura, non scriverlo.

Per quanto riguarda la denominazione delle cose, per me fa parte della "scrittura", ma è senza dubbio una parte molto importante della programmazione: non esitare a pensare intensamente a come nominare le cose e a pensare più intensamente, maggiore è la portata del nome.

Trovare i giusti nomi, la giusta architettura, la giusta modularità e le giuste astrazioni è parte dell'esperienza che guadagnerai facendo errori. Nel corso degli anni ho scritto un programma facendo la stessa cosa circa cinque volte e il codice era molto diverso ogni volta perché ogni iterazione passata mi dava suggerimenti per un design migliore.