[1] Know what you are trying to achieve
[2] Keep in mind that software development is a human activity
[3] Proof by analogy is fraud
[4] Have specific and tangible aims
[5] Don’t try technological fixes for sociological problems
[6] Consider the longer term in design and in the treatment of people
[7] There is no lower limit to the size of programs for which it is sensible to design before starting to code
[8] Design processes to encourage feedback
[9] Don’t confuse activity for progress
[10] Don’t generalize beyond what is needed, what you have direct experience with, and what can be tested
[11] Represent concepts as classes
[12] There are properties of a system that should not be represented as a class
[13] Represent hierarchical relationships between concepts as class hierarchies
[14] Actively search for commonality in the concepts of the application and implementation and represent the resulting more general concepts as base classes
[15] Classifications in other domains are not necessarily useful classifications in an inheritance model for an application
[16] Design class hierarchies based on behaviour and invariants
[17] Consider use cases
[18] Consider using CRC cards
[19] Use existing systems as models, as inspiration, and as starting points
[20] Beware of viewgraph engineering
[21] Throw a prototype away before it becomes a burden
[22] Design for change, focusing on flexibility, extensibility, portability, and reuse
[23] Focus on component design
[24] Let each interface represent a concept at a single level of abstraction
[25] Design for stability in the face of change
[26] Make designs stable by making heavily used interfaces minimal, general, and abstract
[27] Keep it small. Don’t add features "just in case"
[28] Always consider alternative representations for a class. If no alternative representation is plausible, the class is probably not representing a clean concept
[29] Repeatedly review and refine both the design and the implementation
[30] Use the best tools available for testing and for analysing the problem, the design, and the implementation
[31] Experiment, analyse, and test as early as possible and as often as possible
[32] Don’t forget about efficiency
[33] Keep the level of formality appropriate to the scale of the project
[34] Make sure that someone is in charge of the overall design
[35] Document, market, and support reusable components
[36] Document aims and principles as well as details
[37] Provide tutorials for new developers as part of the documentation
[38] Reward and encourage reuse of designs, libraries, and classes
I found these great tips in a classic programming book: The C++ Programming Language Third Edition by Bjarne Stroustrup, the creator of C++. If you want to learn C++ or deepen your knowledge, this is The Book.
Error'd: Hypersensitive
1 day ago
No comments:
New comments are not allowed.