Difference between revisions of "Software design"
Karl Jones (Talk | contribs) (→See also) |
Karl Jones (Talk | contribs) (→Advice) |
||
| Line 24: | Line 24: | ||
<blockquote> | <blockquote> | ||
Most projects start with high ambitions, and an imperfect understanding of the problem at hand. Our implementations tend to outpace our understanding. It is possible to write code without understanding the problem fully; that code is just more complex than it needs to be because of our lack of understanding. | Most projects start with high ambitions, and an imperfect understanding of the problem at hand. Our implementations tend to outpace our understanding. It is possible to write code without understanding the problem fully; that code is just more complex than it needs to be because of our lack of understanding. | ||
| + | |||
| + | Good code comes from solving the same problem multiple times, or [[Code refactoring|refactoring]]. Usually, this proceeds by noticing recurring patterns and replacing them with a mechanism that does the same thing in a consistent way - replacing a lot of "case-specific" code, which in fact was just there because we didn't see that a simpler mechanism could achieve the same thing. | ||
[http://singlepageappbook.com/goal.html Source] | [http://singlepageappbook.com/goal.html Source] | ||
Latest revision as of 14:16, 8 November 2016
Software design is the process of creating specifications for software, including software development artifacts.
This article is about the activity between requirements and programming. For the broader meaning, see software development.
Contents
Description
Software design may refer to either "all the activities involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."
Solving problems with software
Software design usually involves problem solving and planning a software solution.
High-level, low-level
Software design is typically divided into two (or more) scales:
- High-level: architectural design
- Low-level: component and algorithm design
Advice
Advice from Mixu:
Most projects start with high ambitions, and an imperfect understanding of the problem at hand. Our implementations tend to outpace our understanding. It is possible to write code without understanding the problem fully; that code is just more complex than it needs to be because of our lack of understanding.
Good code comes from solving the same problem multiple times, or refactoring. Usually, this proceeds by noticing recurring patterns and replacing them with a mechanism that does the same thing in a consistent way - replacing a lot of "case-specific" code, which in fact was just there because we didn't see that a simpler mechanism could achieve the same thing.
See also
- Artifact (software development)
- Software architecture
- Software development
- Software engineering
- Software requirements
External links
- Software design @ Wikipedia
