|
1 .. -*- coding: utf-8; -*- |
|
2 .. include:: HEADER.rst |
|
3 |
|
4 ============================ |
|
5 Software development rules |
|
6 ============================ |
|
7 .. contents:: |
|
8 :local: |
|
9 |
|
10 General discussion |
|
11 ================== |
|
12 |
|
13 See: |
|
14 |
|
15 http://en.wikipedia.org/wiki/List_of_software_development_philosophies |
|
16 http://en.wikipedia.org/wiki/List_of_eponymous_laws |
|
17 |
|
18 Principle of good enough (POGE) |
|
19 =============================== |
|
20 |
|
21 It favours quick-and-simple (but potentially extensible) designs over |
|
22 elaborate systems designed by committees. |
|
23 |
|
24 Once the quick-and-simple design is deployed, it can then evolve as needed, |
|
25 driven by user requirements. |
|
26 |
|
27 This kind of design is not appropriate in systems where it is not possible to |
|
28 evolve the system over time, or where the full functionality is required from |
|
29 the start. |
|
30 |
|
31 See: |
|
32 |
|
33 http://en.wikipedia.org/wiki/Principle_of_good_enough |
|
34 |
|
35 No Silver Bullet |
|
36 ================ |
|
37 |
|
38 There is no single development, in either technology or management technique, |
|
39 which by itself promises even one order of magnitude improvement within a |
|
40 decade in productivity, in reliability, in simplicity. |
|
41 |
|
42 See: |
|
43 |
|
44 http://en.wikipedia.org/wiki/No_Silver_Bullet |
|
45 |
|
46 Rule of thumb |
|
47 ============= |
|
48 |
|
49 A rule of thumb is a principle that postulate in some case use simple |
|
50 procedure wich produce approximate result instead use complex but exact |
|
51 produce. |
|
52 |
|
53 See: |
|
54 |
|
55 http://en.wikipedia.org/wiki/Rule_of_thumb |
|
56 |
|
57 The Zero One or Infinity |
|
58 ======================== |
|
59 |
|
60 The Zero One or Infinity (ZOI) rule is a rule of thumb in software design. It |
|
61 suggests that arbitrary limits on the number of instances of a particular |
|
62 entity should not be allowed. Specifically, that an entity should either be |
|
63 forbidden entirely, one should be allowed, or any number (presumably, to the |
|
64 limit of available storage) of them should be allowed. It should not be the |
|
65 software that puts a hard limit on the number of instances of the entity. |
|
66 |
|
67 http://en.wikipedia.org/wiki/Zero_One_Infinity |
|
68 |
|
69 80-20 rule (pareto principle) |
|
70 ============================= |
|
71 |
|
72 This rule postulate that roughly 80% of the effects come from 20% of the |
|
73 causes. |
|
74 |
|
75 This rule applied to optimisation (most time spent by program only by little |
|
76 piece of code), functionality (80% of users use only 20% of program |
|
77 functionality); bugs (fixing the top 20% of most reported bugs solve 80% of |
|
78 the error and crashes). |
|
79 |
|
80 See: |
|
81 |
|
82 http://en.wikipedia.org/wiki/80:20_rule |
|
83 |
|
84 1% rule |
|
85 ======= |
|
86 |
|
87 The 1% rule states that the number of people who create content on the |
|
88 internet represents approximately 1% (or less) of the people actually viewing |
|
89 that content. |
|
90 |
|
91 See: |
|
92 |
|
93 http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29 |
|
94 |
|
95 Parkinson's Law |
|
96 =============== |
|
97 |
|
98 Work expands so as to fill the time available for its completion. |
|
99 |
|
100 Data expands to fill the space available for storage. |
|
101 |
|
102 See: |
|
103 |
|
104 http://en.wikipedia.org/wiki/Parkinson%27s_law |
|
105 |
|
106 Ninety-ninety rule |
|
107 ================== |
|
108 |
|
109 The first 90% of the code accounts for the first 10% of the development time. |
|
110 The remaining 10% of the code accounts for the other 90% of the development |
|
111 time. |
|
112 |
|
113 See: |
|
114 |
|
115 http://en.wikipedia.org/wiki/Ninety-ninety_rule |
|
116 |
|
117 Wirth's law |
|
118 =========== |
|
119 |
|
120 Software is getting slower more rapidly than hardware becomes faster. |
|
121 |
|
122 See: |
|
123 |
|
124 http://en.wikipedia.org/wiki/Wirth%27s_law |
|
125 |
|
126 Student syndrome |
|
127 ================ |
|
128 |
|
129 Student syndrome refers to the phenomenon that many people will start to fully |
|
130 apply themselves to a task just at the last possible moment before a deadline. |
|
131 |
|
132 The student syndrome is a form of procrastination (). |
|
133 |
|
134 See: |
|
135 |
|
136 http://en.wikipedia.org/wiki/Student_syndrome |
|
137 |
|
138 Conway's Law |
|
139 ============ |
|
140 |
|
141 ...organizations which design systems ... are constrained to produce designs |
|
142 which are copies of the communication structures of these organizations. |
|
143 |
|
144 Example: Consider a two-person team of software engineers, A and B. Say A |
|
145 designs and codes a software class X. Later, the team discovers that class X |
|
146 needs some new features. If A adds the features, A is likely to simply expand X |
|
147 to include the new features. If B adds the new features, B may be afraid of |
|
148 breaking X, and so instead will create a new derived class X2 that inherits X's |
|
149 features, and puts the new features in X2. So the final design is a reflection |
|
150 of who implemented the functionality. |
|
151 |
|
152 A real life example: NASA's Mars Climate Orbiter crashed because one team used |
|
153 United States customary units (e.g., inches, feet and pounds) while the other |
|
154 used metric units for a key spacecraft operation. |
|
155 |
|
156 See: |
|
157 |
|
158 http://en.wikipedia.org/wiki/Conway%27s_Law |
|
159 |
|
160 Brooks's law |
|
161 ============ |
|
162 |
|
163 It takes some time for the people added to a project to become productive. |
|
164 |
|
165 Communication overheads increase as the number of people increases. |
|
166 |
|
167 Adding manpower to a late software project makes it later. |
|
168 |
|
169 See: |
|
170 |
|
171 http://en.wikipedia.org/wiki/Brooks%27_law |
|
172 |
|
173 Code bloat |
|
174 ========== |
|
175 |
|
176 Code bloat is the production of code that is perceived as unnecessarily long, |
|
177 slow, or otherwise wasteful of resources. Code bloat generally refers to |
|
178 source code size but sometimes is used to refer to the generated code size or |
|
179 even the binary file size. |
|
180 |
|
181 http://en.wikipedia.org/wiki/Code_bloat |
|
182 |
|
183 Software bloat |
|
184 ============== |
|
185 |
|
186 Software bloat is a term used to describe the tendency of newer computer |
|
187 programs to have a larger installation footprint, or have many unnecessary |
|
188 features that are not used by end users, or just generally use more system |
|
189 resources than necessary, while offering little or no benefit to its users. |
|
190 |
|
191 |
|
192 Comparison of Microsoft Windows minimum hardware requirements (for 32-bit |
|
193 versions): |
|
194 |
|
195 Windows version Processor Memory Hard disk |
|
196 Windows 95[4] 25 MHz 4 MB ~50 MB |
|
197 Windows 98[5] 66 MHz 16 MB ~200 MB |
|
198 Windows 2000[6] 133 MHz 32 MB 650 MB |
|
199 Windows XP[7] 233 MHz 64 MB 1.5 GB |
|
200 Windows Vista[8] 800 MHz 512 MB 15 GB |
|
201 Windows 7[9] 1 GHz 1 GB 16 GB |
|
202 |
|
203 .. epigraph:: |
|
204 |
|
205 Every program attempts to expand until it can read mail. Those programs which |
|
206 cannot so expand are replaced by ones which can. |
|
207 |
|
208 -- Jamie Zawinski |
|
209 |
|
210 Second-system effect |
|
211 ==================== |
|
212 |
|
213 In computing, the second-system effect or sometimes the second-system syndrome |
|
214 refers to the tendency, when following on from a relatively small, elegant, |
|
215 and successful system, to design the successor as an elephantine, |
|
216 feature-laden monstrosity. The term was first used by Fred Brooks in his |
|
217 classic The Mythical Man-Month.[1] It described the jump from a set of simple |
|
218 operating systems on the IBM 700/7000 series to OS/360 on the 360 series. |
|
219 |
|
220 Inner-platform effect |
|
221 ===================== |
|
222 |
|
223 The inner-platform effect is the tendency of software architects to create a |
|
224 system so customizable as to become a replica, and often a poor replica, of |
|
225 the software development platform they are using. |
|
226 |
|
227 XXX read more http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx |
|
228 |
|
229 http://en.wikipedia.org/wiki/Inner-platform_effect |
|
230 |
|
231 Feature creep |
|
232 ============= |
|
233 |
|
234 Feature creep is the proliferation of features in a product such as computer |
|
235 software. Extra features go beyond the basic function of the product and so |
|
236 can result in baroque over-complication, or "featuritis", rather than simple, |
|
237 elegant design. |
|
238 |
|
239 http://en.wikipedia.org/wiki/Feature_creep |
|
240 |
|
241 Bullet-point engineering |
|
242 ======================== |
|
243 |
|
244 Bullet-point engineering is a software design anti-pattern where developers |
|
245 use the features of competing software packages as checklists of features to |
|
246 implement in their own product. These features are often implemented poorly |
|
247 and haphazardly, without any real design, merely so they can be added to a |
|
248 bulleted list of features in marketing material. Bullet point engineering |
|
249 often leads to feature creep and software bloat but may also simply result in |
|
250 a poorly designed imitative product. |
|
251 |
|
252 http://en.wikipedia.org/wiki/Bullet-point_engineering |
|
253 |
|
254 KISS |
|
255 ==== |
|
256 |
|
257 Keep it simple and stupid, or keep it simple, stupid! |
|
258 |
|
259 Instruction creep and function creep, two instances of creeping featuritis, |
|
260 are examples of failure to follow the KISS principle in software development. |
|
261 |
|
262 http://en.wikipedia.org/wiki/KISS_principle |
|
263 |
|
264 Minimalism |
|
265 ========== |
|
266 |
|
267 In computing, minimalism refers to the application of minimalist philosophies |
|
268 and principles in hardware and software design and usage. |
|
269 |
|
270 http://en.wikipedia.org/wiki/Minimalism_%28computing%29 |
|
271 |
|
272 Unix philosophy |
|
273 =============== |
|
274 |
|
275 .. epigraph:: |
|
276 |
|
277 "Do one thing and do it well." |
|
278 |
|
279 -- Doug McIlroy |
|
280 |
|
281 .. epigraph:: |
|
282 |
|
283 "Write programs that do one thing and do it well. Write programs to work |
|
284 together. Write programs to handle text streams, because that is a universal |
|
285 interface." |
|
286 |
|
287 -- Doug McIlroy |
|
288 |
|
289 .. epigraph:: |
|
290 |
|
291 #. You cannot tell where a program is going to spend its time. Bottlenecks |
|
292 occur in surprising places, so do not try to second guess and put in a speed |
|
293 hack until you've proven that's where the bottleneck is. |
|
294 #. Measure. Do not tune for speed until your performance analysis tool tells |
|
295 you which part of the code overwhelms the rest. |
|
296 #. Fancy algorithms tend to run more slowly on small data sets than simple |
|
297 algorithms. They tend to have a large constant factor in O(n) analysis, and |
|
298 n is usually small. So don't get fancy unless Rule 2 indicates that n is big |
|
299 enough. |
|
300 #. Simplify your algorithms and data structures wherever it makes sense because |
|
301 fancy algorithms are more difficult to implement without defects. The data |
|
302 structures in most programs can be built from array lists, linked lists, |
|
303 hash tables, and binary trees. |
|
304 #. Data dominates. If you have chosen the right data structures and organized |
|
305 things well, the algorithms will almost always be self-evident. Data |
|
306 structures, not algorithms, are central to programming. |
|
307 |
|
308 -- Pike: Notes on Programming in C. |
|
309 |
|
310 .. epigraph:: |
|
311 |
|
312 1. Small is beautiful. |
|
313 2. Make each program do one thing well. |
|
314 3. Build a prototype as soon as possible. |
|
315 4. Choose portability over efficiency. |
|
316 5. Store data in flat text files. |
|
317 6. Use software leverage to your advantage. |
|
318 7. Use shell scripts to increase leverage and portability. |
|
319 8. Avoid captive user interfaces. |
|
320 9. Make every program a filter. |
|
321 |
|
322 -- Mike Gancarz: The UNIX Philosophy |
|
323 |
|
324 With this not all agree: |
|
325 |
|
326 1. Allow the user to tailor the environment. |
|
327 2. Make operating system kernels small and lightweight. |
|
328 3. Use lowercase and keep it short. |
|
329 4. Save trees. |
|
330 5. Silence is golden. |
|
331 6. Think parallel. |
|
332 7. The sum of the parts is greater than the whole. |
|
333 8. Look for the 90-percent solution. |
|
334 9. Worse is better. |
|
335 10. Think hierarchically. |
|
336 |
|
337 |
|
338 ** Misc. |
|
339 |
|
340 "Unix is simple. It just takes a genius to understand its simplicity." |
|
341 -– Dennis Ritchie |
|
342 "Unix never says 'please'." |
|
343 -– Rob Pike |
|
344 |
|
345 http://en.wikipedia.org/wiki/Unix_philosophy |
|
346 |
|
347 Worse is better |
|
348 =============== |
|
349 |
|
350 In the "Worse is better" design style, simplicity of both the interface and |
|
351 the implementation is more important than any other attribute of the system — |
|
352 including correctness, consistency and completeness. |
|
353 |
|
354 Simplicity |
|
355 The design must be simple, both in implementation and interface. It is |
|
356 more important for the implementation to be simpler than the interface. |
|
357 Simplicity is the most important consideration in a design. |
|
358 Correctness |
|
359 The design must be correct in all observable aspects. It is slightly better |
|
360 to be simple than correct. |
|
361 Consistency |
|
362 The design must not be overly inconsistent. Consistency can be sacrificed |
|
363 for simplicity in some cases, but it is better to drop those parts of the |
|
364 design that deal with less common circumstances than to introduce either |
|
365 implementational complexity or inconsistency. |
|
366 Completeness |
|
367 The design must cover as many important situations as is practical. All |
|
368 reasonably expected cases should be covered. Completeness can be sacrificed |
|
369 in favor of any other quality. In fact, completeness must be sacrificed |
|
370 whenever implementation simplicity is jeopardized. Consistency can be |
|
371 sacrificed to achieve completeness if simplicity is retained; especially |
|
372 worthless is consistency of interface. |
|
373 |
|
374 http://dreamsongs.com/WIB.html |
|
375 Lisp: Good News, Bad News, How to Win Big |
|
376 |
|
377 The right thing |
|
378 =============== |
|
379 |
|
380 The MIT approach (known as "The right thing"): |
|
381 |
|
382 Simplicity |
|
383 The design must be simple, both in implementation and interface. It is |
|
384 more important for the interface to be simpler than the implementation. |
|
385 Correctness |
|
386 The design must be correct in all observable aspects. Incorrectness is |
|
387 simply not allowed. |
|
388 Consistency |
|
389 The design must be consistent. A design is allowed to be slightly less |
|
390 simple and less complete to avoid inconsistency. Consistency is as important |
|
391 as correctness. |
|
392 Completeness |
|
393 The design must cover as many important situations as is practical. All |
|
394 reasonably expected cases must be covered. Simplicity is not allowed to |
|
395 overly reduce completeness. |
|
396 |
|
397 http://dreamsongs.com/WIB.html |
|
398 Lisp: Good News, Bad News, How to Win Big |
|
399 |
|
400 YAGNI |
|
401 ===== |
|
402 |
|
403 "You aren't gonna need it" (or YAGNI for short) is the principle in extreme |
|
404 programming that programmers should not add functionality until it is |
|
405 necessary. |
|
406 |
|
407 http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it |
|
408 |
|
409 DRY (DIE) |
|
410 ========= |
|
411 |
|
412 Don't Repeat Yourself (DRY) or Duplication is Evil (DIE). |
|
413 |
|
414 * VCS allow multiple and diverging copies ("branches"). |
|
415 * Source code generation. |
|
416 |
|
417 http://en.wikipedia.org/wiki/Don%27t_repeat_yourself |
|
418 |
|
419 Do it yourself (DIY) |
|
420 ==================== |
|
421 |
|
422 Do it yourself (or DIY) is a term used to describe building, modifying, or |
|
423 repairing of something without the aid of experts or professionals. |
|
424 |
|
425 when tasklist longer then people life mutch easy use already written libraries |
|
426 then wrote own. |
|
427 |
|
428 http://en.wikipedia.org/wiki/Do_it_yourself |
|
429 |
|
430 Once and Only Once (OAOO) |
|
431 ========================= |
|
432 |
|
433 MoSCoW Method |
|
434 ============= |
|
435 |
|
436 The capital letters in MoSCoW stand for: |
|
437 |
|
438 * M - MUST have this (included in the current delivery timebox in order |
|
439 for it to be a success). |
|
440 * S - SHOULD have this if at all possible (critical to the success of the |
|
441 project, but are not necessary for delivery in the current delivery |
|
442 timebox). |
|
443 * C - COULD have this if it does not affect anything else (nice to have). |
|
444 * W - WON'T have this time but WOULD like in the future. |
|
445 |
|
446 http://en.wikipedia.org/wiki/MoSCoW_Method |
|
447 |
|
448 Separation of concerns |
|
449 ====================== |
|
450 |
|
451 In computer science, separation of concerns (SoC) is the process of separating |
|
452 a computer program into distinct features that overlap in functionality as |
|
453 little as possible. A concern is any piece of interest or focus in a program. |
|
454 Typically, concerns are synonymous with features or behaviors. Progress |
|
455 towards SoC is traditionally achieved through modularity of programming and |
|
456 encapsulation (or "transparency" of operation), with the help of information |
|
457 hiding. Layered designs in information systems are also often based on |
|
458 separation of concerns (e.g., presentation layer, business logic layer, data |
|
459 access layer, database layer). |
|
460 |
|
461 HyperText Markup Language (HTML) and cascading style sheets (CSS) are |
|
462 languages intended to separate style from content. |
|
463 |
|
464 http://en.wikipedia.org/wiki/Separation_of_concerns |
|
465 |
|
466 Modular design |
|
467 ============== |
|
468 |
|
469 In systems engineering, modular design — or "modularity in design" — is an |
|
470 approach that subdivides a system into smaller parts (modules) that can be |
|
471 independently created and then used in different systems to drive multiple |
|
472 functionalities. |
|
473 |
|
474 http://en.wikipedia.org/wiki/Modular_design |
|
475 |
|
476 Occam's razor |
|
477 ============= |
|
478 |
|
479 "entia non sunt multiplicanda praeter necessitatem" |
|
480 |
|
481 Entities must not be multiplied beyond necessity. |
|
482 |
|
483 Code and fix |
|
484 ============ |
|
485 |
|
486 Programmers immediately begin producing code. Bugs must be fixed before the |
|
487 product can be shipped. |
|
488 |
|
489 http://en.wikipedia.org/wiki/Code_and_fix |
|
490 |
|
491 Cowboy coding |
|
492 ============= |
|
493 |
|
494 Cowboy coding is a term used to describe software development where the |
|
495 developers have autonomy over the development process. This includes control |
|
496 of the project's schedule, algorithms, tools, and coding style. |
|
497 |
|
498 A cowboy coder can be a lone developer or part of a group of developers with |
|
499 either no external management or management that controls only non-development |
|
500 aspects of the project, such as its nature, scope, and feature set (the |
|
501 "what", but not the "how"). |
|
502 |
|
503 http://en.wikipedia.org/wiki/Cowboy_coding |
|
504 |
|
505 Extreme Programming |
|
506 =================== |
|
507 |
|
508 http://en.wikipedia.org/wiki/Extreme_Programming |
|
509 |
|
510 Hollywood Principle |
|
511 =================== |
|
512 |
|
513 In computer programming, the Hollywood Principle is stated as "don't call us, |
|
514 we'll call you." It has applications in software engineering; see also |
|
515 implicit invocation for a related architectural principle. |
|
516 |
|
517 http://en.wikipedia.org/wiki/Hollywood_Principle |
|
518 |
|
519 Inversion of control |
|
520 ==================== |
|
521 |
|
522 Inversion of control, or IoC, is an abstract principle describing an aspect of |
|
523 some software architecture designs in which the flow of control of a system is |
|
524 inverted in comparison to procedural programming. |
|
525 |
|
526 http://en.wikipedia.org/wiki/Inversion_of_control |
|
527 |
|
528 Literate programming |
|
529 ==================== |
|
530 |
|
531 http://en.wikipedia.org/wiki/Literate_Programming |
|
532 |
|
533 Model-driven architecture |
|
534 ========================= |
|
535 |
|
536 http://en.wikipedia.org/wiki/Model-driven_architecture |
|
537 |
|
538 Quick-and-dirty |
|
539 =============== |
|
540 |
|
541 Quick-and-dirty is a term used in reference to anything that is an easy way to |
|
542 implement a workaround or "kludge." Its usage is popular among programmers, |
|
543 who use it to describe a crude solution or programming implementation that is |
|
544 imperfect, inelegant, or otherwise inadequate, but which solves or masks the |
|
545 problem at hand, and is generally faster and easier to put in place than a |
|
546 proper solution. |
|
547 |
|
548 http://en.wikipedia.org/wiki/Quick-and-dirty |
|
549 |
|
550 Release early, release often |
|
551 ============================ |
|
552 |
|
553 Release early, release often (sometimes abbreviated RERO) is a software |
|
554 development philosophy that emphasizes the importance of early and frequent |
|
555 releases in creating a tight feedback loop between developers and testers or |
|
556 users. |
|
557 |
|
558 http://en.wikipedia.org/wiki/Release_early,_release_often |
|
559 |
|
560 Test-driven development |
|
561 ======================= |
|
562 |
|
563 Test-driven development (TDD) is a software development technique that relies |
|
564 on the repetition of a very short development cycle: First the developer |
|
565 writes a failing automated test case that defines a desired improvement or new |
|
566 function, then produces code to pass that test and finally refactors the new |
|
567 code to acceptable standards. |
|
568 |
|
569 http://en.wikipedia.org/wiki/Test-driven_development |
|
570 |
|
571 Unified Process |
|
572 =============== |
|
573 |
|
574 The Unified Software Development Process or Unified Process is a popular |
|
575 iterative and incremental software development process framework. The |
|
576 best-known and extensively documented refinement of the Unified Process is the |
|
577 Rational Unified Process (RUP). |
|
578 |
|
579 http://en.wikipedia.org/wiki/Unified_Process |
|
580 |
|
581 Waterfall model |
|
582 =============== |
|
583 |
|
584 1. Requirements specification |
|
585 2. Design |
|
586 3. Construction (AKA implementation or coding) |
|
587 4. Integration |
|
588 5. Testing and debugging (AKA Validation) |
|
589 6. Installation |
|
590 7. Maintenance |
|
591 |
|
592 http://en.wikipedia.org/wiki/Waterfall_model |
|
593 |
|
594 * Do it yourself. |