Difference between revisions of "Software design"
Karl Jones (Talk | contribs) (→External links) |
Karl Jones (Talk | contribs) (→Advice) |
||
(One intermediate revision by the same user not shown) | |||
Line 17: | Line 17: | ||
* High-level: [[Software architecture|architectural design]] | * High-level: [[Software architecture|architectural design]] | ||
* Low-level: [[component]] and [[algorithm design]] | * Low-level: [[component]] and [[algorithm design]] | ||
+ | |||
+ | == Advice == | ||
+ | |||
+ | Advice from Mixu: | ||
+ | |||
+ | <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. | ||
+ | |||
+ | 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] | ||
+ | </blockquote> | ||
== See also == | == See also == |
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