Utente:Marcobombe/Sandbox: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica
Nessun oggetto della modifica
Riga 1:
'''"Cowboy coding"''' è un termine utilizzato per descrivere una metodologia di sviluppo del software in cui i programmatori hanno piena autonomia nel controllo della pianificazione del progetto, nella scelta degli algoritmi, degli strumenti di sviluppo e dello stile di programmazione del codice.
'''Cowboy coding''' is a term used to describe software development where the developers have [[autonomy]] over the development process. This includes control of the project's schedule, algorithms, tools, and coding style.
Un "cowboy coder" può essere uno sviluppatore isolato o parte di un gruppo di sviluppatori, in assenza di alcuna gestione esterna che controlli gli aspetti di sviluppo del progetto, come la sua natura, la portata, il set di funzionalità.
 
"Cowboy coding" può avere connotazioni positive o negative, a seconda delle proprie opinioni sul ruolo di gestione e di processo formale nello sviluppo di software. Spesso usato come termine dispregiativo dai sostenitori delle metodologie di sviluppo software, è tuttavia rivalutato da programmatori che praticano il loro lavori all'interno di alcune comunità.
A cowboy coder can be a lone developer or part of a group of developers with either no external management or management that controls only non-development aspects of the project, such as its nature, scope, and feature set (the "what", but not the "how").
 
Cowboy coding can have positive or negative [[connotations]], depending on one's opinions on the role of management and formal process in software development; "cowboy coding" is often used as a [[pejorative|derogatory]] term by supporters of software development methodologies, such as [[Agile software development|Agile]]. However, the term has been [[reclaimed word|reclaimed]] to some extent by those practicing within the community.
 
== Disadvantages of Cowboy Coding ==
In cowboy coding, the lack of formal [[software project management]] methodologies may be indicative (though not necessarily) of a project's small size or experimental nature<ref>Hughes, Bob and Cotterell, Mike (2006). ''Software Project Management'', pp.283-289. McGraw Hill Education, Berkshire. ISBN 007719899</ref>. Software projects with these attributes may exhibit:
 
* Lack of release structure
The project may lack a [[feasibility study]], [[estimation (project management)|estimation]], or implementation planning may cause a project to be delayed. Sudden deadlines or pushes to release software may encourage the use of [[quick and dirty]] or [[code and fix]] techniques that will require further attention later.
* Inexperienced developers
Cowboy coding is common at the hobbyist- or student-level where developers may initially unfamiliar with the technologies, such as the [[build tool|build tools]], that the project requires. This can result in time required for learning to be underestimated, causing delays in the development process. Inexperience may also lead to disregard of accepted [[Standard_Operating_Procedure#Information_technology_industry_use|standards]], making the project source difficult to read or causing conflicts between the [[Semantics#Computer_science|semantics]] of the language constructs and the result of their output.
* Uncertain design requirements
Custom software applications, even when using a proven development cycle, can experience problems with the client concerning requirements. Cowboy coding can accentuate this problem by not scaling the requirements to a reasonable timeline, and may result in unused or unusable components being created before the project is finished. Similarly, projects with less tangible clients (often experimental projects, see [[independent game development]]) may begin with code and never a formal analysis of the design requirements. Lack of design analysis may lead to incorrect or insufficient technology choices, possibly requiring the developer to [[porting|port]] or rewrite their software in order for the project to be completed.
* Incompleteness
Many software development models, such as [[SCRUM]], use an incremental approach which stresses functional prototypes at each phase. Non-managed projects may have few [[unit testing|unit tests]] or working iterations, leaving an incomplete project unusable.
 
== DisadvantagesSvantaggi ofdel "Cowboy Coding" ==
In contesto "Cowboy Coding", la mancanza nel progetto di formali metodologie software di gestione possono essere indicativi (anche se non necessariamente) di piccole dimensioni di un progetto o di una sua natura sperimentale.
Progetti software con questi attributi possono presentare:
*Carenze nella struttura dei rilasci
Il progetto può mancare di uno studio di fattibilità, di stima, pianificazione o attuazione che può causare ritardi di progetto. Improvvise scadenze ed emergenze di rilascio potrebbero favorire la produzione di software con codice sporco e scritto velocemente, in cui gli errori vengono corretti al fine dell' immediata funzionalità e non secondo uno stile pulito e un approccio flessibile e generale. Spesso gli errori corretti in questo modo devono essere ripresi in futuro con maggiore attenzione e maggiore perdita di ulteriore tempo di sviluppo.
* Sviluppatori inesperti
Il "Cowboy Coding" è comune a hobbisti o a programmatori ancora studenti in cui gli sviluppatori possono inizialmente avere familiarità minima con le tecnologie, come ad esempio gli strumenti di sviluppo, che il progetto richiede. Ciò può comportare che il tempo necessario per imparare le conoscenze di base possa essere sottovalutato e accorciato causando ritardi successivi ben più gravi nel processo di sviluppo. L'inesperienza può portare anche a non tener conto di norme comunemente accettate, rendendo il codice sorgente di difficile lettura o causare conflitti tra la semantica dei costrutti del linguaggio e il risultato della loro produzione.
*Requisiti di progettazione incerti
Applicazioni software personalizzate, anche quando si utilizza un ciclo di comprovata di sviluppo, possono verificarsi dei problemi con il cliente in materia di requisiti. Codifica Cowboy può accentuare questo problema non scala i requisiti per un calendario ragionevole, e può causare i componenti inutilizzati o inutilizzabili essere creato prima che il progetto è finito. Allo stesso modo, i progetti con i clienti meno tangibili (progetti, spesso sperimentali, vedere lo sviluppo di giochi indipendenti) può iniziare con il codice e non un'analisi formale dei requisiti di progettazione. Mancanza di analisi di progettazione può portare a scelte tecnologiche errati o insufficienti, eventualmente, richiedere agli sviluppatori di porto o riscrivere il loro software in modo che il progetto deve essere completato.
Incompletezza
Molti modelli di sviluppo software, come SCRUM, utilizzare un approccio incrementale che sottolinea prototipi funzionali in ogni fase. Progetti non gestiti possono avere pochi o test di unità di lavoro iterazioni, lasciando un progetto incompleto inutilizzabile.
== Advantages of Cowboy Coding ==
* Developers maintain a [[Freeform art|freeform]] working environment that may encourage experimentation, learning, and free distribution of results.
Riga 22 ⟶ 21:
* Independent developers can begin with cowboy coding techniques before later selling them to commercial use or creating community-supported projects.
* Small projects may be burdened by heavy software management methodologies; cowboy coding removes this burden.
* By coding in their own time, a hobby project may come to fruition which otherwise wouldn't have<ref>K, Alex. Google's "20 percent time" in action http://googleblog.blogspot.com/2006/05/googles-20-percent-time-in-action.html, Official Google Blog, 2006-5-18</ref>.
 
== References ==
<references/>
 
<!--
== Examples of cowboy coding ==
{{POV-section|date=September 2009}}
 
* [http://web.archive.org/web/20070717193315/http://siliconuser.com/?q=node/10 How Adobe's Photoshop Was Born]
* [http://httpd.apache.org/ABOUT_APACHE.html About Apache HTTP Server]
* [http://www.guardian.co.uk/technology/2007/jul/25/media.newmedia A brief history of Facebook]
* [[History of Google#Early_history|Early history of Google]]
* [http://www.pacifict.com/Story/ The Graphing Calculator Story]
* [http://netfiles.uiuc.edu/rhasan/linux/#New%20Baby%20in%20the%20Horizon History of Linux]
* [http://blogs.sun.com/TechDaysEvents/entry/the_mysql_story The MySQL Story]
* [http://folklore.org/StoryView.py?story=Switcher.txt Switcher: The Macintosh's first multi-tasking environment]
 
== External links ==
* [http://c2.com/cgi/wiki?CowboyCoder Cowboy Coder] definition at Wards Wiki
* [http://cowboyprogramming.com/2007/01/11/delving-into-cowboy-programming/ Delving into Cowboy Programming]
 
[[CategoryCategoria:SoftwareMetodologie developmentdi philosophiessviluppo]] -->