diff -r 1e9323e7ec88 -r 837f1337c59b devel-rules.rst --- 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 +==============