Content deleted Content added
m Reverted 1 edit by 212.47.136.197 (talk) to last revision by Murray Langton |
Link suggestions feature: 2 links added. |
||
| (3 intermediate revisions by 3 users not shown) | |||
Line 2:
{{multiple issues|
{{more footnotes|date=July 2012}}
{{Tone|date=
}}
Line 78:
===Design===
{{Main|Software design}}
The primary purpose of design is to fill in the details which have been glossed over in the architectural design. The intention is that the design should be detailed enough to provide a good guide for actual coding, including details of any particular algorithms to be used. For example, at the architectural level, it may have been noted that some data has to be sorted, while at the design level, it is necessary to decide which [[sorting algorithm]] is to be used. As a further example, if an object-oriented approach is being used, then the details of the objects must be determined (attributes and methods).
===Choice of programming language(s)===
Line 100:
===Commenting===
Due to time restrictions or enthusiastic programmers who want immediate results for their code, commenting of code often takes a back seat. Programmers working as a team have found it better to leave comments behind since coding usually follows cycles, or more than one person may work on a particular module. However, some commenting can decrease the cost of [[knowledge transfer]] between developers working on the same module.
In the early days of computing, one commenting practice was to leave a brief description of the following:
Line 176:
# Customize deployment: Newer software products such as APIs, micro-services, etc. require specific considerations for successful deployment.<ref>{{Cite web|url=https://airbrake.io/blog/software-development/speed-up-deployment-match-demand|title=Tools You Need to Speed Up Deployment to Match Demand|date=February 3, 2017}}</ref><ref>{{Cite web|url=https://www.linux.com/news/devops-and-art-secure-application-deployment/|title=DevOps and the Art of Secure Application Deployment|first=Amber|last=Ankerholz|date=September 14, 2016}}</ref><ref>{{Cite web|url=https://aws.amazon.com/blogs/architecture/organizing-software-deployments-to-match-failure-conditions/|title=Organizing Software Deployments to Match Failure Conditions|date=May 5, 2014|website=Amazon Web Services}}</ref>
# Reduce risk from other development phases: If other activities such as testing and configuration management are wrong, deployment surely will fail.<ref>{{Cite web|url=https://www.theserverside.com/news/1364556/Best-Practices-for-Risk-Free-Deployment|title=Best Practices for Risk-Free Deployment|website=TheServerSide.com}}</ref><ref>{{Cite web|url=http://www.drdobbs.com/effective-software-deployment/184415760|title=Effective Software Deployment|first=Scott|last=Ambler|website=Dr. Dobb's}}</ref>
# Consider the influence each stakeholder has: Organizational, social, governmental considerations.<ref>{{cite web|url=http://searchitoperations.techtarget.com/tip/Enterprise-application-deployment-The-humanity-of-software-implementation|url-status=dead|archive-url=https://web.archive.org/web/20160821101511/http://searchitoperations.techtarget.com/tip/Enterprise-application-deployment-The-humanity-of-software-implementation|archive-date=2016-08-21|title=Enterprise application deployment: The humanity of software implementation}}</ref><ref>{{Cite web|url=https://18f.gsa.gov/2014/05/14/hacking-bureaucracy-improving-hiring-and-software/|archive-url=https://web.archive.org/web/20150118055134/https://18f.gsa.gov/2014/05/14/hacking-bureaucracy-improving-hiring-and-software/|url-status=dead|archive-date=January 18, 2015|title=Hacking bureaucracy: improving hiring and software deployment | 18F: Digital service delivery|website=18f.gsa.gov|date=14 May 2014}}</ref><ref>{{Cite web|url=https://intact-tech.com/why-a-bad-software-deployment-is-worse-than-doing-nothing/|title=A Bad Software Deployment Is Worse Than Doing Nothing|date=June 1, 2016|website=Intact Technology |last1=Horning |first1=Brian }}</ref>
==See also==
| |||