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

-3

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

  • fare la scelta giusta della lingua / paradigma
  • progettazione di un diagramma di classi
  • organizzando le diverse parti di un codice e in che modo interagiranno tra loro
posta Vincent 17.08.2013 - 21:52
fonte

1 risposta

3

Credo che il termine che stai cercando sia Software Architect .

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

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

making the right choice of language/paradigm

È piuttosto raro che un progetto sia in grado di sostituire la lingua esistente o l'architettura generale. Queste scelte possono e devono accadere con progetti di campo verde (anche quelli nuovi di zecca), ma generalmente è considerato un cambiamento catastrofico per un progetto esistente.

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

designing a class diagram

Al livello più ampio, questo viene fatto dagli architetti e dagli altri lead leader / sviluppatori di piombo. È raro che un singolo individuo capisca tutte le applicazioni, quindi le modifiche di progettazione più importanti che richiedono un diagramma di classe saranno gestite da un team.

Al contrario, i progetti che sono abbastanza piccoli da consentire a un singolo individuo di comprendere tutte le applicazioni generalmente non hanno un architetto dedicato. Di solito hanno uno sviluppatore solitario (o due) che conosce il prodotto e apporta le modifiche necessarie.

organizing the different parts of a code and how they will interact between each other

Il tuo criterio qui implica che queste cose cambiano tutto il tempo su un progetto attivo. Non lo fanno. Viene definito un approccio, il team si attiene a questo e cambia solo quando il dolore sufficiente provoca la necessità di tale cambiamento. I cambiamenti strutturali tendono ad essere piuttosto dolorosi e costosi, quindi vengono eseguiti solo se 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) esporrà vaste aree e inizierà a stabilire contratti per le interazioni tra gli strati. Se c'è abbastanza lavoro per giustificare definizioni strutturali come questa, allora ci deve essere una squadra che spiega come stanno andando a interagire.

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

Da Wikipedia:

The role of software architect generally has certain common traits:
* Architect makes high-level design choices much more often than low-level choices. In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms.
* Software architects may also be engaged in the design of the architecture of the hardware environment, or may focus entirely on the design methodology of the code.
* Architects can use various software architectural models that specialize in communicating architecture.

Da SEI:

Crafting the right architecture to solve the problem at hand is only part of architects' responsibilities. They must also
* define, document, and communicate it
* make sure the right modeling is being done, to know that qualities like performance are going to be met
* give input as needed to issues like tool and environment selection
* understand and plan for evolutionary paths
* plan for new technology insertion

Un ultimo pensiero -

Molti dei ruoli principali di un architetto del software sono un po 'nebulosi e il ciclo di feedback nell'individuare le buone decisioni può essere abbastanza esteso. Ci possono essere molti rischi aziendali senza il vantaggio associato di avere architetti dedicati che non sono sviluppatori. Gli architetti del software sono così rari nel settore. In realtà sono solo i progetti ultra-grandi che possono permettersi di avere architetti dedicati che lavorano in un team sulle principali aree del loro progetto.

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

Questo blog / articolo va in qualche altro specifico oltre a quello che toccato. E la definizione di SEI di Architecture potrebbe essere di interesse.

    
risposta data 18.08.2013 - 02:09
fonte

Leggi altre domande sui tag