Mercurial Mercurial > tips / diff
summary | shortlog | changelog | graph | tags | bookmarks | branches | files | changeset | file | latest | revisions | annotate | diff | comparison | raw | help
Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
devel-rules.rst
changeset 2228 837f1337c59b
parent 1912 8b81a8f0f692
child 2230 9e6ad6607a9e 
--- a/devel-rules.rst	Sat Feb 10 01:28:53 2018 +0200
+++ b/devel-rules.rst	Sat Feb 10 01:30:24 2018 +0200
@@ -11,8 +11,8 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/List_of_software_development_philosophies
-  http://en.wikipedia.org/wiki/List_of_eponymous_laws
+* http://en.wikipedia.org/wiki/List_of_software_development_philosophies
+* http://en.wikipedia.org/wiki/List_of_eponymous_laws
 
 Principle of good enough (POGE)
 ===============================
@@ -29,7 +29,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Principle_of_good_enough
+* http://en.wikipedia.org/wiki/Principle_of_good_enough
 
 No Silver Bullet
 ================
@@ -40,7 +40,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/No_Silver_Bullet
+* http://en.wikipedia.org/wiki/No_Silver_Bullet
 
 Rule of thumb
 =============
@@ -51,7 +51,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Rule_of_thumb
+* http://en.wikipedia.org/wiki/Rule_of_thumb
 
 The Zero One or Infinity
 ========================
@@ -63,7 +63,7 @@
 limit of available storage) of them should be allowed. It should not be the
 software that puts a hard limit on the number of instances of the entity.
 
-  http://en.wikipedia.org/wiki/Zero_One_Infinity
+* http://en.wikipedia.org/wiki/Zero_One_Infinity
 
 80-20 rule (pareto principle)
 =============================
@@ -78,7 +78,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/80:20_rule
+* http://en.wikipedia.org/wiki/80:20_rule
 
 1% rule
 =======
@@ -89,7 +89,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29
+* http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29
 
 Parkinson's Law
 ===============
@@ -100,7 +100,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Parkinson%27s_law
+* http://en.wikipedia.org/wiki/Parkinson%27s_law
 
 Ninety-ninety rule
 ==================
@@ -111,7 +111,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Ninety-ninety_rule
+* http://en.wikipedia.org/wiki/Ninety-ninety_rule
 
 Wirth's law
 ===========
@@ -120,7 +120,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Wirth%27s_law
+* http://en.wikipedia.org/wiki/Wirth%27s_law
 
 Student syndrome
 ================
@@ -132,7 +132,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Student_syndrome
+* http://en.wikipedia.org/wiki/Student_syndrome
 
 Conway's Law
 ============
@@ -154,7 +154,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Conway%27s_Law
+* http://en.wikipedia.org/wiki/Conway%27s_Law
 
 Brooks's law
 ============
@@ -167,7 +167,7 @@
 
 See:
 
-  http://en.wikipedia.org/wiki/Brooks%27_law
+* http://en.wikipedia.org/wiki/Brooks%27_law
 
 Code bloat
 ==========
@@ -177,7 +177,7 @@
 source code size but sometimes is used to refer to the generated code size or
 even the binary file size.
 
-  http://en.wikipedia.org/wiki/Code_bloat
+* http://en.wikipedia.org/wiki/Code_bloat
 
 Software bloat
 ==============
@@ -225,7 +225,7 @@
 
 XXX read more http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx
 
-  http://en.wikipedia.org/wiki/Inner-platform_effect
+* http://en.wikipedia.org/wiki/Inner-platform_effect
 
 Feature creep
 =============
@@ -235,7 +235,7 @@
 can result in baroque over-complication, or "featuritis", rather than simple,
 elegant design.
 
-  http://en.wikipedia.org/wiki/Feature_creep
+* http://en.wikipedia.org/wiki/Feature_creep
 
 Bullet-point engineering
 ========================
@@ -248,7 +248,7 @@
 often leads to feature creep and software bloat but may also simply result in
 a poorly designed imitative product.
 
-  http://en.wikipedia.org/wiki/Bullet-point_engineering
+* http://en.wikipedia.org/wiki/Bullet-point_engineering
 
 KISS
 ====
@@ -258,7 +258,7 @@
 Instruction creep and function creep, two instances of creeping featuritis,
 are examples of failure to follow the KISS principle in software development.
 
-  http://en.wikipedia.org/wiki/KISS_principle
+* http://en.wikipedia.org/wiki/KISS_principle
 
 Minimalism
 ==========
@@ -266,7 +266,7 @@
 In computing, minimalism refers to the application of minimalist philosophies
 and principles in hardware and software design and usage.
 
-  http://en.wikipedia.org/wiki/Minimalism_%28computing%29
+* http://en.wikipedia.org/wiki/Minimalism_%28computing%29
 
 Unix philosophy
 ===============
@@ -322,26 +322,27 @@
 
 With this not all agree:
 
- 1. Allow the user to tailor the environment.
- 2. Make operating system kernels small and lightweight.
- 3. Use lowercase and keep it short.
- 4. Save trees.
- 5. Silence is golden.
- 6. Think parallel.
- 7. The sum of the parts is greater than the whole.
- 8. Look for the 90-percent solution.
- 9. Worse is better.
- 10. Think hierarchically.
+1. Allow the user to tailor the environment.
+2. Make operating system kernels small and lightweight.
+3. Use lowercase and keep it short.
+4. Save trees.
+5. Silence is golden.
+6. Think parallel.
+7. The sum of the parts is greater than the whole.
+8. Look for the 90-percent solution.
+9. Worse is better.
+10. Think hierarchically.
 
 
-** Misc.
+Misc
+====
 
 "Unix is simple. It just takes a genius to understand its simplicity."
-                              -– Dennis Ritchie
+  -– Dennis Ritchie
 "Unix never says 'please'."
-                              -– Rob Pike
+  -– Rob Pike
 
-  http://en.wikipedia.org/wiki/Unix_philosophy
+* http://en.wikipedia.org/wiki/Unix_philosophy
 
 Worse is better
 ===============
@@ -370,8 +371,8 @@
   sacrificed to achieve completeness if simplicity is retained; especially
   worthless is consistency of interface.
 
-  http://dreamsongs.com/WIB.html
-                Lisp: Good News, Bad News, How to Win Big
+http://dreamsongs.com/WIB.html
+  Lisp: Good News, Bad News, How to Win Big
 
 The right thing
 ===============
@@ -393,8 +394,10 @@
   reasonably expected cases must be covered. Simplicity is not allowed to
   overly reduce completeness.
 
-  http://dreamsongs.com/WIB.html
-                Lisp: Good News, Bad News, How to Win Big
+See:
+
+http://dreamsongs.com/WIB.html
+  Lisp: Good News, Bad News, How to Win Big
 
 YAGNI
 =====
@@ -403,17 +406,17 @@
 programming that programmers should not add functionality until it is
 necessary.
 
-  http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
+* http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
 
 DRY (DIE)
 =========
 
 Don't Repeat Yourself (DRY) or Duplication is Evil (DIE).
 
- * VCS allow multiple and diverging copies ("branches").
- * Source code generation.
+* VCS allow multiple and diverging copies ("branches").
+* Source code generation.
 
-  http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
+* http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
 
 Do it yourself (DIY)
 ====================
@@ -424,7 +427,7 @@
 when tasklist longer then people life mutch easy use already written libraries
 then wrote own.
 
-  http://en.wikipedia.org/wiki/Do_it_yourself
+* http://en.wikipedia.org/wiki/Do_it_yourself
 
 Once and Only Once (OAOO)
 =========================
@@ -434,15 +437,17 @@
 
 The capital letters in MoSCoW stand for:
 
- * M - MUST have this (included in the current delivery timebox in order
-   for it to be a success).
- * S - SHOULD have this if at all possible (critical to the success of the
-   project, but are not necessary for delivery in the current delivery
-   timebox).
- * C - COULD have this if it does not affect anything else (nice to have).
- * W - WON'T have this time but WOULD like in the future.
+* M - MUST have this (included in the current delivery timebox in order
+  for it to be a success).
+* S - SHOULD have this if at all possible (critical to the success of the
+  project, but are not necessary for delivery in the current delivery
+  timebox).
+* C - COULD have this if it does not affect anything else (nice to have).
+* W - WON'T have this time but WOULD like in the future.
 
-  http://en.wikipedia.org/wiki/MoSCoW_Method
+See:
+
+* http://en.wikipedia.org/wiki/MoSCoW_Method
 
 Separation of concerns
 ======================
@@ -460,7 +465,7 @@
 HyperText Markup Language (HTML) and cascading style sheets (CSS) are
 languages intended to separate style from content.
 
-  http://en.wikipedia.org/wiki/Separation_of_concerns
+* http://en.wikipedia.org/wiki/Separation_of_concerns
 
 Modular design
 ==============
@@ -470,7 +475,7 @@
 independently created and then used in different systems to drive multiple
 functionalities.
 
-  http://en.wikipedia.org/wiki/Modular_design
+* http://en.wikipedia.org/wiki/Modular_design
 
 Occam's razor
 =============
@@ -485,7 +490,7 @@
 Programmers immediately begin producing code. Bugs must be fixed before the
 product can be shipped.
 
-  http://en.wikipedia.org/wiki/Code_and_fix
+* http://en.wikipedia.org/wiki/Code_and_fix
 
 Cowboy coding
 =============
@@ -499,12 +504,12 @@
 aspects of the project, such as its nature, scope, and feature set (the
 "what", but not the "how").
 
-  http://en.wikipedia.org/wiki/Cowboy_coding
+* http://en.wikipedia.org/wiki/Cowboy_coding
 
 Extreme Programming
 ===================
 
-  http://en.wikipedia.org/wiki/Extreme_Programming
+* http://en.wikipedia.org/wiki/Extreme_Programming
 
 Hollywood Principle
 ===================
@@ -513,7 +518,7 @@
 we'll call you." It has applications in software engineering; see also
 implicit invocation for a related architectural principle.
 
-  http://en.wikipedia.org/wiki/Hollywood_Principle
+* http://en.wikipedia.org/wiki/Hollywood_Principle
 
 Inversion of control
 ====================
@@ -522,17 +527,17 @@
 some software architecture designs in which the flow of control of a system is
 inverted in comparison to procedural programming.
 
-  http://en.wikipedia.org/wiki/Inversion_of_control
+* http://en.wikipedia.org/wiki/Inversion_of_control
 
 Literate programming
 ====================
 
-  http://en.wikipedia.org/wiki/Literate_Programming
+* http://en.wikipedia.org/wiki/Literate_Programming
 
 Model-driven architecture
 =========================
 
-  http://en.wikipedia.org/wiki/Model-driven_architecture
+* http://en.wikipedia.org/wiki/Model-driven_architecture
 
 Quick-and-dirty
 ===============
@@ -544,7 +549,7 @@
 problem at hand, and is generally faster and easier to put in place than a
 proper solution.
 
-  http://en.wikipedia.org/wiki/Quick-and-dirty
+* http://en.wikipedia.org/wiki/Quick-and-dirty
 
 Release early, release often
 ============================
@@ -554,7 +559,7 @@
 releases in creating a tight feedback loop between developers and testers or
 users.
 
-  http://en.wikipedia.org/wiki/Release_early,_release_often
+* http://en.wikipedia.org/wiki/Release_early,_release_often
 
 Test-driven development
 =======================
@@ -565,7 +570,7 @@
 function, then produces code to pass that test and finally refactors the new
 code to acceptable standards.
 
-  http://en.wikipedia.org/wiki/Test-driven_development
+* http://en.wikipedia.org/wiki/Test-driven_development
 
 Unified Process
 ===============
@@ -575,19 +580,20 @@
 best-known and extensively documented refinement of the Unified Process is the
 Rational Unified Process (RUP).
 
-  http://en.wikipedia.org/wiki/Unified_Process
+* http://en.wikipedia.org/wiki/Unified_Process
 
 Waterfall model
 ===============
 
-   1. Requirements specification
-   2. Design
-   3. Construction (AKA implementation or coding)
-   4. Integration
-   5. Testing and debugging (AKA Validation)
-   6. Installation
-   7. Maintenance
+1. Requirements specification
+2. Design
+3. Construction (AKA implementation or coding)
+4. Integration
+5. Testing and debugging (AKA Validation)
+6. Installation
+7. Maintenance
 
-  http://en.wikipedia.org/wiki/Waterfall_model
+* http://en.wikipedia.org/wiki/Waterfall_model
 
-* Do it yourself.
+Do it yourself
+==============
tips