Translate fr.md via GitLocalize

Turkish Translation Update

.github/contributing.md

@@ -1,6 +1,5 @@
 # Contributing Guidelines
 
-
 <!-- vim-markdown-toc GFM -->
 
 * [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
@@ -25,6 +24,7 @@ Some other tips:
 - Be careful not to copy-and-paste content (unless it is explicitly quoted), as it might violate copyright.
 - Include hyperlinks to referenced material.
 - Do not advocate for the law, or aim to be opinionated on the correctness or incorrectness of the law, as this repository is simply the descriptions and links.
+- Avoid 'you' when writing. For example, prefer "This law suggests refactoring should be avoided when..." rather than "you should avoid refactoring when...". This keeps the style slightly more formal and avoids seeming like advocation of a law.
 
 An example law is shown below, which covers most of the key points:
 

.github/pull_request_template.md

@@ -2,7 +2,7 @@
 
 Please double check the items below!
 
-- [ ] I have read the [Contributor Guidelines](./.github/contributing.md).
+- [ ] I have read the [Contributor Guidelines](https://github.com/dwmkerr/hacker-laws/blob/master/.github/contributing.md).
 - [ ] I have not directly copied text from another location (unless explicitly indicated as a quote) or violated copyright.
 - [ ] I have linked to the original Law.
 - [ ] I have quote the law (if possible) and the author's name (if possible).

LICENSE

@@ -1,21 +1,173 @@
-MIT License
+Copyright (c) Dave Kerr 2019
 
-Copyright (c) 2018 Dave Kerr
+# Attribution-ShareAlike 4.0 International
 
-Permission is hereby granted, free of charge, to any person obtaining a copy
+Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
 
-The above copyright notice and this permission notice shall be included in all
+### Using Creative Commons Public Licenses
-copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+* __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors).
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+* __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees).
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+
-SOFTWARE.
+## Creative Commons Attribution-ShareAlike 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
+
+### Section 1 – Definitions.
+
+a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
+
+b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
+
+c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License.
+
+d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
+
+e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
+
+f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
+
+g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
+
+h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
+
+i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
+
+j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License.
+
+k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
+
+l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
+
+m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
+
+### Section 2 – Scope.
+
+a. ___License grant.___
+
+   1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
+
+       A. reproduce and Share the Licensed Material, in whole or in part; and
+
+       B. produce, reproduce, and Share Adapted Material.
+
+   2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
+
+   3. __Term.__ The term of this Public License is specified in Section 6(a).
+
+   4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
+
+   5. __Downstream recipients.__
+
+       A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
+
+       B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
+
+       C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
+
+   6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
+
+b. ___Other rights.___
+
+   1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
+
+   2. Patent and trademark rights are not licensed under this Public License.
+
+   3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
+
+### Section 3 – License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the following conditions.
+
+a. ___Attribution.___
+
+   1. If You Share the Licensed Material (including in modified form), You must:
+
+       A. retain the following if it is supplied by the Licensor with the Licensed Material:
+
+         i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
+
+         ii. a copyright notice;
+
+         iii. a notice that refers to this Public License;
+
+         iv. a notice that refers to the disclaimer of warranties;
+
+         v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
+
+       B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
+
+       C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
+
+   2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
+
+   3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
+
+b. ___ShareAlike.___
+
+In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
+
+1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
+
+2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
+
+3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
+
+### Section 4 – Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
+
+a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
+
+b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
+
+c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
+
+### Section 5 – Disclaimer of Warranties and Limitation of Liability.
+
+a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__
+
+b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__
+
+c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
+
+### Section 6 – Term and Termination.
+
+a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
+
+b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
+
+   1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
+
+   2. upon express reinstatement by the Licensor.
+
+   For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
+
+c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
+
+d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
+
+### Section 7 – Other Terms and Conditions.
+
+a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
+
+b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
+
+### Section 8 – Interpretation.
+
+a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
+
+b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
+
+c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
+
+d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
+
+> Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
+>
+> Creative Commons may be contacted at creativecommons.org.

README.md

@@ -2,15 +2,9 @@
 
 Laws, Theories, Principles and Patterns that developers will find useful.
 
-- 🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)!
+[Translations](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translationis/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr)
-- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)!
-- 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)!
-- 🇷🇺 [Русская версия / Russian Version](https://github.com/solarrust/hacker-laws) - thanks [Alena Batitskaya](https://github.com/solarrust)!
-- 🇹🇷 [Türkçe / Turkish Version](https://github.com/umutphp/hacker-laws-tr) - thanks [Umut Işık](https://github.com/umutphp)
-- 🇧🇷 [Brasileiro / Brazilian Version](./translations/pt-BR.md) - thanks [Leonardo Costa](https://github.com/LeoFC97)
-- 🇪🇸 [Castellano / Spanish Version](./translations/es-ES.md) - thanks [Manuel Rubio](https://github.com/manuel-rubio)
 
-Like this project? Please considering [Sponsoring Me](https://github.com/sponsors/dwmkerr)!
+Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations).
 
 ---
 
@@ -19,6 +13,7 @@ Like this project? Please considering [Sponsoring Me](https://github.com/sponsor
 * [Introduction](#introduction)
 * [Laws](#laws)
     * [Amdahl's Law](#amdahls-law)
+    * [The Broken Windows Theory](#the-broken-windows-theory)
     * [Brooks' Law](#brooks-law)
     * [Conway's Law](#conways-law)
     * [Cunningham's Law](#cunninghams-law)
@@ -30,9 +25,11 @@ Like this project? Please considering [Sponsoring Me](https://github.com/sponsor
     * [Hutber's Law](#hutbers-law)
     * [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
     * [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
+    * [Kernighan's Law](#kernighans-law)
     * [Metcalfe's Law](#metcalfes-law)
     * [Moore's Law](#moores-law)
     * [Murphy's Law / Sod's Law](#murphys-law--sods-law)
+    * [Occam's Razor](#occams-razor)
     * [Parkinson's Law](#parkinsons-law)
     * [Premature Optimization Effect](#premature-optimization-effect)
     * [Putt's Law](#putts-law)
@@ -60,6 +57,9 @@ Like this project? Please considering [Sponsoring Me](https://github.com/sponsor
     * [YAGNI](#yagni)
     * [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
 * [Reading List](#reading-list)
+* [Translations](#translations)
+* [Related Projects](#related-projects)
+* [Contributing](#contributing)
 * [TODO](#todo)
 
 <!-- vim-markdown-toc -->
@@ -84,7 +84,7 @@ Best illustrated with an example. If a program is made up of two parts, part A,
 
 The diagram below shows some examples of potential improvements in speed:
 
-![Diagram: Amdahl's Law](./images/amdahls_law.png)
+<img width="480px" alt="Diagram: Amdahl's Law" src="./images/amdahls_law.png" />
 
 *(Image Reference: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
 
@@ -97,6 +97,24 @@ See also:
 - [Brooks' Law](#brooks-law)
 - [Moore's Law](#moores-law)
 
+### The Broken Windows Theory
+
+[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+The Broken Windows Theory suggests that visible signs of crime (or lack of care of an environment) lead to further and more serious crimes (or further deterioration of the environment).
+
+This theory has been applied to software development, suggesting that poor quality code (or [Technical Debt](#TODO)) can lead to a perception that efforts to improve quality may be ignored or undervalued, thus leading to further poor quality code. This effect cascades leading to a great decrease in quality over time.
+
+See also:
+
+- [Technical Debt](#TODO)
+
+Examples:
+
+- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
+- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
 ### Brooks' Law
 
 [Brooks' Law on Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
@@ -158,7 +176,7 @@ See also:
 
 Gall's Law implies that attempts to _design_ highly complex systems are likely to fail. Highly complex systems are rarely built in one go, but evolve instead from more simple systems.
 
-The classic example is the world-wide-web. In it's current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time.
+The classic example is the world-wide-web. In its current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time.
 
 See also:
 
@@ -181,7 +199,7 @@ Also commonly referenced as:
 The law states that the measure-driven optimizations could lead to devaluation of the measurement outcome itself. Overly selective set of measures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) blindly applied to a process results in distorted effect. People tend to optimize locally by "gaming" the system in order to satisfy particular metrics instead of paying attention to holistic outcome of their actions.
 
 Real-world examples:
-- Assert-free tests satisfy the code coverage expectation, despite the metric intent was to create well-tested software.
+- Assert-free tests satisfy the code coverage expectation, despite the fact that the metric intent was to create well-tested software.
 - Developer performance score indicated by the number of lines committed leads to unjustifiably bloated codebase.
 
 See also:
@@ -260,6 +278,23 @@ See also:
 - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
 - [XKCD 1172](https://xkcd.com/1172/)
 
+### Kernighan's Law
+
+> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
+>
+> (Brian Kernighan)
+
+Kernighan's Law is named for [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) and derived from a quote from Kernighan and Plauger's book [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+
+> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
+
+While hyperbolic, Kernighan's Law makes the argument that simple code is to be preferred over complex code, because debugging any issues that arise in complex code may be costly or even infeasible.
+
+See also:
+
+- [The KISS Principle](#the-kiss-principle)
+- [The Unix Philosophy](#the-unix-philosophy)
+- [Occam's Razor](#occams-razor)
 
 ### Metcalfe's Law
 
@@ -300,6 +335,25 @@ See Also:
 - [Confirmation Bias](#TODO)
 - [Selection Bias](#TODO)
 
+### Occam's Razor
+
+[Occam's Razor on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Entities should not be multiplied without necessity.
+>
+> William of Ockham
+
+Occam's razor says that among several possible solutions, the most likely solution is the one with the least number of concepts and assumptions. This solution is the simplest and solves only the given problem, without introducing accidental complexity and possible negative consequences.
+
+See also:
+
+- [YAGNI](#yagni)
+- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Example:
+
+- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
 ### Parkinson's Law
 
 [Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law)
@@ -400,7 +454,7 @@ This law suggests that groups will give far more time and attention to trivial o
 
 The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself. It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input. Hence a tendency to focus too much time on small details, which can be reasoned about easily, but are not necessarily of particular importance.
 
-The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details. An alternative term is 'Yak Shaving'.
+The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details. A related term is '[Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving),' which connotes a seemingly irrelevant activity that is part of a long chain of prerequisites to the main task.
 
 ### The Unix Philosophy
 
@@ -484,7 +538,7 @@ The Pareto Principle suggests that in some cases, the majority of results come f
 
 In the 1940s American-Romanian engineer Dr. Joseph Juran, who is widely credited with being the father of quality control, [began to apply the Pareto principle to quality issues](https://en.wikipedia.org/wiki/Joseph_M._Juran).
 
-This principle is also known as: The 80/20 Rule, The Law of the Vital Few and The Principle of Factor Sparsity.
+This principle is also known as: The 80/20 Rule, The Law of the Vital Few, and The Principle of Factor Sparsity.
 
 Real-world examples:
 
@@ -513,10 +567,17 @@ See Also:
 
 > Be conservative in what you do, be liberal in what you accept from others.
 
-Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed.
+Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should aim to allow non-conformant input if it can be processed.
 
 The goal of this principle is to build systems which are robust, as they can handle poorly formed input if the intent can still be understood. However, there are potentially security implications of accepting malformed input, particularly if the processing of such input is not well tested.
 
+Allowing non-conformant input, in time, may undermine the ability of protocols to evolve as implementors will eventually rely on this liberality to build their features.
+
+See Also:
+
+- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
+
+
 ### SOLID
 
 This is an acronym, which refers to:
@@ -552,7 +613,7 @@ See also:
 
 The second of the '[SOLID](#solid)' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour _extended_, but that their _existing_ behaviour should not be able to be modified.
 
-As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that how existing Markdown features are handled, then it would be _closed_ for modification.
+As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed Markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that now existing Markdown features are handled, then it would be _closed_ for modification.
 
 This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behaviour changed in unexpected ways.
 
@@ -666,7 +727,7 @@ See also:
 
 ### The Fallacies of Distributed Computing
 
-[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/You_aren%https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
 
 Also known as _Fallacies of Networked Computing_, the Fallacies are a list of conjectures (or beliefs) about distributed computing, which can lead to failures in software development. The assumptions are:
 
@@ -701,6 +762,36 @@ If you have found these concepts interesting, you may enjoy the following books.
 - [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - A comic look at corporate America, from the author who created the [Dilbert Principle](#the-dilbert-principle).
 - [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
 
+## Translations
+
+Thanks to a number of wonderful contributors, Hacker Laws is available in a number of languages. Please consider sponsoring moderators!
+
+| Language | Moderator | Status |
+|----------|-----------|--------|
+| [🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) |
+| [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partially complete |
+| [🇩🇪 Deutsch / German](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge) |
+| [🇫🇷 Français / French](./translationis/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge) |
+| [🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge) |
+| [🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partially complete |
+| [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partially complete |
+| [🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge) |
+| [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partially complete |
+| [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partially complete |
+| [🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge) |
+
+If you would like to update a translation, just [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls). If you want to add a new language, log onto [GitLocalize](https://gitlocalize.com/) to create an account, then open an issue asking to administer the language and I will add you to the project! It would also be super helpful if you can open a pull request which updates the table above and link at the top of the file.
+
+## Related Projects
+
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receive a daily hacker law/principle.
+
+## Contributing
+
+Please do contribute! [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new) if you'd like to suggest an addition or change, or [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) to propose your own changes.
+
+Please be sure to read the [Contributing Guidelines](./.github/contributing.md) for requirements on text, style and so on. Please be aware of the [Code of Conduct](./.github/CODE_OF_CONDUCT.md) when engaging in discussions on the project.
+
 ## TODO
 
 Hi! If you land here, you've clicked on a link to a topic I've not written up yet, sorry about this - this is work in progress!

translations/fr.md

@@ -0,0 +1,779 @@
+# 💻📖 hacker-laws
+
+Lois, théories, principes et modèles que les développeurs trouveront utiles.
+
+[Traductions](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translationis/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr)
+
+Vous aimez ce projet ? N'hésitez pas à [me sponsoriser](https://github.com/sponsors/dwmkerr) ainsi que [les traducteurs](#traductions).
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+- [Introduction](#introduction)
+- [Lois](#lois)
+    - [Loi d'Amdahl](#loi-damdahl)
+    - [Théorie de la vitre brisée](#theorie-de-la-vitre-brisee)
+    - [Loi de Brooks](#loi-de-brooks)
+    - [Loi de Conway](#loi-de-conway)
+    - [Loi de Cunningham](#loi-de-cunningham)
+    - [Nombre de Dunbar](#nombre-de-dunbar)
+    - [Loi de Gall](#loi-de-gall)
+    - [Loi de Goodhart](#loi-de-goodhart)
+    - [Rasoir de Hanlon](#rasoir-de-hanlon)
+    - [Loi de Hofstadter](#loi-de-hofstadter)
+    - [Loi de Hutber](#loi-de-hutber)
+    - [Cycle du hype & Loi d'Amara](#cycle-de-hype--loi-damara)
+    - [Loi d'Hyrum (loi des interfaces implicites)](#loi-dhyrum)
+    - [Loi de Kernighan](#loi-de-kernighan)
+    - [Loi de Metcalfe](#loi-de-metcalfe)
+    - [Loi de Moore](#loi-de-moore)
+    - [Loi de Murphy / Loi de Sod](#loi-de-murphy--loi-de-sod)
+    - [Rasoir d'Occam](#rasoir-doccam)
+    - [Loi de Parkinson](#loi-de-parkinson)
+    - [Effet d'optimisation prématurée](#effet-doptimisation-prematuree)
+    - [Loi de Putt](#loi-de-putt)
+    - [Loi de Reed](#loi-de-reed)
+    - [Loi de la conservation de la complexité (Loi de Tesler)](#loi-de-tesler)
+    - [Loi des abstractions qui fuient](#loi-des-abstractions-qui-fuient)
+    - [Loi de futilité](#loi-de-futilite)
+    - [Philosophie d'Unix](#philosophie-dunix)
+    - [Modèle de Spotify](#modele-de-spotify)
+    - [Loi de Wadler](#loi-de-wadler)
+    - [Loi de Wheaton](#loi-de-wheaton)
+- [Principes](#principes)
+    - [Principe de Dilbert](#principe-de-dilbert)
+    - [Principe de Pareto (Regle des 80/20)](#principe-de-pareto-regle-des-8020)
+    - [Principe de Peter](#principe-de-peter)
+    - [Principe de robustesse (loi de Postel)](#principe-de-robustesse-loi-de-postel)
+    - [SOLID](#solid)
+    - [Principe de responsabilité unique](#principe-de-responsabilite-unique)
+    - [Principe ouvert/fermé](#principe-ouvertferme)
+    - [Principe de substitution de Liskov](#principe-de-substitution-de-liskov)
+    - [Principe de ségrégation des interfaces](#principe-de-segregation-des-interfaces)
+    - [Principe d'inversion des dépendances](#principe-dinversion-des-dependances)
+    - [Principe DRY](#principe-dry)
+    - [Principe KISS](#principe-kiss)
+    - [YAGNI](#yagni)
+    - [Illusions de l'informatique distribuée](#illusions-de-linformatique-distribuee)
+- [À lire](#a-lire)
+- [Traductions](#traductions)
+- [Projets liés](#projets-lies)
+- [Contribuer](#contribuer)
+- [TODO](#todo)
+
+<!-- vim-markdown-toc -->
+
+## Introduction
+
+Il y a beaucoup de "lois" dont les gens parlent quand on discute de développement. Ce repository offre une vue d'ensemble et une référence des plus communes. N'hésitez pas à partager et à proposer vos PRs !
+
+❗: Ce repo ne *préconise* aucune des lois, principes ou modèles qui y sont expliqués. Leur application devrait toujours être le sujet d'un débat, et dépend grandement de ce sur quoi vous travaillez.
+
+## Lois
+
+Nous y voila !
+
+### Loi d'Amdahl
+
+[Loi d'Amdahl sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_d%27Amdahl)
+
+> La loi d'Amdahl est une formule qui montre le *gain de vitesse potentiel* sur un calcul, obtenu en augmentant les ressources d'un système. Habituellement utilisé en calcul parallèle, elle peut prédire les bénéfices réels de l'accroissement du nombre de processeurs. Bénéfices qui sont limités par le potentiel du programme à être parallélisé.
+
+Prenons un exemple: si un programme est composé de 2 parties, la partie A devant être exécuté par un seul processeur et la partie B pouvant être parallélisée, alors on peut constater qu'ajouter plusieurs processeurs au système executant le programme ne peut avoir qu'un bénéfice limité. Cela peut potentiellement améliorer grandement la vitesse de la partie B, mais la vitesse de la partie A restera inchangée.
+
+Le diagramme ci-dessous montre quelques exemples de gain de vitesse potentiels :
+
+<img width="480px" alt="Diagram: Amdahl's Law" src="../images/amdahls_law.png">
+
+*(Reference: par Daniels220 sur English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Comme il est visible, un programme qui est parallélisable à 50% ne bénéficiera que très peu au delà des 10 processeurs, tandis qu'un programme parallélisable à 95% peut encore gagner en vitesse avec plus d'un millier de processeurs.
+
+À mesure que la [loi de Moore](#loi-de-moore) ralenti et que l'accélération de la vitesse de calcul des processeurs diminue, la parallélisation est la clef de l'amélioration des performances. Prenons par exemple la programmation graphique avec les calculs de Shader: chaque pixel ou fragment peut être rendu en parallèle. Ce qui explique que les cartes graphiques récentes ont souvent plusieurs milliers de coeurs de calcul (GPUs ou Shader Units).
+
+Voir aussi:
+
+- [Loi de Brooks](#loi-de-brooks)
+- [Loi de Moore](#loi-de-moore)
+
+### Théorie de la vitre brisée
+
+[Théorie de la vitre brisée sur Wikipedia](https://fr.wikipedia.org/wiki/Hypoth%C3%A8se_de_la_vitre_bris%C3%A9e)
+
+La théorie de la vitre brisée suggère que des signes visibles de criminalité (ou de manque de soin d'un environnement) amène à des crimes plus nombreux et plus sérieux (ou une plus grande détérioration de l'environnement).
+
+Cette théorie est aussi appliqué au développement logiciel pour suggérer que du code de mauvaise qualité (ou de la [dette technique](#TODO)) peut amener à penser que les efforts fait pour améliorer le code ne sont pas valorisés, voir complètement ignorés. Menant ainsi à une plus grande détérioration de la qualité du code au fil du temps.
+
+Voir aussi:
+
+- [Dette technique](#TODO)
+
+Exemples:
+
+- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
+- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
+### Loi de Brooks
+
+[Loi de Brooks sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Brooks)
+
+> Ajouter des personnes à un projet en retard accroît son retard.
+
+Cette loi suggère que dans beaucoup de cas, tenter d'accélérer le bouclage d'un projet qui est en retard en ajoutant plus de personnes dessus rendra le projet encore plus en retard. Brooks est clair sur le fait qu'il s'agit d'une grande simplification, mais le raisonnement général est que la vitesse d'avancement du projet sur le court terme diminue à cause du temps nécessaire à l'intégration des nouveaux arrivants et du surplus de communication nécessaire. De plus, de nombreuses tâches peuvent ne pas être divisibles, comprendre réparties entre plusieurs personnes. Ce qui abaisse encore le potentiel d'augmentation de la vitesse d'avancement du projet.
+
+La phrase bien connue "Neuf femmes ne peuvent pas faire un bébé en un mois" illustre la loi de Brooks, en particulier le fait que certaines tâches ne sont pas divisibles ou parallélisables.
+
+C'est un thème central du livre '[The Mythical Man Month](#reading-list)'.
+
+Voir aussi:
+
+- [Death March](#todo)
+- [Reading List: The Mythical Man Month](#reading-list)
+
+### Loi de Conway
+
+[Loi de Conway sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Conway)
+
+Cette loi suggère que les contours techniques d'un système reflètent la structure de l'organisation qui a produit le système. Cette loi est souvent évoquée quand on cherche à améliorer l'organisation en question. Si une organisation est structurée en plusieurs unités déconnectées, le logiciel qui est produit le sera aussi. Si une organisation est composée de silos verticaux orientés autour de fonctionnalités ou services, le logiciel le reflètera aussi.
+
+Voir aussi:
+
+- [Modèle de Spotify](#modele-de-spotify)
+
+### Loi de Cunningham
+
+[Loi de Cunningham sur Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> Le meilleur moyen d'obtenir une bonne réponse sur Internet n'est pas de poser la question, mais de poster la mauvaise réponse.
+
+Selon Steven McGeady, Ward Cunningham lui aurait conseillé au début des années 1980: "le meilleur moyen d'obtenir une bonne réponse sur Internet n'est pas de poser la question, mais de poster la mauvaise réponse." McGeady baptisa cette phrase la loi de Cunningham, bien que Cunningham lui même en réfute la parenté. Faisant initialement référence aux interactions sur Usenet, cette loi a été utilisé pour décrire le fonctionnement d'autres communautés en ligne (Wikipedia, Reddit, Twitter, Facebook).
+
+Voir aussi:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
+### Nombre de Dunbar
+
+[Nombre de Dunbar sur Wikipedia](https://fr.wikipedia.org/wiki/Nombre_de_Dunbar)
+
+"Le nombre de Dunbar est le nombre maximum d'individus avec lesquels une personne peut entretenir simultanément une relation humaine stable." À savoir une relation dans laquelle un individu sait qui est chaque personne et comment elle est liée aux autres personnes. Il n'y a pas de véritable consensus sur le nombre exact. "... [Dunbar] avance que les êtres humains peuvent maintenir confortablement seulement 150 relations stables". Il place le nombre dans un contexte social: "le nombre de personnes envers lesquelles vous ne vous sentiriez pas embarrassé de partager un verre si vous les croisiez par hasard dans un bar". Les estimations du nombre tombent généralement entre 100 et 250.
+
+De même que les relations stables entre individus, la relation entre un développeur et une codebase requiert des efforts pour être maintenu. Lorsque nous faisons face à de larges projets compliqués ou nombreux, nous pouvons nous aider de conventions, de procédures ou de modèles. Le nombre de Dunbar est important à garder à l'esprit non seulement lorsque la taille d'une entreprise augmente mais aussi lorsqu'on décide de la portée des efforts à réaliser pour une équipe. Pris dans un contexte d'ingénierie, il représente le nombre de projets sur lesquels on pourrait sereinement faire du support si on y était amené.
+
+Voir aussi :
+
+- [Loi de Conway](#loi-de-conway)
+
+### Loi de Gall
+
+[Loi de Gall sur Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Un système complexe qui fonctionne est une évolution d'un système simple qui fonctionne. Un système complexe entièrement conçu depuis zero ne fonctionne jamais et ne peut pas être modifié pour le faire fonctionner. Il faut recommencer avec un système simple qui fonctionne.
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+La loi de Gall implique que les tentatives de *concevoir* un système fortement complexe ont de grandes chances d'échouer. Les systèmes fortement complexes sont rarement construits d'un seul coup, mais évoluent plutôt depuis des systèmes plus simples.
+
+Un exemple classique est le world-wide-web. Dans son état actuel, il s'agit d'un système fortement complexe. Cependant, il était initialement définit comme un simple moyen d'échanger du contenu entre établissements universitaires. Ayant atteint cet objectif avec un grand succès, le système a évolué pour devenir de plus en plus complexe au fil du temps.
+
+Voir aussi :
+
+- [KISS (Keep It Simple, Stupid)](#principe-kiss)
+
+### Loi de Goodhart
+
+[Loi de Goodhart sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Goodhart)
+
+> Toute régularité statistique observée a tendance à perdre de sa fiabilité lorsque on tente de la contrôler.
+> *Charles Goodhart*
+
+Souvent aussi énoncée de cette manière :
+
+> Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.
+> *Marilyn Strathern*
+
+Cette loi indique que les optimisations basées sur une mesure peuvent amener à une perte de valeur de la mesure elle même. Un ensemble de mesures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) trop restraint appliqué aveuglément à un process déforme le résultat. Les gens tendent à "tricher" localement pour satisfaire une mesure en particulier sans faire attention aux effect globaux de leurs actions sur le système.
+
+Exemples concrets :
+
+- Il est possible d'atteindre un taux de couverture du code arbitraire en rédigeant des tests qui ne vérifient rien. Alors que le but initial de la mesure était d'avoir du code correctement testé.
+- Mesurer les performances des développeurs avec le nombre de lignes de code rédigées amène à des codebases inutilement grosses.
+
+Voir aussi :
+
+- [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
+
+### Rasoir de Hanlon
+
+[Rasoir de Hanlon sur Wikipedia](https://fr.wikipedia.org/wiki/Rasoir_de_Hanlon)
+
+> Ne jamais attribuer à la malveillance ce que la bêtise suffit à expliquer.
+> Robert J. Hanlon
+
+Ce principe suggère que des actions produisant un mauvais résultat ne sont pas toujours motivées par de mauvaises intentions. Il est au contraire plus probable que le problème se situe dans la compréhension de ces actions et de leurs impacts.
+
+### Loi de Hofstadter
+
+[Loi de Hofstadter sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Hofstadter)
+
+> Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter.
+> (Douglas Hofstadter)
+
+Vous pourrez entendre parler de cette loi lorsqu'on cherche à estimer le temps nécessaire pour faire quelque chose. C'est un lieu commun de dire que nous ne sommes pas très bon pour estimer le temps nécessaire à boucler un projet en développement logiciel.
+
+c'est un extrait du livre '[Gödel, Escher, Bach: An Eternal Golden Braid](#a-lire)'.
+
+Voir aussi :
+
+- [À lire: Gödel, Escher, Bach: An Eternal Golden Braid](#a-lire)
+
+### Loi de Hutber
+
+[Loi de Hutber sur Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Amélioration veut dire détérioration.
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+Cette loi suggère que les améliorations apportées à un système vont mener à la détérioration d'autres choses. Ou qu'elles vont cacher d'autres détériorations, amenant globalement à une dégradation de l'état du système.
+
+Par exemple, un abaissement de la latence de réponse sur une route (end-point) peut causer des problèmes de débit et de capacité plus loin, affectant un sous-système entièrement différent.
+
+### Cycle du hype & Loi d'Amara
+
+[Cycle du hype sur Wikipedia](https://fr.wikipedia.org/wiki/Cycle_du_hype)
+
+> On a tendance à surestimer l'effet d'une technologie sur le court terme et à le surestimer sur le long terme.
+> (Roy Amara)
+
+Le cycle du hype est une représentation visuelle de l'attrait et du développement d'une technologie au fil du temps. Initialement réalisé par Gartner, le concept est plus clair avec un diagramme :
+
+![The Hype Cycle](../images/gartner_hype_cycle.png)
+
+*(Reference: par Jeremykemp sur English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+En clair, ce cycle montre qu'il y a généralement un pic d'excitation concernant les nouvelles technologies et leur potentiel impact. Les équipes adoptent ces technologies rapidement et se retrouvent parfois déçues des résultats. Cela peut être à cause d'un manque de maturité de la technologie, ou parce que les applications concrètes de cette technologie ne sont pas encore totalement maitrisées. Après un certain temps, les opportunités d'utiliser cette technologie ainsi que ses capacités augmentent suffisamment pour que les équipes deviennent vraiment productives. La citation de Roy Amara le résume de manière plus succincte: "On a tendance à surestimer l'effet d'une technologie sur le court terme et à le surestimer sur le long terme".
+
+### Loi d'Hyrum (loi des interfaces implicites)
+
+[Loi d'Hyrum en ligne](http://www.hyrumslaw.com/)
+
+> > Passé un certain nombre d'utilisateur d'une API, peu importe ce qui est promis par l'interface, tous les comportements possibles du système seront utilisés.
+> (Hyrum Wright)
+
+La loi d'Hyrum décris le fait que lorsqu'une API a un *nombre suffisamment élevé d'utilisateurs*, tous les comportements de l'API (y compris ceux qui ne sont pas définis publiquement) seront utilisés par quelqu'un. Un exemple trivial peut concerner les éléments non fonctionnels de l'API comme le temps de réponse. Un exemple plus subtil peut être l'utilisation d'une regex sur les messages d'erreurs pour en déterminer le *type*. Même si la spécification de l'API ne mentionne rien quant au contenu des messages, *certains* utilisateurs peuvent utiliser ces messages. Un changement au niveau de ces messages reviendrait à casser l'API pour ces utilisateurs.
+
+Voir aussi :
+
+- [Loi des abstractions qui fuient](#loi-des-abstractions-qui-fuient)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Loi de Kernighan
+
+> Debugger est deux fois plus difficile que de rédiger le code initial. Par conséquent si vous rédiger le code de manière aussi maligne que possible, vous n'êtes, par définition, pas assez intelligent pour le debugger.
+> (Brian Kernighan)
+
+La loi de Kernighan est nommée d'après [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) et est basée d'une citation du livre de Kernighan et Plauger: [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style).
+
+> Tout le monde sait que debugger est 2 fois plus difficile que de rédiger le programme en premier lieu. Donc si vous êtes aussi malin que possible en le rédigeant, comment pourrez vous le debugger ?
+
+Bien qu'étant hyperbolique, la loi de Kernighan présente l'argument que du code simple est préférable à du code complexe, car tout problème qui pourrait apparaitre dans du code complexe sera couteux voir impossible à debugger.
+
+Voir aussi :
+
+- [Principe KISS](#principe-kiss)
+- [Philosophie d'Unix](#philosophie-dunix)
+- [Rasoir d'Occam](#rasoir-doccam)
+
+### Loi de Metcalfe
+
+[Loi de Metcalfe sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Metcalfe)
+
+> L’utilité d’un réseau est proportionnelle au carré du nombre de ses utilisateurs.
+
+Cette loi est basée sur le nombre de connexions par pair à l'intérieur d'un système et est fortement liée à la [Loi de Reed](#loi-de-reed). Odlyzko et d'autres ont soutenus l'argument que la loi de Reed et la loi de Metcalfe surestiment la valeur du système en ne tenant pas compte des limites de l'intellect humain. Voir le [Nombre de Dunbar](#nombre-de-dunbar).
+
+Voir aussi :
+
+- [Loi de Reed](#loi-de-reed)
+- [Nombre de Dunbar](#nombre-de-dunbar)
+
+### Loi de Moore
+
+[Loi de Moore sur Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Le nombre de transistors dans un circuit intégré double approximativement tous les 2 ans.
+
+Souvent utilisée pour illustrer la grande vitesse à laquelle les semi-conducteurs et les technologies de puces informatiques ont évoluées. Cette prédiction de Moore s'est révélée être très précise des années 70 aux années 2000. Plus récemment ceci dit, la tendance a ralentie, en partie du [aux limites physiques de la miniaturisation des composants](https://en.wikipedia.org/wiki/Quantum_tunnelling). Cependant, les avancées dans la parallélisation et les changements potentiellement révolutionnaires dans les technologies des semi-conducteurs et du calcul quantique continueront peut être de faire respecter la loi de Moore pour les décennies à venir.
+
+### Loi de Murphy / Loi de Sod
+
+[Loi de Murphy sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Murphy)
+
+> Tout ce qui est susceptible d'aller mal, ira mal.
+
+Énoncée par [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.), la *loi de Murphy* déclare que si quelque chose peut mal tourner, cela tournera mal.
+
+C'est une formule bien connue des développeurs. Parfois l'inattendu surviens lors du développement, des tests, ou même en production. Cette loi peut aussi être liée à la *loi de Sod* (plus courante en Anglais d'Angleterre) :
+
+> Si quelque chose peut mal tourner, cela tournera mal. Au pire moment possible.
+
+Ces 'lois' sont souvent utilisées dans un sens humoristique. Cependant, des biais cognitifs tels que le [*biais de confirmation*](#TODO) et le [*biais de sélection*](#TODO) peuvent amener des gens à porter trop d'importance à ces lois. (On ne porte pas attention aux choses quand elles fonctionnent, la plupart du temps. Quand il y a un problème en revanche, c'est plus remarqué et peut entrainer des discussions)
+
+Voir aussi :
+
+- [Biais de confirmation](#TODO)
+- [Biais de sélection](#TODO)
+
+### Rasoir d'Occam
+
+[Rasoir d'Occam sur Wikipedia](https://fr.wikipedia.org/wiki/Rasoir_d%27Ockham)
+
+> Les multiples ne doivent pas être utilisés sans nécessité.
+> William of Ockham
+
+Le rasoir d'Occam nous indique que parmi plusieurs solutions possibles, la plus probable est celle à laquelle est attachée le moins de concepts et d'à priori. Cette solution est la plus simple et résout le problème donné sans ajouter accidentellement de la complexité et de potentielles conséquences négatives.
+
+Voir aussi :
+
+- [YAGNI](#yagni)
+- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Exemple :
+
+- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Loi de Parkinson
+
+[Loi de Parkinson sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Parkinson)
+
+> Le travail s’étale de façon à occuper le temps disponible pour son achèvement.
+
+Dans son contexte original, cette loi était basée sur l'étude des administrations. Elle peut être appliquée aux projets de développement logiciel, la théorie étant que les équipes seront inefficaces jusqu'à l'approche des deadlines puis se dépêcheront de finir le travail pour tenir les délais. Rendant la deadline plus ou moins arbitraire.
+
+Si cette loi est combinée avec la [loi de Hofstadter](#loi-de-hofstadter), on arrive à une perspective encore plus pessimiste: le travail s'étale pour occuper tout le temps disponible et au final prendra *encore plus de temps que prévu*.
+
+Voir aussi :
+
+- [Loi de Hofstadter](#loi-de-hofstadter)
+
+### Effet d'optimisation prématurée
+
+[Optimisation prématurée sur WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> L'optimisation prématurée est la source de tous les maux.
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+Dans l'article [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) rédigé par Donald Knuth, celui-ci écrit : "Les programmeurs perdent un temps énorme à réfléchir ou à se soucier de la vitesse de certaines parties non-critiques de leurs programmes. Et ces tentatives d'être performant ont en vérité un impact fortement négatif quand on prend en compte le debugging et la maintenance. Nous devrions oublier les petits rendements. Disons que 97% du temps: **l'optimisation prématurée est la source de tous les maux**. Ceci dit, nous ne devrions pas louper les opportunités disponibles dans ces 3% cruciaux."
+
+*L'optimisation prématurée* peut aussi être définie plus simplement comme: optimiser avant qu'on soit sûr qu'il faille le faire.
+
+### Loi de Putt
+
+[Loi de Putt sur Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> La technologie est dominée par deux types de personnes: celles qui comprennent ce qu'elles ne managent pas et celles qui managent ce qu'elles ne comprennent pas.
+
+La loi de Putt est souvent suivie par sa corollaire :
+
+> Toute hiérarchie technique développe tôt ou tard une inversion de compétence.
+
+Ces déclarations suggèrent que étant donné les divers critères de sélection et tendances dans la manière dont les groupes s'organisent, on trouvera au sein d'une entreprise technique deux types d'employés: des employés compétents techniquement non cadres et des employés à des postes de gestion qui ne comprennent pas aussi bien la complexité et les difficultés techniques. Cela peut être attribué à des phénomènes comme le [principe de Peter](#principe-de-peter) or le [principe de Dilbert](#principe-de-dilbert).
+
+Ceci dit, il est important de préciser que ce genre de lois sont des généralisations et s'appliquent à *certains* types d'organisation, sans s'appliquer à d'autres.
+
+Voir aussi :
+
+- [Principe de Peter](#principe-de-peter)
+- [Principe de Dilbert](#principe-de-dilbert)
+
+### Loi de Reed
+
+[Loi de Reed sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Reed)
+
+> L'utilité des grands réseaux, particulièrement des réseaux sociaux, s'accroit exponentiellement avec la taille du réseau.
+
+Cette loi est basée sur la théorie des graphs, où l'utilité s'accroit avec le nombre de sous-groupes possibles. Odlyzko et d'autres ont avancé l'argument que la loi de Reed surestime l'utilité du réseau en ne prenant pas en compte les limites du cerveau humain; voir le [nombre de Dunbar](#nombre-de-dunbar).
+
+Voir aussi :
+
+- [Loi de Metcalfe](#loi-de-metcalfe)
+- [Nombre de Dunbar](#nombre-de-dunbar)
+
+### Loi de la conservation de la complexité (Loi de Tesler)
+
+[Loi de la conservation de la complexité sur Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Cette loi énonce qu'il y a une certaine quantité de complexité dans un système qui ne peut pas être réduite.
+
+Une partie de la complexité d'un système est du à de la négligence. Conséquence d'une mauvaise structure, d'erreurs ou d'une mauvaise modélisation du problème à résoudre. Ce type de complexité peut être réduit, voir éliminé. Cependant, il y a une autre partie de la complexité qui est intrinsèque, du au problème qu'on cherche à résoudre. Ce type de complexité peut être déplacé mais pas éliminé.
+
+Un élément interessant soulevé par cette loi est la suggestion que même en simplifiant le système en entier, la complexité intrinsèque n'est pas réduite, elle est *déportée sur l'utilisateur*, qui doit alors compenser.
+
+### Loi des abstractions qui fuient
+
+[Loi des abstractions qui fuient sur Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> Toutes les abstractions non-triviales fuient plus ou moins.
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+Cette loi énonce que les abstractions, qui sont généralement utilisé en informatique pour simplifier l'utilisation de systèmes complexes, vont "fuirent" une partie du système sous-jacent dans certaines situations.
+
+Si on prends l'exemple de la lecture d'un fichier. Les APIs pour les systèmes de fichier sont une *abstraction* des systèmes plus bas niveau du kernel, qui sont eux même une abstraction du processus physique de changement de données sur le disque (ou la mémoire flash pour un SSD). Dans la plupart des cas, l'abstraction consistant à traiter un fichier comme un flux de données binaire fonctionnera comme prévu. Cependant, avec un disque magnétique la lecture de données séquentielle sera *significativement* plus rapide que la lecture de données aléatoire (due aux couts plus élevés d'erreurs de page). Mais pour un disque SSD, ces couts supplémentaires n'existent pas. On peut donc voir que les détails sous-jacents doivent être compris pour gérer cet exemple efficacement (par exemple les fichiers d'index de base de données sont structurés de manière à limiter le surcout des accès aléatoires). L'abstraction "fuit" certains détails d'implémentation que le développeur peut donc avoir besoin de connaitre.
+
+L'exemple ci-dessus peut devenir plus complexe quand des abstractions *supplémentaires* sont présentes. Par exemple, le système d'exploitation Linux permet aux fichiers d'accéder à des fichiers via un réseau, mais les présente sur la machine comme étant "normaux". Cette abstraction va fuir s'il y a des problèmes de réseau. Si un développeur traite ces fichiers comme étant "normaux" sans considérer le fait qu'ils peuvent être sujets à de la latence ou des échecs réseaux, le logiciel fonctionnera mal.
+
+L'article décrivant cette loi suggère qu'une dépendance trop forte aux abstractions combinée à une faible compréhension des processus sous-jacent rend le problème *plus* complexe à gérer dans certains cas.
+
+Voir aussi :
+
+- [Loi d'Hyrum](#loi-dhyrum)
+
+Exemples concrets :
+
+- - [Démarrage lent de Photoshop](https://forums.adobe.com/thread/376152) - un problème que j'ai eut par le passé. Photoshop était lent au démarrage, prenant parfois plusieurs minutes. Le problème venait du fait que le logiciel récupérait des informations sur l'imprimante par défaut au démarrage. Hors, si cette imprimante était reliée par réseau, cela prenait extrêmement longtemps. *L'abstraction* de l'imprimante réseau présentée comme étant similaire à une imprimante locale causait ce problème pour les utilisateurs avec une mauvaise connexion.
+
+### Loi de futilité
+
+[Loi de futilité sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_futilit%C3%A9_de_Parkinson)
+
+Cette loi suggère que les organisations donnent largement plus de temps et d'attention à des détails triviaux ou cosmétiques qu'aux problèmes fondamentaux et difficiles.
+
+L'exemple fictif couramment utilisé est celui d'un comité approuvant les plans d'une centrale nucléaire et qui passe la majorité de son temps à parler du local à vélo plutôt que de la conception de la centrale en elle même. Il peut être difficile de participer de manière utile à des discussions concernant des sujets vastes et complexes sans une grande expertise ou préparation. Cependant les gens veulent être vu comme participant de manière utile. D'où une tendance à trop se focaliser sur des détails qui peuvent être abordés simplement mais qui n'ont pas particulièrement d'importance.
+
+L'exemple ci-dessus à conduit à l'utilisation du terme 'Bike Shedding' (en rapport à l'abri à vélo) comme expression désignant une perte de temps sur des détails triviaux. Un autre terme apparenté est '[Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving)', qui désigne une activité apparemment inutile qui fait partie d'une longe chaine de pré-requis à la tâche principale.
+
+### Philosophie d'Unix
+
+[The Unix Philosophie d'Unix sur Wikipedia](https://fr.wikipedia.org/wiki/Philosophie_d%27Unix)
+
+La philosophie d'Unix consiste à dire que les programmes informatiques doivent être petits, ne faire qu'une seule chose et la faire bien. Cela peut rendre plus simple la construction de systèmes en combinant des unités simples petites et bien définies plutôt que des programmes larges, complexes et servant à plusieurs choses.
+
+Certaines pratiques récentes comme l'architecture en microservices peut être vue comme une application de cette loi, où les services sont petits et ne font qu'une seule chose, permettant la création de comportements complexes à partir de briques qui sont simples.
+
+### Modèle de Spotify
+
+[Modèle de Spotify sur Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+Le modèle de Spotify est une approche à la structure d'entreprise et des équipes qui a été popularisée par Spotify. Dans ce modèle, les équipes sont organisées autour des fonctionnalités plutôt que des technologies.
+
+Le modèle de Spotify a également popularisé les concepts de Tribus, Guildes, et Chapitres qui sont d'autres éléments de leur structure.
+
+### Loi de Wadler
+
+[Loi de Wadler sur wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> Dans toute conception de langage, le temps total passé à discuter un aspect de cette liste est proportionnel à deux élevé à la puissance de la position correspondante.
+> 1. Sémantique
+> 2. Syntaxe
+> 3. Syntaxe lexicale
+> 4. Syntaxe lexicale des commentaires
+> (en clair, pour chaque heure passée sur la sémantique, 8 heures seront passées sur la syntaxe des commentaires)
+
+Similaire à la [loi de trivialité](#loi-de-futilite), la loi de Wadler énonce que lors de la conception d'un langage, le temps passé à discuter des différents aspects est inversement proportionnel à l'importance de ces aspects.
+
+Voir aussi :
+
+- [Loi de futilité](#loi-de-futilite)
+
+### Loi de Wheaton
+
+[Le lien](http://www.wheatonslaw.com/)
+
+[Le jour officiel](https://dontbeadickday.com/)
+
+> Ne soyez pas un connard.
+> *Wil Wheaton*
+
+Inventée par Will Wheaton (Star Trek: The Next Generation, The Big Bang Theory), cette loi simple, concise et puissante vise à augmenter l'harmonie et le respect au sein d'un environnement professionnel. Elle peut être appliquée lorsqu'on parle à ses collègues, effectue une code review, argumente contre un autre point de vue, critique et de manière générale, lors de la plupart des interactions entre humains.
+
+## Principes
+
+Les principes sont généralement des lignes directrices liés à la conception.
+
+### Principe de Dilbert
+
+[Principe de Dilbert sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_Dilbert)
+
+> Les entreprises tendent à promouvoir systématiquement les employés incompétents afin de les sortir du workflow.
+> *Scott Adams*
+
+Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limité les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).
+
+Voir aussi :
+
+- [Principe de Peter](#principe-de-peter)
+- [Loi de Putt](#loi-de-putt)
+
+### Principe de Pareto (règle des 80/20)
+
+[Principe de Pareto sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_Pareto)
+
+> La plupart des choses dans la vie ne sont pas réparties également.
+
+Le principe de Pareto suggère que dans certains cas, la majorité des résultats provient d'une minorité des actions :
+
+- 80% d'un certain logiciel peut être écrit en 20% du temps de développement alloué (inversement, les 20% les plus difficiles prennent 80% du temps)
+- 20% de l'effort fourni produit 80% du résultat
+- 20% du travail amène 80% des revenus
+- 20% des bugs causent 80% des crashs
+- 20% des fonctionnalités entrainent 80% de l'utilisation
+
+Dans les années 1940, l'ingénieur Américano-Roumain Dr. Joseph Juran, qui est largement crédité comme étant le père du contrôle qualité, [commença à appliquer le principe de Pareto pour résoudre des problèmes de qualité](https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+Ce principe est aussi connu comme la règle des 80/20, 'The Law of the Vital Few' et 'The Principle of Factor Sparsity'.
+
+Exemples concrets :
+
+- - En 2002, Microsoft reporta qu'en réglant les 20% des bugs les plus reportés, 80% des erreurs et des crashs liés dans Windows et Office ont été éliminés ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### Principe de Peter
+
+[Principe de Peter sur Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
+
+> Les gens faisant partie d'une hiérarchie tendent à s'élever à leur "niveau d'incompétence"
+> *Laurence J. Peter*
+
+Le principe de Peter est un concept de management inventé par Laurence J. Peter qui observe que les gens qui sont bons dans leur travail sont promus jusqu'à ce qu'ils atteignent un niveau où ils ne réussissent plus (leur "niveau d'incompétence"). À ce point, étant donné leur expérience ils sont moins susceptibles de se faire renvoyer (à part s'ils obtiennent des résultats particulièrement mauvais) et vont demeurer dans un poste pour lequel ils ont potentiellement peu de compétences.
+
+Ce principe est particulièrement intéressant pour les ingénieurs qui démarrent leur carrière dans des postes profondément techniques mais évoluent souvent vers des postes de *managers*, qui requiert des compétences fondamentalement différentes.
+
+Voir aussi :
+
+- [Principe de Dilbert](#principe-de-dilbert)
+- [Loi de Putt](#loi-de-putt)
+
+### Principe de robustesse (loi de Postel)
+
+[Principe de robustesse sur Wikipedia](https://fr.wikipedia.org/wiki/Jon_Postel#Principe_de_robustesse)
+
+> Soyez tolérant dans ce que vous acceptez, et pointilleux dans ce que vous envoyez
+
+Souvent appliqué dans le développement d'application serveur, ce principe énonce que ce que vous envoyez aux autres devrait être aussi minimal et conforme que possible. Mais que vous devriez accepter des données en entrée non-conforme si elles peuvent être traités.
+
+Le but de ce principe est de construire des systèmes qui sont robustes dans le sens où ils peuvent gérer des entrées mal formées du moment qu'elles restent compréhensibles. Cependant, il y a de potentielles implications de sécurité à accepter des entrés mal formées. Particulièrement si le traitement de ces entrées n'est pas correctement testé.
+
+À terme, autoriser des entrées non-conforme peut amoindrir la capacité d'évolution des protocoles étant donné que les utilisateurs vont tôt ou tard compter sur cette tolérance lors de leur utilisation.
+
+Voir aussi :
+
+- [Loi d'Hyrum](#loi-dhyrum)
+
+### SOLID
+
+Il s'agit d'un acronyme qui signifie :
+
+- S: [Single responsibility principle](#principe-de-responsabilite-unique) (principe de responsabilité unique)
+- O: [The Open/Closed Principle](#principe-ouvertferme) (principe ouvert/fermé)
+- L: [The Liskov Substitution Principle](#principe-de-substitution-de-liskov) (Principe de substitution de Liskov)
+- I: [The Interface Segregation Principle](#principe-de-segregation-des-interfaces) (principe de ségrégation des interfaces)
+- D: [Principe d'inversion des dépendances](#principe-dinversion-des-dependances)
+
+Ces principes sont fondamentaux dans la [programmation orientée objet](#TODO). Ces principes de conception devraient pouvoir aider les développeurs à construire des systèmes plus facilement maintenable.
+
+### Principe de responsabilité unique
+
+[Principe de responsabilité unique sur Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> Chaque module ou classe ne doit avoir qu'une seule responsabilité.
+
+Le premier des principes '[SOLID](#solid)'. Il suggère que les modules ou classes ne devraient faire qu'une chose unique. Autrement dit, un seul petit changement sur une fonctionnalité d'un programme ne devrait nécessiter de changer qu'un seul composant. Par exemple, changer la manière de valider un mot de passe ne devrait nécessiter un changement qu'à un endroit du programme.
+
+Théoriquement, cela devrait rendre le code plus robuste et plus simple à modifier. Savoir qu'un composant en train d'être modifié possède une seule responsabilité veut aussi dire que *tester* cette modification devrait être plus simple. Pour reprendre l'exemple precedent, changer le composant concernant la validation d'un mot de passe ne devrait affecter que cette fonctionnalité. Il est souvent beaucoup plus difficile de réfléchir aux impacts d'un changement sur un composant qui est responsable de plusieurs choses.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+
+### Principe ouvert/fermé
+
+[Principe ouvert/fermé sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_ouvert/ferm%C3%A9)
+
+> Les entités devraient être ouvertes à l'extension et fermées à la modification.
+
+Le deuxième des principes '[SOLID](#solid)'. Il énonce que le comportement des entités (classes, modules, fonctions, etc.) devraient pouvoir être *étendu*, mais que le comportement *existant* ne devrait pas pouvoir être modifié.
+
+Imaginons par exemple un module capable de changer un document rédigé en Markdown en HTML. Ce module peut être étendu en y ajoutant le support pour une nouvelle fonctionnalité Markdown sans modifier son fonctionnement interne. Le module est en revanche *fermé* à la modification dans le sens où un utilisateur *ne peut pas* changer la manière dont le code existant est rédigé.
+
+Ce principe est particulièrement pertinent pour la programmation orientée objet, où on cherche la plupart du temps à concevoir des objets qu'on puisse facilement étendre mais dont le comportement existant ne puisse pas être modifié de manière imprévue.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+
+### Principe de substitution de Liskov
+
+[Principe de substitution de Liskov sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_substitution_de_Liskov)
+
+> Il devrait être possible de remplacer un type avec un sous-type sans casser le système.
+
+Le troisième des principes '[SOLID](#solid)'. Il énonce que si un composant repose sur un type, alors il devrait être capable d'utiliser un sous-type de ce type sans que le système ne plante ou qu'il y ai besoin de connaitre les détails de ce sous-type.
+
+Imaginons par exemple que nous ayons une méthode qui lit un document XML depuis une structure représentant un fichier. Si cette méthode utilise un type 'fichier' de base, alors tous les types dérivant de 'fichier' devraient pouvoir être utilisé avec cette fonction. Si 'fichier' supporte une recherche partant de la fin et que le parser XML utilise cette fonction, mais que le type dérivé 'fichier réseau' ne permet pas de recherche en partant de la fin, alors 'fichier réseau' viole le principe.
+
+Ce principe est particulièrement pertinent pour la programmation orientée objet, où les hierarchies de types doivent être conçues soigneusement pour éviter de brouiller les utilisateurs d'un système.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+
+### Principe de ségrégation des interfaces
+
+[Principe de ségrégation des interfaces sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces)
+
+> Aucun client de devrait dépendre de méthodes qu'il n'utilise pas.
+
+Le quatrième des principes '[SOLID](#solid)'. Celui-ci énonce que les utilisateurs d'un composant ne devraient pas dépendre des fonctions de ce composant qu'il n'utilise pas.
+
+Par exemple, imaginons que nous ayons une méthode qui lit un document XML depuis une structure représentant un fichier. Elle nécéssite seulement de pouvoir lire des octets, avancer ou reculer dans le fichier. Le principe sera invalidé si cette méthode a besoin d'être mise à jour lorsqu'une fonctionnalité sans rapport du fichier change (ex. une mise à jour de modèle de permissions pour l'accès au fichier). Il serait préférable pour le fichier d'implémenter une interface 'seekable-stream', et pour le lecteur XML de l'utiliser.
+
+Ce principe est particulièrement pertinent pour la programmation orientée objet, où les interfaces, hierarchies et type abstraits sont utilisés pour [minimiser le couplage](#todo) entre les différents composants. Le [duck typing](#todo) est une méthode qui applique ce principe en éliminant les interfaces explicites.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Decouplage](#todo)
+
+### Principe d'inversion des dépendances
+
+[Principe d'inversion des dépendances sur Wikipedia](https://fr.wikipedia.org/wiki/Inversion_des_d%C3%A9pendances)
+
+> Les modules de haut niveau ne devraient pas dépendre des implémentations de bas niveau.
+
+Le cinquième des principes '[SOLID](#solid)'. Il énonce que les composants de hauts niveau ne devraient pas avoir à connaitre les détails de leurs dependences.
+
+Prenons par exemple un programme qui lit des méta-donnés depuis un site web. Ce programme possède un composant principal qui connait un autre composant chargé de télécharger le contenu de la page, ainsi qu'un autre composant capable de lire les méta-donnés. En prenant en compte le principe d'inversion des dépendances, le composant principal ne devrait dépendre que de: un composant abstrait capable de télécharger des données binaires, ainsi que d'un composant abstrait capable de lire des méta-donnés depuis un flux binaire. Le composant principal ne devrais pas à connaitre les concepts de TCP/IP, HTTP, HTML, etc.
+
+Ce principe est complexe étant donné qu'il semble 'inverser' les dépendances attendues dans un système (d'où le nom). En pratique cela veut aussi dire qu'un composant 'orchestrateur' doit s'assurer que les types abstraits soient correctement implémentés. (Pour reprendre l'exemple précédent, *quelque chose* doit fournir un downloader de fichier HTTP et un liseur de meta tag HTML au composant lisant les méta-donnés.) On touche alors à des patterns tels que l'[inversion de contrôle](#todo) et l'[injection de dépendances](#todo).
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+- [Inversion de contrôle](#todo)
+- [Injection de dépendances](#todo)
+
+### Principe DRY
+
+[Principe DRY sur Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité.
+
+DRY est un acronyme pour *Don't Repeat Yourself* (ne vous répétez pas). Ce principe vise à aider les développeurs à réduire les répétitions de code et à garder l'information à un seul endroit. Il a été formulé en 1999 par Andrew Hunt et Dave Thomas dans le livre [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer).
+
+> L'opposé de DRY serait *WET* (Write Everything Twice ou We Enjoy Typing, qu'on peut traduire par Tout écrire en double ou On aime taper au clavier).
+
+En pratique, si vous avez la même information dans deux (ou plus) endroits, vous pouvez utiliser DRY pour les fusionner et réutiliser cette unique instance partout où c'est nécessaire.
+
+Voir aussi :
+
+- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### Principe KISS
+
+[KISS sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_KISS)
+
+> > Keep it simple, stupid. (Ne complique pas les choses)
+
+Le principe KISS énonce que la plupart des systèmes fonctionnent mieux s'ils sont simples que compliqués. Par conséquent, la simplicité devrait être un but essentiel dans la conception et toute complexité inutile devrait être évité. Provenant de la marine Américaine en 1960, la phrase est attribuée à l'ingénieur Kelly Johnson.
+
+Le principe est exemplifié le mieux par l'histoire de Johnson qui donna à une équipe d'ingénieurs une poignée d'outils et le défi de concevoir un avion de chasse qui soit réparable par un mécanicien lambda, sur le terrain, en condition de combat avec ces outils uniquement. Le "supid" fait donc référence à la relation entre la manière dont les choses cassent et la sophistication des outils à disposition pour les réparer, et non aux capacités des ingénieurs eux-mêmes.
+
+Voir aussi :
+
+- [Loi de Gall](#loi-de-gall)
+
+### YAGNI
+
+[YAGNI sur Wikipedia](https://fr.wikipedia.org/wiki/YAGNI)
+
+Il s'agit d'un acronyme pour ***Y**ou **A**in't **G**onna **N**eed **I**t*. Que l'on peut traduire par: "vous n'en aurez pas besoin".
+
+> Implémentez les choses uniquement quand vous en avez réellement besoin et non quand vous pensez que vous en aurez besoin plus tard.
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (Co-fondateur de XP et auteur du livre "Extreme Programming Installed")
+
+Ce principe *d'Extreme Programming* (XP) suggère que les développeurs ne devraient implémenter que les fonctionnalités qui sont nécessaires immédiatement et éviter de tenter de prédire l'avenir en implémentant des fonctionnalités qui pourraient être nécessaires plus tard.
+
+Adhérer à ce principe devrait réduire la quantité de code inutilisé dans la codebase et permettre d'éviter de passer du temps et des efforts sur des fonctionnalités qui n'apportent rien.
+
+Voir aussi :
+
+- [À lire: Extreme Programming Installed](#a-lire)
+
+### Illusions de l'informatique distribuée
+
+[Illusions de l'informatique distribuée sur Wikipedia](https://fr.wikipedia.org/wiki/Illusions_de_l%27informatique_distribu%C3%A9e)
+
+Aussi connues sous le nom de *illusions de l'informatique en réseau*, les illusions sont une liste de suppositions (ou croyances) concernant l'informatique distribuée, qui peuvent amener à des problèmes dans le développement logiciel. Les suppositions sont :
+
+- Le réseau est fiable
+- Le temps de latence est nul
+- La bande passante est infinie
+- Le réseau est sûr
+- La topologie du réseau ne change pas
+- Il y a un et un seul administrateur réseau
+- Le coût de transport est nul
+- Le réseau est homogène
+
+Les quatre premiers éléments furent listés par [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) et [Tom Lyon](https://twitter.com/aka_pugs) vers 1991 et qualifiés pour la première fois d'"illusions de l'informatique distribuée" par [James Gosling](https://en.wikipedia.org/wiki/James_Gosling). [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) ajouta les 5ème, 6ème et 7ème illusions. Gosling ajouta la 8ème illusion vers la fin des années 90.
+
+Le groupe était inspiré par ce qui se passait à l'époque chez [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+Ces illusions devraient être gardées à l'esprit pour concevoir du code résistant étant donné que chacune d'entre elle peut mener à une perception biaisée qui ne prend pas en compte la réalité et la complexité des systèmes distribués.
+
+Voir aussi :
+
+- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
+- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
+## À lire
+
+Si vous avez trouvé ces concepts intéressants, vous apprécierez peut être aussi les livres suivants :
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Couvre les principes fondamentaux de l'Extreme Programming.
+- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Un classique sur le développement logiciel. La [loi de Brooks](#loi-de-brooks) est un thème central du livre.
+- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Un livre difficile à classe. La [loi de Hofstadter](#loi-de-hofstadter) est tirée de ce livre.
+- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Un regard humoristique sur l'Amérique corporate, par l'auteur du [principle de Dilbert](#principe-de-dilbert).
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Un autre regard humoristique porté sur les challenges du management et des grandes entreprises. L'origine du [principe de Peter](#principe-de-peter).
+
+## Traductions
+
+Grâce à l'aide de merveilleux contributeurs, Hacker Laws est disponible dans plusieurs langues. N'hésitez pas à envisager de sponsoriser les modérateurs !
+
+Langue | Moderateur | Status
+--- | --- | ---
+[🇧🇷 Brasileiro / Brésilien](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)
+[🇨🇳 中文 / Chinois](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partiellement complète
+[🇩🇪 Deutsch / Allemand](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)
+[🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)
+[🇬🇷 ελληνικά / Grecque](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)
+[🇮🇹 Italiano / Italien](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partiellement complète
+[🇰🇷 한국어 / Coréen](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partiellement complète
+[🇱🇻 Latviešu Valoda / Letton](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)
+[🇷🇺 Русская версия / Russe](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partiellement complète
+[🇪🇸 Castellano / Espagnol](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partiellement complète
+[🇹🇷 Türkçe / Turc](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)
+
+Si vous souhaitez mettre à jour une traduction, vous pouvez [ouvrir une pull request](https://github.com/dwmkerr/hacker-laws/pulls). Si vous voulez ajouter une nouvelle langue, connectez vous à [GitLocalize](https://gitlocalize.com/) pour créer un compte, puis créez une issue afin que je vous ajoute au projet ! Il serait également très apprécié d'ouvrir une pull request correspondante qui met à jour le tableau ci-dessus et la liste de liens au début de ce fichier.
+
+## Projets liés
+
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Recevez quotidiennement une loi / principe.
+
+## Contribuer
+
+N'hésitez pas à contribuer ! Vous pouvez [créer une issue](https://github.com/dwmkerr/hacker-laws/issues/new) pour suggérer une addition ou un changement, ou [ouvrir une pull request](https://github.com/dwmkerr/hacker-laws/compare) pour proposer vos propres modifications.
+
+Merci de lire le [guide de contribution](./.github/contributing.md) pour connaitre les pré-requis concernant le style, le contenu, etc. Veuillez lire également le [code de conduite](./.github/CODE_OF_CONDUCT.md) afin de le respecter lors des discussions sur le projet.
+
+## TODO
+
+Si vous êtes atteris ici vous avez cliqué sur un lien concernant un sujet qui n'a pas encore été rédigé. Désolé ! Tout n'est pas encore terminé.
+
+N'hésitez pas à [créer une issue](https://github.com/dwmkerr/hacker-laws/issues) pour avoir plus de détails, ou [ouvrez une pull request](https://github.com/dwmkerr/hacker-laws/pulls) pour soumettre votre propre texte sur le sujet.

translations/lv.md

@@ -0,0 +1,783 @@
+# 💻 📖 hacker-laws
+
+[![gitlocalized](https://gitlocalize.com/repo/2513/whole_project/badge.svg)](https://gitlocalize.com/repo/2513/whole_project?utm_source=badge)
+
+Likumi, teorijas, principi un apraksti, kas izstrādātājiem šķitīs noderīgi.
+
+- 🇨🇳 [中文/Chinese Version](https://github.com/nusr/hacker-laws-zh) - paldies [Steve Xu](https://github.com/nusr)!
+- 🇮🇹 [traduzione Italiano](https://github.com/dwmkerr/hacker-laws/blob/master/translations/it-IT.md) - paldies [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🇰🇷 [한국어/korejiešu versija](https://github.com/codeanddonuts/hacker-law-kr) - paldies [Doughnut](https://github.com/codeanddonuts)!
+- 🇷🇺 [Русская версия/Krievijas versija](https://github.com/solarrust/hacker-laws) - paldies [Alena Batitskaya](https://github.com/solarrust)!
+- 🇹🇷 [türkçe/Turkish Version](https://github.com/umutphp/hacker-laws-tr) - paldies [Umut Işık](https://github.com/umutphp)
+- 🇧🇷 [Brasileiro/Brazīlijas versija](./translations/pt-BR.md) - paldies [Leonardo Costa](https://github.com/LeoFC97)
+- 🇪🇸 [Castellano/Spānijas versija](./translations/es-ES.md) - paldies [Manuel Rubio](https://github.com/manuel-rubio)
+- 🇱🇻 [Latvian/Latvijas versija](./translations/lv.md) - paldies [Artūrs Jansons](https://github.com/iegik)
+- 🇺🇸 [Original English Version - Oriģinālā angļu versija](https://github.com/dwmkerr/hacker-laws) - paldies [Dave Kerr](https://github.com/dwmkerr)!
+
+Kā šis projekts? Lūdzu, apsveriet iespēju [Sponsoring Me](https://github.com/sponsors/dwmkerr)!
+
+---
+
+<!-- VIM-markdown-toc GFM -->
+
+* [Ievads](#ievads)
+* [Likumi](#likumi)
+    * [Amdahla likums](#amdahla-likums)
+    * [Izsisto logu teorija](#izsisto-logu-teorija)
+    * [Brūku likums](#bruku-likums)
+    * [Konveja likums](#conways-likums)
+    * [Kaningemas likums](#cunninghams-likums)
+    * [Danbara numurs](#dunbars-numurs)
+    * [Galla likums](#galls-likums)
+    * [Goodharta likums](#goodharts-likums)
+    * [Hanona Razora](#hanlons-razor)
+    * [Hofstadtera likums](#hofstadtera-likums)
+    * [Hutbera likums](#hutbera-likums)
+    * [Hype Cycle & Amaras likums](#hype-cycle-amaras-likums)
+    * [Hyruma likums (Perifērisko saskarņu likums)](#hyruma-likums-perifērisko-saskarņu-likums)
+    * [Kernigana likums](#kernigana-likums)
+    * [Metkalfa likums](#metkalfa-likums)
+    * [Mora likums](#mora-likums)
+    * [Mērfija likums/Soda likums](#murphys-sods-likums)
+    * [Occam's Razor](#occams-razor)
+    * [Parkinsona likums](#parkinsons-Law)
+    * [Priekšlaicīgas optimizēšanas efekts](#premature-optimizēšanas-efekts)
+    * [Putta likums](#putta-likums)
+    * [Reeda likums](#reeda-likums)
+    * [Taisnīguma saglabāšanas likums (Teslera likums)](#taisnīguma-saglabāšanas-likums-teslera-likums)
+    * [Leaky Abstractions likums](#leaky-Abstractions-likums)
+    * [Trivialitātes likums](#trivialitātes-likums)
+    * [Unix filozofija](#unix-filozofija)
+    * [Spotify modelis](#spotify-modelis)
+    * [Wadlera likums](#wadlera-likums)
+    * [Wheatona likums](#wheatons-likums)
+* [Principi](#principi)
+    * [Dilberta princips](#dilberta-princips)
+    * [Pareto princips (kārtula 80/20)](#pareto-princips-kārtula-8020)
+    * [Petera princips](#petera-princips)
+    * [Uzturības princips (Postela likums)](#uzturības-princips-postela-likums)
+    * [SOLID](#solid)
+    * [Vienotās atbildības princips](#vienotās-atbildības-princips)
+    * [Atklātais/slēgtais princips](#atklātaisslēgtais-princips)
+    * [Liskova aizstāšanas princips](#liskova-aizstāšanas-princips)
+    * [Interfeisa segmenta noteikšanas princips](#interfeisa-segmenta-noteikšanas-princips)
+    * [Atkarībās inversijas princips](#atkarības-inversijas-princips)
+    * [DRY princips](#dry-princips)
+    * [KISS princips](#kiss-princips)
+    * [YAGNI](#yagni)
+    * [Dalītās datošanas maldības](#dalītās-datošanas-maldības)
+* [Lasīšanas saraksts](#lasīšanas-saraksts)
+* [Ieguldījums](#ieguldījums)
+* [Uzdevums](#TODO)
+    
+<!-- VIM-markdown-toc -->
+
+## Ievads
+
+Ir daudz likumu, kurus cilvēki apspriež, runājot par attīstību. Šis repozitorijs ir atsauce un pārskats par dažiem visbiežāk sastopamajiem. Lūdzu, kopīgojiet un iesniedziet PRs!
+
+❗: šis repo satur dažu likumu, principu un modeļu skaidrojumu, bet ne _aizstāv_ nevienam no tiem. Tas, vai tās jāpiemēro, vienmēr būs debašu jautājums un lielā mērā atkarīgs no tā, ar ko jūs strādājat.
+
+## Tiesību akti
+
+Un te nu mēs ejam!
+
+### Amdahl likums
+
+[Amdahl likums Vikipēdijā](https://en.wikipedia.org/wiki/Amdahl%27s_law)
+
+> Amdahl likums ir formula, kas parāda skaitļošanas uzdevuma _increedup_, ko var sasniegt, palielinot sistēmas resursus. Parasti izmanto paralēlā skaitļošanā, tā var paredzēt faktisko labumu no procesoru skaita palielināšanas, ko ierobežo programmas paralēliskās iespējas.
+
+Vislabāk ilustrēts ar piemēru. Ja programma sastāv no divām daļām, daļas A, kas jāizpilda vienam procesoram, un daļas B, ko var līdzināt, mēs redzam, ka vairāku procesoru pievienošana sistēmai, kas izpilda programmu, var sniegt tikai ierobežotu labumu. Tas var ievērojami uzlabot B daļas ātrumu, bet daļas a ĀTRUMS paliks nemainīgs.
+
+Turpmāk redzamajā diagrammā ir parādīti daži iespējamo ātruma uzlabojumu piemēri.
+
+<img alt="Diagram: Amdahla likums" src="../images/amdahls_law.png" width="480px"/>
+
+*(Atsauce uz attēlu: Daniels220 angļu valodā Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Kā redzams, pat programma, kas ir 50% parallelisable, gūs ļoti maz vairāk nekā 10 procesoru vienību, bet programma, kas ir 95% parallelisable, joprojām var sasniegt ievērojamus ātruma uzlabojumus ar vairāk nekā tūkstoš procesoriem.
+
+Tā kā [Mora likums](#mora-likums) palēninās un individuālā procesora ātruma paātrināšanās palēninās, paralelizācija ir būtiska, lai uzlabotu veiktspēju. Grafikas programmēšana ir lielisks piemērs - ar mūsdienu Shader bāzes skaitļošanu, atsevišķiem pikseļiem vai fragmentiem var renderēt paralēli - tāpēc mūsdienu grafikas kartēs bieži vien ir daudz tūkstošu apstrādes kodolu (GPUs vai Shader Units).
+
+Skatīt arī:
+
+- [Brūku likums](#brooks-likums)
+- [Mora likums](#mora-likums)
+
+### Izsisto logu teorija
+
+[Izsisto logu teorija Vikipēdijā](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+Izsisto logu teorija liecina, ka redzamas nozieguma pazīmes (vai kādas vides rūpju trūkums) noved pie tālākiem un smagākiem noziegumiem (vai tālākas vides pasliktināšanās).
+
+Šī teorija ir izmantota programmatūras izstrādei, kas liek domāt, ka sliktas kvalitātes kods (vai [Technical Debt](#TODO)) var radīt priekšstatu, ka kvalitātes uzlabošanas centieni var tikt ignorēti vai nepietiekami novērtēti, tādējādi radot vēl vairāk sliktas kvalitātes kodu. Šī efekta kaskādes izraisa ievērojamu kvalitātes samazināšanos laika gaitā.
+
+Skatīt arī:
+
+- [Tehniskais parāds](#TODO)
+
+Piemēri:
+- [Pracistic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-break-window-theory/)
+- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
+### Brūku likums
+
+[Brūku likums Vikipēdijā](https://en.wikipedia.org/wiki/Brooks%27s_law)
+
+> Personāla resursu pievienošana vēlākam programmatūras izstrādes projektam to dara vēlāk.
+
+Šis likums liek domāt, ka daudzos gadījumos mēģinājums paātrināt tāda projekta īstenošanu, kas jau ir novēlots, pieskaitot vairāk cilvēku, padarīs piegādi vēl vēlāku. Bruks ir skaidrs, ka tā ir pārmērīga vienkāršošana, tomēr vispārīgie apsvērumi ir tādi, ka, ņemot vērā jaunu resursu ieviešanas laiku un sakaru pieskaitāmās izmaksas, tuvākajā laikā ātrums samazinās. Turklāt daudzi uzdevumi var nebūt dalāmi, t. i., viegli sadalāmi starp lielākiem resursiem, kas nozīmē, ka arī potenciālais ātruma pieaugums ir mazāks.
+
+Izplatītā frāze “Deviņi sievietes nevar dzemdēt bērnu vienā mēnesī” attiecas uz Brūku likumu, jo īpaši uz faktu, ka daži darba veidi nav dalāmi vai parallelisable.
+
+Šī ir grāmatas “[The Mythical Man Monthly](#lasīšanas-saraksts)” galvenā tēma.
+
+Skatīt arī:
+
+- [Nāves marts](#TODO)
+- [reading List: The Mythical Man Month](#reading saraksts)
+
+### Konveja likums
+
+[Conwaya likums Vikipēdijā](https://en.wikipedia.org/wiki/Conway%27s_law)
+
+Šis likums paredz, ka sistēmas tehniskās robežas atspoguļos organizācijas struktūru. Parasti tas tiek pieminēts, aplūkojot organizācijas uzlabojumus, Konveja likums liecina, ka, ja organizācija ir strukturēta uz daudzām mazām, atvienotām vienībām, tad tā ražotā programmatūra būs. Ja organizācija ir vairāk izveidota, izmantojot "vertikāles”, kas ir orientētas uz līdzekļiem vai pakalpojumiem, arī programmatūras sistēmas to atspoguļo.
+
+Skatīt arī:
+
+- [Spotify modelis](#spotify-modelis)
+
+### Kaningemas likums
+
+[Kaningemas likums Vikipēdijā](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham_likums)
+
+> Labākais veids, kā iegūt pareizo atbildi internetā, ir neuzdot jautājumu, tas ir, izlikt nepareizu atbildi.
+
+Pēc Stīvena McGeady teiktā, Vords Kaningems astoņdesmito gadu sākumā viņam ieteicis: “Labākais veids, kā iegūt pareizo atbildi internetā, ir neuzdot jautājumu, tas ir, izlikt nepareizu atbildi.” Mcgeady šo Kaningemas likumu nodēvēja par “nepatiesu”, lai gan Kaningems to noliedz. Lai gan sākotnēji tas attiecās uz mijiedarbību ar Usenet, likums ir izmantots, lai aprakstītu, kā darbojas citas tiešsaistes kopienas (piemēram, Wikipedia, Reddit, Twitter, Facebook).
+
+Skatīt arī:
+
+- [XKCD 386: “Duty Calls”](https://xkcd.com/386/)
+
+### Danbara numurs
+
+[Danbara numurs Vikipēdijā](https://en.wikipedia.org/wiki/Dunbar%27s_number)
+
+“Danbara skaitlis ir ieteicams izziņas ierobežojums to cilvēku skaitam, ar kuriem var uzturēt stabilas sociālās attiecības — attiecības, kurās indivīds zina, kas ir katrs cilvēks un kā katrs cilvēks ir saistīts ar katru citu cilvēku.” Ir kādas domstarpības ar precīzu skaitli. “..” “Dunbar” ierosināja, ka cilvēki var mierīgi uzturēt tikai 150 stabilas attiecības.” Viņš ievietoja numuru vairāk sabiedriskā kontekstā, “tik daudz cilvēku, cik jūs nejustos apmulsuši, ka pievienojaties nelūgtam dzērienam, ja jums gadītos ar viņiem ieskrieties bārā.” Aptuvenie skaitļi parasti ir no 100 līdz 250.
+
+Tāpat kā stabilas attiecības starp indivīdiem, arī izstrādātāja attiecības ar kodebīlu prasa pūles uzturēt. Saskaroties ar lieliem sarežģītiem projektiem vai daudzu projektu īpašumtiesībām, mēs paļaujamies uz konvencionālo, politiku un modelēto procedūru mērogu. Danbara numurs ir svarīgs ne tikai biroja izaugsmei, bet arī, nosakot darba grupas darba apjomu vai lemjot par to, kad sistēmai jāiegulda līdzekļi, lai palīdzētu modelēt un automatizēt loģistikas pieskaitāmās izmaksas. Skaitlis tiek iekļauts tehniskā kontekstā, tas ir tādu projektu skaits (vai atsevišķa projekta normalizēta sarežģītība), kuriem jūs justos droši, pievienojoties zvanu rotācijai, lai atbalstītu.
+
+Skatīt arī:
+
+- [Conwaya likums](#conways-likums)
+
+### Galla likums
+
+[Galla likums Vikipēdijā](https://en.wikipedia.org/wiki/John_Gall_(autors)#Gall's_law)
+
+> Salikta sistēmā, kas darbojas, pastāvīgi tiek atrasta, ka tā ir attīstījusies no vienkāršas sistēmas, kas darbojās. Sarežģīta sistēma, kas veidota no nulles, nekad nedarbojas, un to nevar patukšot, lai tā darbotos. Jāsāk ar vienkāršu darba sistēmu.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(autors)))
+
+Gall likums nozīmē, ka mēģinājumi _izstrādāt_ ļoti sarežģītas sistēmas var neizdoties. Ļoti sarežģītas sistēmas reti tiek veidotas vienā paņēmienā, bet attīstās no vienkāršākām sistēmām.
+
+Klasiskais piemērs ir vispasaules tīmeklis. Pašreizējā stāvoklī tā ir ļoti sarežģīta sistēma. Tomēr sākotnēji tas tika definēts kā vienkāršs veids satura koplietošanai starp akadēmiskajām institūcijām. Tas bija ļoti veiksmīgs šo mērķu sasniegšanā un attīstījās, lai laika gaitā kļūtu sarežģītāks.
+
+Skatīt arī:
+
+- [KISS (keep It Simple, Stupid)](#kiss-princips)
+
+### Goodharta likums
+
+[Goodharta likums Vikipēdijā](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> jebkura novērotā statistiskā regularitāte var sabrukt, kad uz to tiek izdarīts spiediens kontroles nolūkā.
+>
+> _Charles Goodhart_
+
+Bieži minēts arī kā:
+
+> kad pasākums kļūst par mērķi, tas vairs nav labs pasākums.
+>
+> _Merilinas Strathern_
+
+Likums nosaka, ka pasākuma virzītā optimizācija var izraisīt paša mērījumu rezultāta devalvāciju. Pārāk selektīvs pasākumu kopums ([KPI](https://en.wikipedia.org/wiki/Performance_indicator)), ko akli piemēro procesam, rada izkropļotu ietekmi. Cilvēki mēdz optimizēt vietējā līmenī, “spēlējot” sistēmu, lai tā atbilstu īpašiem rādītājiem, nevis pievērstu uzmanību viņu darbību visaptverošajiem rezultātiem.
+
+Reālpasaules piemēri:
+
+- izmēģinājumi bez pārbaudes atbilst koda pārklājuma prognozēm, neskatoties uz to, ka metrikas nolūks bija izveidot labi pārbaudītu programmatūru.
+- izstrādātāja snieguma rezultāts, ko norāda veikto rindu skaits, noved pie nepamatoti uzpūstas kodebāzes.
+
+Skatīt arī:
+
+- [Goodharta likums: How Measuring The Wrong Things Drive Immoral Bemoral haviour](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
+
+### Hanlons Razors
+
+[Hanlon's Razor Vikipēdijā](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
+
+> nekad nepiedēvē ļaunprātību, kas ir pietiekami izskaidrota ar muļķību.
+>
+> Roberts J. Hanlons
+
+Šis princips liek domāt, ka darbības, kas rada negatīvu rezultātu, nav sliktas gribas rezultāts. Tā vietā negatīvais iznākums drīzāk tiek attiecināts uz šīm darbībām un/vai ietekme netiek pilnībā izprasta.
+
+### Hofstadtera likums
+
+[Hefstadtera likums Vikipēdijā](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
+
+> Tas vienmēr aizņem vairāk laika, nekā jūs domājat, pat ņemot vērā Hofštera likumu.
+>
+> (Duglass Hofstadters)
+
+Jūs varētu dzirdēt, kā šis likums tiek pieminēts, skatoties uz aprēķiniem, cik ilgi kaut kas notiks. Šķiet, ka programmatūras izstrādes triks ir tāds, ka mēs nemēdzam precīzi novērtēt, cik ilgs laiks būs vajadzīgs, lai to paveiktu.
+
+Tas ir no grāmatas “[Gödel, Escher, Bahs: An Mūžīgais Zelta Breidijs](#lasīšanas-saraksts)”.
+
+Skatīt arī:
+
+- [Lasīšanas saraksts: Gödel, Escher, Baach: An Mūžīgais zelta Breids](#lasīšanas-saraksts)
+
+### Hutbera likums
+
+[Hutbera likums Vikipēdijā](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Uzlabošanās nozīmē nolietošanos.
+>
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+Šis likums liek domāt, ka sistēmas uzlabojumi novedīs pie citu daļu pasliktināšanās vai arī apslēps citu pasliktināšanos, kas kopumā novedīs pie degradācijas no sistēmas pašreizējā stāvokļa.
+
+Piemēram, atbildes latentuma samazināšanās konkrētā galapunktā varētu radīt papildu caurlaidspējas un jaudas problēmas pieprasījuma plūsmā, ietekmējot pilnīgi citu apakšsistēmu.
+
+### Hype Cycle & Amara likums
+
+[Hype Cycle Vikipēdijā](https://en.wikipedia.org/wiki/Hype_cycle)
+
+> Mēs pārāk augstu vērtējam tehnoloģijas ietekmi īstermiņā un nepietiekami novērtējam tās ietekmi ilgtermiņā.
+>
+> (Rojs Amara)
+
+Hype Cycle ir Gārtnera sākotnēji ražotās tehnoloģijas saviļņojuma un attīstības vizuāls attēlojums laika gaitā. Vislabāk to rāda vizuāli:
+
+![The Hype Cycle](../images/gartner_hype_cycle.png)
+
+*(Atsauce uz attēlu: angļu valodā Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+Īsāk sakot, šis cikls liecina, ka parasti rodas satraukums par jaunām tehnoloģijām un to iespējamo ietekmi. Komandas bieži vien ātri iesoļo šajās tehnoloģijās un reizēm jūtas vīlušās ar rezultātiem. Tas varētu būt tāpēc, ka tehnoloģija vēl nav pietiekami izstrādāta vai arī reālie lietojumi vēl nav pilnībā īstenoti. Pēc zināma laika tehnoloģijas iespējas palielinās un praktiskās iespējas to izmantot palielinās, un komandas beidzot var kļūt ražīgas. Rojs Amars (Roy Amara) citēja šo jautājumu visskaļāk: “Mums ir tendence pārvērtēt tehnoloģijas ietekmi īstermiņā un novērtēt to par zemu ilgtermiņā.”
+
+### Hiruma likums (Perifērisko saskarņu likums)
+
+[Hiruma likums Online](http://www.hyrumslaw.com/)
+
+> Ar pietiekamu API lietotāju skaitu,
+> nav svarīgi, ko jūs solāt līgumā:
+> visas novērojamās sistēmas darbības
+> būs atkarīgs no kāda.
+>
+> (Hyrum Wright)
+
+Hirum likums nosaka, ka tad, ja jums ir _pietiekami liels API patērētāju skaits_, visas API darbības (pat tās, kas nav definētas kā publiskā līguma daļa) galu galā būs atkarīgas no kāda. Triviāls piemērs var būt nefunkcionāli elementi, piemēram, API atbildes laiks. Smalkāks piemērs varētu būt patērētāji, kas paļaujas uz regex piemērošanu kļūdas ziņojumam, lai noteiktu API kļūdas *tipu*. Pat tad, ja API publiskajā līgumā nav norādīts ziņojuma saturs, norādot, ka lietotājiem jālieto saistītais kļūdas kods, _daži_ lietotāji var izmantot ziņojumu un, mainot ziņojumu, būtībā tiek pārtraukta API šiem lietotājiem.
+
+Skatīt arī:
+
+- [Leaky Abstractions likums](#the-law-of-dioxide-freshctions)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Kernigana likums
+
+> Atkļūdošana ir divreiz smagāka nekā koda rakstīšana pirmajā vietā. Tāpēc, ja jūs uzrakstāt kodu pēc iespējas gudrāk, jūs pēc definīcijas neesat pietiekami gudrs, lai to atkļūdotu.
+>
+> (Brian Kernighan)
+
+Kernigana likums ir nosaukts [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) un atvasināts no citāta no Kernighan un Plaugera grāmatas [Programmēšanas stila elementi](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+
+> Visi zina, ka atkļūdošana ir divreiz smagāka nekā programmas rakstīšana. Tātad, ja tu esi tik gudrs, cik vari būt, kad tu to raksti, kā tu jebkad to atkļūsi?
+
+Lai gan Kernigana likums ir hiperbolisks, tas ir arguments, ka vienkāršam kodam ir jādod priekšroka attiecībā pret sarežģītu kodu, jo jebkuru sarežģītā koda jautājumu atkļūdošana var būt dārga vai pat neiespējama.
+
+Skatīt arī:
+
+- [KISS princips](#kiss-princips)
+- [Unix filozofija](#unix-filozofija)
+- [Occam's Razor](#occams-razor)
+
+### Metkalfa likums
+
+[Metkalfea likums Vikipēdijā](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> Tīkla teorijā sistēmas vērtība pieaug aptuveni pēc sistēmas lietotāju skaita kvadrāta.
+
+Šis likums ir balstīts uz iespējamo pārtikušo savienojumu skaitu sistēmā un ir cieši saistīts ar [Reeda likums](#reeda-likums). Odlyzko un citi apgalvoja, ka gan Rīda likums, gan Metkalfa likums nosaka pārāk augstu sistēmas vērtību, neņemot vērā cilvēku izziņas robežas attiecībā uz tīkla ietekmi; skatīt [Danbara numurs](#dunbars-number).
+
+Skatīt arī:
+
+- [Reeda likums](#reeda-likums)
+- [Danbara numurs](#Danbara-numurs)
+
+### Mora likums
+
+[Mora likums Vikipēdijā](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Tranzistoru skaits integrālajā shēmā divkāršojas aptuveni reizi divos gados.
+
+Mora prognozes ir ļoti precīzas no 1970. gadiem līdz pat 2000. gadu beigām. Pēdējos gados tendence ir nedaudz mainījusies, daļēji pateicoties [fiziskās robežas pakāpei, kādā komponentus var miniaturizēt](https://en.wikipedia.org/wiki/Quantum_tunnelling). Tomēr progress paralēlizācijā un, iespējams, revolucionāras izmaiņas pusvadītāju tehnoloģijā un kvantu skaitļošanā var nozīmēt, ka Mora likums varētu būt spēkā arī turpmākajos gadu desmitos.
+
+### Mērfija likums/Soda likums
+
+[Mērfija likums Vikipēdijā](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Jebkas, kas var noiet greizi, noies greizi.
+
+Saistībā ar [Edvards A. Mērfijs, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Mērfija likums_ teikts: ja kaut kas var noiet greizi, tas noies greizi.
+
+Tā ir vispārpieņemta izvēle izstrādātāju vidū. Dažreiz tas negaidītais notiek, attīstoties, testējot vai pat ražojot. Tas var būt saistīts arī ar (biežāk angļu valodā) _Sod's Law_:
+
+> Ja kaut kas var noiet greizi, tas notiks vissliktākajā laikā.
+
+Šos “likumus” parasti izmanto komiskā nozīmē. Tomēr tādas parādības kā [_Confirmation Bias_](#TODO) un [_Selection Bias_](#TODO) var likt cilvēkiem, iespējams, pārmērīgi uzsvērt šos likumus (lielākā daļa gadījumu, kad lietas darbojas, tās paliek nepamanītas, tomēr kļūmes ir pamanāmākas un rosina vairāk diskusiju).
+
+Skatīt arī:
+
+- [Bias apstiprinājums](#TODO)
+- [Bias atlases](#TODO)
+
+### Okuta Razors
+
+[Occam's Razor Vikipēdijā](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Entītijas nedrīkst reizināt bez nepieciešamības.
+>
+> Oklema Viljams
+
+Ouema skuveklis stāsta, ka starp vairākiem iespējamiem risinājumiem ticamākais risinājums ir tas, kuram ir vismazākais jēdzienu un pieņēmumu skaits. Šis risinājums ir vienkāršākais un atrisinās tikai dotā problēma, neieviešot nejaušu sarežģītību un iespējamās negatīvās sekas.
+
+Skatīt arī:
+
+- [YAGNI](#yagni)
+- [Bez sudraba aizzīme: hoc Compluncity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Piemērs:
+- [prospect Software Development: Eliminate Waste laundering](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Parkinsona likums
+
+[Parkinsona likums Vikipēdijā](https://en.wikipedia.org/wiki/Parkinson%27s_law)
+
+> Darbs tiek izvērsts, lai aizpildītu laiku, kas ir pieejams tā pabeigšanai.
+
+Tā sākotnējā kontekstā šis likums balstījās uz birokrātijas pētījumiem. Tas var tikt pesimistiski piemērots programmatūras izstrādes iniciatīvām, jo teorija ir tāda, ka darba grupas būs neefektīvas līdz termiņa beigām, bet pēc tam steidzas pabeigt darbu līdz noteiktajam termiņam, tādējādi padarot faktisko termiņu nedaudz patvaļīgu.
+
+Ja šis likums tiktu apvienots ar [Hofštera likumu](#hofstadtera-likums), tad tiek panākts vēl pesimistiskāks viedoklis - darbs paplašināsies, lai aizpildītu tā pabeigšanai pieejamo laiku, un *joprojām paies ilgāk, nekā paredzēts*.
+
+Skatīt arī:
+
+- [Hofstadtera likums](#hofstadtera-likums)
+
+### Priekšlaicīgas optimizācijas efekts
+
+[Priekšlaicīga optimizācija WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> Priekšlaicīga optimizācija ir visa ļaunuma sakne.
+>
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+Donalda Knuta (Donald Knuth) rakstā [Structured Programming With Go To Deements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) viņš rakstīja: „Programmeri tērē milzīgus laika apjomus, domājot par savu programmu nekritisko daļu ātrumu vai raizējoties par to, un šiem efektivitātes mēģinājumiem patiesībā ir liela negatīva ietekme, ja tiek apsvērta atkļūdošana un uzturēšana. Mums vajadzētu aizmirst par nelielu efektivitāti, teiksim par 97% no laika: **priekšlaicīga optimizācija ir visa ļaunuma sakne**. Tomēr mums nevajadzētu izmantot savas iespējas šajā būtiskajā 3%.”
+
+Tomēr _Premature Optimization_ var definēt (mazāk noslogotā izteiksmē) kā optimizāciju, pirms mēs zinām, ka tas ir nepieciešams.
+
+### Putta likums
+
+[Putta likums Vikipēdijā](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Tehnoloģijā dominē divu veidu cilvēki, tie, kas saprot, ko nepārvalda, un tie, kas pārvalda to, ko nesaprot.
+
+Flowera likums bieži seko līdzi Putt Corollary:
+
+> katra tehniskā hierarhija laika gaitā attīsta kompetences neversiju.
+
+Šie paziņojumi liecina, ka, ņemot vērā dažādus atlases kritērijus un tendences attiecībā uz grupu organizāciju, būs daudz kvalificētu cilvēku tehniskās organizācijas darba līmenī un vairāki cilvēki vadošos amatos, kuri neapzinās viņu vadītā darba sarežģītību un problēmas. To var izraisīt tādas parādības kā [The Peter Principle](#the-peter-principle) vai [The Dilbert Principle](#the-dilbert-principle).
+
+Tomēr jāuzsver, ka šādi tiesību akti ir plaši vispārinājumi un var attiekties uz _dažiem_ organizāciju veidiem, nevis uz citiem.
+
+Skatīt arī:
+
+- [Peter Principle](#petera-princips)
+- [Dilberta princips](#dilberta-princips)
+
+### Reeda likums
+
+[Reeda likums Vikipēdijā](https://en.wikipedia.org/wiki/Reed's_law)
+
+> Lielo tīklu, it īpaši sociālo tīklu, lietderība ir atkarīga no tīkla lieluma.
+
+Šis likums balstās uz grafiku teoriju, kur lietderības mērogs ir kā iespējamo apakšgrupu skaits, kas ir ātrāks par dalībnieku skaitu vai iespējamo pārotāju savienojumu skaitu. Odlyzko un citi apgalvoja, ka Rīda likums nosaka sistēmas lietderību, nerēķinoties ar cilvēku izziņas ierobežojumiem attiecībā uz tīkla ietekmi; sk. [Danbara numurs](#Danbara-numurs).
+
+Skatīt arī:
+
+- [Metkalfa likums](#metkalfa-likums)
+- [Danbara numurs](#Danbara-numurs)
+
+### Taisnīguma saglabāšanas likums (Teslera likums)
+
+[Likums par stabilitātes saglabāšanu attiecībā uz Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Šis likums nosaka, ka sistēmā, kuru nevar samazināt, pastāv zināma sarežģītības pakāpe.
+
+Sistēmas sarežģītība ir “netīša”. Tās ir vājās struktūras, kļūdu vai tikai sliktas problēmas modelēšanas sekas. Nejaušu sarežģītību var samazināt (vai novērst). Tomēr, ņemot vērā problēmas sarežģītību, pastāv zināma sarežģītība. Šo sarežģītību var pārvietot, bet ne likvidēt.
+
+Viens no šā likuma interesantākajiem elementiem ir ieteikums, ka pat vienkāršojot visu sistēmu, netiek samazināta iekšējā sarežģītība, tas ir _jāpārvieto uz lietotāju_, kam jāuzvedas sarežģītāk.
+
+### “Leaky Abstractions” likums
+
+[The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-dioxide-freshctions/)
+
+> Visas netriviālās abstrakcijas zināmā mērā ir sūces.
+>
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+Šis likums nosaka, ka abstrakcijas, ko parasti izmanto skaitļošanā, lai vienkāršotu darbu ar sarežģītām sistēmām, noteiktās situācijās “noplūdīs” pamatsistēmas elementi, tādējādi padarot abstrakciju neparedzētu.
+
+Kā piemēru var minēt faila ielādi un tā satura lasīšanu. Failu sistēmas API ir zemāka līmeņa kodola sistēmu _abstrakcija_, kas pati par sevi ir abstrakcija pār fiziskajiem procesiem, kas saistīti ar datu maiņu magnētiskajā platē (vai zibatmiņu SSD). Vairumā gadījumu faila apstrāde kā bināro datu straume būs efektīva. Taču magnētiskajam diskam nolasāmie dati secīgi būs *ievērojami* ātrāki nekā brīvpiekļuves (jo palielinās lapu defektu pārsniegums), bet SSD diskdzinim šī pieskaitāmība nebūs. Lai risinātu šo gadījumu, būs jāizprot pamatinformācija (piemēram, datu bāzes indeksa faili ir strukturēti tā, lai samazinātu brīvpiekļuves pieskaitāmo daļu), bet izstrādātājam, iespējams, ir jāzina abstrakcijas “noplūžu” ieviešanas detaļas.
+
+Iepriekš minētais piemērs var kļūt sarežģītāks, ieviešot _vairāk_ abstrakciju. Operētājsistēma Linux ļauj piekļūt failiem, izmantojot tīklu, bet tā ir lokāli attēlota kā “parastie” faili. Šī abstrakcija “noplūdīs”, ja radīsies tīkla kļūmes. Ja izstrādātājs uzskata šos failus par “parastiem” failiem, neņemot vērā to, ka tie var būt pakļauti tīkla latentumam un kļūmēm, risinājumi būs neefektīvi.
+
+Tiesību aktu aprakstošais pants liecina, ka pārmērīga paļaušanās uz abstrakcijām apvienojumā ar vāju izpratni par pamatā esošajiem procesiem, atsevišķos gadījumos liek risināt šo problēmu _vairāk_ sarežģīti.
+
+Skatīt arī:
+
+- [Hyruma likums](#hyruma-likums-perifērisko-saskarņu-likums)
+
+Reālpasaules piemēri:
+
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - problēma, ar kuru saskāros agrāk. Photoshop startēšana bija lēna, dažreiz tas prasīja dažas minūtes. Šķiet, problēma bija tā, ka startējot tas nolasa daļu informācijas par pašreizējo noklusējuma printeri. Tomēr, ja šis printeris faktiski ir tīkla printeris, tas var aizņemt ļoti ilgu laiku. Tīkla printera _abstrakcija_, kas tiek prezentēta sistēmai līdzīgi lokālajam printerim, radīja problēmas lietotājiem sliktā savienojamības situācijā.
+
+### Trivialitātes likums
+
+[Trivialitātes likums Vikipēdijā](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+Šis likums liek domāt, ka grupas daudz vairāk laika un uzmanības veltīs triviāliem vai kosmētiskiem jautājumiem, nevis nopietniem un būtiskiem.
+
+Kopējais izdomātais piemērs ir komiteja, kas apstiprina plānus atomelektrostacijai, kura lielāko daļu laika pavada, apspriežot velosipēdistu nojumes struktūru, nevis pašu nozīmīgāko spēkstacijas projektu. Var būt grūti sniegt vērtīgu ieguldījumu diskusijās par ļoti lielām, komplicētām tēmām bez augstas kompetences vai sagatavotības. Tomēr cilvēki vēlas saņemt vērtīgu ieguldījumu. Tādēļ tendence pārāk daudz laika veltīt sīkumiem, par kuriem var viegli spriest, bet kuri ne vienmēr ir īpaši svarīgi.
+
+Iepriekš aprakstītais piemērs lika lietot terminu “Bike Shedding” kā izteicienu, lai izšķiestu laiku triviāliem sīkumiem. Saistītais termins ir “[Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving)”, kas saista šķietami nebūtisku darbību, kas ir daļa no gara priekšnosacījumu ķēdes galvenajam uzdevumam.
+
+### Unix filozofija
+
+[Unix filozofija Vikipēdijā](https://en.wikipedia.org/wiki/Unix_philosophy)
+
+Unix filozofija ir tāda, ka programmatūras komponentiem jābūt maziem un jābūt vērstiem uz to, lai labi paveiktu vienu konkrētu lietu. Tas var atvieglot sistēmu izveidi, izveidojot kopā mazas, vienkāršas, labi definētas vienības, nevis izmantojot lielas, sarežģītas, daudzfunkcionālas programmas.
+
+Mūsdienu praksi, piemēram, "Microservice arhitektūru”, var uzskatīt par šī likuma piemērošanu, kur pakalpojumi ir mazi, koncentrēti un dara vienu konkrētu lietu, ļaujot kompleksai rīcībai veidot vienkāršus veidošanas blokus.
+
+### Spotify modelis
+
+[Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+“Spotify” modelis ir pieeja komandas un organizācijas struktūrai, ko popularizē “Spotify”. Šajā modelī komandas tiek organizētas ap funkcijām, nevis tehnoloģijām.
+
+Spotify modelis popularizē arī Tribes, Guilds, Chapters jēdzienus, kas ir citi to organizācijas struktūras elementi.
+
+### Wadlera likums
+
+[Lunga likums on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> jebkurā valodas dizainā kopējais laiks, kas pavadīts, apspriežot kādu līdzekli šajā sarakstā, ir proporcionāls diviem, kas izvirzīti tā atrašanās vietai.
+>
+> 0. Semantika
+> 1. Sintakse
+> 2. Leksiskā sintakse
+> 3. Komentāru leksiskā sintakse
+>
+> (īsāk sakot, par katru semantiku pavadīto stundu komentāru sintaksē tiks pavadītas 8 stundas).
+
+Līdzīgi kā [Trivialitātes likums](#trivialitātes-likums), Wadlera likums nosaka, ka, projektējot valodu, laika apjoms, kas tiek tērēts valodas konstrukcijām, ir nesamērīgi augsts salīdzinājumā ar šo iezīmju nozīmi.
+
+Skatīt arī:
+
+- [Trivialitātes likums](#trivialitātes-likums)
+
+### Wheaton likums
+
+[Saite](http://www.wheatonslaw.com/)[Oficiālā diena](https://dontbeadickday.com/)
+
+> Neesi stulbenis.
+>
+> _Wil Wheaton_
+
+Šī vienkāršā, lakoniskā un spēcīgā likuma mērķis ir palielināt harmoniju un cieņu profesionālajā organizācijā. To var izmantot, runājot ar kolēģiem, veicot koda pārskatīšanu, cīnoties pret citiem skatījumiem, kritizēšanu un kopumā lielāko daļu profesionālo mijiedarbību ar cilvēkiem.
+
+## Principi
+
+Parasti ir lielāka iespēja, ka principi ir pamatnostādnes, kas attiecas uz dizainu.
+
+### Dilberta princips
+
+[Dilberta princips Vikipēdijā](https://en.wikipedia.org/wiki/Dilbert_principle)
+
+> uzņēmumos tiek sistemātiski reklamēti nekompetenti darbinieki vadībai, lai tos izdabūtu no darbplūsmas.
+>
+> _Scott Adams_
+
+Vadības konceptu, ko izstrādājis Skots Adamss (Dilbert komiksu striptīza radītājs), Dilbert Princips iedvesmo [The Peter Principle](#the-peter-principle). Saskaņā ar Dilbert principu darbinieki, kas nekad nav bijuši kompetenti, tiek paaugstināti vadībā, lai ierobežotu kaitējumu, ko viņi var nodarīt. Adams vispirms izskaidroja šo principu 1995. gada “Wall Street Journal” rakstā un izvērsa to savā 1996. gada uzņēmējdarbības grāmatā [The Dilbert Principle](#lasīšanas-saraksts).
+
+Skatīt arī:
+
+- [Petera princips](#petera-princips)
+- [Putta likums](#putta-likums)
+
+### Pareto princips (kārtula 80/20)
+
+[Pareto Principle Vikipēdijā](https://en.wikipedia.org/wiki/Pareto_principle)
+
+> Vairums lietu dzīvē netiek sadalītas vienmērīgi.
+
+Pareto princips liecina, ka dažos gadījumos lielākā daļa rezultātu nāk no nelieliem ieguldījumiem:
+- 80% no noteiktas programmatūras var rakstīt 20% no kopējā piešķirtā laika (pretēji tam, visgrūtākie 20% no koda aizņem 80% laika).
+- 20% no piepūles veido 80% no rezultāta,
+- 20% no darba rada 80% no ieņēmumiem,
+- 20% atkritumu izraisa 80% avāriju
+- 20% līdzekļu izraisa 80% lietošanas
+
+1940. gadā amerikāņu un rumāņu inženieris doktors Džozefs Jurans (Joseph Juran), kurš plaši tiek ieskaitīts kā kvalitātes kontroles tēvs, sāka piemērot Pareto principu attiecībā uz kvalitātes jautājumiem (https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+Šis princips ir pazīstams arī kā 80/20 likums, Vital Few likums un The Principle of Factor Sparsity.
+
+Reālpasaules piemēri:
+
+- 2002. gadā korporācija Microsoft ziņoja, ka, fiksējot 20% lielāko visvairāk ziņoto kļūdu, tiks novērstas 80% saistīto kļūdu un avāriju logos un birojos ([Atsauce](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-'t-just-features.htm)).
+
+### Pētera princips
+
+[Peter Principle Vikipēdijā](https://en.wikipedia.org/wiki/Peter_principle)
+
+> Cilvēki hierarhijā tiecas sasniegt savu “nekompetences līmeni”.
+>
+> _Laurence J. Peter_
+
+Laurences J. Peteras (Peter Principle) izstrādātajā vadības koncepcijā norādīts, ka tiek reklamēti cilvēki, kas labi strādā savā darbavietā, līdz sasniedz līmeni, kurā viņi vairs nav veiksmīgi (viņu “nekompetences līmenis”. Šobrīd, tā kā viņi ir vecākie, ir mazāk ticams, ka viņi tiks izņemti no organizācijas (ja vien viņi nedarbosies īpaši slikti), un viņi turpinās strādāt tādā lomā, kurā viņiem ir maz iedzimtas prasmes, jo viņu sākotnējās prasmes, kas viņus padarījušas veiksmīgus, ne vienmēr ir vajadzīgas viņu jaunajiem darbiem.
+
+Tas jo īpaši interesē inženierus, kuri sākotnēji sāk pildīt ļoti tehniskas funkcijas, bet kuriem bieži vien ir karjeras ceļš, kas liek _vadīt_ citus inženierus, - kam ir nepieciešams būtiski atšķirīgs prasmju kopums.
+
+Skatīt arī:
+
+- [Dilberta princips](#dilberta-princips)
+- [Putta likums](#putta-likums)
+
+### Uzturības princips (Postel's Law)
+
+[Stabilitātes princips Vikipēdijā](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Esiet konservatīvi pret to, ko darāt, esiet liberāli tajā, ko pieņemat no citiem.
+
+Bieži lietots serveru lietojumprogrammu izstrādē, šis princips nosaka, ka tam, ko sūtāt citiem, ir jābūt pēc iespējas mazākam un atbilstošam, bet, ja to var apstrādāt, ir jācenšas atļaut nestandarta ievadi.
+
+Šā principa mērķis ir izveidot stabilas sistēmas, jo tās var izmantot vāju ieguldījumu, ja to vēl var saprast. Tomēr ir iespējamas sekas saistībā ar drošību, pieņemot nepareizi ievadītus datus, jo īpaši, ja šādu resursu apstrāde nav labi pārbaudīta.
+
+Ja laikus tiks pieļauta neatbilstība, protokola spēja attīstīties var mazināties, jo, lai veidotu savas iezīmes, īstenotāji, iespējams, paļausies uz šo liberalitāti.
+
+Skatīt arī:
+
+- [Hyruma likums](#hyruma-likums-perifērisko-saskarņu-likums)
+
+### SOLID
+
+Tas ir akronīms, kas attiecas uz:
+
+* S: [Vienotās atbildības princips](#vienotās-atbildības-princips)
+* O: [Atklātais/slēgtais princips](#atklātaisslēgtais-princips)
+* L: [Liskova aizstāšanas princips](#liskova-aizstāšanas-princips)
+* I: [Interfeisa segmenta noteikšanas princips](#interfeisa-segmenta-noteikšanas-princips)
+* D: [Atkarības inversijas princips](#atkarības-inversijas-princips)
+
+Šie ir galvenie principi programmā [Object-oriented Programming](#TODO). Projektēšanas principiem ir jābūt tādiem, kas var palīdzēt izstrādātājiem veidot labāk funkcionējošas sistēmas.
+
+### Vienotās atbildības princips
+
+[Vienotās atbildības princips Vikipēdiā](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> katram modulim vai klasei ir jābūt tikai vienai atbildībai.
+
+Pirmais no “[SOLID](#solid)” principiem. Šis princips liek domāt, ka moduļiem vai klasēm būtu jādara tikai viens un tikai viens. Praktiskāk tas nozīmē, ka, veicot vienu nelielu programmas līdzekļa maiņu, ir jāmaina tikai viens komponents. Piemēram, paroles validācijas sarežģītības dēļ ir jāmaina tikai viena programmas daļa.
+
+Teorētiski tam vajadzētu padarīt kodu spēcīgāku un vieglāk maināmu. Zinot, ka pārveidojamam komponentam ir tikai viena atbildība, tas nozīmē, ka _testēt_ šīs izmaiņas ir vieglāk. Izmantojot iepriekšējo piemēru, paroles sarežģītības komponenta maiņa var ietekmēt tikai ar paroles sarežģītību saistītos līdzekļus. Daudz grūtāk var būt pamatot pārmaiņu ietekmi uz komponentu, kam ir daudz pienākumu.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+
+### Open/Slēgts princips
+
+[Atklātais/slēgtais princips Vikipēdijā](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
+
+> entītijām jābūt atvērtām paplašinājumam un slēgtām modificēšanai.
+
+Otro no “[SOLID](#solid)” principiem. Šis princips nosaka, ka subjektiem (kas varētu būt klases, moduļi, funkcijas utt.) jābūt iespējai īstenot savu darbību _prolongēt_, bet to _esošo_ uzvedību nedrīkst mainīt.
+
+Kā hipotētisku piemēru iedomājieties moduli, kas var pārvērst Piezīmes dokumentu HTML formātā. Ja moduli varētu paplašināt, lai to varētu izmantot nesen ierosinātajai vērtības samazināšanas funkcijai, nemainot moduli, tas būtu atvērts paplašinājumam. Ja lietotājs varētu modificēt moduli _not_, lai ar to varētu rīkoties tagad, kad tiek apstrādāti esošie salīdzināšanas līdzekļi, tad tas būtu _slēgts_ modificēšanai.
+
+Šim principam ir īpaša nozīme attiecībā uz uz objektu vērstu programmēšanu, kur mēs varam projektēt objektus, lai tos varētu viegli paplašināt, bet mēs izvairītos no tādu objektu projektēšanas, kuru pašreizējā uzvedība var negaidīti mainīties.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+
+### Liskova aizstāšanas princips
+
+[Liskova aizstāšanas princips Vikipēdijā](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
+
+> ir jābūt iespējai aizstāt tipu ar apakštipu, nelaužot sistēmu.
+
+Trešais no “[SOLID](#solid)” principiem. Šis princips nosaka, ka, ja kāds komponents balstās uz kādu tipu, tad tam vajadzētu būt iespējai izmantot šāda tipa apakštipus, bez sistēmas kļūmes vai informācijas par to, kas ir šis apakštips.
+
+Piemēram, iedomājieties, ka mums ir metode, kas nolasa XML dokumentu no struktūras, kas apzīmē failu. Ja metodē ir izmantots bāzes tips “fails”, funkcijā var izmantot jebko, kas izriet no “fails”. Ja 'fails' atbalsta meklēšanu atpakaļgaitā un XML parsētājs izmanto šo funkciju, bet atvasinātais tips 'tīkla fails' neizdodas, mēģinot veikt reverso meklēšanu, tad 'tīkla fails' pārkāptu principu.
+
+Šim principam ir īpaša nozīme uz objektu orientētā programmēšanā, kur tipa hierarhijas ir rūpīgi jāmodelē, lai izvairītos no sistēmas lietotāju apjukuma.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+
+### Interfeisa segmenta noteikšanas princips
+
+[Interfeisa segmenta noteikšanas princips Vikipēdijā](https://en.wikipedia.org/wiki/Interface_segregation_principle)
+
+> Neviens klients nedrīkst būt atkarīgs no metodēm, ko tas neizmanto.
+
+Ceturtā daļa no “[SOLID](#solid)” principiem. Šis princips nosaka, ka kāda komponenta patērētājiem nevajadzētu būt atkarīgiem no tā komponenta funkcijām, kuru tie faktiski neizmanto.
+
+Piemēram, iedomājieties, ka mums ir metode, kas nolasa XML dokumentu no struktūras, kas apzīmē failu. Tai tikai jālasa baiti, jāpārvietojas uz priekšu vai jāpārvietojas atpakaļ failā. Ja šī metode ir jāatjaunina, jo mainās ar failu struktūru nesaistīts faila struktūras līdzeklis (piemēram, faila drošības apzīmēšanai izmantotā atļauju modeļa atjauninājums), princips ir anulēts. Labāk būtu, ja fails ieviestu 'tries-stream' interfeisu un XML lasītājs to izmantotu.
+
+Šim principam ir īpaša nozīme uz objektu orientētajā programmēšanā, kur tiek izmantotas saskarnes, hierarhijas un abstrakti tipi, lai [minimizētu savienošanu](#TODO) starp dažādiem komponentiem. [pīļu tipizēšana](#TODO) ir metodika, kas ievieš šo principu, novēršot nepārprotamas saskarnes.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+- [pīļu tipēšana](#TODO)
+- [atsaiste](#TODO)
+
+### Atkarības inversijas princips
+
+[Atkarības inversijas princips](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
+
+> Augsta līmeņa moduļi nedrīkst būt atkarīgi no zema līmeņa ieviešanas.
+
+Piektā daļa no “[SOLID](#solid)” principiem. Šis princips nosaka, ka lielāka līmeņa orķestrācijas komponentiem nav jāzina to atkarības detaļas.
+
+Piemēram, iedomājieties, ka mums ir programma, kas lasa metadatus no vietnes. Mēs pieņemam, ka galvenais komponents būtu jāzina par komponentu, lai lejupielādētu tīmekļa lapas saturu, pēc tam komponentu, kas var lasīt metadatus. Ja mēs ņemtu vērā atkarības inversiju, galvenais komponents būtu atkarīgs tikai no abstrakta komponenta, kas var iegūt baitu datus, un pēc tam no abstrakta komponenta, kas spētu nolasīt metadatus no baitu straumes. Galvenais komponents nezinātu par TCP/IP, HTTP, HTML utt.
+
+Šis princips ir sarežģīts, jo var šķist, ka tas "apgriež” sagaidāmās sistēmas (tātad nosaukuma) atkarības. Praksē tas nozīmē arī to, ka atsevišķam orķestrācijas komponentam ir jānodrošina abstrakto tipu pareiza ieviešana (piemēram, iepriekšējā piemērā _kaut kam_ joprojām ir jānodrošina metadatu lasītāja komponents HTTP faila lejupielādētājs un HTML metatagu lasītājs). Tas pieskaras tādiem modeļiem kā [Inversion of Control](#TODO) un [Atkarības injekcija](#TODO).
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+- [Control inversija](#TODO)
+- [Atkarības injekcija](#TODO)
+
+### DRY princips
+
+[DRY princips Vikipēdijā](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Katram zināšanu gabalam ir jābūt vienotam, nepārprotamam, autoritatīvam attēlojumam sistēmā.
+
+DRY ir akronīms _Neatkārtot sevi_. Šī principa mērķis ir palīdzēt izstrādātājiem samazināt koda atkārtojumu un saglabāt informāciju vienā vietā, un 1999. gadā to citēja Endrū Bads un Deivs Tomass grāmatā [The Praietverot izstrādātāju](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+> PRETĒJS sausums būtu _WET_ (Rakstiet All Twice vai We Enjoy Typing).
+
+Praksē, ja jums ir viena un tā pati informācija divās (vai vairākās) dažādās vietās, varat izmantot DRY, lai sapludinātu tās vienā un atkārtoti izmantotu visur, kur vēlaties/vajag.
+
+Skatīt arī:
+
+- [Pracistic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### KISS princips
+
+[KISS princips Vikipēdijā](https://en.wikipedia.org/wiki/KISS_principle)
+
+> saglabāt vienkāršu, stulbu
+
+KISS princips nosaka, ka vairums sistēmu darbojas vislabāk, ja tās ir vienkāršas, nevis sarežģītas; tāpēc vienkāršībai jābūt galvenajam mērķim, un jāizvairās no nevajadzīgas sarežģītības. Šī frāze, kuras izcelsme ir ASV Jūras kara flotē 1960. gadā, ir saistīta ar gaisa kuģu inženieri Kelliju Džonsonu.
+
+Šo principu vislabāk raksturo stāsts par to, ka Džonsons ir pasniedzis dizaina inženieru komandai sauju darbarīku, ar izaicinājumu, ka reaktīvo lidmašīnu, ko viņi projektēja, ir jālabo vidusmēra mehāniķim kaujas apstākļos ar tikai šiem rīkiem. Līdz ar to “muļķīgais” attiecas uz attiecību starp to, kā viss sabrūk, un to, cik sarežģīti ir instrumenti, kas ir pieejami, lai tos salabotu, nevis uz pašu inženieru spējām.
+
+Skatīt arī:
+
+- [Galla Likums](#galla-likums)
+
+### YAGNI
+
+[YAGNI Vikipēdijā](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
+
+Šis ir akronīms, kas paredzēts _**Y**ou **A**in't **G**onna **N**eed **I**t_.
+
+> vienmēr ieviesiet lietas, kad tās jums patiešām ir vajadzīgas, nekad neparedzot, ka jums tās ir nepieciešamas.
+>
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP līdzdibinātājs un grāmatas “Extreme Programming Installed” autors)
+
+Šis _Extreme Programming_ (XP) princips paredz, ka izstrādātājiem ir tikai jāievieš tūlītējām prasībām nepieciešamā funkcionalitāte un jāizvairās no mēģinājumiem prognozēt nākotni, ieviešot funkcionalitāti, kas varētu būt nepieciešama vēlāk.
+
+Ievērojot šo principu, būtu jāsamazina neizmantotā koda daudzums konvertācijā un jāizvairās no laika un pūles izniekošanas funkcionalitātei, kas nerada nekādu vērtību.
+
+Skatīt arī:
+
+- [Lasīšanas saraksts: Extreme Programming Installed](#lasīšanas-saraksts)
+
+### Dalītās datošanas maldības
+
+[Dalītās datošanas maldības Vikipēdijā](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+
+Fallacies, ko dēvē arī par _Networking Computing_, ir Fallacies saraksts ar pieņēmumiem (vai uzskatiem) par dalīto skaitļošanu, kas var novest pie kļūmēm programmatūras izstrādē. Pieņēmumi ir šādi:
+
+- tīkls ir uzticams
+- latentums ir nulle
+- joslas platums ir bezgalīgs
+- tīkls ir drošs
+- topoloģija nemainās
+- ir viens administrators,
+- transporta izmaksas ir nulle
+- tīkls ir viendabīgs
+
+Pirmo četru pozīciju sarakstā bija iekļauti [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) un [Tom Lyon](https://twitter.com/aka_pugs) aptuveni 1991. gadā, un tās pirmo reizi klasificēja [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) kā “Networks Computing” Fallacies. [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) pievienoja 5., 6. un 7. 90. gadu beigās Goslings pievienoja 8. maldu.
+
+Grupu iedvesmoja tas, kas tolaik notika [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+Šīs kļūdas būtu rūpīgi jāapsver, izstrādājot kodu, kas ir elastīgs; pieņemot, ka kāds no šiem viltojumiem var novest pie kļūdainas loģikas, kas nerisina dalīto sistēmu realitāti un sarežģītību.
+
+Skatīt arī:
+
+- [Barošana dalītās datošanas maldības (1. daļa) — Vaidehi Jošipar vidēju](https://medium.com/baseds/foraging-for-the-fallacies-of-trapped-part-1-1b35c3b85b53)
+- [Deutsch's Fallacies, 10 years After](http://java.sys-con.com/node/38665)
+
+## Lasīšanas saraksts
+
+Ja šos jēdzienus esat uzskatījis par interesantiem, varat baudīt šādas grāmatas.
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834).
+- [The Mythical Man Monthly - Frederik P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Klasisks sējums par programmatūras inženieriju. [Brūku likums](#bruku-likums) ir grāmatas galvenā tēma.
+- [Gödel, Escher, Bahs: An Mūžīgais Zelta Breids - Duglass R. Hofštters.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Šo grāmatu ir grūti klasificēt. [hofstadtera likums](#hofstadtera-likums) ir no grāmatas.
+- [Dilberta princips - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Komisks skats uz korporatīvo Ameriku, no autora, kurš radīja [Dilbert principu](#the-dilbert-principle).
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Vēl viens komisks skatījums uz lielāku organizāciju un tautas menedžmenta izaicinājumiem, [The Peter Principle](#the-peter-principle) avots.
+
+## Saistītie projekti
+
+- Dienas padoms - saņemiet ikdienas hakeru likumu/principu.
+
+## Ieguldījums
+
+Lūdzu, sniedziet ieguldījumu! [celiet problēmu](https://github.com/dwmkerr/hacker-laws/issues/new), ja vēlaties ierosināt papildinājumu vai izmaiņas, vai [Atvērt vilkšanas pieprasījumu](https://github.com/dwmkerr/hacker-law/compare), lai piedāvātu savas izmaiņas.
+
+Lūdzu, izlasiet [Ieguldījuma vadlīnijas](./.github/contributing.md) prasības par tekstu, stilu un tā tālāk. Iesaistoties diskusijās par projektu, lūdzu, ņemiet vērā [Uzvedības kodeksu](./.github/CODE_OF_CONDUCT.md).
+
+## TODO
+
+Sveiks! Ja jūs nolaisties šeit, jūs esat noklikšķinājis uz saites uz tēmu, kuru es vēl neesmu uzrakstījis, atvainojiet par to - šis ir darbs, kas notiek!
+
+Lai iesniegtu piedāvāto tēmas definīciju, varat [Raise an Issue](https://github.com/dwmkerr/hacker-law/issues) pieprasīt detalizētāku informāciju vai [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pull).

translations/pt-BR.md

@@ -52,7 +52,7 @@ Existem muitas leis que as pessoas discutem quando falam sobre desenvolvimento.
 
 <!--There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs! <!-->
 
-❗: Esse repositório comtém explicações sobre algumas léis, pincípios e padrões, mas não _advoca_ para nenhum. Se eles devem ser aplicados sempre é uma questão de debate, e depende diretamente no que você está trabalhando.
+❗: Esse repositório contém explicações sobre algumas léis, pincípios e padrões, mas não _advoca_ para nenhum. Se eles devem ser aplicados sempre é uma questão de debate, e depende diretamente no que você está trabalhando.
 
 ## Leis
 
@@ -68,7 +68,7 @@ Fica mais fácil de entender com um exemplo prático. Se um programa é feito de
 
 O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:
 
-![Diagram: Lei de Amadhl](./images/amdahls_law.png)
+![Diagram: Lei de Amadhl](../images/amdahls_law.png)
 
 *(Image Reference: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
 
@@ -153,11 +153,11 @@ This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de
 > Roy Amara
 
 O Ciclo Hype é uma representação visual da empolgação e desenvolvimento da tecnologia ao longo do tempo, originalmente produzida por Gartner.
-![The Hype Cycle](./images/gartner_hype_cycle.png)
+![The Hype Cycle](../images/gartner_hype_cycle.png)
 
 *(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
 
-Em curto prazo, o cilco sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impácto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivos. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
+Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impacto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real que não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivas. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
 
 
 ### Lei de Hyrum (A lei de interfaces implicitas)
@@ -172,7 +172,7 @@ Em curto prazo, o cilco sugere que acontece uma explosão de empolgação a cerc
 >
 > (Hyrum Wright)
 
-A lei de Hyrum sugere que quando voce tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API(mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
+A lei de Hyrum sugere que quando você tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API (mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
 
 Veja Também:
 

translations/tr.md

@@ -2,13 +2,7 @@
 
 Programcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler.
 
-- 🇨🇳 [中文 / Çince İçin](https://github.com/nusr/hacker-laws-zh) - Teşekkürler [Steve Xu](https://github.com/nusr)!
+[Çeviriler](#%C3%A7eviriler): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translationis/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr)
-- 🇮🇹 [Italyanca için](https://github.com/csparpa/hacker-laws-it) - Teşekkürler [Claudio Sparpaglione](https://github.com/csparpa)!
-- 🇰🇷 [한국어 / Korece İçin](https://github.com/codeanddonuts/hacker-laws-kr) - Teşekkürler [Doughnut](https://github.com/codeanddonuts)!
-- 🇷🇺 [Русская версия / Rusça İçin](https://github.com/solarrust/hacker-laws) - Teşekkürler [Alena Batitskaya](https://github.com/solarrust)!
-- 🇹🇷 [Türkçe / Turkçe İçin](https://github.com/umutphp/hacker-laws-tr) - Teşekkürler [Umut Işık](https://github.com/umutphp)
-- 🇧🇷 [Brasileiro / Brezilyaca İçin](./translations/pt-BR.md) - Teşekkürler [Leonardo Costa](https://github.com/LeoFC97)
-- 🇪🇸 [Castellano / İspanyolca İçin](./translations/es-ES.md) - Teşekkürler [Manuel Rubio](https://github.com/manuel-rubio)
 
 Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors/dwmkerr) düşünün!
 
@@ -19,6 +13,7 @@ Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors
 - [Giriş](#introduction)
 - [Yasalar](#laws)
     - [Amdahl Yasası](#amdahls-law)
+    - [Kırık Camlar Teorisi](#k%C4%B1r%C4%B1k-camlar-teorisi)
     - [Brooks Yasası](#brooks-law)
     - [Conway Yasası](#conways-law)
     - [Cunningham Yasası](#cunninghams-law)
@@ -30,9 +25,11 @@ Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors
     - [Hutber Yasası](#hutbers-law)
     - [Hype Döngüsü ve Amara Yasası](#the-hype-cycle--amaras-law)
     - [Hyrum Yasası (Arabirimlerin Örtülü Hukuku)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Kernighan Yasası](#kernighan-yasas%C4%B1)
     - [Metcalfe Yasası](#metcalfes-law)
     - [Moore Yasası](#moores-law)
     - [Murphy Yasası / Sod  Yasası](#murphys-law--sods-law)
+    - [Occam'ın Usturası](#occam%C4%B1n-usturas%C4%B1)
     - [Parkinson Yasası](#parkinsons-law)
     - [Olgunlaşmamış Optimizasyon Etkisi](#premature-optimization-effect)
     - [Putt Yasası](#putts-law)
@@ -60,6 +57,9 @@ Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors
     - [YAGNI](#yagni)
     - [Dağıtık Sistemlerin Yanılgıları](#the-fallacies-of-distributed-computing)
 - [Ek Kaynaklar](#reading-list)
+- [Çeviriler](#%C3%A7eviriler)
+- [Katkıda Bulunmak İçin](#katk%C4%B1da-bulunmak-i%CC%87%C3%A7in)
+- [Katkıda Bulunmak İçin](#katk%C4%B1)
 - [TODO](#todo)
 
 <!-- vim-markdown-toc -->
@@ -84,7 +84,8 @@ En güzel şu örnekle anlatılabilir. Bir programın iki bölümden oluştuğun
 
 Aşağıdaki diyagram bazı olası hız geliştirmelerine örnekler içeriyor:
 
-![Diagram: Amdahl's Law](../images/amdahls_law.png)
+
+<img width="480px" alt="Diagram: Amdahl's Law" src="../../images/amdahls_law.png">
 
 *(Diyagramın kaynağı: Daniels220 tarafından İngilizce Wikipedia'da, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
 
@@ -97,6 +98,24 @@ Ek kaynaklar:
 - [Brooks Yasası](#brooks-law)
 - [Moore Yasası ](#moores-law)
 
+### Kırık Camlar Teorisi
+
+[Wikipedia'da Kırık Camlar Teorisi](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+Kırık Camlar Teorisi, gözle görülebilir suç belirtilerinin (ya da ortamın  bakımsızlığının) daha ciddi suçlara (ya da ortamın daha da bozulmasına) yol açtığını göstermektedir.
+
+Bu teori, yazılım geliştirmeye şu şekilde uygulanabilir; düşük kalite kodun (veya [Teknik Borcun](#TODO)) varlığı kaliteyi geliştirme çabalarının göz ardı edilebileceği veya önemsenmeyeceği algısına yol açabileceği ve dolayısıyla düşük kalite koda sebep olabileceğidir. Bu etki zamanla kalitenin daha çok azalmasına neden olur.
+
+Ek kaynaklar:
+
+- [Teknik Borç](#yapmak)
+
+Örnekler:
+
+- [Pragmatik Programlama: Yazılım Entropisi](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [Kodlama Kabusu: Kırık Camlar Teorisi](https://blog.codinghorror.com/the-broken-window-theory/)
+- [Açık Kaynak: Eğlenceli Programlama - Kırık Camlar Teorisi](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
 ### Brooks Yasası
 
 [Wikipedia'da Brooks Yasası](https://en.wikipedia.org/wiki/Brooks%27s_law)
@@ -153,9 +172,7 @@ Ek kaynaklar:
 [Wikipedia'da Gall Yasası](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
 
 > Çalışan karmaşık bir sistemin her zaman işe yarayan daha basit bir sistemden evrimleştiği kesinlikle söylenebilir. Başlangıçtan itibaren karmaşık tasarlanmış bir sistemin asla çalışmayacağı ve sonradan da düzeltilemeyeceği kesindir. Çalışsan daha basit bir sistem ile başlamanız gerekir.
-> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
-> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
-> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
 
 Gall Yasası der ki, çok karmaşık sistemleri *tasarlamaya* çalışmak her zaman başarısızlıkla sonuçlanır. Bu tür sistemlerin ilk denemede başarılı olmaları çok nadir görülür ama genellikle basit sistemlerden evrilirler.
 
@@ -171,13 +188,11 @@ Ek kaynaklar:
 
 > Gözlemlenen herhangi bir istatistiksel düzenlilik, kontrol amaçları için üzerine baskı uygulandığında çökme eğiliminde olacaktır.
 > *Charles Goodhart*
-> *Charles Goodhart*
 
 Ayrıca şu şekilde de ifade edilir:
 
 > Bir ölçüm hedef haline geldiğinde, iyi bir ölçüm olmaktan çıkar.
 > *Marilyn Strathern*
-> *Marilyn Strathern*
 
 Bu yasa, ölçüme dayalı optimizasyonların, ölçüm sonucunun kendisinin anlamsızlaşmasına yol açabileceğini belirtmektedir. Bir prosese kör bir şekilde uygulanan aşırı seçici tedbirler ( [KPI'ler](https://en.wikipedia.org/wiki/Performance_indicator) ) çarpık bir etkiye neden olur. İnsanlar, eylemlerinin bütünsel sonuçlarına dikkat etmek yerine belirli metrikleri tatmin etmek için sistemle "oynayarak" yerel olarak optimize etme eğilimindedir.
 
@@ -197,7 +212,6 @@ Ek kaynaklar:
 
 > Aptallıkla layıkıyla açıklanabilecek bir şeyi, asla kötü niyete bağlamayın.
 > Robert J. Hanlon
-> Robert J. Hanlon
 
 Bu prensip, olumsuz sonuçlara yol açan eylemlerin, çoğunlukla kötü niyetin sonucu olmadığını savunmaktadır. Aksine, olumsuz sonuç daha büyük olasılıkla bu eylemlerin ve/veya etkinin tam olarak anlaşılamamasına bağlıdır.
 
@@ -207,7 +221,6 @@ Bu prensip, olumsuz sonuçlara yol açan eylemlerin, çoğunlukla kötü niyetin
 
 > Bir iş her zaman umduğundan daha uzun sürer, Hofstadter yasasını göz önünde bulundursan bile.
 > (Douglas Hofstadter)
-> (Douglas Hofstadter)
 
 Bu yasayı bir işin ne kadar süreceğini tahminlenirken hatırlatıldığı için duymuş olabilirsiniz. Herkesin kabul ettiği bir gerçek var ki, yazılım geliştirmede en kötü olduğumuz alan işin ne kadar sürede biteceğini tahmin etmektir.
 
@@ -223,7 +236,6 @@ Ek kaynaklar:
 
 > İyileştirme, bozulma anlamına da gelir.
 > ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
-> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
 
 Bu yasa der ki; sistemde yapılan bir iyileştirme sistemin diğer taraflarında bozulmaya sebep olabilir ya da başka bozuklukları gizleyebilir, bu da sistemin mevcut durumunun daha da bozulmasına sebep olabilir.
 
@@ -238,7 +250,7 @@ Bu yasa der ki; sistemde yapılan bir iyileştirme sistemin diğer taraflarında
 
 Hype Döngüsü bir teknolojinin zamanla yarattığı heyecan ve gelişiminin görsel olarak sunumudur ve Gartner tarafından ilk olarak oluşturulmuştur. En güzel anlatım aşağıdaki bir görsel ile yapılabilir:
 
-![The Hype Cycle](../images/gartner_hype_cycle.png)
+![The Hype Cycle](../../images/gartner_hype_cycle.png)
 
 *(Resmin Kaynağı: Jeremykemp tarafından İngilizce Wikipeda'da, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
 
@@ -258,6 +270,23 @@ Ek kaynaklar:
 - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
 - [XKCD 1172](https://xkcd.com/1172/)
 
+### Kernighan Yasası
+
+> Kodda hata ayıklama yapmak, o kodun sıfırdan yazılmasından iki kat daha zordur. Dolayısıyla, yazdığın bir kodu hatasız yazdığını düşünüyorsan, tanım olarak o koddaki hatayı ayıklayacak kadar zeki değilsin demektir.
+> (Brian Kernighan)
+
+Kernighan Yasası adını [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan)'dan almıştır ve "[The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style)" adlı Kernighan ve Plauger tarafından yazılan kitaptaki bir cümleden türetilmiştir:
+
+> Herkes hata ayıklamanın kodu sıfırdan yazmaktan iki katı daha zor olduğunu bilir. Dolayısıyla, kodu yazarken bütün zekanızı kullanıp elinizden gelenin en iyisini yaptığınızda o koddaki hatayı daha sonra nasıl ayıklayabilirsiniz?
+
+Abartılı olmakla birlikte, Kernighan Yasası karmaşık kod yerine basit kodun tercih edileceği iddiasını ortaya koymaktadır, çünkü karmaşık kodda ortaya çıkan herhangi bir sorunu ayıklamak maliyetli veya hatta mümkün olmayabilir.
+
+Ek kaynaklar:
+
+- [KISS Prensibi](#kiss-prensibi)
+- [Unix Felsefesi](#unix-felsefesi)
+- [Occam'ın Usturası](#occam%C4%B1n-usturas%C4%B1)
+
 ### Metcalfe Yasası
 
 [Wikipedia'da Metcalfe Yasası](https://en.wikipedia.org/wiki/Metcalfe's_law)
@@ -298,6 +327,24 @@ Ek kaynaklar:
 - [Doğrulama Önyargısı](#TODO)
 - [Seçim Tarafgirliği](#TODO)
 
+### Occam'ın Usturası
+
+[Wikipedia'da Occam'ın Usturası](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Çözümün elemanları sebep olmaksızın çoğaltılmamalıdır.
+> Ockham'lı William
+
+Occam'ın usturası, birkaç olası çözüm arasında en olası çözümün, en az sayıda kavram ve varsayımı olan çözüm olduğunu söylüyor. Bu çözüm en basit olandır ve yanlışlıkla ortaya çıkan karmaşıklığa ya da olası olumsuz sonuçlara sebep olmadan sadece verilen sorunu çözer.
+
+Ek kaynaklar:
+
+- [YAGNI](#yagni)
+- [Gümüş Bir Mermi Yok: Kazara Oluşan Karmaşıklık ve Gerekli Karmaşıklık](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Örnek:
+
+- [Yalın Yazılım Geliştirme: Çöpü Boşaltın](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
 ### Parkinson Yasası
 
 [Wikipedia'da Parkinson Yasası](https://en.wikipedia.org/wiki/Parkinson%27s_law)
@@ -423,7 +470,7 @@ Spotify Modeli kabileler (Tribes), birlikler (Guilds) ve kısımlar (Chapter) gi
 > 2. Genel sözdizimi
 > 3. Sözcük sözdizimi
 > 4. Yorumlardaki sözcük sözdizimi
-> (Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır.)
+> (Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır).
 
 [Önemsizlik Yasasında](#the-law-of-triviality) öne sürülene benzer olarak, Wadler Yasası yeni bir programlama dili tasarlanırken konunun önemi ile o konu için harcanan zaman ters orantılı olduğunu söylüyor.
 
@@ -452,9 +499,8 @@ Prensiplerin genellikle tasarıma ilişkin rehberlerdir.
 
 > Şirketler, yetersiz çalışanları, iş akışından uzaklaştırmak için sistematik olarak yönetici olmaya teşvik etme eğilimindedir.
 > *Scott Adams*
-> *Scott Adams*
 
-Scot Adams (Dilbert çizgi dizisinin yazarı) [Peter prensibinden](#the-peter-principle) esinlenerek ortaya atılmış bir yönetim kavramıdır. Dilbert prensibine göre yetenekli olmayan çalışanlar yönetim kadorlarına dopru yükseltilirler ki üretime verecekleri zarar aza indirilsin. Adams bunu ilk olarak 1995'te Wall Street Journal'da yazdığı bir makalede açıkladı daha sonra ise 1996'da yazdığı [Dilbert Prensibi](#reading-list) adlı kitabında detaylandırdı.
+Scot Adams (Dilbert çizgi dizisinin yazarı) [Peter prensibinden](#the-peter-principle) esinlenerek ortaya atılmış bir yönetim kavramıdır. Dilbert prensibine göre yetenekli olmayan çalışanlar yönetim kadorlarına doğru yükseltilirler ki üretime verecekleri zarar aza indirilsin. Adams bunu ilk olarak 1995'te Wall Street Journal'da yazdığı bir makalede açıkladı daha sonra ise 1996'da yazdığı [Dilbert Prensibi](#reading-list) adlı kitabında detaylandırdı.
 
 Ek kaynaklar:
 
@@ -477,7 +523,6 @@ Pareto Prensibi der ki, çıktıların önemli bir çoğunluğu girdilerin çok
 
 1940'lı yıllarda Romanya kökenli Amerikalı mühendis Dr. Joseph Juran, kendisi kalite kontrolün babası olarak nitelendirilir, [kalite kontrol sorunlarında Pareto Prensibini kullanmaya başladı](https://en.wikipedia.org/wiki/Joseph_M._Juran).
 
-
 Bu prensip aynı zamanda 80/20 Kuralı (The Law of the Vital Few and The Principle of Factor Sparsity) olarak da bilinir.
 
 Gerçek dünyadan örnekler:
@@ -490,7 +535,6 @@ Gerçek dünyadan örnekler:
 
 > Hiyerarşideki insanlar “yetersizlik seviyelerine” göre yükselme eğilimindedir.
 > *Laurence J. Peter*
-> *Laurence J. Peter*
 
 Laurence J. Peter tarafından geliştirilen bir yönetim konsepti olan Peter Prensibi, işlerinde iyi olan kişilerin, artık başarılı olamadıkları bir seviyeye (kendi "yetersizlik seviyelerine") ulaşana kadar terfi ettiğini gözlemlemektedir. Bu durumda şirket içinde çok tecrübeli olduklarından organizasyondan (çok aykırı birşey yapmadıkları sürece) dışlanmazlar ve az sayıda temel beceriye sahip olacakları bir rolde kalmaya devam edecekler, çünkü onları başarılı kılan orijinal becerileri mutlaka bu yeni rolleri için gereken beceriler değildir.
 
@@ -511,6 +555,12 @@ Genellikle sunucu uygulamaları geliştirirken uygulanabilir. Bu prensip der ki;
 
 Bu prensibin amacı dayanıklı sistemlere geliştirmektir ve bu sistemler kötü yapılandırılmış girdileri bile anlayabildikleri durumda işleyebilmeliler. Bunun güvenlik açısından kötü amaçlı ve yeterince kontrol edilmemiş girdileri kabul etmek anlamına gelebileceği için riskli olduğu düşünülebilir. Tabiki bu riskin de göz önünde bulundurulması gerekir.
 
+Uygun olmayan girdilere zaman içinde izin verilmesi, uygulayıcıların yeni özellikler oluştururken bu serbestliğe güvenmesini sağlayacağından en sonunda protokollerin evrimleşme yeteneğini zayıflatabilir.
+
+Ek kaynaklar:
+
+- [Hyrum Yasası](#hyrum-yasas%C4%B1-arabirimlerin-%C3%B6rt%C3%BCl%C3%BC-hukuku)
+
 ### SOLID
 
 SOLID aşağıdaki beş prensibin baş harflerinden oluşan bir kısaltmadır;
@@ -531,7 +581,7 @@ Bunları [Nesne Tabanlı Proglamlama'nın](#todo) temel prensipleri olarak değe
 
 Bu '[SOLID](#solid)' prensiplerinin ilkidir. Bu prensip der ki her bir sistem parçasının yada programlama sınıfının sadece ama sadece bir sorumluluğu olması gerekir. Daha sade anlatmak gerekirse, bir programdaki sadece bir özelliği etkileyen bir değişiklik sadece o özelliği ilgilendiren parça ya da sınıfta yapılmalı. Örneğin, şifrelerin doğruluğunun kontrolünde bir değiştirme yapılacaksa sadece programın o bölümünde değişiklik yapılmalı.
 
-Teorik olarak, bu prensibe uygun yazılmış kodlar daha sağlam ve değiştirilmesi kolaydır. Sadece tek bir parçanın değiştirildiğine emin olunduğunda değişimi *tesk etmek* de kolay olacaktır. Önceki şifre örneğini düşünürsek, şifrenin zorluk seviyesi değiştirildiğinde sadece şifre ilgili bölümlerin etkilenecektir. Birden fazla sorumluluğu olan bir bölümde olan değişikliğin nereleri etkileceğini hesaplamak daha zordur.
+Teorik olarak, bu prensibe uygun yazılmış kodlar daha sağlam ve değiştirilmesi kolaydır. Sadece tek bir parçanın değiştirildiğine emin olunduğunda değişimi *test etmek* de kolay olacaktır. Önceki şifre örneğini düşünürsek, şifrenin zorluk seviyesi değiştirildiğinde sadece şifre ilgili bölümlerin etkilenecektir. Birden fazla sorumluluğu olan bir bölümde olan değişikliğin nereleri etkileceğini hesaplamak daha zordur.
 
 Ek kaynaklar:
 
@@ -548,7 +598,6 @@ Bu '[SOLID](#solid)' prensiplerinin ikincisidir ve herhangi bir sistem parçası
 
 Örneğin Markdown formatındaki belgeleri HTML formatına çeviren bir modülü düşünelim. Eğer bu modül kendisi değiştirilmeden yeni bir Markdown formatını da işlemesi sağlanacak şekilde geliştirilebiliyorsa, bu modül genişletilmeye açık demektir. Eğer sonradan değiştirilip Markdown formatı işlemesi ile ilgili geliştirme *yapılamıyorsa*, bu modül değiştirilmeye *kapalı* demektir.
 
-
 Bu prensip nesne-tabanlı programlamaya tam uygundur. Şöyle ki, kendi nesne ve sınıflarımızı miras alınarak geliştirmeye uygun ve değiştirmeye ihtiyaç duymayacak şekilde tasarlarsak ve yazarsak nesne-tabanlı programlamaya tam uygun kod yazmış oluruz.
 
 Ek kaynaklar:
@@ -604,7 +653,6 @@ Ek kaynaklar:
 
 Bu prensip olması gereken bağımlığı tersine çevirdiği düşünebileceğinden (isminden dolayı) biraz karmaşık gelebilir. Pratikte, ayrı bir düzenleme bileşeninin, soyut türlerin doğru uygulamalarının kullanılmasını sağlaması gerektiği anlamına gelir (önceki örnekte, *bir şey* hala meta veri okuyucu bileşenine bir HTTP dosyası indiricisi ve HTML meta etiketi okuyucu sağlamalıdır). Bu prensip aynı zamanda [Kontrolün Ters Çevirilmesi](#todo) ve [Bağımlık Enjeksiyonu](#todo) gibi konularla da bağlantılıdır.
 
-
 Ek kaynaklar:
 
 - [Nesne Tabanlı Programlama](#todo)
@@ -620,7 +668,6 @@ Ek kaynaklar:
 
 *DRY Don't Repeat Yourself* yani Kendini Tekrar Etme deyimin kısaltılmasıdır. İlk olarak Andrew Hunt ve Dave Thomas tarafından [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) kitabında bahsedilmiştir. Bu ilke, geliştiricilere kod tekrarını azaltma ve bilgileri tek bir yerde tutmalarına yardımcı olmayı amaçlamaktadır.
 
-
 > DRY'nin tam tersi *WET* olacaktır (Write Everything Twice (Her Şeyi İki Kez Yaz) We Enjoy Typing (Yazmayı Seviyoruz)).
 
 Uygulamada, aynı bilgi parçasını iki (veya daha fazla) farklı yerde kullanıyorsanız, DRY'yi bunları tek bir tanede birleştirmek ve istediğiniz / ihtiyaç duyduğunuz yerde tekrar kullanmak için kullanabilirsiniz.
@@ -650,9 +697,7 @@ Ek kaynaklar:
 ***Y**ou **A**ren't **G**onna **N**eed **I**t* (İhtiyacın olmayacak) deyiminin kısaltmasıdır.
 
 > İhtiyaç duyduğunuz şeyleri her zaman ihtiyaç duyduğunuzda geliştirin, onlara ihtiyacınız olacağını düşündüğünüzde değil.
-> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP eş-kurucusu and "Extreme Programming Installed" kitabının yazarı)
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed")
-> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP eş-kurucusu and "Extreme Programming Installed" kitabının yazarı)
-> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP eş-kurucusu and "Extreme Programming Installed" kitabının yazarı)
 
 Bu *Aşırı Programlama* (XP) ilkesi, geliştiricilerin yalnızca acil gereksinimler için gerekli olan işlevleri yerine getirmeleri gerektiğini ve daha sonra ihtiyaç duyulabilecek işlevleri uygulayarak geleceği tahmin etme girişimlerinden kaçınmalarını önerir.
 
@@ -685,8 +730,7 @@ Dayanıklı sistemler tasarlarken bu yanılgılar dikkatlice ele alınmalı; bu
 
 Ek kaynaklar:
 
-- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
+- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
-    on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
 - [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
 
 ## Ek Kaynaklar
@@ -699,9 +743,38 @@ Bu kavramları ilginç bulduysanız, aşağıdaki kitapların keyfini çıkarabi
 - [Dilbert Prensibi - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - [Dilbert İlkesini](#the-dilbert-principle) oluşturan yazardan, kurumsal Amerika'ya komik bir bakış.
 - [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
 
+## Çeviriler:
+
+Katkıda bulunan harika insanlar sayesinde Hacker Laws birçok dilde mevcuttur. Lütfen çeviri sahiplerine de sponsor olmayı düşünün!
+
+Dil | Moderatör | Durum
+--- | --- | ---
+[🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)
+[🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Kısmen tamamlandı
+[🇩🇪 Deutsch / German](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)
+[🇫🇷 Français / French](./translationis/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)
+[🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)
+[🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Kısmen tamamlandı
+[🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Kısmen tamamlandı
+[🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)
+[🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Kısmen tamamlandı
+[🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Kısmen tamamlandı
+[🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)
+
+Bir çeviriyi güncellemek isterseniz, [bir PR açmanız yeterlidir](https://github.com/dwmkerr/hacker-laws/pulls) . Yeni bir dil eklemek istiyorsanız, bir hesap oluşturmak için [GitLocalize'a](https://gitlocalize.com/) giriş yapın, ardından dili yönetmek istediğinizi belirten bir Issue açın; sizi projeye ekleyeceğim! Yukarıdaki tabloyu güncelleyen bir PR açabilmeniz de çok yararlı olacaktır.
+
+## İlgili Projeler
+
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Hergün bir hacker yasası ya da prensibi.
+
+## Katkıda Bulunmak İçin
+
+Lütfen katkıda bulunun! Bir ekleme veya değişiklik önermek istiyorsanız [bir sorun oluşturun](https://github.com/dwmkerr/hacker-laws/issues/new) veya kendi değişikliklerinizi önermek için [bir PR açın](https://github.com/dwmkerr/hacker-laws/compare) .
+
+Lütfen metin, stil ve benzeri gereksinimler için [Katkıda Bulunma Kılavuzunu](./.github/contributing.md) okuduğunuzdan emin olun. Lütfen projeyle ilgili tartışmalarda [Davranış Kurallarına](./.github/CODE_OF_CONDUCT.md) dikkat edin.
+
 ## TODO
 
 Selam!. Buraya ulaştıysanız, henüz yazmadığım bir konunun bağlantısını tıkladınız, bunun için üzgünüm - ve en kısa zamanda tamamlamaya çalışacağım!
 
 Soru ve önerileriniz için [issue](https://github.com/dwmkerr/hacker-laws/issues) açabilirsiniz, ya da katkıda bulunmak isterseniz [Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) açabilirsiniz.
-