Come si chiama la disciplina che consiste nel fare la giusta scelta di lingua/paradigma/diagrammi di classe? [chiuso]

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/208633

Domanda

\ nChiuso .Questa domanda deve essere più concentrato. Attualmente non sta accettando risposte. Vuoi migliorare questa domanda?Aggiorna la domanda in modo che si concentri su un solo problema entro il modifica questo post. Chiuso 7 anni fa .\"2013-08-18 Migliora questa domanda

Come fisico, ho imparato a programmare da solo.Ma vorrei conoscere il nome della disciplina (come l'algoritmica è la disciplina della progettazione di algoritmi) che consiste in:

  • fare la giusta scelta di lingua/paradigma
  • progettare un diagramma di classe
  • organizzare le diverse parti di un codice e come interagiranno tra loro
È stato utile?

Soluzione

Credo che il termine che stai cercando sia Software Architect.

Ecco la definizione di Wikipedia di Architetto software Ed ecco la definizione di SEI di Architetto software

Tuttavia, i criteri che hai fornito sono un po' confusi.

fare la giusta scelta di lingua/paradigma

È piuttosto raro che un progetto sia in grado di sostituire il linguaggio esistente o l'architettura generale.Tali scelte possono e si verificano con progetti green field (ovvero nuovi di zecca), ma generalmente è considerato un cambiamento catastrofico per un progetto esistente.

Tuttavia, un architetto guiderà il progetto nell'adozione di nuove tecnologie nello stack esistente.Ciò può significare un nuovo framework o approccio di sviluppo, ma in genere si tratta di un cambio di tipo incrementale.Tieni inoltre presente che l'elenco dei potenziali candidati sarà limitato dalla scelta della lingua esistente e dalla struttura del codice.

progettare un diagramma di classe

A livello più ampio, questo viene fatto dagli architetti e da altri team leader/sviluppatori principali.È raro che un singolo individuo comprenda tutta un'applicazione, quindi le principali modifiche alla progettazione che richiedono un diagramma di classe verrebbero gestite da un team.

Al contrario, i progetti sufficientemente piccoli da consentire a un singolo individuo di comprendere tutta l'applicazione in genere non hanno un architetto dedicato.Di solito hanno uno sviluppatore solitario (o due) che conosce il prodotto e apporta le modifiche necessarie.

organizzare le diverse parti di un codice e come interagiranno tra loro

Il tuo criterio qui implica che queste cose cambiano continuamente su un progetto attivo.Non lo fanno.Viene definito un approccio, il team si attiene ad esso e cambia solo quando un dolore sufficiente rende necessario quel cambiamento.I cambiamenti strutturali tendono ad essere piuttosto dolorosi e costosi, quindi vengono eseguiti solo quando è assolutamente necessario.

Anche nel raro caso di un progetto di campo verde destinato a essere "qualcosa di grande", il team di progettazione (ovvero gli architetti e i team leader) disegnerà ampie aree e inizierà a stabilire contratti per le interazioni tra i livelli.Se c'è abbastanza lavoro per giustificare definizioni strutturali come questa, allora ci deve essere un team che spieghi come interagiranno.

Quindi, con tutto ciò spiegato, diamo un'occhiata alle citazioni pertinenti da Wikipedia e SEI.


Da Wikipedia:

Il ruolo dell'architetto software ha generalmente alcuni tratti comuni: * L'architetto fa scelte progettuali di alto livello molto più spesso delle scelte di basso livello.Inoltre, l'architetto a volte può dettare standard tecnici, inclusi standard di codifica, strumenti o piattaforme. * Gli architetti del software possono anche essere coinvolti nella progettazione dell'architettura dell'ambiente hardware o possono concentrarsi interamente sulla metodologia di progettazione del codice. * Gli architetti possono utilizzare vari modelli di architettura software specializzati nella comunicazione dell'architettura.

Da SEI:

Creare l'architettura giusta per risolvere il problema è solo una parte delle responsabilità degli architetti.Devono anche * definirlo, documentarlo e comunicarlo * assicurati che venga eseguita la modellazione corretta, per sapere che qualità come le prestazioni saranno soddisfatte * fornisci l'input necessario per problemi come la selezione di strumenti e ambienti * comprendere e pianificare percorsi evolutivi * piano per l'inserimento di nuove tecnologie


Un ultimo pensiero -

Molti dei ruoli primari di un Software Architect sono un po' nebulosi e il ciclo di feedback nell'identificazione di buone decisioni può diventare piuttosto esteso.Ci possono essere molti rischi aziendali senza il vantaggio associato nell'avere architetti dedicati che non sono sviluppatori.Quindi gli architetti del software puri sono piuttosto rari nel settore.Sono davvero solo i progetti ultra-grandi che possono permettersi di avere architetti dedicati che lavorano in team sulle principali aree del loro progetto.

Molti dei criteri che hai menzionato sono gestiti da team leader e sviluppatori senior nella maggior parte degli altri progetti.Spesso è semplicemente perché la decisione è presa al meglio da qualcuno che conosce intimamente il codice che sarà influenzato.Alcune metodologie di sviluppo (come Agile) precludono naturalmente la presenza di un architetto dedicato nel team.Ci sono sicuramente delle eccezioni a questa affermazione, ma Agile si concentra sugli sviluppatori che guidano quelle decisioni in base alle esigenze aziendali.

Questo blog / articolo entra in qualche dettaglio in più oltre a ciò che ho toccato.E la definizione di SEI del Architettura può essere interessante.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top