diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml new file mode 100644 index 00000000..6a75e655 --- /dev/null +++ b/.github/FUNDING.yml @@ -0,0 +1,2 @@ +# Support 'GitHub Sponsors' funding. +github: dwmkerr diff --git a/.github/contributing.md b/.github/contributing.md index 6dc01bda..4acda234 100644 --- a/.github/contributing.md +++ b/.github/contributing.md @@ -1,5 +1,17 @@ # Contributing Guidelines + + +* [Goal of the Project](#goal-of-the-project) +* [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions) +* [Localisation](#localisation) +* [How do I know if a law is relevant?](#how-do-i-know-if-a-law-is-relevant) +* [How do I know if a law is 'well known' enough?](#how-do-i-know-if-a-law-is-well-known-enough) + + + +## Goal of the Project + The goal of this project is to have a set of _concise_ definitions to laws, principles, methodologies and patterns which hackers will find useful. They should be: 1. Short - one or two paragraphs. @@ -17,12 +29,13 @@ 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: --- -### The Law of Leaky Abstractions +## Example Law: The Law of Leaky Abstractions [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) @@ -45,3 +58,19 @@ See also: Real-world examples: - [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations. + +## Localisation + +We are currently using [GitLocalize](https://gitlocalize.com) to handle translations. This provides features to make it easier for people to manage translations as changes come in: + +![GitLocalize Screenshot](../images/gitlocalize.png) + +This is still work in progress - if you would like to be a maintainer for a language just open an issue to get in touch! + +## How do I know if a law is relevant? + +In general, it should be reasonably applicable to the world of computer sciences, IT or coding in general. + +## How do I know if a law is 'well known' enough? + +A good test is 'If I search for it on Google, will I find it in the first few results?'. diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index da77bc21..8a8010f2 100644 --- a/.github/pull_request_template.md +++ b/.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). diff --git a/.github/workflows/build-on-pull-request.yaml b/.github/workflows/build-on-pull-request.yaml new file mode 100644 index 00000000..447ceac6 --- /dev/null +++ b/.github/workflows/build-on-pull-request.yaml @@ -0,0 +1,43 @@ +# This pipeline builds the PDF ebook on any pull request to master. +name: "Build PDF" +on: + pull_request: + branches: + - master + +jobs: + prepare-pdf: + # Focal Fossa. Please don't use 'latest' tags, it's an anti-pattern. + runs-on: ubuntu-20.04 + steps: + # Checkout the code. + - name: Checkout + uses: actions/checkout@v2 + + # Set a descriptive version. For PRs it'll be the short sha. + - name: Set Version + id: set_version + run: echo ::set-output name=VERSION::$(git rev-parse --short HEAD) + + # Prepare the content files. + - name: Prepare Content + run: ./scripts/prepare-markdown-for-ebook.sh ${{ steps.set_version.outputs.VERSION }} + + # Create a PDF from the prepared markdown. + - name: Prepare PDF + uses: docker://pandoc/latex:2.9 + with: + args: "-V toc-title:\"Table Of Contents\" --toc --pdf-engine=pdflatex --standalone --output hacker-laws.pdf hacker-laws.md" + + # Publish the PDF and intermediate markdown as an artifact. + - name: Publish PDF Artifact + uses: actions/upload-artifact@master + with: + name: hacker-laws.pdf + path: hacker-laws.pdf + + - name: Publish Intermiediate Markdown Artifact + uses: actions/upload-artifact@master + with: + name: hacker-laws.md + path: hacker-laws.md diff --git a/.github/workflows/release-on-tag.yaml b/.github/workflows/release-on-tag.yaml new file mode 100644 index 00000000..7c527d13 --- /dev/null +++ b/.github/workflows/release-on-tag.yaml @@ -0,0 +1,69 @@ +# This pipeline builds the PDF ebook on any tag starting with 'v'. +name: "Create Release" +on: + push: + tags: + - 'v*' + +jobs: + prepare-pdf: + # Focal Fossa. Please don't use 'latest' tags, it's an anti-pattern. + runs-on: ubuntu-20.04 + steps: + # Checkout the code. + - name: Checkout + uses: actions/checkout@v2 + + # Set a descriptive version. For PRs it'll be the short sha. + - name: Set Version + id: set_version + run: echo ::set-output name=VERSION::${GITHUB_REF/refs\/tags\//} + + # Prepare the content files. + - name: Prepare Content + run: ./scripts/prepare-markdown-for-ebook.sh ${{ steps.set_version.outputs.VERSION }} + + # Create a PDF from the prepared markdown. + - name: Prepare PDF + uses: docker://pandoc/latex:2.9 + with: + args: "-V toc-title:\"Table Of Contents\" --toc --pdf-engine=pdflatex --standalone --output hacker-laws.pdf hacker-laws.md" + + # Publish the PDF artifact. + - name: Publish PDF Artifacts + uses: actions/upload-artifact@master + with: + name: hacker-laws.pdf + path: hacker-laws.pdf + + release: + needs: prepare-pdf + runs-on: ubuntu-20.04 + steps: + - name: Download artifact + uses: actions/download-artifact@v2 + with: + name: hacker-laws.pdf + + - name: Create Release + id: create-release + uses: actions/create-release@v1 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + tag_name: ${{ github.ref }} + release_name: ${{ github.ref }} + body: | + Hacker Laws E-Book + draft: false + prerelease: false + + - name: Upload Release Asset + uses: actions/upload-release-asset@v1 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + upload_url: ${{ steps.create-release.outputs.upload_url }} + asset_path: ./hacker-laws.pdf + asset_name: hacker-laws.pdf + asset_content_type: application/pdf diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md deleted file mode 100644 index 515e77de..00000000 --- a/CONTRIBUTORS.md +++ /dev/null @@ -1 +0,0 @@ -- [rheh](https://github.com/rheh) - Suggestion - Brooks's Law diff --git a/LICENSE b/LICENSE index 51573edb..c06b66fa 100644 --- a/LICENSE +++ b/LICENSE @@ -1,21 +1,173 @@ -MIT License - -Copyright (c) 2018 Dave Kerr - -Permission is hereby granted, free of charge, to any person obtaining a copy -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 -copies or substantial portions of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE -SOFTWARE. +Copyright (c) Dave Kerr 2020 + +# Attribution-ShareAlike 4.0 International + +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. + +### Using Creative Commons Public Licenses + +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. + +* __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). + +* __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). + +## 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. diff --git a/README.md b/README.md index eec17e67..418b07a0 100644 --- a/README.md +++ b/README.md @@ -2,8 +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)! -- 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)! +[Translations](#translations): [🇮🇩](./translations/id.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/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) [🇯🇵](./translations/jp.md) [🇺🇦](./translations/uk.md) + +Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations). Also check out this podcast on [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403) to learn more about the project! You can also [download the latest PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf). Check the [Contributor Guide](./.github/contributing.md) if you are keen to contribute! --- @@ -11,25 +12,51 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [Introduction](#introduction) * [Laws](#laws) + * [90–9–1 Principle (1% Rule)](#9091-principle-1-rule) * [Amdahl's Law](#amdahls-law) + * [The Broken Windows Theory](#the-broken-windows-theory) * [Brooks' Law](#brooks-law) + * [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem) * [Conway's Law](#conways-law) + * [Cunningham's Law](#cunninghams-law) * [Dunbar's Number](#dunbars-number) + * [The Dunning-Kruger Effect](#the-dunning-kruger-effect) + * [Fitts' Law](#fitts-law) + * [Gall's Law](#galls-law) + * [Goodhart's Law](#goodharts-law) * [Hanlon's Razor](#hanlons-razor) + * [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law) * [Hofstadter's Law](#hofstadters-law) + * [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) + * [Linus's Law](#linuss-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) + * [Reed's Law](#reeds-law) * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law) + * [The Law of Demeter](#the-law-of-demeter) * [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions) * [The Law of Triviality](#the-law-of-triviality) * [The Unix Philosophy](#the-unix-philosophy) * [The Spotify Model](#the-spotify-model) + * [The Two Pizza Rule](#the-two-pizza-rule) * [Wadler's Law](#wadlers-law) + * [Wheaton's Law](#wheatons-law) * [Principles](#principles) + * [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law) + * [Chesterson's Fence](#chestersons-fence) + * [The Dead Sea Effect](#the-dead-sea-effect) + * [The Dilbert Principle](#the-dilbert-principle) * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule) + * [The Shirky Principle](#the-shirky-principle) + * [The Peter Principle](#the-peter-principle) * [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law) * [SOLID](#solid) * [The Single Responsibility Principle](#the-single-responsibility-principle) @@ -38,7 +65,16 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [The Interface Segregation Principle](#the-interface-segregation-principle) * [The Dependency Inversion Principle](#the-dependency-inversion-principle) * [The DRY Principle](#the-dry-principle) + * [The KISS principle](#the-kiss-principle) + * [YAGNI](#yagni) + * [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing) * [Reading List](#reading-list) +* [Online Resources](#online-resources) +* [PDF eBook](#pdf-ebook) +* [Podcast](#podcast) +* [Translations](#translations) +* [Related Projects](#related-projects) +* [Contributing](#contributing) * [TODO](#todo) @@ -53,6 +89,20 @@ There are lots of laws which people discuss when talking about development. This And here we go! +### 90–9–1 Principle (1% Rule) + +[1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)) + +The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content. + +Real-world examples: + +- A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2% ([Reference](https://www.jmir.org/2014/2/e33/)) + +See Also: + +- [Pareto principle](#the-pareto-principle-the-8020-rule) + ### Amdahl's Law [Amdahl's Law on Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law) @@ -63,9 +113,9 @@ 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) +Diagram: Amdahl's Law -*(Image Reference: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* +*(Image Reference: By Daniels219 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* As can be seen, even a program which is 50% parallelisable will benefit very little beyond 10 processing units, whereas a program which is 95% parallelisable can still achieve significant speed improvements with over a thousand processing units. @@ -76,9 +126,27 @@ 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://flylib.com/books/en/1.315.1.15/1/) +- [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.m.wikipedia.org/wiki/Brooks%27s_law) +[Brooks' Law on Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law) > Adding human resources to a late software development project makes it later. @@ -93,6 +161,30 @@ See also: - [Death March](#todo) - [Reading List: The Mythical Man Month](#reading-list) +### CAP Theorem (Brewer's Theorem) + +The CAP Theorem (defined by Eric Brewer) states that for a distributed data store only two out of the following three guarantees (at most) can be made: + +- Consistency: when reading data, every request receives the _most recent_ data or an error is returned +- Availability: when reading data, every request receives _a non error response_, without the guarantee that it is the _most recent_ data +- Partition Tolerance: when an arbitrary number of network requests between nodes fail, the system continues to operate as expected + +The core of the reasoning is as follows. It is impossible to guarantee that a network partition will not occur (see [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)). Therefore in the case of a partition we can either cancel the operation (increasing consistency and decreasing availability) or proceed (increasing availability but decreasing consistency). + +The name comes from the first letters of the guarantees (Consistency, Availability, Partition Tolerance). Note that it is very important to be aware that this does _not_ relate to [_ACID_](#TODO), which has a different definition of consistency. More recently, [PACELC](#TODO) theorem has been developed which adds constraints for latency and consistency when the network is _not_ partitioned (i.e. when the system is operating as expected). + +Most modern database platforms acknowledge this theorem implicitly by offering the user of the database the option to choose between whether they want a highly available operation (which might include a 'dirty read') or a highly consistent operation (for example a 'quorum acknowledged write'). + +Real world examples: + +- [Inside Google Cloud Spanner and the CAP Theorem](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) - Goes into the details of how Cloud Spanner works, which appears at first to seem like a platform which has _all_ of the guarantees of CAP, but under the hood is essentially a CP system. + +See also: + +- [ACID](#TODO) +- [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing) +- [PACELC](#TODO) + ### Conway's Law [Conway's Law on Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law) @@ -103,6 +195,18 @@ See also: - [The Spotify Model](#the-spotify-model) +### Cunningham's Law + +[Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law) + +> The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer. + +According to Steven McGeady, Ward Cunningham advised him in the early 1980s: "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." McGeady dubbed this Cunningham's law, though Cunningham denies ownership calling it a "misquote." Although originally referring to interactions on Usenet, the law has been used to describe how other online communities work (e.g., Wikipedia, Reddit, Twitter, Facebook). + +See also: + +- [XKCD 386: "Duty Calls"](https://xkcd.com/386/) + ### Dunbar's Number [Dunbar's Number on Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number) @@ -115,6 +219,83 @@ See also: - [Conway's Law](#conways-law) + +### The Dunning-Kruger Effect + +[The Dunning-Kruger Effect on Wikipedia](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) + +> If you're incompetent, you can't know you're incompetent... The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is. +> +> ([David Dunning](https://en.wikipedia.org/wiki/David_Dunning)) + +The Dunning–Kruger effect is a theoretical cognitive bias which was described by David Dunning and Justin Kruger in a 1999 psychological study and paper. The study suggests that people with a low level of ability at a task are likely to overestimate their ability of the task. The proposed reason for this bias is that a sufficient _awareness_ of the complexity of a problem or domain is required for a person to be able to make an informed opinion of their capability to work in that domain. + +The Dunning-Kruger effect has sometimes been used to describe a related, but not necessarily implied effect which could be described as "The less a person understands a domain, the more they are likely to believe they can easily solve problems in that domain, as they are more likely to see the domain as _simple_". This more general effect is highly relevant in technology. It would suggest that people who are less familiar with a domain, such as non-technical team members or less experienced team members, are more likely to _underestimate_ the effort required to solve a problem in this space. + +As a person's understanding and experience in a domain grows, they may well encounter another effect, which is that they tend to _overestimate_ the ability of _others_ or _underestimate_ their own ability, as they are have become so experienced in the domain. In all cases these effects are _cognitive biases_. As with any bias, an understanding that it may be present will often be sufficient to help avoid the challenges - as when there is awareness of a bias more inputs and opinions can be included to attempt to eliminate these biases. A closely related is the bias of [Illusory superiority](https://en.wikipedia.org/wiki/Illusory_superiority). + +Real-world examples: + +* [Apple vs. FBI: Why This Anti-Terror Hawk Switched Sides](https://fortune.com/2016/03/10/apple-fbi-lindsay-graham/) - In 2016 Senator Lindsey Graham changed his stance on Apple creating a 'backdoor' in their encryption of devices. Initially Graham had been critical of Apple challenging a request to create a 'backdoor', which he saw as necessary to investigate potential terrorist plots. However, by Graham's own admission, as he learned more about the technical complexity of the domain, he realised that he had assumed it to be far more simple than he had realised, and that such a backdoor could have serious negative consequences. This could potentially be considered an example of the Dunning-Kruger effect - a cyber-security expert would likely understand immediately how such a backdoor could be exploited, as they have deep understanding of the domain, a layperson might assume that phone security is more similar to _physical security_ where the practice of having a 'master key' for law enforcement is possible, but this analogy does not apply sufficiently well to describe modern encryption in cyber-security. + +### Fitts' Law + +[Fitts' Law on Wikipedia](https://en.wikipedia.org/wiki/Fitts%27s_law) + +Fitts' law predicts that the time required to move to a target area is a function of the distance to the target divided by the width of the target. + +Diagram: Fitts Law + +*(Image Reference: By Foobar628 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)* + +The consequences of this law dictate that when designing UX or UI, interactive elements should be as large as possible and the distance between the users attention area and interactive element should be as small as possible. This has consequences on design, such as grouping tasks that are commonly used with one another close. + +It also formalises the concept of 'magic corners', the corners of the screen to which a user can 'sweep' their mouse to easily hit - which is where key UI elements can be placed. The Windows Start button is in a magic corner, making it easy to select, and as an interesting contrast, the MacOS 'close window' button is _not_ in a magic corner, making it hard to hit by mistake. + +See also: + +- [The information capacity of the human motor system in controlling the amplitude of movement.](https://www.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d) + +### Gall's Law + +[Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) + +> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. +> +> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author))) + +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 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: + +- [KISS (Keep It Simple, Stupid)](#the-kiss-principle) + +### Goodhart's Law + +[The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law) + +> Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. +> +> _Charles Goodhart_ + +Also commonly referenced as: + +> When a measure becomes a target, it ceases to be a good measure. +> +> _Marilyn Strathern_ + +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 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: +- [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) + ### Hanlon's Razor [Hanlon's Razor on Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor) @@ -125,13 +306,36 @@ See also: This principle suggests that actions resulting in a negative outcome were not a result of ill will. Instead the negative outcome is more likely attributed to those actions and/or the impact being not fully understood. +### Hick's Law (Hick-Hyman Law) + +[Hick's law on Wikipedia](https://en.wikipedia.org/wiki/Hick%27s_law) + +> Decision time grows logarithmically with the number of options you can choose from. +> +> William Edmund Hick and Ray Hyman + +In the equation below, `T` is the time to make a decision, `n` is the number of options, and `b` is a constant which is determined by analysis of the data. + +![Hicks law](./images/hicks_law.svg) + +*(Image Reference: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)* + +This law only applies when the number of options is _ordered_, for example, alphabetically. This is implied in the base two logarithm - which implies the decision maker is essentially performing a _binary search_. If the options are not well ordered, experiments show the time taken is linear. + +This is has significant impact in UI design; ensuring that users can easily search through options leads to faster decision making. + +A correlation has also been shown in Hick's Law between IQ and reaction time as shown in [Speed of Information Processing: Developmental Change and Links to Intelligence](https://www.sciencedirect.com/science/article/pii/S0022440599000369). + +See also: +- [Fitts's Law](#fitts-law) + ### Hofstadter's Law [Hofstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law) > It always takes longer than you expect, even when you take into account Hofstadter's Law. > -> Douglas Hofstadter +> (Douglas Hofstadter) You might hear this law referred to when looking at estimates for how long something will take. It seems a truism in software development that we tend to not be very good at accurately estimating how long something will take to deliver. @@ -141,6 +345,18 @@ See also: - [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list) +### Hutber's Law + +[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) + +> Improvement means deterioration. +> +> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber)) + +This law suggests that improvements to a system will lead to deterioration in other parts, or it will hide other deterioration, leading overall to a degradation from the current state of the system. + +For example, a decrease in response latency for a particular end-point could cause increased throughput and capacity issues further along in a request flow, affecting an entirely different sub-system. + ### The Hype Cycle & Amara's Law [The Hype Cycle on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle) @@ -175,6 +391,54 @@ 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) + +### Linus's Law + +[Linus's Law on Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law) + +> Given enough eyeballs, all bugs are shallow. +> +> _Eric S. Raymond_ + +This law simply states that the more people who can see a problem, the higher the likelihood that someone will have seen and solved the problem before, or something very similar. + +Although it was originally used to describe the value of open-source models for projects it can be accepted for any kind of software project. It can also be extended to processes - more code reviews, more static analysis and multi-disciplined test processes will make the problems more visible and easy to identify. + +A more formal statement can be: + +> Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and can be solved by someone who has encountered a similar problem before. + +This law was named in honour of [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in Eric S. Raymond's book "[The Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)". + +### Metcalfe's Law + +[Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law) + +> In network theory, the value of a system grows as approximately the square of the number of users of the system. + +This law is based on the number of possible pairwise connections within a system and is closely related to [Reed's Law](#reeds-law). Odlyzko and others have argued that both Reed's Law and Metcalfe's Law overstate the value of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number). + +See also: +- [Reed's Law](#reeds-law) +- [Dunbar's Number](#dunbars-number) + ### Moore's Law [Moore's Law on Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law) @@ -183,6 +447,44 @@ See also: Often used to illustrate the sheer speed at which semiconductor and chip technology has improved, Moore's prediction has proven to be highly accurate over from the 1970s to the late 2000s. In more recent years, the trend has changed slightly, partly due to [physical limitations on the degree to which components can be miniaturised](https://en.wikipedia.org/wiki/Quantum_tunnelling). However, advancements in parallelisation, and potentially revolutionary changes in semiconductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come. +### Murphy's Law / Sod's Law + +[Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law) + +> Anything that can go wrong will go wrong. + +Related to [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Murphy's Law_ states that if a thing can go wrong, it will go wrong. + +This is a common adage among developers. Sometimes the unexpected happens when developing, testing or even in production. This can also be related to the (more common in British English) _Sod's Law_: + +> If something can go wrong, it will, at the worst possible time. + +These 'laws' are generally used in a comic sense. However, phenomena such as [_Confirmation Bias_](#TODO) and [_Selection Bias_](#TODO) can lead people to perhaps over-emphasise these laws (the majority of times when things work, they go unnoticed, failures however are more noticeable and draw more discussion). + +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) @@ -197,6 +499,18 @@ See also: - [Hofstadter's Law](#hofstadters-law) +### Premature Optimization Effect + +[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) + +> Premature optimization is the root of all evil. +> +> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) + +In Donald Knuth's paper [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: **premature optimization is the root of all evil**. Yet we should not pass up our opportunities in that critical 3%." + +However, _Premature Optimization_ can be defined (in less loaded terms) as optimizing before we know that we need to. + ### Putt's Law [Putt's Law on Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) @@ -207,15 +521,26 @@ Putt's Law is often followed by Putt's Corollary: > Every technical hierarchy, in time, develops a competence inversion. -These statements suggest that due to various selection criteria and trends in how groups organise, there will be a number of skilled people at working levels of a technical organisations, and a number of people in managerial roles who are not aware of the complexities and challenges of the work they are managing. This can be due to phenomena such as [The Peter Principle](#TODO) or [Dilbert's Law](#TODO). +These statements suggest that due to various selection criteria and trends in how groups organise, there will be a number of skilled people at working levels of a technical organisations, and a number of people in managerial roles who are not aware of the complexities and challenges of the work they are managing. This can be due to phenomena such as [The Peter Principle](#the-peter-principle) or [The Dilbert Principle](#the-dilbert-principle). However, it should be stressed that Laws such as this are vast generalisations and may apply to _some_ types of organisations, and not apply to others. See also: -- [The Peter Principle](#TODO) -- [Dilbert's Law](#TODO). +- [The Peter Principle](#the-peter-principle) +- [The Dilbert Principle](#the-dilbert-principle) + +### Reed's Law + +[Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law) +> The utility of large networks, particularly social networks, scales exponentially with the size of the network. + +This law is based on graph theory, where the utility scales as the number of possible sub-groups, which is faster than the number of participants or the number of possible pairwise connections. Odlyzko and others have argued that Reed's Law overstates the utility of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number). + +See also: +- [Metcalfe's Law](#metcalfes-law) +- [Dunbar's Number](#dunbars-number) ### The Law of Conservation of Complexity (Tesler's Law) @@ -227,13 +552,25 @@ Some complexity in a system is 'inadvertent'. It is a consequence of poor struct One interesting element to this law is the suggestion that even by simplifying the entire system, the intrinsic complexity is not reduced, it is _moved to the user_, who must behave in a more complex way. +### The Law of Demeter + +[The Law of Demeter on Wikipedia](https://en.wikipedia.org/wiki/Law_of_Demeter) + +> Don't talk to strangers. + +The Law of Demeter, also known as "The Principle of Least Knowledge" is a principle for software design, particularly relevant in object orientated languages. + +It states that a unit of software should talk only to its immediate collaborators. An object `A` with a reference to object `B` can call its methods, but if `B` has a reference to object `C`, `A` should not call `C`s methods. So, if `C` has a `doThing()` method, `A` should not invoke it directly; `B.getC().doThis()`. + +Following this principal limits the scope of changes, making them easier and safer in future. + ### The Law of Leaky Abstractions [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) > All non-trivial abstractions, to some degree, are leaky. > -> (Joel Spolsky) +> ([Joel Spolsky](https://twitter.com/spolsky)) This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations 'leak' elements of the underlying system, this making the abstraction behave in an unexpected way. @@ -259,7 +596,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. +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 @@ -277,17 +614,31 @@ The Spotify Model is an approach to team and organisation structure which has be The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure. +Members of the organisation have described that the actual meaning of these groups changes, evolves and is an on-going experiment. The fact that the model is a _process in motion_, rather than a fixed model continues to lead to varying interpretations of the structure, which may be based on presentations given by employees at conferences. This means 'snapshots' may be 're-packaged' by third parties as a _fixed structure_, with the fact that the model is dynamic being lost. + +### The Two Pizza Rule + +> If you can't feed a team with two pizzas, it's too large. +> +> (Jeff Bezos) + +This rule suggests that regardless of the size of the company, teams should be small enough to be fed by two pizzas. Attributed to Jeff Bezos and Amazon, this belief is suggests that large teams are inherently inefficient. This is supported by the fact that as the team size increases linearly, the links between people increases quadratically; thus the cost of coordinating and communicating also grows quadratically. If this cost of coordination is essentially overhead, then smaller teams should be preferred. + +The number of links between people can be expressed as `n(n-1)/2` where n = number of people. + +Complete graph; Links between people + ### Wadler's Law [Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) > In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position. -> +> > 0. Semantics > 1. Syntax > 2. Lexical syntax > 3. Lexical syntax of comments -> +> > (In short, for every hour spent on semantics, 8 hours will be spent on the syntax of comments). Similar to [The Law of Triviality](#the-law-of-triviality), Wadler's Law states what when designing a language, the amount of time spent on language structures is disproportionately high in comparison to the importance of those features. @@ -296,10 +647,75 @@ See also: - [The Law of Triviality](#the-law-of-triviality) +### Wheaton's Law + +[The Link](http://www.wheatonslaw.com/) + +[The Official Day](https://dontbeadickday.com/) + +> Don't be a dick. +> +> _Wil Wheaton_ + +Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), this simple, concise, and powerful law aims for an increase in harmony and respect within a professional organization. It can be applied when speaking with coworkers, performing code reviews, countering other points of view, critiquing, and in general, most professional interactions humans have with each other. + ## Principles Principles are generally more likely to be guidelines relating to design. +### All Models Are Wrong (George Box's Law) + +[All Models Are Wrong](https://en.wikipedia.org/wiki/All_models_are_wrong) + +> All models are wrong, but some are useful. +> +> _George Box_ + +This principle suggests that all models of systems are flawed, but that as long as they are not _too_ flawed they may be useful. This principle has its roots in statistics but applies to scientific and computing models as well. + +A fundamental requirement of most software is to model a system of some kind. Regardless of whether the system being modeled is a computer network, a library, a graph of social connections or any other kind of system, the designer will have to decide an appropriate level of detail to model. Excessive detail may lead to too much complexity, too little detail may prevent the model from being functional. + +See also: + +- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions) + +### Chesterson's Fence + +[Chesterson's Fence on Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence) + +> Reforms should not be made until the reasoning behind the existing state of affairs is understood. + +This principle is relevant in software engineering when removing technical debt. Each line of a program was originally written by someone for some reason. Chesterson's Fence suggests that one should try to understand the context and meaning of the code fully, before changing or removing it, even if at first glance it seems redundant or incorrect. + +The name of this principle comes from a story by [G.K. Chesterson](https://en.wikipedia.org/wiki/G._K._Chesterton). A man comes across a fence crossing the middle of the road. He complains to the mayor that this useless fence is getting in the way, and asks to remove it. The mayor asks why the fence is there in the first place. When the man says he doesn't know, the mayor says, "If you don't know its purpose, I certainly won't let you remove it. Go and find out the use of it, and then I may let you destroy it." + +### The Dead Sea Effect + +[The Dead Sea Effect on Bruce F. Webster](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/) + +> "... [T]he more talented and effective IT engineers are the ones most likely to leave - to evaporate ... [those who tend to] remain behind [are] the 'residue' — the least talented and effective IT engineers." +> +> _Bruce F. Webster_ + +The "Dead Sea Effect" suggests that in any organisation, the skills/talent/efficacy of engineers is often inversely proportional to their time in the company. + +Typically, highly skilled engineers find it easy to gain employment elsewhere and are the first to do so. Engineers who have obsolete or weak skills will tend to remain with the company, as finding employment elsewhere is difficult. This is particularly pronounced if they have gained incremental pay rises over their time in the company, as it can be challenging to get equivalent remuneration elsewhere. + +### The Dilbert Principle + +[The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle) + +> Companies tend to systematically promote incompetent employees to management to get them out of the workflow. +> +> _Scott Adams_ + +A management concept developed by Scott Adams (creator of the Dilbert comic strip), the Dilbert Principle is inspired by [The Peter Principle](#the-peter-principle). Under the Dilbert Principle, employees who were never competent are promoted to management in order to limit the damage they can do. Adams first explained the principle in a 1995 Wall Street Journal article, and expanded upon it in his 1996 business book, [The Dilbert Principle](#reading-list). + +See Also: + +- [The Peter Principle](#the-peter-principle) +- [Putt's Law](#putts-law) + ### The Pareto Principle (The 80/20 Rule) [The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle) @@ -316,21 +732,64 @@ 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: - In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). +### The Shirky Principle + +[The Shirky Principle explained](https://kk.org/thetechnium/the-shirky-prin/) + +> Institutions will try to preserve the problem to which they are the solution. +> +> _Clay Shirky_ + +The Shirky Principle suggests that complex solutions - a company, an industry, or a technology - can become so focused on the problem that they are solving, that they can inadvertently perpetuate the problem itself. This may be deliberate (a company striving to find new nuances to a problem which justify continued development of a solution), or inadvertent (being unable or unwilling to accept or build a solution which solves the problem completely or obviates it). + +Related to: + +- Upton Sinclair's famous line, _"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"_ +- Clay Christensen's _The Innovator's Dilemma_ + +See also: + +- [Pareto Principle](#the-pareto-principle-the-8020-rule) + +### The Peter Principle + +[The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle) + +> People in a hierarchy tend to rise to their "level of incompetence". +> +> _Laurence J. Peter_ + +A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their "level of incompetence"). At this point, as they are more senior, they are less likely to be removed from the organisation (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs. + +This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skills-set. + +See Also: + +- [The Dilbert Principle](#the-dilbert-principle) +- [Putt's Law](#putts-law) + ### The Robustness Principle (Postel's Law) [The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) > 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. These implications and other issues are described by Eric Allman in [The Robustness Principle Reconsidered](https://queue.acm.org/detail.cfm?id=1999945). + +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) -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. ### SOLID @@ -367,7 +826,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. Now imagine there is a new syntax added to the Markdown specification, which adds support for mathematical equations. The module should be _open to extension_ to implement the new mathematics syntax. However, existing syntax implementations (like paragraphs, bullets, etc) should be _closed for modification_. They already work, we don't want people to change them. 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. @@ -414,7 +873,7 @@ See also: ### The Dependency Inversion Principle -[The Dependency Inversion Principle](https://en.wikipedia.org/wiki/Dependency_inversion_principle) +[The Dependency Inversion Principle on Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle) > High-level modules should not be dependent on low-level implementations. @@ -447,15 +906,131 @@ See also: - [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) +### The KISS principle + +[KISS on Wikipedia](https://en.wikipedia.org/wiki/KISS_principle) + +> Keep it simple, stupid + +The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson. + +The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves. + +See also: + +- [Gall's Law](#galls-law) + +### YAGNI + +[YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it) + +This is an acronym for _**Y**ou **A**in't **G**onna **N**eed **I**t_. + +> Always implement things when you actually need them, never when you just foresee that you need them. +> +> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed") + +This _Extreme Programming_ (XP) principle suggests developers should only implement functionality that is needed for the immediate requirements, and avoid attempts to predict the future by implementing functionality that might be needed later. + +Adhering to this principle should reduce the amount of unused code in the codebase, and avoid time and effort being wasted on functionality that brings no value. + +See also: + +- [Reading List: Extreme Programming Installed](#reading-list) + +### The 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: + +- The network is reliable +- Latency is zero +- Bandwidth is infinite +- The network is secure +- Topology doesn't change +- There is one administrator +- Transport cost is zero +- The network is homogeneous + +The first four items were listed by [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) and [Tom Lyon](https://twitter.com/aka_pugs) around 1991 and first classified by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) as the "Fallacies of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy. + +The group was inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems). + +These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems. + +See also: + +- [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) + ## Reading List If you have found these concepts interesting, you may enjoy the following books. +- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming. - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book. - [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hofstadter's Law](#hofstadters-law) is from the book. +- [The Cathedral and the Bazaar - Eric S. Raymond](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) - a collection of essays on open source. This book was the source of [Linus's Law](#linuss-law). +- [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). +- [Structure and Interpretation of Computer Programs - Harold Abelson, Gerald Jay Sussman, Julie Sussman](https://www.goodreads.com/book/show/43713) - If you were a comp sci or electical engineering student at MIT or Cambridge this was your intro to programming. Widely reported as being a turning point in people's lives. + +## Online Resources + +Some useful resources and reading. + +- [CB Insights: 8 Laws Driving Success In Tech: Amazon's 2-Pizza Rule, The 80/20 Principle, & More](https://www.cbinsights.com/research/report/tech-laws-success-failure) - an interesting write up of some laws which have been highly influential in technology. + +## PDF eBook + +The project is available as a PDF eBook, [download the latest PDF eBook with this link](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) or check the [release](https://github.com/dwmkerr/hacker-laws/releases) page for older versions. + +A new version of the eBook is created automatically when a new version tag is pushed. + +## Podcast + +Hacker Laws has been featured in [The Changelog](https://changelog.com/podcast/403), you can check out the Podcast episode with the link below: + +Changelog Podcast Image + +## Translations + +Thanks to a number of wonderful contributors, Hacker Laws is available in a number of languages. Please consider sponsoring moderators! + +| Language | Moderator | Status | +|----------|-----------|--------| +| [🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)](https://gitlocalize.com/repo/2513/id?utm_source=badge) | +| [🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [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](./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) | +| [🇬🇷 ελληνικά / 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 | +| [🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)| [![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](https://gitlocalize.com/repo/2513/ja?utm_source=badge) | +| [🇰🇷 한국어 / 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) | +| [🇺🇦 українська мова / Ukrainian](./translations/uk.md) | [Nazar](https://github.com/troyane), [Helga Lastivka](https://github.com/HelgaLastivka) | [![gitlocalized ](https://gitlocalize.com/repo/2513/uk/badge.svg)](https://gitlocalize.com/repo/2513/uk?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. +- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - List, view and see random laws from the terminal! +- [Hacker Laws Action](https://github.com/marketplace/actions/hacker-laws-action) - Adds a random Hacker Law to a pull request as a small gift for the contributor, thanks [Umut Işık](https://github.com/umutphp) + +## 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! -Feel free to [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) requesting more details, or [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) to submit your proposed definition of the topic. +Feel free to [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) requesting more details, or [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) to submit your proposed definition of the topic. diff --git a/assets/sharing.md b/assets/sharing.md new file mode 100644 index 00000000..f35e7e7e --- /dev/null +++ b/assets/sharing.md @@ -0,0 +1,20 @@ +# Sharing + +Copy paste the below for sharing on social media. The channels are: + +- [Hacker News](https://news.ycombinator.com) +- [`r/programming`](https://reddit.com/r/programming/) +- LinkedIn +- Twitter + +## LinkedIn + +#hackerlaws - - + + + +Hacker Laws is a set of theories, principles and patterns that developers will find useful. + +Thanks + +#hacking #programming #coding #development #computerscience #logic diff --git a/images/Fitts_Law.svg b/images/Fitts_Law.svg new file mode 100644 index 00000000..c4059d67 --- /dev/null +++ b/images/Fitts_Law.svg @@ -0,0 +1,42 @@ + + + + + Layer 1 + + + + + + + + + + + + + Target + + W + + + + + + + + + + D + + + + + + + + + + + + \ No newline at end of file diff --git a/images/changelog-podcast.png b/images/changelog-podcast.png new file mode 100644 index 00000000..072bd002 Binary files /dev/null and b/images/changelog-podcast.png differ diff --git a/images/complete_graph.png b/images/complete_graph.png new file mode 100644 index 00000000..65a69285 Binary files /dev/null and b/images/complete_graph.png differ diff --git a/images/gitlocalize.png b/images/gitlocalize.png new file mode 100644 index 00000000..9d3069f8 Binary files /dev/null and b/images/gitlocalize.png differ diff --git a/images/hicks_law.svg b/images/hicks_law.svg new file mode 100644 index 00000000..b4079977 --- /dev/null +++ b/images/hicks_law.svg @@ -0,0 +1,35 @@ + +{\displaystyle T=b\cdot \log _{2}(n+1)} + + + \ No newline at end of file diff --git a/scripts/prepare-markdown-for-ebook.sh b/scripts/prepare-markdown-for-ebook.sh new file mode 100755 index 00000000..38bd356f --- /dev/null +++ b/scripts/prepare-markdown-for-ebook.sh @@ -0,0 +1,42 @@ +#!/usr/bin/env bash +# This script prepares a `hacker-laws.md` file which is in a format ready to be +# exported to PDF or other formats for an e-book. + +# Require that we provide the version number and get a date. +version=$1 +date=$(date "+%Y-%m-%d") + +if [ -z $version ]; then + echo "version must be specified: ./prepare-markdown-for-ebook.sh " + exit 1 +fi + +# Create the frontmatter. +cat << EOF > frontmatter.md +--- +title: "Hacker Laws" +author: "Dave Kerr, github.com/dwmkerr/hacker-laws" +subtitle: "Laws, Theories, Principles and Patterns that developers will find useful. ${version}, ${date}." +--- +EOF + +# Combine the frontmatter and the laws. +cat frontmatter.md README.md >> hacker-laws.md + +# Remove the title - we have it in the front-matter of the doc, so it will +# automatically be added to the PDF. +sed -i'' '/💻📖.*/d' hacker-laws.md + +# We can't have emojis in the final content with the PDF generator we're using. +sed -i'' 's/❗/Warning/' hacker-laws.md + +# Now rip out the translations line. +sed -i'' '/^\[Translations.*/d' hacker-laws.md + +# # Now rip out any table of contents items. +sed -i'' '/\*.*/d' hacker-laws.md +sed -i'' '/ \*.*/d' hacker-laws.md + +# Delete everything from 'Translations' onwards (we don't need the translations +# lists, related projects, etc). +sed -i'' '/## Translations/,$d' hacker-laws.md diff --git a/translations/es-ES.md b/translations/es-ES.md new file mode 100644 index 00000000..8c9a44c8 --- /dev/null +++ b/translations/es-ES.md @@ -0,0 +1,645 @@ +# 💻📖 hacker-laws + +Leyes, Teorías, Principios y Patrones que los desarrolladores encontrarán útiles. + +- 🇨🇳 [中文 / Versión China](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)! +- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)! +- 🇰🇷 [한국어 / Versión Koreana](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)! +- 🇷🇺 [Русская версия / Versión Rusa](https://github.com/solarrust/hacker-laws) - thanks [Alena Batitskaya](https://github.com/solarrust)! +- 🇹🇷 [Türkçe / Versión Turca](https://github.com/umutphp/hacker-laws-tr) - thanks [Umut Işık](https://github.com/umutphp) +- 🇧🇷 [Brasileiro / Versión Brasileña](./translations/pt-BR.md) - thanks [Leonardo Costa](https://github.com/LeoFC97) +- 🇺🇸 [Original English Version - Versión Original en Inglés](https://github.com/dwmkerr/hacker-laws) - grazie [Dave Kerr](https://github.com/dwmkerr)! + +¿Te gusta este proyecto? Por favor, considera [Esponsorizarme](https://github.com/sponsors/dwmkerr)! + +--- + + + +* [Introducción](#introduccion) +* [Leyes](#leyes) + * [Ley de Amdahl](#ley-de-amdahl) + * [Ley de Brooks](#ley-de-brooks) + * [Ley de Conway](#ley-de-conways) + * [Ley de Cunningham](#ley-de-cunningham) + * [Número de Dunbar](#numero-de-dunbar) + * [Ley de Gall](#ley-de-gall) + * [Cuchilla de Hanlon](#cuchilla-de-hanlon) + * [Ley de Hofstadter](#ley-de-hofstadter) + * [Ley de Hutber](#ley-de-hutber) + * [El Ciclo de Sobreexpectación y la Ley de Amara](#el-ciclo-de-sobreexpectacion-y-la-ley-de-amara) + * [Ley de Hyrum (La Ley de las Interfaces Implícitas)](#ley-de-hyrum-la-ley-de-las-interfaces-implicitas) + * [Ley de Metcalfe](#ley-de-metcalfe) + * [Ley de Moore](#ley-de-moore) + * [Ley de Murphy / Ley de Sod](#ley-de-murphy--ley-de-sod) + * [Ley de Parkinson](#ley-de-parkinson) + * [Efecto de Optimización Prematura](#efecto-de-optimizacion-prematura) + * [Ley de Putt](#ley-de-putt) + * [Ley de Reed](#ley-de-reed) + * [Ley de Conservación de Complejidad (Ley de Tesler)](#ley-de-conservacion-de-complejidad-ley-de-tesler) + * [Ley de Abstracciones Permeables](#ley-de-abstracciones-permeables) + * [Ley de la Trivialidad](#ley-de-la-trivialidad) + * [Filosofía Unix](#filosofia-unix) + * [El Modelo Spotify](#el-modelo-spotify) + * [Ley de Wadler](#ley-de-wadler) +* [Principios](#principios) + * [El Principio de Dilbert](#el-principio-de-dilbert) + * [El Principio de Pareto (La Regla 80/20)](#el-principio-de-pareto-la-regla-8020) + * [El Principio de Peter](#el-principio-de-peter) + * [El Principio de la Robustez (Ley de Postel)](#el-principio-de-la-robustez-ley-de-postel) + * [SOLID](#solid) + * [El Principio de Única Responsabilidad](#el-principio-de-unica-responsabilidad) + * [El Principio Abierto/Cerrado](#el-principio-abierto-cerrado) + * [El Principio de Sustitución de Liskov](#el-principio-de-sustitucion-de-liskov) + * [El Principio de Segregación de Interfaz](#el-principio-de-segregacion-de-interfaz) + * [El Principio de Inversión de Dependencia](#el-principio-de-inversion-de-dependencia) + * [El Principio DRY](#el-principio-dry) + * [El Principio KISS](#el-principio-kiss) + * [YAGNI](#yagni) +* [Lista de Lectura](#lista-de-lectura) +* [POR-HACER](#por-hacer) + + + +## Introducción + +Hay montones de leyes que la gente discute cuando habla sobre desarrollo. Este repositorio es una referencia y un resumen de algunos de los más conocidos. Por favor, ¡comparte y sube tus PRs! + +❗: Este repositorio contiene una explicación sobre algunas leyes, principios y patrones, pero no _defendemos_ ninguno de ellos. Si estos pueden ser aplicados o no siempre será materia de debate y muy dependiente de en qué estés trabajando. + +## Leyes + +¡Y aquí vamos! + +### Ley de Amdahl + +[Ley de Amdahl en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Amdahl) + +> La ley de Amdahl se puede interpretar de manera más técnica, pero en términos simples, significa que es el algoritmo el que decide la mejora de velocidad, no el número de procesadores. Finalmente se llega a un momento que no se puede paralelizar más el algoritmo. + +Mejor lo ilustramos con un ejemplo. Si un programa se compone de dos partes, la parte A debe ser ejecutada en un solo procesador y la parte B puede ser paralelizada, entonces vemos que agregamos múltiples procesadores al sistema en ejecución ese programa puede solo tener un beneficio limitado. Este puede potencialmente mejorar mucho la velocidad de la parte B - pero la velocidad de la parte A se mantendrá sin cambios. + +El diagrama de abajo muestra algunos ejemplos de mejoras potenciales en velocidad: + +![Diagram: Amdahl's Law](./images/amdahls_law.png) + +*(Imagen de Referencia: Por Daniels220 en Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* + +Como podemos ver, incluso un programa el cual es un 50% paralelizable se beneficiará muy poco más allá de 10 unidades de procesamiento, mientras que un programa el cual es 95% paralelizable todavía puede alcanzar mejoras significativas de velocidad con más de mil unidades de procesamiento. + +A medida que la [Ley de Moore](#ley-de-moore) se ralentiza y la aceleración de la velocidad del procesador individual disminuye, la paralelización es la clave para incrementar el rendimiento.La programación de gráficos es un excelente ejemplo: con la informática moderna basada en Shader, píxeles individuales o fragmentos pueden ser renderizados en paralelo. Este es el porqué las tarjetas gráficas modernas en ocasiones disponen de miles de núcleos de procesamiento (GPUs o Unidades de Shader). + +Vea también: + +- [Ley de Brooks](#ley-de-brooks) +- [Ley de Moore](#ley-de-moore) + +### Ley de Brooks + +[Ley de Brooks en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Brooks) + +> Cuando se incorpora una persona en un proyecto, éste se ralentiza en lugar de acelerarse. Brooks también afirmó que "Nueve mujeres no pueden tener un bebé en un mes". + +Esta ley sugiere que en muchos casos, intentar acelerar la entrega de un proyecto el cual ya va tarde, agregando más personas, hará que la entrega vaya aún más tarde. Brooks clarifica que esto es una simplificación, sin embargo, el razonamiento general es que el tiempo de aceleración de nuevos recursos y la sobrecarga de comunicación, en el inmediato corto plazo hace que la velocidad caiga. También, muchas tareas pueden no ser divisibles, es decir que pueden no ser fácilmente distribuibles entre más personas, significando que el potencial incremento de velocidad es incluso menor. + +La frase común en entregas "Nueve mujeres no pueden tener un bebé en un mes" está relacionada a la Ley de Brooks, en particular, al hecho de que algunos tipos de trabajos no son divisibles ni paralelizables. + +Este es el tema central del libro '[El Mítico Hombre Mes](#lista-de-lectura)'. + +Vea también: + +- [Marcha de la Muerte](#todo) +- [Lista de Lectura: El Mítico Hombre Mes](#reading-list) + +### Ley de Conway + +[La Ley de Conway en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Conway) + +Esta ley sugiere que los límites técnicos de un sistema reflejan la estructura de la organización. Es comúnmente referido a cuando se observan mejoras de una organización, la Ley de Conway sugiere que si una organización es estructurada en muchas unidades pequeñas y desconectadas, el software que producirá será así. Si una organización es construída más entorno a soluciones 'verticales' las cuales están orientadas alrededor de características o servicios, los sistemas de software también reflejarán esto. + +Vea también: + +- [El Modelo Spotify](#el-modelo-spotify) + +### Ley de Cunningham + +[Ley de Cunningham en Wikipedia](https://meta.wikimedia.org/wiki/Cunningham%27s_Law/es) + +> La mejor forma de obtener la respuesta correcta en Internet no es hacer una pregunta, es enviar la respuesta errónea. + +Acorde a Steven McGeady, Ward Cunningham le aconsejó a principios de los 80: "La mejor forma de obtener la respuesta correcta en Internet no es hacer una pregunta, es enviar una respuesta incorrecta." McGeady lo llamó la Ley de Cunningham, sin embargo Cunningham niega su propiedad diciendo que es una cita errónea. Aunque originalmente se refiere a las interacciones en Usenet, la ley ha sido usada para describir como otras comunidades online funcionan (e.g., Wikipedia, Reddit, Twitter, Facebook). + +Vea también: + +- [XKCD 386: "Duty Calls" (El Deber Llama)](https://xkcd.com/386/) + +### El Número de Dunbar + +[El Número de Dunbar en Wikipedia](https://es.wikipedia.org/wiki/N%C3%BAmero_de_Dunbar) + +"El número de Dunbar es un límite cognitivo sugerido sobre el número de personas con las que puedes mantener relaciones sociables estables- relaciones en las que un individuo sabe quien es la otra persona and cómo cada persona se relaciona con cada una de las otras personas." Hay algún desacuerdo sobre el número exacto. "... [Dunbar] propuso que los humanos pueden mantener cómodamente solo 150 relaciones estables." El puso el número dentro de un contexto más social, "el número de personas con las que no sentirías vergüenza de invitarlas a tomar una copa +"Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships— relationships in which an individual knows who each person is and how each person relates to every other person." There is some disagreement to the exact number. "... [Dunbar] proposed that humans can comfortably maintain only 150 stable relationships." He put the number into a more social context, "la cantidad de personas de las que no te sentirías avergonzado por unirte sin invitación a tomar una copa si te topas con ellas en un bar." Estima que el número puede rondar generalmente entre 100 y 250. + +Al igual que relaciones estables entre individuos, la relación de un desarrollador con su código base toma esfuerzo mantenerla. Cuando afrontas un gran número de proyectos complicados o creas muchos proyectos, nos apoyamos en convenciones, políticas y modelamos procedimientos para escalar. El número de Dunbar no es solo importante para tener en mente como una oficina crece, también cuando configuramos el alcance de los esfuerzos de un equipo o decidimos cuando debemos invertir en herramientas para asistir en el modelado y automatizar el sobregasto logístico. Poniendo el número en el contexto de ingeniería, es el número de proyectos (o complejidad normalizada de un único proyecto) para los cuales podrías sentirte seguro de unirte para las rondas de soporte telefónico. + +Vea también: + +- [Ley de Conway](#ley-de-conway) + +### Ley de Gall + +[Ley de Gall en Wikipedia (inglés)](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) + +> Un sistema complejo que funciona ha sido evolucionado invariablemente desde un sistema simple que funcionaba. Un sistema complejo diseñado desde cero nunca funcionará y no puede ser arreglado para que funcione. Tienes que comenzar de nuevo con un sistema simple que funcione. +> +> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author))) + + +La Ley de Gall implica que los intentos de _diseñar_ un sistema altamente complejo tenderán siempre a fallar. Sistemas altamente complejos son raramente construidos de una sola vez, estos suelen ser evoluciones de sistemas mucho más simples. + +El ejemplo clásico es la World Wide Web (WWW). En su estado actual, es un sistema altamente complejo. Sin embargo, esta fue definida inicialmente como una forma simple de compartir contenido entre instituciones académicas. Esta fue un éxito cumpliendo sus objetivos y evolucionó para llegar a ser más compleja con el tiempo. + +Vea también: + +- [KISS (Keep It Simple, Stupid)](#el-principio-kiss) + +### La Navaja de Hanlon + +[La Navaja de Hanlon en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Hanlon) + +> Nunca atribuyas a la malicia lo que puede ser adecuadamente explicado por la estupidez. +> +> Robert J. Hanlon + +Este principio sugiere que las acciones resultantes en un resultado negativo no fueron resultado de una mala intención. En su lugar el resultado negativo es mejor atribuído a que esas acciones y/o el impacto no fueron completamente entendidos. + +### Ley de Hofstadter + +[Ley de Hofstadter en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Hofstadter) + +> Siempre lleva más tiempo de lo que esperas, incluso si tienes en cuenta la Ley de Hofstadter. +> +> (Douglas Hofstadter) + +Quizás hayas oído esta ley referida a cuando se busca estimar el tiempo que tomará algo. Esto parece una verdad absoluta en el desarrollo de software donde tendemos a no ser muy buenos estimando con precisión cuanto tiempo tomará entregar algo. + +Esto proviene del libro '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-lectura)'. + +Vea también: + +- [Lista de lectura: Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-lectura) + +### Ley de Hutber + +[Ley de Hutber en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Hutber%27s_law) + +> Mejorar signfica deteriorar. +> +> ([Patrick Hutber (inglés)](https://en.wikipedia.org/wiki/Patrick_Hutber)) + +Esta ley sugiere que las mejoras realizadas en un sistema llevarán a su deterioro en otras partes, u ocultará otros deterioros, llevando a una degradación total del estado actual del sistema. + +Por ejemplo, un decremento en la latencia de respuesta para un end-point particular podría causar problemas de rendimiento y capacidad de procesamiento más adelante en el flujo de peticiones, afectando a un subsistema completamente diferente. + +### El Ciclo de Sobreexpectación y La Ley de Amara + +[El Ciclo de Sobreexpectación](https://es.wikipedia.org/wiki/Ciclo_de_sobreexpectaci%C3%B3n) + +> Tendemos a sobreestimar el efecto de una tecnología a corto plazo y subestimar su efecto a largo plazo. +> +> (Roy Amara) + +El Ciclo de Sobreexpectación es una representación visual de la excitación y desarrollo de tecnología a lo largo del tiempo, originalmente producido por Gartner. Se explica mejor de forma visual: + +![El Cico de Sobreexpectación](./images/gartner_hype_cycle.png) + +*(Referencia de Imagen: Por Jeremykemp en Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* + +En pocas palabras, el ciclo sugiere que hay una típica burbuja de excitación alrededor de cada nueva tecnología y su impacto potencial. Los equipos a veces saltan rápidamente a emplear estas tecnologías y a veces se encuentran a sí mismos decepcionados con los resultados. Esto puede ser porque la tecnología no es aún lo suficientemente madura, o las aplicaciones del mundo real no están completamente desarrolladas. Después de cierto tiempo, las capacidades de la tecnología se incrementan y las oportunidades de ser empleada de forma práctica aumentan permitiendo a los equipos ser finalmente productivos. La frase de Roy Amara resume este hecho de forma breve - "Tendemos a sobreestimar el efecto de una tecnología a corto plazo y subestimarla a largo plazo". + +### Ley de Hyrum (La Ley de las Interfaces Implícitas) + +[Ley de Hyrum (inglés)](http://www.hyrumslaw.com/) + +> Con un número suficiente de usuarios de una API, +> no importa que prometas en el contrato: +> alguien dependerá de todos los comportamientos observables +> de tu sistema. +> +> (Hyrum Wright) + +La Ley de Hyrum establece que cuando tienes un _número grande y suficiente de consumidores_ de una API, todos los comportamientos de la API (incluso aquellos no definidos como parte del contrato público) llegarán de forma eventual a ser dependencia de alguien. Un ejemplo trivial pueden ser los elementos no-funcionales como el tiempo de respuesta de una API. Un ejemplo más sutil puede ser qué consumidores están dependiendo en la aplicación de una expresión regular sobre un mensaje de error para determinar el *tipo* de error de una API. Incluso si el contrato público de la API no establece nada acerca del contenido del mensaje de error indicando a los usuarios que deben emplear un código de error, _algunos_ usuarios usarán el mensaje y cambiar el mensaje esencialmente romperá la API para estos usuarios. + +Vea también: + +- [La Ley de las Abstracciones Permeables](#la-ley-de-las-abstracciones-permeables) +- [XKCD 1172](https://xkcd.com/1172/) + + +### Ley de Metcalfe + +[Ley de Metcalfe en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Metcalfe's_law) + +> En teoría de redes, el número en el que un sistema crece es aproximadamente el cuadrado del número de usuarios de ese sistema. + +Esta ley está basada en el número de posibles conexiones por pares dentro de un sistema y está muy relacionado con [La Ley de Reed](#ley-de-reed). Odlyzko y otros han argumentado que ambas leyes (Reed y Metcalfe) exageran el valor de un sistema por no tener en cuenta los límites de la cognición humana en efectos de redes; vea [El Número de Dunbar](#numero-de-dunbar). + +Vea también: +- [Ley de Reed](#ley-de-reed) +- [Número de Dunbar](#numero-de-dunbar) + +### Ley de Moore + +[Ley de Moore en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Moore) + +> El número de transistores en un circuito integrado se dobla aproximadamente cada dos años. + +A veces empleado para ilustrar la velocidad pura a la que un semiconductor y la tecnología de chips ha mejorado, la predicción de Moore probó ser altamente precisa desde los 70 hasta finales de la primera década de 2000. En los años recientes, la tendencia ha cambiado ligeramente, parcialmente debido a [las limitaciones físicas en el grado en el que los componentes pueden ser miniaturizados (inglés)](https://en.wikipedia.org/wiki/Quantum_tunnelling). Sin embargo, los avances en la paralelización y potencialmente los cambios revolucionarios en la tecnología de semiconductores y computación cuántica puedan significar que la Ley de Moore continúe siendo cierta en las siguientes décadas. + +### Ley de Murphy / Ley de Sod + +[Ley de Murphy en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Murphy) + +> Si algo puede ir mal, irá mal. + +Relacionado con [Edward A. Murphy, Jr](https://es.wikipedia.org/wiki/Edward_A._Murphy_Jr.) la _Ley de Murphy_ establece que si algo puede ir mal, irá mal. + +Este dicho es muy común entre desarrolladores. A veces algo inesperado sucede cuando se desarrolla, se hacen pruebas o incluso en producción. Esto puede relacionarse también a la (más común en inglés británico) _Ley de Sod_: + +> Si algo puede ir mal, irá mal, en el peor momento posible. + +Estas leyes son generalmente empleadas en sentido cómico. Sin embargo, tales fenómenos como la [_Sesgo de Confirmación_](#por-hacer) y [_Sesgo de Selección_](#por-hacer) pueden llevar a la gente a sobre-enfatizar estas leyes (la mayoría de las veces cuando las cosas funcionan, estas pasan sin tenerse en cuenta, mientras que los fallos son muy notalbes y entran más en las conversaciones). + +Vea también: + +- [Sesgo de Confirmación](#por-hacer) +- [Sesgo de Selección](#por-hacer) + +### Ley de Parkinson + +[Ley de Parkinson en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Parkinson) + +> El trabajo se expande hasta llenar el tiempo disponible para que se termine. + +En su contexto original, esta Ley se basó en estudios de burocracias. Esta podía ser aplicada de forma pesimista a las iniciativas de desarrollo de software, la teoría sería que los equipos serán ineficientes hasta que la fecha de entrega esté cerca, entonces se apresurarán a completar el trabajo para la entrega, haciendo la fecha de entrega real de algún modo arbitraria. + +Si esta ley se combina con la [Ley de Hofstadter](#ley-de-hofstadter), un punto de vista incluso más pesimista es alcanzado - el trabajo se expandirá hasta rellenar el tiempo disponible para su compleción y *aún tomará más tiempo del esperado*. + +Vea también: + +- [Ley de Hofstadter](#ley-de-hofstadter) + +### Efecto de Optimización Prematura + +[Optimización Prematura en Wikipedia](https://es.wikipedia.org/wiki/Optimizaci%C3%B3n_de_software#Cu%C3%A1ndo_optimizar) + +> Debemos olvidar las pequeñas eficiencias, por ejemplo, el 97% del tiempo: la optimización prematura es la raíz de todos los males. +> +> [(Donald Knuth, diciembre de 1974)](https://twitter.com/realdonaldknuth) + +En el documento de Donald Knuth titulado [Programación Estructurada con Mandatos Go To (inglés)](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), escribió: "Los programadores desperdician enormes cantidades de tiempo pensando o preocupándose acerca de la velocidad de partes no-críticas de sus programas, y esos intentos de eficiencia en realidad tienen un impacto negativo cuando consideramos la depuración o el mantenimiento. Debemos olvidar las pequeñas eficiencias, por ejemplo, el 97% del tiempo: **la optimización prematura es la raíz de todos los males**. Aunque no debemos dejar pasar nuestras oportunidades en ese crítico 3%." + +Sin embargo, _Premature Optimization_ puede ser definido (en términos menos cargados) como nosotros sabemos lo que tenemos que hacer. + +### Ley de Putt + +[Ley de Putt (inglés)](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) + +> La Tecnología es dominada por dos tipos de personas, aquellos quienes comprenden lo que no controlan y aquellos quienes controllan lo que no entienden. + +La Ley de Putt a veces es seguida por el Corolario de Putt: + +> Cada jerarquía técnica, con el tiempo, desarrolla una inversión de competencia. + +Estos mandatos sugieren que debido a varios criterios de selección y tendencias en cómo los grupos se organizan, habrá un número de personas cualificadas en los niveles de trabajo de una organización técnica y una cantidad de personas en roles directivos que no son conscientes de las complejidades y desafíos del trabajo que están manejando. Esto puede ser debido al fenómenos tales como [El Principio de Peter](#el-principio-de-peter) o [El Principio de Dilbert](#el-principio-de-dilbert). + +Sin embargo, debe enfatizarse que leyes como esta son generalizaciones amplias y pueden aplicarse a _algunos_ tipos de organizaciones y no a otras. + +Vea también: + +- [El Principio de Peter](#el-principio-de-peter) +- [El Principio de Dilbert](#el-principio-de-dilbert) + +### La Ley de Reed + +[La Ley de Reed en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Reed's_law) + +> La utilidad de redes grandes, particularmente redes sociales, escala exponencialmente con el tamaño de la red. + +Esta ley está basada en la teoría de grafos, donde la utilidad escala como el número de posibles sub-grupos, el cuál es más rápido que el número de participantes o el número de posibles conexiones p +Esta ley se basa en la teoría de grafos, donde la utilidad se escala como el número de subgrupos posibles, que es más rápido que el número de participantes o el número de posibles conexiones por pares. Odlyzko y otros han argumentado que la Ley de Reed exagera la utilidad del sistema al no tener en cuenta los límites de la cognición humana sobre los efectos de la red; ver [El Número de Dunbar](#numero-de-dunbar). + +See also: +- [La Ley de Metcalfe's Law](#metcalfes-law) +- [Número de Dunbar](#numero-de-dunbar) + +### Ley de Conservación de Complejidad (Ley de Tesler) + +[La Ley de Conservación de Complejidad en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) + +Esta ley establece que hay una cierta cantidad de complejidad en un sistema la cuál no puede ser reducida. + +Cierta complejidad en un sistema puede ser 'involuntaria'. Es consecuencia de una estructura deficiente, errores o tan solo un mal modelo de un problema a resolver. La complejidad involuntaria puede ser reducida (o eliminada). Sin embargo, cierta complejidad es 'intrínseca' como consecuencia de la complejidad inherente de un problema que se está resolviendo. Esta complejidad puede ser desplazada, pero no eliminada. + +Un elemento interesate de esta ley es la sugerencia de que incluso simplificando el sistema entero, la complejidad intrínseca no se reduce, esta se _desplaza hacia el usuario_, el cuál debe comportarse de una forma compleja. + +### Ley de las Abstracciones Permeables + +[La Ley de las Abstracciones Permeables en Joel on Software (inglés)](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) + +> Toda abstracción no trivial, en algún grado, es permeable. +> +> ([Joel Spolsky](https://twitter.com/spolsky)) + +Esta ley establece que las abstracciones, las cuales son generalmente usadas en computación para simplificar el trabajo con sistemas complicados, en ciertas situaciones 'filtrarán' sus elementos a un sistema subyacente, haciendo que la abstracción se comporte de una forma inesperada. + +Un ejemplo puede ser la carga de un fichero y lectura de sus contenidos. Las APIs del sistema de ficheros son una _abstracción_ del bajo nivel de los sistemas del kernel, los cuales son en sí mismos abstracciones de los procesos físicos relacionados con el cambio de información en un disco magnético (o memoria flash para un SSD). En la mayoría de los casos, funcionará la abstracción de tratar al fichero como un flujo de datos binarios. Sin embargo, para un disco magnético, leer datos secuenciales puede ser *significativamente* más rápido que los accesos aleatorios (debido al aumento de la sobrecarga de fallas), pero no para un disco SSD donde este aumento no estará presente. Los detalles subyacentes necesitarán ser entendidos para tratar cada caso (por ejemplo, índices de base de datos son estructurados para reducir la sobrecarga del acceso aleatorio), la abstracción 'filtra' detalles de la implementación al desarrollador que pueda necesitar tener en cuenta. + +El ejemplo anterior puede llegar a ser aún más complejo cuando _más_ abstracciones sean introducidas. El sistema operativo Linux permite acceder a ficheros en red pero representados de forma local como ficheros 'normales'. Esta abstracción 'filtrará' si hay errores de red. Si un desarrollador trata estos ficheros como 'normales', sin considerar el hecho de que puedan estar sujetos a latencia de red y fallos, las soluciones serán defectuosas. + +El artículo que describe esta ley sugiere que una dependenica excesiva de abstracciones, combinada con un entendimiento deficiente del proceso subyacente, en realidad hace que tratar con el problema sea _más_ complejo en algunos casos. + +Vea también: + +- [Ley de Hyrum](#ley-de-hyrum-la-ley-de-las-interfaces-implicitas) + +Ejemplos del Mundo-Real: + +- [Inicio lento en Photoshop (inglés)](https://forums.adobe.com/thread/376152) - un problema que encontré en el pasado. Photoshop podría tener un inicio lento, algunas veces tomando incluso minutos. Parece que el problema fue debido a que al inicio lee cierta información sobre la impresora por defecto. Sin embargo, si la impresora está en red, esto puede tomar mucho tiempo. La _abstracción_ de una impresora en red siendo presentada al sistema de forma similar a una impresora local causó un problema para usuarios en situaciones de conectividad de red deficiente. + +### Ley de la Trivialidad + +[Ley de la Trivialidad en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Law_of_triviality) + +Esta ley sugiere que los grupos invertirán mucho más tiempo y atención a problemas triviales y cosméticos que a problemas serios y sustanciales. + +El ejemplo común y ficticio usado para ilustrarlo es que un comité aprobando planes para una planta nuclear invertirá la mayor parte del tiempo discutiendo la estructura del aparcamiento de bicicletas que diseños mucho más importantes para la planta nuclear en sí misma. Puede ser difícil hacer aportes valiosos en las discusiones sobre temas muy grandes y complejos sin un alto grado de experiencia y preparación en el tema. Sin embargo, la gente quiere ser vista contribuyendo de forma valiosa. De ahí la tendencia a enfocarse demasiado en detalles pequeños, los cuales pueden ser razonados fácilmente, pero no necesariamente de particular importancia. + +El ejemplo ficticio de arriba nos lleva al uso del término 'Aparcamiento de Bicicletas' (Bike Shedding) como una expresión para el desperdicio del tiempo en detalles triviales. + +### Filosofía Unix + +[La Filosofía Unix en Altenwald](https://altenwald.org/2008/09/22/filosofia-unix/) + +La Filosofía Unix es que los componentes de software debe ser pequeños y enfocados en hacer tan solo una cosa bien. Esto puede hacer más fácil construir sistemas a través de la composición conjunta de pequeñas, simples y bien definidas unidades mejor que usar programas grandes, complejos y multi-propósito. + +Prácticas modernas como 'Arquitectura de Microservicios' pueden ser pensadas como una aplicación de esta ley, donde los servicios son pequeños, enfocados y hacen una cosa específica, permitiendo componer comportamientos más complejos compuestos de bloques de construcción simples. + +### El Modelo Spotify + +[El Modelo Spotify en Spotify Labs (inglés)](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) + +El Modelo Spotify es un enfoque a una estructura de organización la cual ha sido popularizada por 'Spotify'. En este modelo, los equipos son organizados alrededor de características en lugar de tecnologías. + +El Modelo Spotify también popularizó los conceptos de Tribus, Gremios y Capítulos, los cuales son otros componentes de su estructura de organización. + +### Ley de Wadler + +[Ley de Wadler en wiki.haskell.org (inglés)](https://wiki.haskell.org/Wadler's_Law) + +> En cualquier diseño de lenguaje, el total de tiempo invertido en discutir una característica en su lista es proporcional a dos elevado a la potencia de su posición: +> +> 0. Semántica +> 1. Sintaxis +> 2. Sintaxis Léxica +> 3. Sintaxis Léxica de Comentarios +> +> (En pocas palabras, por cada hora invertida en semántica, 8 horas serán invertidas en la sintaxis de los comentarios). + +Similar a [La Ley de la Trivialidad](#ley-de-la-trivialidad), la Ley de Walder establece que cuando un se diseña un lenguaje, la cantidad de horas invertida en las estructuras del lenguaje es desproporcionadamente alta en comparación a la importancia de estas características. + +Vea también: + +- [La Ley de la Trivialidad](#ley-de-la-trivialidad) + +## Principios + +Los Principios son generalmente más propensos a ser pautas relacionadas al diseño. + +### El Principio de Dilbert + +[El Principio de Dilbert en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Dilbert_principle) + +> Las compañías tienden sistémicamente a promocionar empleados incompetentes a dirección para eliminarlos del flujo de trabajo. +> +> _Scott Adams_ + +Un concepto de administración desarrollado por Scott Adams (creador de la tira cómica de Dilbert), el Principio de Dilbert está inspirado por [El Principio de Peter](#el-principio-de-peter). Bajo el Principio de Dilbert, los empleados que nunca fueron competentes son promocionados a cargos directivos para limitar el daño que pueden hacer. Adams primero explicó el principio en 1995 en un artículo del Wall Street Journal y lo expandió en su libro de negocios publicado en 1996, [The Dilbert Principle (inglés)](#lista-de-lectura). + +Vea también: + +- [El Principio de Peter](#el-principio-de-peter) +- [Ley de Putt](#ley-de-putt) + +### El Principio de Pareto (La Regla 80/20) + +[El Principio de Pareto en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Pareto) + +> La mayoría de cosas en la vida no se distribuyen de forma uniforme. + +El Principio de Pareto sugiere que en algunos casos, la mayoría de los resultados vienen de la minoría de entradas: + +- El 80% de un cierto trozo de software puede ser escrito con el 20% del total de tiempo asignado (a la inversa, el 20% del código más difícil toma el 80% del tiempo). +- El 20% del esfuerzo produce el 80% del resultado +- El 20% del trabajo crea el 80% de los ingresos +- El 20% de los fallos causa el 80% de los problemas +- El 20% de las características se emplean 80% más que el resto + +En los años 1940s el ingeniero americano-romaní Dr. Joseph Juran, quien es ampliamente reconocido por atribuírsele ser el padre del control de calidad, [comenzó a aplicar el principio de Pareto a problemas de calidad](https://es.wikipedia.org/wiki/Joseph_Juran). + +Este principio es también conocido como: La Regla 80/20, La Ley de los Pocos Vitales y el Principio del Factor de Escasez. + +Ejemplos del Mundo-Real: + +- En 2002 Microsoft reportó que arreglando el 20% de los errores más reportados, 80% de los errores relacionados y los crashes en Windows y Office habían sido eliminados ([Referencia (en inglés)](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). + +### El Principio de Peter + +[El Principio de Peter en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Peter) + +> La gente en una jerarquía tiende a ascender hasta su "nivel de incompetencia". +> +> _Laurence J. Peter_ + +Un concepto de administración de Laurence J. Peter, el Principio de Peter observa que la gente que es buena en sus trabajos es promocionada hasta llegar a un nivel donde ya no son tan exitosos (su "nivel de incompetencia"). En este punto, como ellos son más _senior_, son menos propensos a ser eliminados de la organización (a menos que su rendimiento sea espectacularmente malo) y continuarán en un rol en el que tienen pocas habilidades intrínsecas. Las habilidades que les hicieron exitosos no son necesariamente las habilidades requeridas para sus nuevos puestos. + +Este es de particular interés para los ingenieros - quienes inicialmente comienzan en roles profundamente técnicos, pero a veces tienen una carrera la cual les guía a _administrar_ a otros ingenieros - los cuales requieren un conjunto fundamentalmente diferente de habilidades. + +Vea también: + +- [El Principio de Dilbert](#el-principio-de-dilbert) +- [La Ley de Putt](#ley-de-putt) + +### El Principio de Robustez (Ley de Postel) + +[El Principio de Robustez en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Robustness_principle) + +> Sé conservador en lo que haces y liberal con lo que recibes de otros. + +A veces aplicado en desarrollo de aplicaciones de servidor, este principio establece que lo que tú envias a otros debe ser tan mínimo y consensuado como sea posible, pero lo que deberías tener como objetivo es permitir la entrada no consensuada si es que puede ser procesada. + +El objetivo de este principio es construir sistemas los cuales sean robustos, tanto que puedan manejar entradas algo deficientes si aún pueden ser entendidas. Sin embargo, hay potenciales implicaciones de seguridad acerca de aceptar entradas mal formadas, particularmente si el procesamiento de tales entradas no ha sido bien testeado. + +### SOLID + +Este es un acrónimo el cual se refiere a: + +* S: [El Principio de Responsabilidad Única](#principio-de-responsabilidad-unica) (S por _Single Responsability_ del inglés) +* O: [El Principio Abierto/Cerrado](#principio-abierto-cerrado) (O por _Open/Close_) +* L: [El Principio de Sustitución de Liskov](#principio-de-sustitucion-de-liskov) (L por _Liskov_) +* I: [El Principio de Segregación de Interfaces](#principio-de-segregacion-de-interfaces) (I por _Interfaces Segregation_) +* D: [El Principio de Inversión de Dependencia](#principio-de-inversion-de-dependencia) + +Estos son los principios clave en la [Programación Orientada a Objetos](#por-hacer). Los principios de diseño tales como estos deben servir de ayuda a desarrolladores para construir sistemas más mantenibles. + +### Principio de Responsabilidad Única + +[El Principio de Responsabilidad Única en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_responsabilidad_%C3%BAnica) + +> Cada módulo o clase debe tener una tan solo una única responsabilidad. + +El primero de los principios '[SOLID](#solid)'. Este principio sugiere que los módulos o clases deben hacer una única cosa y solo una. En términos más prácticos, esto quire decir que una único, pequeño cambio a una característica de un programa debe requerir un cambio en un solo componente. Por ejemplo, cambiar como una contraseña es validada por complejidad debe requerir un cambio en solo una parte del programa. + +Teóricamente, esto debe hacer el código más robusto (sólido) y fácil de cambiar. Sabiendo que un componente el cual está siendo modificado tiene una única responsabilidad sólo significa que _comprobar_ ese cambio dede ser más fácil. Usando el ejemplo anterior, cambiar el componente de complejidad de la contraseña debe solo afectar a las características relacionadas con la complejidad de la contraseña. Puede ser mucho más difícil tener en cuenta el impacto de un cambio en un componente el cual tiene muchas responsabilidades. + +Vea también: + +- [Programación Orientada a Objetos](#por-hacer) +- [SOLID](#solid) + +### Principio de Abierto/Cerrado + +[Principio de Abierto/Cerrado](https://es.wikipedia.org/wiki/Principio_de_abierto/cerrado) + +> Las entidades deben estar abiertas para ser extendidas y cerradas para ser modificadas. + +El segundo de los principios '[SOLID](#solid). Este principio establece que las entidades (las cuales pueden ser clases, módulos, funciones u otras similares) deben tener la capacidad para ser _extendidas_ (ampliadas), pero de la misma forma debe _existir_ en su comportamiento la capacidad de no ser modificadas. + +Como un ejemplo hipotético, imagina un módulo el cual es capaz de convertir un documento Markdown en uno HTML. Si el módulo puede ser ampliado para manejar nuevas características de Markdown, sin modificar el funcionamiento interno del módulo, entonces podemos decir que está abierto para ser ampliado para su extensión. Si el módulo _no_ pudiera ser modificado por un consumidor de manera que se manejen las características existentes de Markdown, entonces se_cierra_ para su modificación. + +Este principio tiene una relevancia particular para la programación orientada a objetos, donde el diseño de objetos puede ser extendido (a través de la herencia), pero evitaríamos diseñar objetos los cuales puedan cambiar su comportamiento existente de formas inesperadas. + +Vea también: + +- [Programación Orientada a Objetos](#por-hacer) +- [SOLID](#solid) + +### Principio de Sustitución de Liskov + +[El Principio de Sustitución de Liskov en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_sustituci%C3%B3n_de_Liskov) + +> Debe ser posible reemplazar un tipo con un subtipo, sin romper el sistema. + +El tercero de los principios '[SOLID](#solid)'. Este principio establece que si un componente se basa en un tipo, entonces debe ser capaz de usar subtipos de ese tipo, sin que el sistema falle o tenga constancia de los detalles de que es un subtipo. + +Como un ejemplo, imagina que tenemos un método el cual lee un documento XML desde una estructura la cual representa un fichero. Si el método usa un tipo base 'fichero', entonces cualquiera que derive de 'fichero' debe ser capaz de ser usado en la función. Si 'fichero' soporta la búsqueda inversa, y el parseador de XML usa esa función, y entonces el tipo derivado 'fichero de red' falla cuando intenta una búsqueda inversa, el tipo derivado 'fichero de red' violaría el principio. + +Este principio tiene particular relevancia en programación orientada a objetos, donde la jerarquía de tipos debe ser modelada con cuidado para evitar confundir a los usuarios de un sistema. + +Vea también: + +- [Programación Orientada a Objetos](#por-hacer) +- [SOLID](#solid) + +### Principio de Segregación de Interfaces + +[El Principio de la Segregación de Interfaces en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_segregaci%C3%B3n_de_la_interfaz) + +> Ningún cliente debe ser forzado a depender de métodos que no use. + +El cuarto de los principios de '[SOLID](#solid)'. Este principio establece que los consumidores de un componente no deben depender en funciones de ese componente que no estén empleando. + +Como un ejemplo, imagina que tenemos un método el cual lee un documento XML de una estructura la cual representa un fichero. Este solo necesita leer bytes, moverse adelante y atrás en el fichero. Si este método necesita ser actualizado porque una característica no relacionada al fichero cambia (tal como una actualización al modelo de permisos usado para representar la seguridad del fichero), entonces el principio queda invalidado. Sería mejor para el fichero implementar una interfaz 'flujo-con-búsqueda' y emplearla para el lector XML. + +El principio tiene particular relevancia en programación orientada a objetos, donde las interfaces, jerarquías y abstracciones de tipos son usados para [minimizar el acoplamiento](#por-hacer) entre los diferentes componentes. [La tipificación dinámica](#por-hacer) (más conocida como _Duck typing_ en inglés) es una metodología que fuerza este principio eliminando las interfaces explícitas. + +Vea también: + +- [Programación Orientada a Objetos](#por-hacer) +- [SOLID](#solid) +- [Tipificación dinámica](#por-hacer) (_Duck typing_) +- [Desacoplado](#por-hacer) + +### Principio de Inversión de Dependencia + +[El Principio de Inversión de Dependencia en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Dependency_inversion_principle) + +> Módulos de alto-nivel no deben depender en implementaciones de bajo nivel. + +El quinto de los principios '[SOLID](#solid)'. Este principio establece que la orquestación de componentes del más alto nivel deben no tener conocimiento de los detalles de sus dependencias. + +Como un ejemplo, imagina que tenemos un programa que lee metadatos de un sitio web. Asumimos que el componente principal pueda tener que saber acerca de un componente de descarga del contenido de la página web y luego un componente que pueda leer los metadatos. Si tenemos la inversión de dependenicas en mente, el componente principal dependerá solo de un componente abstracto el cual obtendrá los bytes de datos y luego un componente abstracto que será capaz de leer los metadatos del flujo de bytes. El componente principal no sabrá nada acerca de TCP/IP, HTTP, HTML, etc. + +Este principio es complejo, puede ser visto como 'inverso' a las dependencias esperadas de un sistema (de ahí el nombre). En la práctica, esto también significa que se separa la orquestación de un componente y debe asegurarse la implementación correcta de los tipos abstractos que son empleados (e.g. en el ejemplo anterior, _algo_ debe aún proporcionar el componente de lectura de los metadatos un descargador de ficheros HTTP y un lector de etiquetas meta de HTML). Este entonces toca patrones tales como [Inversión de Control](#por-hacer) y [Inyección de Dependencias](#por-hacer). + +Vea también: + +- [Programación Orientada a Objetos](#por-hacer) +- [SOLID](#solid) +- [Inversión de Control](#por-hacer) +- [Inyección de Dependencias](#por-hacer) + +### Principio DRY + +[El Principio DRY en Wikipedia](https://es.wikipedia.org/wiki/No_te_repitas) + +> Cada pieza de conocimiento debe tener una representación única, no ambigua y autoritaria dentro de un sistema. + +DRY es el acrónimo en inglés para _Don't Repeat Yourself_ (No te repitas). Este principio se enfoca en ayudar a los desarrolladores a reducir las repeticiones de código y mantener la información en un único lugar y fue citado en 1999 por Andrew Hunt y Dave Thomas en el libro [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) (El Desarrollador Pragmático). + +> Lo contrario a DRY sería _WET_ (Write Everthing Twice, escribe todo dos veces o We Enjoy Typing, disfrutamos escribiendo) + +En la práctica, si tienes el mismo trozo de información en dos (o más) sitios diferentes, puedes usar DRY para mezclarlo en uno solo y reusarlo en cualquier lugar que lo quieras/necesites. + +Vea también: + +- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) + +### Principio KISS + +[KISS en Wikipedia](https://es.wikipedia.org/wiki/Principio_KISS) + +> Keep it simple, stupid (Mantenlo simple, estúpido) + +El principio KISS establece que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de complejos; por lo tanto, simplicidad debe ser el objetivo clave en el diseño y la complejidad innecesaria debe ser evitada. Originado en las fuerzas armadas de los Estados Unidos (U.S. Navy) en 1960, la frase ha sido asociada con la ingeniera aérea Kelly Johnson. + +El principio es mejor ejemplificado por la historia de Johnson manejando un equipo de ingenieros de diseño de herramientas, con el desafío del jet aircraft ellos debían diseñar sobretodo que fuese reparable por un mecánico medio en el campo y en condiciones de combate con solo esas herramientas. De aquí el "estúpido" refiriéndose a la relación entre la forma en que las cosas se rompen y la sofisticación de las herramientas disponibles para repararlas, no las capacidades de los ingenieros en sí mismos. + +Vea también: + +- [Ley de Gall](#ley-de-gall) + +### YAGNI + +[YAGNI en Wikipedia](https://es.wikipedia.org/wiki/YAGNI) + +Este es un acrónimo para (en inglés) _**Y**ou **A**ren't **G**onna **N**eed **I**t_ o _No vas a necesitarlo_. + +> Siempre implementar cosas cuando vayas a necesitarlas realmente, nunca cuando preveas que las necesitarás. +> +> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-fundador y autor del libro "Extreme Programming Installed") + +Este principio de _Extreme Programming_ (XP) sugiere a los desarrolladores que deben solo implementar funcionalidad que es necesaria para los requisitos inmediatos y evitar los intentos de predecir el futuro implementando funcionalidades que podrían necesitarse luego. + +Adherirse a este principio debe reducir la cantidad de código sin usar en la base de código y evitar tiempo y esfuerzo de ser malgastado en funcionalidades que no aportan valor. + +Vea también: + +- [Lista de lectura: Extreme Programming Installed](#lista-de-lectura) + + +## Lista de Lectura + +Si has encontrado estos conceptos interesantes, puede que disfrutes estos libros: + +- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming. +- [El Mítico Hombre Mes](https://es.wikipedia.org/wiki/El_M%C3%ADtico_Hombre-Mes) - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book. +- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hofstadter's Law](#hofstadters-law) is from the book. +- [The Dilbert Principle - Adam Scott](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-principl). +- [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). + +## Por Hacer + +¡Hola! Si llegaste aquí es porque hiciste clic en un enlace a un tema que aún no ha sido escrito, perdón por eso, ¡este es aún un trabajo en proceso! + +Sé libre de [Abrir un _Issue_](https://github.com/manuel-rubio/hacker-laws/issues) para solicitar más detalles, o [abre una petición de cambio (_pull request_)](https://github.com/manuel-rubio/hacker-laws/pulls) para enviar tus definiciones propuestas acerca del asunto. diff --git a/translations/fr.md b/translations/fr.md new file mode 100644 index 00000000..128a6c65 --- /dev/null +++ b/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). + +--- + + + +- [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) + + + +## 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 : + +Diagram: Amdahl's Law + +*(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 effets 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 revue de code (*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.) devrait être *étendu*, mais que le comportement *existant* ne devrait pas ê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 le codebase et permet d'éviter de passer du temps 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. diff --git a/translations/id.md b/translations/id.md new file mode 100644 index 00000000..e64c219b --- /dev/null +++ b/translations/id.md @@ -0,0 +1,783 @@ +# 💻📖 Undang Undang Peretas + +[![gitlocalized](https://gitlocalize.com/repo/2513/whole_project/badge.svg)](https://gitlocalize.com/repo/2513/whole_project?utm_source=badge) + +Hukum, Teori, Prinsip dan Pola yang berguna bagi pengembang (developer). + +- 🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - Terima kasih kepada [Steve Xu](https://github.com/nusr)! +- 🇮🇹 [Traduzione in Italiano](https://github.com/dwmkerr/hacker-laws/blob/master/translations/it-IT.md) - Terima kasih kepada [Claudio Sparpaglione](https://github.com/csparpa)! +- 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - Terima kasih kepada [Doughnut](https://github.com/codeanddonuts)! +- 🇷🇺 [Русская версия / Russian Version](https://github.com/solarrust/hacker-laws) - Terima kasih kepada [Alena Batitskaya](https://github.com/solarrust)! +- 🇹🇷 [Türkçe / Turkish Version](https://github.com/umutphp/hacker-laws-tr) - Terima kasih kepada [Umut Işık](https://github.com/umutphp) +- 🇧🇷 [Brasileiro / Brazilian Version](./translations/pt-BR.md) - Terima kasih kepada [Leonardo Costa](https://github.com/LeoFC97) +- 🇪🇸 [Castellano / Spanish Version](./translations/es-ES.md) - Terima kasih kepada [Manuel Rubio](https://github.com/manuel-rubio) + +Suka dengan project ini? Silahkan Mempertimbangkan untuk [Mensponsori saya](https://github.com/sponsors/dwmkerr)! + +--- + + + +* [Pendahuluan](#pendahuluan) +* [Undang Undang](#undang-undang) + * [Hukum Amdahl](#hukum-amdahl) + * [Teori Windows Rusak](#teori-windows-rusak) + * [Hukum Brooks](#hukum-brook) + * [Hukum Conway](#hukum-conway) + * [Hukum Cunningham](#hukum-cunningham) + * [Nomor Dunbar](#nomor-dunbar) + * [Hukum Gall](#hukum-gall) + * [Hukum Goodhart](#hukum-goodhart) + * [Pisau Cukur Hanlon](#pisau-cukur-hanlon) + * [Hukum Hofstadter](#hukum-hofstadter) + * [Hukum Hutber](#hukum-hutber) + * [Siklus Hype & Hukum Amara](#sirklus-hype-dan-hukum-amara) + * [Hukum Hyrum (Hukum Antarmuka Implisit)](#hukum-hyrum-hukum-antarmuka-implisit) + * [Hukum Kernighan](#hukum-kernighan) + * [Hukum Metcalfe](#hukum-metcalfe) + * [Hukum Moore](#hukum-moore) + * [Hukum Murphy / Hukum Sod](#hukum-murphy) + * [Pisau Cukur Occam](#pisau-cukup-occam) + * [Hukum Parkinson](#hukum-parkinson) + * [Efek Optimalisasi Prematur](#efek-optimasi-prematur) + * [Hukum Putt](#hukum-putt) + * [Hukum Reed](#hukum-reed) + * [Hukum Konservasi Kompleksitas (Hukum Tesler)](#hukum-konservasi-kompleksitas-hukum-tesler) + * [Hukum Abstraksi Kebocoran](#hukum-abstraksi-kebocoran) + * [Hukum Triviality](#hukum-triviality) + * [Filsafat Unix](#filsafat-unix) + * [Model Spotify](#model-spotify) + * [Hukum Wadler](#hukum-wadler) + * [Hukum Wheaton](#hukum-gandum) +* [Prinsip](#prinsip) + * [Prinsip Dilbert](#prinsip-dilbert) + * [Prinsip Pareto (Aturan 80/20)](#prinsip-pareto-aturan-8020) + * [Prinsip Peter](#prinsip-peter) + * [Prinsip Robustness (Hukum Postel)](#prinsip-robustness-princihukumple-postel) + * [SOLID](#solid) + * [Prinsip Tanggung Jawab Tunggal](#prinsip-tanggung-jawab-tunggal) + * [Prinsip Terbuka / Tertutup](#prinsip-terbukatertutup) + * [Prinsip Substitusi Liskov](#prinsip-substitusi-liskov) + * [Prinsip Segregasi Antarmuka](#prinsip-segregasi-antarmuka) + * [Prinsip Ketergantungan Inversi](#prinsip-ketergantungan-inversi) + * [Prinsip KERING](#prinsip-kering) + * [Prinsip KISS](#prinsip-kiss) + * [YAGNI](#yagni) + * [Kekeliuran Komputasi Terdistribusi](#kekeliuran-komputasi-terdistribusi) +* [Daftar Bacaan](#daftar-bacaan) +* [Berkontribusi](#berkontribusi) +* [TODO](#todo) + + + +## Pendahuluan + +Ada banyak undang-undang yang dibahas orang ketika berbicara tentang pembangunan. Repositori ini adalah referensi dan gambaran umum dari beberapa yang paling umum. Silakan bagikan dan kirimkan PR! + +❗: Repo ini berisi penjelasan tentang beberapa undang-undang, prinsip, dan pola, tetapi tidak _advokasi_ untuk salah satu dari mereka. Apakah mereka harus diterapkan akan selalu menjadi masalah perdebatan, dan sangat tergantung pada apa yang sedang Anda kerjakan. + +## Undang-undang + +Dan ini dia! + +### Hukum Amdahl + +[Hukum Amdahl di Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law) + +> Hukum Amdahl adalah formula yang menunjukkan _kecepatan potensial_ dari tugas komputasi yang dapat dicapai dengan meningkatkan sumber daya suatu sistem. Biasanya digunakan dalam komputasi paralel, ia dapat memprediksi manfaat secara aktual dari peningkatan jumlah prosesor, yang dibatasi oleh kemampuan program yang paralel. + +Ilustrasikan terbaik dengan sebuah contoh. Jika suatu program terdiri dari dua bagian, bagian A, yang harus dijalankan oleh satu prosesor, dan bagian B, yang dapat diparalelkan, maka jika kita melihat ketika menambahkan beberapa prosesor ke sistem yang menjalankan program maka hanya dapat memiliki manfaat yang terbatas. Ini berpotensi dapat sangat meningkatkan kecepatan bagian B - tetapi kecepatan bagian A akan tetap tidak berubah. + +Diagram di bawah ini menunjukkan beberapa contoh peningkatan kecepatan potensial: + +Diagram: Amdahl's Law + +*(Gambar referensi: Oleh Daniels220 di Wikipedia Bahasa Inggris, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* + +Seperti dapat dilihat, bahkan sebuah program yang parallelisable 50% akan mendapat manfaat sangat sedikit di luar 10 unit pemrosesan, sedangkan program yang 95% parallelisable masih dapat mencapai peningkatan kecepatan yang signifikan dengan lebih dari seribu unit pemrosesan. + +Karena [Hukum Moore](#hukum-moore) melambat, dan akselerasi kecepatan prosesor individu melambat, parallelisation adalah kunci untuk meningkatkan kinerja. Pemrograman grafik adalah contoh yang sangat baik - dengan komputasi berbasis Shader modern, piksel atau fragmen individual dapat diterjemahkan secara paralel - inilah sebabnya modern graphics cards sering memiliki ribuan inti pemrosesan (GPU atau Unit Shader). + +Lihat juga: + +- [Hukum Brook](#hukum-brook) +- [Hukum Moore](#hukum-moore) + +### Teori Windows Rusak + +[Teori Windows Rusak di Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory) + +Teori Windows Rusak menunjukkan bahwa tanda-tanda kejahatan yang nyata (atau kurangnya kepedulian terhadap suatu lingkungan) mengarah pada kejahatan yang semakin serius (atau semakin memburuknya lingkungan). + +Teori ini telah diterapkan pada pengembangan perangkat lunak, menunjukkan bahwa kode kualitas yang buruk (atau [Utang Teknis](#TODO)) dapat mengarah pada persepsi bahwa upaya untuk meningkatkan kualitas dapat diabaikan atau diremehkan, sehingga mengarah pada kode kualitas yang lebih buruk lagi. Efek ini mengalir ke penurunan kualitas yang besar dari waktu ke waktu. + +Lihat juga: + +- [Hutang Teknis](#TODO) + +Contoh: + +- [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/) + +### Hukum Brooks + +[Hukum Brooks di Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law) + +> Menambahkan sumber daya manusia ke proyek pengembangan perangkat lunak yang terlambat membuatnya nanti. + +Undang-undang ini menunjukkan bahwa dalam banyak kasus, upaya untuk mempercepat pengiriman proyek yang sudah terlambat, dengan menambah lebih banyak orang, akan membuat pengiriman lebih lambat. Brooks jelas bahwa ini adalah penyederhanaan yang berlebihan, namun, alasan umum adalah bahwa mengingat peningkatan waktu sumber daya baru dan overhead komunikasi, dalam jangka pendek langsung kecepatan berkurang. Selain itu, banyak tugas yang mungkin tidak dapat dibagi, yaitu mudah didistribusikan di antara lebih banyak sumber daya, yang berarti peningkatan kecepatan potensial juga lebih rendah. + +Ungkapan umum dalam persalinan "Sembilan wanita tidak bisa menghasilkan bayi dalam satu bulan" berhubungan dengan Hukum Brooks, khususnya, fakta bahwa beberapa jenis pekerjaan tidak dapat dibagi atau diparalelkan. + +Ini adalah tema sentral dari buku '[The Mythical Man Month](#daftar-bacaan)'. + +Lihat juga: + +- [Death March](#todo) +- [Daftar Bacaan: The Mythical Man Month](#daftar-bacaan) + +### Hukum Brooks + +[Hukum Brooks di Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law) + +Undang-undang ini menyatakan bahwa batasan teknis suatu sistem akan mencerminkan struktur organisasi. Ini biasa disebut ketika melihat perbaikan organisasi, Hukum Brooks menyarankan bahwa jika organisasi terstruktur menjadi banyak unit kecil, terputus, perangkat lunak yang dihasilkannya akan. Jika suatu organisasi dibangun lebih di sekitar 'vertikal' yang berorientasi pada fitur atau layanan, sistem perangkat lunak juga akan mencerminkan hal ini. + +Lihat juga: + +- [Model Spotify](#model-spotify) + +### Hukum Cunningham + +[Hukum Cunningham di Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law) + +> Cara terbaik untuk mendapatkan jawaban yang benar di Internet adalah tidak dengan mengajukan pertanyaan, itu untuk mengirim jawaban yang salah. + +Menurut Steven McGeady, Ward Cunningham menasihatinya pada awal 1980-an: "Cara terbaik untuk mendapatkan jawaban yang benar di Internet adalah tidak mengajukan pertanyaan, itu untuk mengirim jawaban yang salah." McGeady menjuluki Hukum Cunningham ini, meskipun Cunningham menyangkal kepemilikan menyebutnya "salah kutip." Meskipun awalnya merujuk pada interaksi di Usenet, undang-undang tersebut telah digunakan untuk menggambarkan cara kerja komunitas online lainnya (mis., Wikipedia, Reddit, Twitter, Facebook). + +Lihat juga: + +- [XKCD 386: "Duty Calls"](https://xkcd.com/386/) + +### Nomor Dunbar + +[Nomor Dunbar di Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number) + +"Nomor Dunbar adalah batasan kognitif yang disarankan untuk jumlah orang yang dengannya seseorang dapat mempertahankan hubungan sosial yang stabil — hubungan di mana seorang individu mengetahui siapa setiap orang dan bagaimana setiap orang berhubungan dengan setiap orang lainnya." Ada beberapa perbedaan pendapat tentang jumlah pastinya. "... [Dunbar] mengusulkan agar manusia dapat dengan nyaman mempertahankan hanya 150 hubungan yang stabil." Dia memasukkan nomor itu ke dalam konteks yang lebih sosial, "jumlah orang yang Anda tidak akan merasa malu untuk bergabung tanpa diundang untuk minum jika Anda kebetulan menabrak mereka di sebuah bar." Perkiraan angka umumnya berkisar antara 100 dan 250. + +Seperti hubungan stabil antara individu, hubungan pengembang dengan basis kode membutuhkan upaya untuk mempertahankan. Ketika dihadapkan dengan proyek-proyek besar yang rumit, atau kepemilikan banyak proyek, kami bersandar pada konvensi, kebijakan, dan model prosedur untuk menskalakan. Nomor Dunbar tidak hanya penting untuk diingat ketika kantor tumbuh, tetapi juga ketika menetapkan ruang lingkup untuk upaya tim atau memutuskan kapan suatu sistem harus berinvestasi dalam perkakas untuk membantu dalam pemodelan dan mengotomatisasi overhead logistik. Menempatkan nomor ke dalam konteks teknik, itu adalah jumlah proyek (atau kompleksitas dinormalisasi dari satu proyek) di mana Anda akan merasa yakin untuk bergabung dengan rotasi on-call untuk mendukung. + +Lihat juga: + +- [Hukum Conway](#Hukum-conway) + +### Hukum Gall + +[Hukum Gall di Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) + +> Sebuah sistem kompleks yang berfungsi selalu ditemukan telah berevolusi dari sistem sederhana yang berfungsi. Sistem kompleks yang dirancang dari awal tidak pernah berfungsi dan tidak dapat ditambal untuk membuatnya berfungsi. Anda harus memulai dari awal dengan sistem sederhana yang berfungsi. +> +> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author))) + +Hukum Gall menyiratkan bahwa upaya untuk _design_ sistem yang sangat kompleks cenderung gagal. Sistem yang sangat kompleks jarang dibangun dalam sekali jalan, tetapi malah berkembang dari sistem yang lebih sederhana. + +Contoh klasik adalah world-wide-web. Dalam kondisi saat ini, ini adalah sistem yang sangat kompleks. Namun, itu didefinisikan pada awalnya sebagai cara sederhana untuk berbagi konten antar institusi akademik. Itu sangat sukses dalam mencapai tujuan-tujuan ini dan berkembang menjadi lebih kompleks dari waktu ke waktu. + +Lihat juga: + +- [KISS (Keep It Simple, Stupid)](#prinsip-kiss) + +### Hukum Goodhart + +[Hukum Goodhart di Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law) + +> Setiap keteraturan statistik yang diamati akan cenderung runtuh begitu tekanan diberikan untuk tujuan kontrol. +> +> _Charles Goodhart_ + +Juga biasa dirujuk sebagai: + +> Ketika suatu ukuran menjadi target, itu tidak lagi menjadi ukuran yang baik. +> +> _Marilyn Strathern_ + +Undang-undang menyatakan bahwa optimasi yang digerakkan oleh tindakan dapat mengarah pada devaluasi hasil pengukuran itu sendiri. Seperangkat tindakan yang terlalu selektif ([KPI](https://en.wikipedia.org/wiki/Performance_indicator)) yang diterapkan secara membuta pada suatu proses menghasilkan efek yang terdistorsi. Orang-orang cenderung untuk mengoptimalkan secara lokal dengan "bermain-main" sistem untuk memenuhi metrik tertentu daripada memperhatikan hasil holistik dari tindakan mereka. + +Contoh dunia nyata: +- Tes bebas-konfirmasi memenuhi ekspektasi cakupan kode, meskipun faktanya maksud metrik adalah untuk menciptakan perangkat lunak yang teruji dengan baik. +- Skor kinerja pengembang ditunjukkan oleh jumlah baris yang dilakukan mengarah pada basis kode yang terlalu besar yang tidak dapat dibenarkan. + +Lihat juga: + +- [Hukum Goodhart: Bagaimana Mengukur Hal-Hal yang Salah Mendorong Perilaku Tidak bermoral](https://coffeeandjunk.com/goodharts-campbells-law/) +- [Dilbert pada perangkat lunak bebas bug](https://dilbert.com/strip/1995-11-13) + +### Pisau Cukur Hanlon + +[Pisau Cukur Hanlon di Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor) + +> Jangan mengaitkan dengan kedengkian yang dijelaskan dengan cukup oleh kebodohan. +> +> Robert J. Hanlon + +Prinsip ini menunjukkan bahwa tindakan yang menghasilkan hasil negatif bukanlah hasil dari niat buruk. Sebaliknya hasil negatif lebih cenderung dikaitkan dengan tindakan-tindakan dan / atau dampak yang tidak sepenuhnya dipahami. + +### Hukum Hofstadter + +[Hukum Hofstadter di Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law) + +> Itu selalu memakan waktu lebih lama dari yang Anda harapkan, bahkan ketika Anda memperhitungkan Hukum Hofstadter. +> +> (Douglas Hofstadter) + +Anda mungkin mendengar undang-undang ini disebut ketika melihat perkiraan berapa lama sesuatu akan terjadi. Tampaknya disangkal dalam pengembangan perangkat lunak yang kita cenderung tidak pandai memperkirakan secara akurat berapa lama waktu yang diperlukan untuk menghasilkan. + +Ini dari buku '[Gödel, Escher, Bach: An Eternal Golden Braid](#daftar-bacaan)'. + +Lihat juga: + +- [Daftar Bacaan: Gödel, Escher, Bach: An Eternal Golden Braid](#daftar-bacaan) + +### Hukum Hutber + +[Hukum Hutber di Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) + +> Perbaikan berarti kemunduran. +> +> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber)) + +Undang-undang ini menunjukkan bahwa perbaikan pada suatu sistem akan menyebabkan kerusakan pada bagian lain, atau akan menyembunyikan kemunduran lainnya, yang secara keseluruhan mengarah pada degradasi dari kondisi sistem saat ini. + +Sebagai contoh, penurunan latensi respons untuk titik akhir tertentu dapat menyebabkan peningkatan throughput dan masalah kapasitas lebih lanjut dalam aliran permintaan, yang mempengaruhi sub-sistem yang sama sekali berbeda. + +### Siklus Hype & Hukum Amara + +[Siklus Hype di Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle) + +> Kita cenderung melebih-lebihkan efek teknologi dalam jangka pendek dan meremehkan efek dalam jangka panjang. +> +> (Roy Amara) + +Hype Siklus adalah representasi visual dari kegembiraan dan pengembangan teknologi dari waktu ke waktu, awalnya diproduksi oleh Gartner. Paling baik ditunjukkan dengan visual: + +![Siklus Hype](./../images/gartner_hype_cycle.png) + +*(Referensi Gambar: Oleh Jeremykemp di bahasa inggris Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* + +Singkatnya, siklus ini menunjukkan bahwa biasanya ada ledakan kegembiraan di sekitar teknologi baru dan dampak potensialnya. Tim sering melompat ke teknologi ini dengan cepat, dan kadang-kadang merasa kecewa dengan hasilnya. Ini mungkin karena teknologinya belum cukup matang, atau aplikasi dunia nyata belum sepenuhnya terwujud. Setelah waktu tertentu, kemampuan teknologi meningkat dan peluang praktis untuk menggunakannya meningkat, dan tim akhirnya menjadi produktif. Kutipan Roy Amara meringkas ini dengan paling ringkas - "Kita cenderung melebih-lebihkan efek teknologi dalam jangka pendek dan meremehkan dalam jangka panjang". + +### Hukum Hyrum (Hukum Antarmuka Implisit) + +[Hukum Hyrum](http://www.hyrumslaw.com/) + +> Dengan jumlah pengguna API yang memadai, +> tidak masalah apa yang Anda janjikan dalam kontrak: +> semua perilaku yang dapat diamati dari sistem Anda +> akan bergantung pada seseorang. +> +> (Hyrum Wright) + +Hukum Hyrum menyatakan bahwa ketika Anda memiliki jumlah konsumen yang cukup besar dari suatu API, semua perilaku API (bahkan mereka yang tidak didefinisikan sebagai bagian dari kontrak publik) pada akhirnya akan tergantung pada seseorang. Contoh sepele mungkin elemen non-fungsional seperti waktu respons API. Contoh yang lebih halus mungkin konsumen yang mengandalkan menerapkan regex ke pesan kesalahan untuk menentukan * jenis * kesalahan API. Sekalipun kontrak publik API tidak menyatakan apa-apa tentang isi pesan, mengindikasikan bahwa pengguna harus menggunakan kode kesalahan yang terkait, _beberapa_ pengguna dapat menggunakan pesan tersebut, dan mengubah pesan pada dasarnya merusak API untuk para pengguna tersebut. + +Lihat juga: + +- [Hukum Abstraksi Kebocoran](#hukum-abstraksi-kebocoran) +- [XKCD 1172](https://xkcd.com/1172/) + +### Hukum Kernighan + +> Debugging dua kali lebih sulit daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk debug itu. +> +> (Brian Kernighan) + +Hukum Kernighan adalah nama untuk [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) dan berasal dari kutipan dari buku Kernighan dan Plauger [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style): + +> Semua orang tahu bahwa debugging dua kali lebih sulit daripada menulis sebuah program. Jadi, jika Anda sepintar ketika Anda menulisnya, bagaimana Anda akan men-debug-nya? + +Sementara hiperbolik, Hukum Kernighan berpendapat bahwa kode sederhana lebih disukai daripada kode kompleks, karena men-debug setiap masalah yang muncul dalam kode kompleks mungkin mahal atau bahkan tidak layak. + +Lihat juga: + +- [Prinsip KISS](#prinsip-kiss) +- [Filsafat Unix](#filsafat-unix) +- [Pisau Cukur Occam](#pisau-cukup-occam) + +### Hukum Metcalfe + +[Hukum Metcalfe di Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law) + +> Dalam teori jaringan, nilai suatu sistem tumbuh sekitar kuadrat dari jumlah pengguna sistem. + +Undang-undang ini didasarkan pada jumlah kemungkinan koneksi berpasangan dalam suatu sistem dan terkait erat dengan [Hukum Reed](#hukum-reed). Odlyzko dan yang lainnya berpendapat bahwa Hukum Reed dan Hukum Metcalfe melebih-lebihkan nilai sistem dengan tidak memperhitungkan batas-batas kognisi manusia pada efek jaringan; lihat [Nomor Dunbar](#nomor-dunbar). + +Lihat juga: + +- [Hukum Reed](#hukum-reed) +- [Nomor Dunbar](#nomor-dunbar) + +### Hukum Moore + +[Hukum Moore di Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law) + +> Jumlah transistor dalam sirkuit terintegrasi bertambah dua kali lipat setiap dua tahun. + +Sering digunakan untuk menggambarkan kecepatan di mana semikonduktor dan teknologi chip telah meningkat, prediksi Moore telah terbukti sangat akurat dari tahun 1970-an hingga akhir 2000-an. Dalam beberapa tahun terakhir, tren telah berubah sedikit, sebagian karena [keterbatasan fisik pada sejauh mana komponen dapat miniatur](https://en.wikipedia.org/wiki/Quantum_tunnelling). Namun, kemajuan dalam parallelisation, dan perubahan revolusioner yang berpotensi dalam teknologi semikonduktor dan komputasi kuantum dapat berarti bahwa Hukum Moore dapat terus berlaku selama beberapa dekade mendatang. + +### Hukum Murphy / Hukum Sod + +[Hukum Murphy di Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law) + +> Apa pun yang bisa salah akan salah. + +Terkait dengan [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Hukum Murphy_ menyatakan bahwa jika ada sesuatu yang salah, itu akan salah. + +Ini adalah pepatah umum di kalangan pengembang. Terkadang hal tak terduga terjadi ketika mengembangkan, menguji, atau bahkan dalam produksi. Ini juga dapat dikaitkan dengan (lebih umum dalam bahasa Inggris Inggris) _Hukum Sod_: + +> Jika ada yang salah, itu akan terjadi, pada saat yang paling buruk. + +'Hukum' ini umumnya digunakan dalam bentuk komik. Namun, fenomena seperti [_Pastikan Konfirmasi_](#TODO) dan [_Seleksi Pemilu_](#TODO) dapat membuat orang mungkin terlalu menekankan hukum-hukum ini (sebagian besar waktu ketika sesuatu bekerja, mereka tidak diperhatikan, kegagalan namun lebih terlihat. dan menarik lebih banyak diskusi). + +Lihat juga: + +- [Confirmation Bias](#TODO) +- [Selection Bias](#TODO) + +### Pisau Cukur Occam + +[Pisau Cukur Occam di Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor) + +> Entitas tidak boleh dikalikan tanpa keharusan. +> +> William dari Ockham + +Pisau Cukur Occam mengatakan bahwa di antara beberapa solusi yang mungkin, solusi yang paling mungkin adalah solusi dengan jumlah konsep dan asumsi paling sedikit. Solusi ini adalah yang paling sederhana dan hanya menyelesaikan masalah yang diberikan, tanpa memperkenalkan kompleksitas yang tidak disengaja dan kemungkinan konsekuensi negatif. + +Lihat juga: + +- [YAGNI](#yagni) +- [No Silver Bullet: Kompleksitas Terkadang dan Kompleksitas Esensial](https://en.wikipedia.org/wiki/No_Silver_Bullet) + +Contoh: + +- [Pengembangan Perangkat Lunak Lean: Menghilangkan Limbah](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) + +### Hukum Parkinson + +[Hukum Parkinson di Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law) + +> Pekerjaan mengembang untuk mengisi waktu yang tersedia untuk penyelesaiannya. + +Dalam konteks aslinya, UU ini didasarkan pada studi tentang birokrasi. Ini mungkin secara pesimis diterapkan pada inisiatif pengembangan perangkat lunak, teorinya adalah bahwa tim akan tidak efisien sampai tenggat waktu dekat, kemudian bergegas untuk menyelesaikan pekerjaan dengan tenggat waktu, sehingga membuat tenggat waktu yang sebenarnya agak sewenang-wenang. + +Jika hukum ini digabungkan dengan [Hukum Hofstadter](#hukum-hofstadter), sudut pandang yang lebih pesimistis tercapai - pekerjaan akan meluas untuk mengisi waktu yang tersedia untuk penyelesaiannya dan * masih lebih lama dari yang diharapkan *. + +Lihat juga: + +- [Hukum Hofstadter](#hukum-hofstadter) + +### Efek Optimalisasi Prematur + +[Optimalisasi Prematur di WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) + +> Optimalisasi Prematur adalah akar dari semua kejahatan. +> +> [(Donald Knuth)] (https://twitter.com/realdonaldknuth?lang=en) + +Dalam makalah Donald Knuth [Pemrograman Terstruktur Dengan Pergi Ke Pernyataan](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ia menulis: "Pemrogram menghabiskan banyak waktu memikirkan, atau mengkhawatirkan, kecepatan bagian nonkritis dari program mereka, dan upaya efisiensi ini sebenarnya memiliki dampak negatif yang kuat ketika debugging dan pemeliharaan dipertimbangkan. Kita harus melupakan efisiensi kecil, katakanlah sekitar 97% dari waktu: **Optimalisasi Prematur adalah akar dari semua kejahatan**. Namun kita seharusnya tidak melewatkan peluang kita dalam 3% kritis itu. " + +Namun, _Optimalisasi Prematur_ dapat didefinisikan (dalam istilah yang lebih sedikit dimuat) sebagai mengoptimalkan sebelum kita tahu bahwa kita perlu. + +### Hukum Putt + +[Hukum Putt di Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) + +> Teknologi didominasi oleh dua jenis orang, mereka yang mengerti apa yang tidak mereka kelola dan mereka yang mengelola apa yang tidak mereka mengerti. + +Hukum Putt sering diikuti oleh Putt's Corollary: + +> Setiap hierarki teknis, pada waktunya, mengembangkan inversi kompetensi. + +Pernyataan-pernyataan ini menunjukkan bahwa karena berbagai kriteria seleksi dan tren dalam bagaimana kelompok mengatur, akan ada sejumlah orang yang terampil di tingkat kerja organisasi teknis, dan sejumlah orang dalam peran manajerial yang tidak menyadari kompleksitas dan tantangan dari pekerjaan yang mereka kelola. Ini bisa disebabkan oleh fenomena seperti [Prinsip Peter](#prinsip-peter) atau [Prinsip Dilbert](#prinsip-dilbert). + +Namun, harus ditekankan bahwa Hukum seperti ini adalah generalisasi yang luas dan dapat berlaku untuk jenis organisasi _some_, dan tidak berlaku untuk yang lain. + +Lihat juga: + +- [Prinsip Peter](#prinsip-peter) +- [Prinsip Dilbert](#prinsip-dilbert) + + +### Hukum Reed + +[Hukum Reed di Wikipedia](https://en.wikipedia.org/wiki/Reed's_law) + +> Utilitas jaringan besar, khususnya jaringan sosial, secara eksponensial dengan ukuran jaringan. + +Undang-undang ini didasarkan pada teori grafik, di mana skala utilitas sebagai jumlah sub-kelompok yang mungkin, yang lebih cepat dari jumlah peserta atau jumlah kemungkinan koneksi berpasangan. Odlyzko dan lainnya berpendapat bahwa Hukum Reed melebih-lebihkan utilitas sistem dengan tidak memperhitungkan batas-batas kognisi manusia pada efek jaringan; lihat [Nomor Dunbar](#nomor-dunbar). + +Lihat juga: + +- [Hukum Metcalfe](#hukum-metcalfe) +- [Nomor Dunbar](#nomor-dunbar) + +### Hukum Konservasi Kompleksitas (Hukum Tesler) + +[Hukum Konservasi Kompleksitas di Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) + +Hukum ini menyatakan bahwa ada sejumlah kompleksitas dalam suatu sistem yang tidak dapat dikurangi. + +Beberapa kompleksitas dalam suatu sistem adalah 'tidak disengaja'. Ini adalah konsekuensi dari struktur yang buruk, kesalahan, atau hanya pemodelan masalah yang buruk untuk dipecahkan. Kompleksitas yang tidak disengaja dapat dikurangi (atau dihilangkan). Namun, beberapa kompleksitas bersifat 'intrinsik' sebagai konsekuensi dari kompleksitas yang melekat pada masalah yang sedang dipecahkan. Kompleksitas ini dapat dipindahkan, tetapi tidak dihilangkan. + +Salah satu elemen yang menarik dari undang-undang ini adalah saran bahwa meskipun dengan menyederhanakan seluruh sistem, kompleksitas intrinsiknya tidak berkurang, tetapi dipindah-pindahkan ke pengguna_, yang harus berperilaku dengan cara yang lebih kompleks. + +### Hukum Abstraksi Kebocoran + +[Hukum Abstraksi Kebocoran on Joel on Software](https://www.joelonsoftware.com/2002/11/11/hukum-abstraksi-kebocoran/) + +> Semua abstraksi non-sepele, sampai taraf tertentu, bocor. +> +> ([Joel Spolsky](https://twitter.com/spolsky)) + +Undang-undang ini menyatakan bahwa abstraksi, yang umumnya digunakan dalam komputasi untuk menyederhanakan bekerja dengan sistem yang rumit, dalam situasi tertentu akan 'membocorkan' elemen sistem yang mendasarinya, ini membuat abstraksi itu berperilaku dengan cara yang tidak terduga. + +Contoh mungkin memuat file dan membaca isinya. API sistem file adalah _abstraksi_ dari sistem kernel level bawah, yang merupakan abstraksi atas proses fisik yang berkaitan dengan perubahan data pada plat magnetik (atau memori flash untuk SSD). Dalam kebanyakan kasus, abstraksi memperlakukan file seperti aliran data biner akan berfungsi. Namun, untuk drive magnetik, membaca data secara berurutan akan * secara signifikan * lebih cepat daripada akses acak (karena peningkatan overhead kesalahan halaman), tetapi untuk drive SSD, overhead ini tidak akan hadir. Detail yang mendasarinya perlu dipahami untuk menangani kasus ini (misalnya, file indeks basis data disusun untuk mengurangi overhead akses acak), rincian implementasi 'kebocoran' abstrak yang mungkin perlu diperhatikan pengembang. + +Contoh di atas dapat menjadi lebih kompleks ketika abstraksi _lebih_ diperkenalkan. Sistem operasi Linux memungkinkan file diakses melalui jaringan tetapi direpresentasikan secara lokal sebagai file 'normal'. Abstraksi ini akan 'bocor' jika ada kegagalan jaringan. Jika pengembang memperlakukan file ini sebagai file 'normal', tanpa mempertimbangkan fakta bahwa mereka mungkin mengalami latensi dan kegagalan jaringan, solusinya akan bermasalah. + +Artikel yang menggambarkan undang-undang ini menunjukkan bahwa ketergantungan yang berlebihan pada abstraksi, dikombinasikan dengan pemahaman yang buruk tentang proses yang mendasarinya, sebenarnya membuat masalah yang dihadapi semakin kompleks dalam beberapa kasus. + +Lihat juga: + +- [Hukum Hyrum](#hukum-hyrum-hukum-antarmuka-implisit) + +Contoh dunia nyata: + +- [Photoshop Startup Lambat](https://forums.adobe.com/thread/376152) - masalah yang saya temui di masa lalu. Photoshop akan lambat untuk memulai, kadang-kadang membutuhkan waktu beberapa menit. Tampaknya masalah adalah pada saat startup membaca beberapa informasi tentang printer default saat ini. Namun, jika printer itu sebenarnya adalah printer jaringan, ini bisa memakan waktu yang sangat lama. The _abstraction_ dari printer jaringan yang disajikan ke sistem yang mirip dengan printer lokal menyebabkan masalah bagi pengguna dalam situasi konektivitas yang buruk. + +### Hukum Triviality + +[Hukum Triviality di Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) + +Undang-undang ini menunjukkan bahwa kelompok akan memberikan lebih banyak waktu dan perhatian pada masalah-masalah sepele atau kosmetik daripada masalah yang serius dan substansial. + +Contoh fiksi umum yang digunakan adalah bahwa komite menyetujui rencana untuk pembangkit listrik tenaga nuklir, yang menghabiskan sebagian besar waktu mereka membahas struktur gudang sepeda, daripada desain yang jauh lebih penting untuk pembangkit listrik itu sendiri. Mungkin sulit untuk memberikan masukan berharga pada diskusi tentang topik yang sangat besar dan kompleks tanpa keahlian atau persiapan subjek tingkat tinggi. Namun, orang ingin dilihat sebagai kontribusi input berharga. Oleh karena itu, kecenderungan untuk memfokuskan terlalu banyak waktu pada perincian kecil, yang dapat dipikirkan dengan mudah, tetapi tidak selalu penting. + +Contoh fiksi di atas menyebabkan penggunaan istilah 'Bike Shedding' sebagai ungkapan untuk membuang-buang waktu pada detail sepele. Istilah terkait adalah '[Mencukur Yak](https://en.wiktionary.org/wiki/yak_shaving),' yang mengartikan aktivitas yang tampaknya tidak relevan yang merupakan bagian dari rantai panjang prasyarat untuk tugas utama. + +### Filsafat Unix + +[Filsafat Unix di Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy) + +Filsafat Unix adalah bahwa komponen perangkat lunak harus kecil, dan fokus pada melakukan satu hal tertentu dengan baik. Ini dapat membuatnya lebih mudah untuk membangun sistem dengan menyusun unit-unit kecil, sederhana, dan terdefinisi dengan baik, daripada menggunakan program-program multi-fungsi yang besar, kompleks, dan multi-guna. + +Praktik modern seperti 'Arsitektur Layanan Mikro' dapat dianggap sebagai penerapan undang-undang ini, di mana layanan kecil, fokus, dan melakukan satu hal spesifik, yang memungkinkan perilaku kompleks dapat terdiri dari blok bangunan sederhana. + +### Model Spotify + +[Model Spotify di Spotify Laboratorium](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) + +Model Spotify adalah pendekatan terhadap tim dan struktur organisasi yang telah dipopulerkan oleh 'Spotify'. Dalam model ini, tim disusun berdasarkan fitur, bukan teknologi. + +Model Spotify juga mempopulerkan konsep Tribes, Guilds, Chapters, yang merupakan komponen lain dari struktur organisasi mereka. + +### Hukum Wadler + +[Hukum Wadler on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) + +> Dalam desain bahasa apa pun, total waktu yang dihabiskan untuk mendiskusikan fitur dalam daftar ini sebanding dengan dua yang diangkat pada kekuatan posisinya. +> +> 0. Semantik +> 1. Sintaks +> 2. Sintaks leksikal +> 3. Sintaksis leksikal komentar +> +> (Singkatnya, untuk setiap jam yang dihabiskan untuk semantik, 8 jam akan dihabiskan untuk sintaksis komentar). + +Mirip dengan [Hukum Triviality] (# hukum-triviality), Hukum Wadler menyatakan apa ketika merancang suatu bahasa, jumlah waktu yang dihabiskan untuk struktur bahasa sangat tinggi dibandingkan dengan pentingnya fitur-fitur itu. + +Lihat juga: + +- [Hukum Triviality](#hukum-triviality) + +### Hukum Wheaton + +[Link](http://www.wheatonslaw.com/) + +[Hari Resmi](https://dontbeadickday.com/) + +> Jangan menjadi kontol. +> +> _Setelah Wheaton_ + +Diciptakan oleh Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), hukum yang sederhana, ringkas, dan kuat ini bertujuan untuk meningkatkan keharmonisan dan rasa hormat dalam organisasi profesional. Ini dapat diterapkan ketika berbicara dengan rekan kerja, melakukan tinjauan kode, menentang sudut pandang lain, mengkritik, dan secara umum, sebagian besar interaksi profesional yang dimiliki manusia satu sama lain. + +## Prinsip + +Prinsip umumnya lebih cenderung menjadi pedoman yang berkaitan dengan desain. + +### Prinsip Dilbert + +[Prinsip Dilbert di Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle) + +> Perusahaan cenderung secara sistematis mempromosikan karyawan yang tidak kompeten ke manajemen untuk mengeluarkan mereka dari alur kerja. +> +> _Scott Adams_ + +Konsep manajemen yang dikembangkan oleh Scott Adams (pencipta strip komik Dilbert), Prinsip Dilbert terinspirasi oleh [Prinsip Peter](#prinsip-peter). Di bawah Prinsip Dilbert, karyawan yang tidak pernah kompeten dipromosikan ke manajemen untuk membatasi kerusakan yang dapat mereka lakukan. Adams pertama kali menjelaskan prinsip tersebut dalam artikel Wall Street Journal 1995, dan memperluasnya dalam buku bisnisnya tahun 1996, [Prinsip Dilbert](#daftar-bacaan). + +Lihat juga: + +- [Prinsip Peter](#prinsip-peter) +- [Hukum Putt](#hukum-putt) + +### Prinsip Pareto (Aturan 80/20) + +[Prinsip Pareto di Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle) + +> Sebagian besar hal dalam hidup tidak terdistribusi secara merata. + +Prinsip Pareto menyarankan bahwa dalam beberapa kasus, sebagian besar hasil berasal dari minoritas input: + +- 80% dari perangkat lunak tertentu dapat ditulis dalam 20% dari total waktu yang dialokasikan (sebaliknya, 20% tersulit dari kode membutuhkan 80% dari waktu) +- 20% dari upaya menghasilkan 80% dari hasilnya +- 20% dari pekerjaan menciptakan 80% dari pendapatan +- 20% dari bug menyebabkan 80% dari crash +- 20% dari fitur menyebabkan 80% dari penggunaan + +Pada tahun 1940-an insinyur Amerika-Rumania Dr. Joseph Juran, yang secara luas diakui sebagai bapak kendali mutu, [mulai menerapkan Prinsip Pareto untuk masalah kualitas](https://en.wikipedia.org/wiki/Joseph_M._Juran). + +Prinsip ini juga dikenal sebagai: Aturan 80/20, Hukum Beberapa Vital, dan Prinsip Faktor Sparsity. + +Contoh dunia nyata: + +- Pada tahun 2002 Microsoft melaporkan bahwa dengan memperbaiki 20% bug yang paling banyak dilaporkan, 80% kesalahan dan kerusakan terkait di windows dan office akan dihilangkan ([Referensi](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). + +### Prinsip Peter + +[Prinsip Peter di Wikipedia](https://en.wikipedia.org/wiki/Peter_principle) + +> Orang-orang dalam hierarki cenderung naik ke "tingkat ketidakmampuan" mereka. +> +> _Laurence J. Peter_ + +Sebuah konsep manajemen yang dikembangkan oleh Laurence J. Peter, Prinsip Peter mengamati bahwa orang yang pandai dalam pekerjaannya dipromosikan, sampai mereka mencapai tingkat di mana mereka tidak lagi sukses ("tingkat ketidakmampuan" mereka. Pada titik ini, sebagaimana mereka lebih senior, mereka cenderung dikeluarkan dari organisasi (kecuali mereka tampil sangat buruk) dan akan terus berada dalam peran yang memiliki sedikit keterampilan intrinsik, karena keterampilan asli mereka yang membuat mereka sukses belum tentu keterampilan yang diperlukan untuk pekerjaan baru mereka. + +Ini sangat menarik bagi para insinyur - yang awalnya memulai dalam peran teknis yang mendalam, tetapi sering memiliki jalur karier yang mengarah ke _mengelola_ insinyur lainnya - yang memerlukan keahlian yang berbeda secara mendasar. + +Lihat juga: + +- [Prinsip Dilbert](#prinsip-dilbert) +- [Hukum Putt](#hukum-putt) + +### Prinsip Robustness (Hukum Postel) + +[Prinsip Robustness di Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) + +> Jadilah konservatif dalam apa yang Anda lakukan, menjadi liberal dalam apa yang Anda terima dari orang lain. + +Sering diterapkan dalam pengembangan aplikasi server, prinsip ini menyatakan bahwa apa yang Anda kirim ke orang lain harus seminimal dan sesesuaian mungkin, tetapi Anda harus bertujuan untuk memungkinkan input yang tidak sesuai jika dapat diproses. + +Tujuan dari prinsip ini adalah untuk membangun sistem yang kuat, karena mereka dapat menangani input yang terbentuk buruk jika maksudnya masih dapat dipahami. Namun, ada kemungkinan implikasi keamanan dari penerimaan input yang cacat, khususnya jika pemrosesan input tersebut tidak diuji dengan baik. + +Membiarkan input yang tidak sesuai, pada waktunya, dapat merusak kemampuan protokol untuk berevolusi karena implementator pada akhirnya akan bergantung pada kebebasan ini untuk membangun fitur mereka. + +Lihat juga: + +- [Hukum Hyrum](#hukum-hyrum-hukum-antarmuka-implisit) + + +### SOLID + +Ini adalah akronim, yang mengacu pada: + +* S: [Prinsip Tanggung Jawab Tunggal](#prinsip-tanggung-jawab-tunggal) +* O: [Prinsip Terbuka / Tertutup](#prinsip-terbukatertutup) +* L: [Prinsip Substitusi Liskov](#prinsip-substitusi-liskov) +* I: [Prinsip Segregasi Antarmuka](#prinsip-segregasi-antarmuka) +* D: [Prinsip Ketergantungan Inversi](#prinsip-ketergantungan-inversi) + +Ini adalah Prinsip utama dalam [Pemrograman Berorientasi Objek](#todo). Prinsip Desain seperti ini harus dapat membantu pengembang membangun sistem yang lebih dapat dipelihara. + +### Prinsip Tanggung Jawab Tunggal + +[Prinsip Tanggung Jawab Tunggal di Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle) + +> Setiap modul atau kelas hanya memiliki satu tanggung jawab. + +Prinsip pertama '[SOLID](#solid)'. Prinsip ini menyarankan agar modul atau kelas harus melakukan satu hal dan satu hal saja. Dalam istilah yang lebih praktis, ini berarti bahwa satu perubahan kecil ke fitur program harus memerlukan perubahan dalam satu komponen saja. Misalnya, mengubah cara kata sandi divalidasi untuk kompleksitas harus memerlukan perubahan hanya dalam satu bagian dari program. + +Secara teoritis, ini harus membuat kode lebih kuat, dan lebih mudah untuk diubah. Mengetahui bahwa komponen yang sedang diubah memiliki tanggung jawab tunggal hanya berarti bahwa _percobaan_ perubahan itu harus lebih mudah. Dengan menggunakan contoh sebelumnya, mengubah komponen kompleksitas kata sandi seharusnya hanya dapat mempengaruhi fitur yang terkait dengan kompleksitas kata sandi. Mungkin akan jauh lebih sulit untuk mempertimbangkan dampak dari perubahan pada komponen yang memiliki banyak tanggung jawab. + +Lihat juga: + +- [Pemrograman Berorientasi Objek](#todo) +- [SOLID](#solid) + +### Prinsip Terbuka / Tertutup + +[Prinsip Terbuka / Tertutup di Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) + +> Entitas harus terbuka untuk ekstensi dan ditutup untuk modifikasi. + +Prinsip kedua '[SOLID](#solid)'. Prinsip ini menyatakan bahwa entitas (yang bisa berupa kelas, modul, fungsi, dan sebagainya) harus dapat memiliki perilakunya _diperpanjang_, tetapi bahwa perilaku mereka _ada_ seharusnya tidak dapat dimodifikasi. + +Sebagai contoh hipotetis, bayangkan sebuah modul yang mampu mengubah dokumen penurunan harga menjadi HTML. Jika modul dapat diperluas untuk menangani fitur penurunan harga yang baru diusulkan, tanpa memodifikasi internal modul, maka itu akan terbuka untuk ekstensi. Jika modul dapat _tidak_ dimodifikasi oleh konsumen sehingga sekarang fitur Markdown yang ada ditangani, maka akan ditutup _ untuk modifikasi. + +Prinsip ini memiliki relevansi khusus untuk Pemrograman Berorientasi Objek, di mana kita dapat mendesain objek agar mudah diperluas, tetapi akan menghindari mendesain objek yang dapat mengubah perilaku mereka saat ini dengan cara yang tidak terduga. + +Lihat juga: + +- [Pemrograman Berorientasi Objek](#todo) +- [SOLID](#solid) + +### Prinsip Substitusi Liskov + +[Prinsip Substitusi Liskov di Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle) + +> Seharusnya dimungkinkan untuk mengganti tipe dengan subtipe, tanpa merusak sistem. + +Yang ketiga dari Prinsip '[SOLID](#solid)'. Prinsip ini menyatakan bahwa jika suatu komponen bergantung pada suatu tipe, maka ia harus dapat menggunakan subtipe dari tipe itu, tanpa sistem gagal atau harus mengetahui detail dari apa subtipe itu. + +Sebagai contoh, bayangkan kita memiliki metode yang membaca dokumen XML dari struktur yang mewakili file. Jika metode ini menggunakan tipe file 'dasar', maka apa pun yang berasal dari 'file' harus dapat digunakan dalam fungsi tersebut. Jika 'file' mendukung pencarian secara terbalik, dan parser XML menggunakan fungsi itu, tetapi tipe turunan 'file jaringan' gagal ketika pencarian terbalik dicoba, maka 'file jaringan' akan melanggar prinsip. + +Prinsip ini memiliki relevansi khusus untuk Pemrograman Berorientasi Objek, di mana hierarki jenis harus dimodelkan dengan cermat untuk menghindari pengguna sistem yang membingungkan. + +Lihat juga: + +- [Pemrograman Berorientasi Objek](#todo) +- [SOLID](#solid) + +### Prinsip Segregasi Antarmuka + +[Prinsip Segregasi Antarmuka di Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle) + +> Tidak ada klien yang harus dipaksa untuk bergantung pada metode yang tidak digunakannya. + +Prinsip keempat '[SOLID](#solid)'. Prinsip ini menyatakan bahwa konsumen suatu komponen tidak boleh bergantung pada fungsi-fungsi komponen yang sebenarnya tidak digunakannya. + +Sebagai contoh, bayangkan kita memiliki metode yang membaca dokumen XML dari struktur yang mewakili file. Itu hanya perlu membaca byte, bergerak maju atau mundur dalam file. Jika metode ini perlu diperbarui karena fitur yang tidak terkait dari perubahan struktur file (seperti pembaruan untuk model izin yang digunakan untuk mewakili keamanan file), maka prinsipnya telah dibatalkan. Akan lebih baik bagi file untuk mengimplementasikan antarmuka 'seekable-stream', dan bagi pembaca XML untuk menggunakannya. + +Prinsip ini memiliki relevansi khusus untuk Pemrograman Berorientasi Objek, di mana antarmuka, hierarki dan tipe abstrak digunakan untuk [meminimalkan kopling] (# todo) antara komponen yang berbeda. [Duck typing] (# todo) adalah metodologi yang menegakkan prinsip ini dengan menghilangkan antarmuka eksplisit. + +Lihat juga: + +- [Pemrograman Berorientasi Objek](#todo) +- [SOLID](#solid) +- [Duck Typing](#todo) +- [Decoupling](#todo) + +### Prinsip Ketergantungan Inversi + +[Prinsip Ketergantungan Inversi di Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle) + +> Modul tingkat tinggi tidak boleh bergantung pada implementasi tingkat rendah. + +Kelima Prinsip '[SOLID](#solid)'. Prinsip ini menyatakan bahwa komponen pengatur tingkat yang lebih tinggi tidak harus mengetahui rincian ketergantungannya. + +Sebagai contoh, bayangkan kita memiliki program yang membaca metadata dari situs web. Kami berasumsi bahwa komponen utama harus mengetahui tentang komponen untuk mengunduh konten halaman web, kemudian komponen yang dapat membaca metadata. Jika kita mempertimbangkan inversi dependensi, komponen utama hanya akan bergantung pada komponen abstrak yang dapat mengambil data byte, dan kemudian komponen abstrak yang dapat membaca metadata dari aliran byte. Komponen utama tidak akan tahu tentang TCP / IP, HTTP, HTML, dll. + +Prinsip ini rumit, karena dapat 'membalikkan' dependensi yang diharapkan dari suatu sistem (karenanya namanya). Dalam praktiknya, ini juga berarti bahwa komponen orkestrasi terpisah harus memastikan implementasi yang benar dari tipe abstrak yang digunakan (mis. Dalam contoh sebelumnya, _sesuatu_ masih harus memberikan komponen pembaca metadata menjadi pengunduh file HTTP dan pembaca tag meta HTML). Ini kemudian menyentuh pola seperti [Pembalikan Kontrol](#todo) dan [Ketergantungan Injeksi](#todo). + +See also: + +- [Pemrograman Berorientasi Objek](#todo) +- [SOLID](#solid) +- [Inversi Kontrol](#todo) +- [Dependensi Injection](#todo) + +### Prinsip KERING + +[Prinsip KERING di Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) + +> Setiap pengetahuan harus memiliki representasi tunggal, tidak ambigu, otoritatif dalam suatu sistem. + +KERING adalah akronim untuk _Jangan Ulangi Diri Sendiri_. Prinsip ini bertujuan untuk membantu pengembang mengurangi pengulangan kode dan menyimpan informasi di satu tempat dan dikutip pada 1999 oleh Andrew Hunt dan Dave Thomas dalam buku [Pengembang Pragmatis](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) + +> Kebalikan dari KERING adalah _WET_ (Tulis Semuanya Dua Kali atau Kami Menikmati Mengetik). + +Dalam praktiknya, jika Anda memiliki informasi yang sama di dua (atau lebih) tempat berbeda, Anda dapat menggunakan KERING untuk menggabungkannya menjadi satu dan menggunakannya kembali di mana pun Anda inginkan / butuhkan. + +Lihat juga: + +- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) + +### Prinsip KISS + +[KISS di Wikipedia](https://en.wikipedia.org/wiki/KISS_principle) + +> Tetap sederhana, bodoh + +Prinsip KISS menyatakan bahwa sebagian besar sistem bekerja paling baik jika dibuat sederhana daripada dibuat rumit; oleh karena itu, kesederhanaan harus menjadi tujuan utama dalam desain, dan kompleksitas yang tidak perlu harus dihindari. Berasal dari Angkatan Laut AS pada tahun 1960, frasa tersebut telah dikaitkan dengan insinyur pesawat terbang Kelly Johnson. + +Prinsipnya paling baik dicontohkan oleh kisah Johnson yang menyerahkan tim insinyur desain beberapa alat, dengan tantangan bahwa pesawat jet yang mereka desain harus diperbaiki oleh mekanik rata-rata di lapangan dalam kondisi pertempuran hanya dengan alat-alat ini. Oleh karena itu, "bodoh" mengacu pada hubungan antara cara barang pecah dan kecanggihan alat yang tersedia untuk memperbaikinya, bukan kemampuan para insinyur itu sendiri. + +Lihat juga: + +- [Hukum Gall](#hukum-gall) + +### YAGNI + +[YAGNI di Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it) + +Ini adalah akronim untuk _**Y**ou **A**in't **G**onna **N**eed **I**t_. + +> Selalu terapkan hal-hal ketika Anda benar-benar membutuhkannya, jangan pernah ketika Anda hanya memperkirakan bahwa Anda membutuhkannya. +> +> ([Ron Jeffries](https://twitter.com/RonJeffries)) (salah satu pendiri dan penulis buku XP "Extreme Programming Installed") + +Prinsip _Extreme Programming_ (XP) ini menyarankan pengembang seharusnya hanya mengimplementasikan fungsionalitas yang diperlukan untuk persyaratan segera, dan menghindari upaya untuk memprediksi masa depan dengan mengimplementasikan fungsionalitas yang mungkin diperlukan nanti. + +Mematuhi prinsip ini harus mengurangi jumlah kode yang tidak digunakan dalam basis kode, dan menghindari waktu dan usaha yang dihabiskan untuk fungsionalitas yang tidak membawa nilai. + +Lihat juga: + +- [Daftar Bacaan: Extreme Programming Installed](#daftar-bacaan) + +### Kekeliuran Komputasi Terdistribusi + +[Kekeliuran Komputasi Terdistribusi di Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) + +Juga dikenal sebagai _Fallacies of Networked Computing_, Fallacy adalah daftar dugaan (atau kepercayaan) tentang komputasi terdistribusi, yang dapat menyebabkan kegagalan dalam pengembangan perangkat lunak. Asumsinya adalah: + +- Jaringannya andal +- Latensi adalah nol +- Bandwidth tidak terbatas +- Jaringan aman +- Topologi tidak berubah +- Ada satu administrator +- Biaya transportasi nol +- Jaringannya homogen + +Empat item pertama didaftar oleh [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) dan [Tom Lyon](https://twitter.com/aka_pugs) sekitar 1991 dan pertama diklasifikasikan oleh [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) sebagai "Fallacy of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) menambahkan fallacy ke-5, ke-6 dan ke-7. Di akhir tahun 90-an Gosling menambahkan kekeliruan ke-8. + +Kelompok itu terinspirasi oleh apa yang terjadi pada saat di dalam [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems). + +Kekeliruan ini harus dipertimbangkan dengan hati-hati ketika merancang kode yang tangguh; dengan asumsi salah satu dari kesalahan ini dapat menyebabkan cacat logika yang gagal untuk berurusan dengan realitas dan kompleksitas sistem terdistribusi. + +Lihat juga: + +- [Mencari Makan untuk Kekeliruan Komputasi Terdistribusi (Bagian 1) - Vaidehi Joshi di 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) + +## Daftar Bacaan + +Jika Anda merasa konsep ini menarik, Anda dapat menikmati buku-buku berikut. + +- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core Prinsip of Extreme Programming. +- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Hukum Brooks](#hukum-brooks) is a central theme of the book. +- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hukum Hofstadter](#hukum-hofstadter) is from the book. +- [Prinsip Dilbert - 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](#prinsip-dilbert). +- [Prinsip Peter - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations dan people management, the source of [Prinsip Peter](#prinsip-peter). + +## Berkontribusi + +Silakan berkontribusi! [Angkat masalah](https://github.com/dwmkerr/hacker-laws/issues/new) jika Anda ingin menyarankan penambahan atau perubahan, atau [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) untuk mengusulkan perubahan Anda sendiri. + +Pastikan untuk membaca [Panduan Berkontribusi](./../.github/contributing.md) untuk persyaratan teks, gaya dan sebagainya. Harap perhatikan [Code of Conduct](./../.github/CODE_OF_CONDUCT.md) ketika terlibat dalam diskusi tentang proyek. + +## TODO + +Hai! Jika Anda mendarat di sini, Anda telah mengklik tautan ke topik yang belum saya tulis, maaf tentang ini - ini sedang dalam proses! + +Jangan ragu untuk [Mengangkat Masalah](https://github.com/dwmkerr/hacker-laws/issues) meminta lebih banyak detail, atau [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) untuk menyerahkan definisi topik yang Anda usulkan. diff --git a/translations/it-IT.md b/translations/it-IT.md new file mode 100644 index 00000000..ec288a18 --- /dev/null +++ b/translations/it-IT.md @@ -0,0 +1,537 @@ +# 💻📖 hacker-laws + +Leggi, teorie, principi e pattern utili agli sviluppatori. + +- 🇨🇳 [中文 / Traduzione in Cinese](https://github.com/nusr/hacker-laws-zh) - grazie [Steve Xu](https://github.com/nusr)! +- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)! +- 🇰🇷 [한국어 / Traduzione in Coreano](https://github.com/codeanddonuts/hacker-laws-kr) - grazie [Doughnut](https://github.com/codeanddonuts)! +- 🇷🇺 [Русская версия / Traduzione in Russo](https://github.com/solarrust/hacker-laws) - grazie [Alena Batitskaya](https://github.com/solarrust)! +- 🇹🇷 [Türkçe / Traduzione in Turco](https://github.com/umutphp/hacker-laws-tr) - grazie [Umut Işık](https://github.com/umutphp)! +- 🇺🇸 [Original English Version - Versione Originale in Inglese](https://github.com/dwmkerr/hacker-laws) - grazie [Dave Kerr](https://github.com/dwmkerr)! + +--- + + + +* [Introduzione](#introduzione) +* [Leggi](#leggi) + * [Legge di Amdahl](#legge-di-amdahl) + * [Legge di Brooks](#legge-di-brooks) + * [Legge di Conway](#legge-di-conway) + * [Numero di Dunbar](#numero-di-dunbar) + * [Legge di Gall](#legge-di-gall) + * [Rasoio di Hanlon](#rasoio-di-hanlon) + * [Legge di Hofstadter](#legge-di-hofstadter) + * [Legge di Hutber](#legge-di-hutber) + * [Hype Cycle e Legge di Amara](#hype-cycle-e-legge-di-amara) + * [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite) + * [Legge di Moore](#legge-di-moore) + * [Legge di Parkinson](#legge-di-parkinson) + * [Ottimizzazione Prematura](#effetto-di-ottimizzazione-prematura) + * [Legge di Putt](#legge-di-putt) + * [Legge di Conservazione della Complessità (Legge di Tesler)](#legge-di-conservazione-della-complessita-legge-di-tesler) + * [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata) + * [Legge di Irrilevanza](#legge-di-irrilevanza) + * [Filosofia Unix](#filosofia-unix) + * [Il modello Spotify](#il-modello-spotify) + * [Legge di Wadler](#legge-di-wadler) +* [Principi](#principi) + * [Il Principo di Pareto (La regola dell'80/20)](#principio-di-pareto-regola-dell-80-20) + * [Il Principio di Robustezza (Legge di Postel's)](#principio-di-robustezza-legge-di-postel) + * [SOLID](#solid) + * [Il Principio di Singola Responsabilità](#principio-di-singola-responsabilita) + * [Il Principio dell'Aperto/Chiuso](#principio-dell-open-closed) + * [Il Principio di Sostituzione di Liskov](#principio-di-sostituzione-di-liskov) + * [Il Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce) + * [Il Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze) + * [Il Principio DRY](#principio-dry) + * [YAGNI](#yagni) +* [Reading List](#reading-list) +* [TODO](#todo) + + + +## Introduzione + +Quando si parla di sviluppo software, si discute di tanti principi. Questo repository fornisce un riferimento e un'introduzione a quelli più comuni. I contributi sono sono ben accetti! + + +❗: Questo repo contiene la spiegazione di alcune leggi, principi e pattern, ma tuttavia non ne _sponsorizza_ nessuno. La loro applicabilità dovrebbe sempre essere discussa ed è sempre dipendente dal progetto specifico su cui state lavorando. + +## Leggi + +Si parte! + +### Legge di Amdahl + +[Legge di Amdahl su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Amdahl) + +> La legge di Amdahl mostra lo _speedup potenziale_ che può essere raggiunto nell'esecuzione di un calcolo aumentando le risorse del sistema di calcolo. Di norma si usa nel calcolo parallelo e può stimare il beneficio atteso, limitato dalla porzione parallelizzabile del programma, e raggiungibile aumentando il numero di core di calcolo. + +Ecco un esempio illustrativo. Se un programma è costituito da due parti - una parte A che deve essere eseguita da un singolo core di calcolo e una parte B che può essere parallelizzata - possiamo notare che aggiungere nuovi core al sistema di calcolo produce un beneficio limitato. L'aggiunta potenzia di molto la velocità di esecuzione della parte B - ma la velocità di esecuzione della parte A resterà la stessa. + +Il diagramma sotto riportato illustra gli andamenti nel tempo della velocità di esecuzione in alcuni casi: + +![Diagram: Amdahl's Law](./images/amdahls_law.png) + +*(Crediti Immagine: Daniels220 su Wikipedia in lingua inglese, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* + +Come si può vedere, anche un programma che è al 50% parallelizzabile beneficerà molto poco dell'aggiunta di più di 10 core di calcolo, mentre un programma che è parallelizzabile al 95% può raggiungere speedup significativi nella velocità di esecuzione anche oltre 1000 core di calcolo aggiunti. + +Dal momento che [la legge di Moore](#legge-di-moore) sta rallentando, e l'aumento della velocità dei singoli core di calcolo diminuisce, parallelizzare diventa la chiave per migliorare le performance. Un eccellente esempio è la grafica computerizzata: con i moderni Shader, è possibile renderizzare in parallelo pixel e frammenti - questo è il motivo per cui le schede grafiche hanno migliaia di core di calcolo (GPU o Shader Unit) + +Vedi anche: + +- [Legge di Brooks](#legge-di-brooks) +- [Legge di Moore](#legge-di-moore) + +### Legge di Brooks + +[Legge di Brooks su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Brooks) + +> L'aggiunta di risorse umane ad un progetto di sviluppo software già in ritardo lo fa tardare ancora di più. + +Questa legge suggerisce che in molti casi il tentativo di accelerare, tramite aggiunta di ulteriori persone a staff, la delivery di un progetto che è già in ritardo risulterà nell'aumento del ritardo progettuale. Brooks sottolinea che questo scenario è certamente molto semplificato, ma che tuttavia il ragionamento alla base è che il tempo necessario alle nuove risorse per diventare produttive e l'overhead di comunicazione introdotto causano una decrescita della velocità nel breve termine. Inoltre molti task risultano non suddivisibili o facilmente distribuibili tra più risorse, causando un corrispondente minor aumento nella velocità potenziale. + +La famosa frase "Nove donne non fanno un figlio in un solo mese" è relativa alla Legge di Brook, in particolare al fatto che alcuni tipi di operazioni non sono suddivisibili o parallelizzabili. + +Questo è un tema centrale del libro '[The Mythical Man Month](#reading-list)'. + +Vedi anche: + +- [Death March](#todo) +- [Reading List: The Mythical Man Month](#reading-list) + +### Legge di Conway + +[Legge di Conway su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Conway) + +Questa legge indica che i confini di un sistema software riflettono la struttura dell'organizzazione che lo produce. Comunemente citata quando si parla di miglioramenti organizzativi, la legge di Conway afferma che se un'organizzazione è strutturata in tante piccole unità tra loro disconnesse, il software che essa produrrà avrà la stessa struttura. Se un'organizzazione invece è costruita attorno a "silo" verticali dedicati a funzionalità o servizi, i suoi sistemi software rifletteranno questa caratteristica. + +Vedi anche: + +- [Il modello Spotify](#il-modello-spotify) + +### Numero di Dunbar + +[Numero di Dunbar su Wikipedia](https://it.wikipedia.org/wiki/Numero_di_Dunbar) +"Il numero di Dunbar è stato suggerito come valore cognitivo che limita il numero di persone con cui un individuo riesce a mantenere relazioni sociali stabili - relazioni in cui l'individuo sa chi è ciascuna controparte e come tutte le controparti si relazionano tra di loro". Non c'è concordanza sull'esatto valore di questo limite. "... Dunbar ha affermato che un essere umano può mantenere solo 150 relazioni stabili". Egli ha inserito questa affermazione in un contesto più sociale: "il numero di persone con cui ti sentiresti a tuo agio a prendere un drink se entrassi in un bar e le incontrassi casualmente". Le stime per il numero generalmente stanno tra 100 e 250. + +Come le relazioni stabili tra individui, le relazioni di uno sviluppatore con una codebase necessitano di impegno per essere mantenute. Quando ci troviamo di fronte a progetti grandi e complicati, o abbiamo la responsabilità di molti progetti, ci affidiamo a convenzioni, policy e procedure disegnate per scalare. Il numero di Dunbar non solo è importante da ricordare quando un ufficio cresce di dimensioni, ma anche quando si stabilisce il perimetro per l'operato di un team o quando si deve decidere se investire nella strumentazione per modellizzare e automatizzare l'overhead logistico. Inquadrando il numero di Dunbar in un contesto ingegneristico, esso rappresenta il numero di progetti (o la comoplessità normalizzata di un singolo progetto) sui quali un individuo si sentirebbe sicuro di lavorare a chiamata. + +Vedi anche: + +- [Legge di Conway](#legge-di-conway) + +### Legge di Gall + +[Legge di Gall su Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) + +> Un sistema di complessità elevata e che funziona è inevitabilmente evoluto a partire da un sistema più semplice che funzionava. Un sistema complesso disegnato da zero non funziona per definizione e non può essere modificato per funzionare: bisogna partire ripartire da un sistema semplice che funziona. +> +> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author))) + +La Legge di Gall implica che i tentativi di _disegnare_ un sistema ad alta complessità hanno alta probabilità di fallire. I sistemi complessi raramente sono costruiti in una sola iterazione, al contrario sono il risultato dell'evoluzione di sistemi più semplici. + +Un classico esempio è il World Wide Web. Al suo stato attuale, è un sistema fortemente complesso. Tuttavia, inizialmente fu definito come un sistema semplice per condividere contenuti tra istituti accademici. Realizzò questo obiettivo con grande successo ed mutò nel tempo divenendo sempre più complesso al passare del tempo. + +Vedi anche: + +- [KISS (Keep It Simple, Stupid)](#TODO) + +### Rasoio di Hanlon + +[Rasoio di Hanlon su Wikipedia](https://it.wikipedia.org/wiki/Rasoio_di_Hanlon) + +> Non attribuire mai a malafede quel che si può ragionevolmente spiegare con la stupidità. +> +> Robert J. Hanlon + +Questo principio suggerisce che l'ottenimento di un risultato negativo con ogni probabilità non è dovuto alla volontà perversa di fallire quanto alla mancata comprensione (totale o parziale) dell'impatto delle proprie azioni. + +### Legge di Hofstadter + +[Legge di Hofstadter su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Hofstadter) + +> Per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter. +> +> (Douglas Hofstadter) + +Questa legge è citata quando si fanno le stime sulla durata di qualcosa. Nello campo dello sviluppo software sembra essere un assioma la tendenza ad essere poco bravi nello stimare con precisione quanto tempo verrà richiesto per le delivery. + +La legge viene dal libro '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'. + +Vedi anche: + +- [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list) + +### Legge di Hutber + +[Legge di Hutber su Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) + +> I miglioramenti spesso celano altri peggioramenti. +> +> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber)) + +La legge indica che i miglioramenti apportati ad una parte di un sistema porteranno ad un inevitabile deterioramento in altre sue parti, causando quindi un globale deterioramento nello stato corrente del sistema. + +Per esempio, la diminuzione nella latenza di risposta di uno specifico end-point provoca un amumento nel throughput e problemi di capacity nel workflow di gestione delle richieste, impattando altri sottosistemi correlati. + +### Hype Cycle e Legge di Amara + +[Hype Cycle su Wikipedia](https://it.wikipedia.org/wiki/Hype_cycle) + +> Tendiamo a sovrastimare l'impatto di una tecnologia sul breve termine e nel sottostimarlo sul lungo termine. +> +> (Roy Amara) + +L'Hype Cycle è una rappresentazione visuale del clamore attorno allo sviluppo di una tecnologia nel tempo, originariamente ideata da Gartner. Un esempio: + +![The Hype Cycle](./images/gartner_hype_cycle.png) + +*(Crediti Immagine: Jeremykemp su Wikipedia in lingua inglese, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* + +In sintesi, il Cycle dice che tipicamente esiste un picco di frenesia quando nasce una nuova tecnologia riguardo i suoi potenziali impatti. I team di lavoro di solito adottano velocemente tali tecnologie e a volte si trovano scontenti del risultato. Ciò può essere dovuto all'immaturità della tecnologia, oppure alla mancanza di applicazioni reali significative. Dopo un certo periodo di tempo, le potenzialità della tecnologia aumentano e aumenta il numero delle opportunità concrete che essa offre, per cui i team di lavoro possono finalmente aumentare la loro produttività adottandola. La citazione di Roy Amara riassume in breve questa situazione - "Tendiamo a sovrastimare l'impatto di una tecnologia sul breve termine e nel sottostimarlo sul lungo termine". + +### Legge di Hyrum (Legge delle Interfacce Implicite) + +[Legge di Hyrum Online](http://www.hyrumslaw.com/) + +> Dato un numero sufficientementa elevato di utenti di un'API, +> il contenuto del contratto di interfaccia non conta: +> tutti i comportamenti osservabili del sistema che espone l'API +> saranno utilizzati da questi utenti. +> +> (Hyrum Wright) + +La lagge di Hyrum dice che quando un'API ha un _numero sufficientementa elevato di consumer_, tutti i comportamenti di essa (anche quelli non definiti come parte dell'interfaccia pubblica) prima o poi costituiranno una dipendenza lato consumer. Un esempio banale è quello degli aspetti non-funzionali come il tempo di risposta di un'API. Un esempio più profondo è quello di consumer che applicano una regex sui messaggi di errore dell'API per determinarne la *tipologia*. Anche se il contratto pubblico di interfaccia un'API non dice nulla riguardo al contenuto dei messaggi e suggerisce agli utentil'utilizzo dei codici di errore associati ai messaggi, _alcuni_ utenti possono comunque utilizzare i messaggi di errore a tal fine e dunque una modifica dei messaggi sostanzialmente rompe l'integrazione per questi utenti. + +Vedi anche: + +- [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata) +- [XKCD 1172](https://xkcd.com/1172/) + +### Legge di Moore + +[Legge di Moore su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Moore) + +> Il numero di transistor in un circuito integrato raddoppia approssimativamente ogni due anni. + +Spesso utilizzata per illustrare il tasso con cui le tecnologie a semiconduttori e i chip migliorano nel tempo, la legge di Moore si è dimostrata molto accurata dagli anni Settanta fino alla fine dei Duemila. Più di recente il trend è lievemente cambiato, in parte a causa delle [limitazioni fisiche alla miniaturizzazione delle componenti elettroniche](https://it.wikipedia.org/wiki/Effetto_tunnel) ma tuttavia avanzamenti nel campo della parallelizzazione del calcolo e scoperte potenzialmente rivoluzionarie nel campo delle tecnologie a semiconduttori e nel quantum computing potrebbero portare la legge di Moore a valere anche nei prossimi decenni. + +### Legge di Parkinson + +[Legge di Parkinson su Wikipedia](https://it.wikipedia.org/wiki/La_legge_di_Parkinson) + +> Il lavoro tende ad espandersi fino ad impiegare tutto il tempo disponibile per svolgerlo. + +Nel suo contesto originale, questa legge era riferita agli studi sulla gestione della burocrazia. Può essere applicata in ottica pessimistica alle iniziative di sviluppo software, e in sostanza afferma che i team saranno inefficienti fino all'approssimarsi delle deadline e lavoreranno quindi di corsa per rispettare tali deadline rendendole, in un certo senso, arbitrarie. + +Combinando la legge di Parkinson con la [Legge di Hofstadter](#legge-di-hofstadter), si ottiene una vista ancora più pessimistica: il lavoro tenderà ad espandersi fino ad impiegare tutto il tempo disponibile per svolgerlo e *in ogni caso richiederà più tempo di quanto previsto*. + +Vedi anche: + +- [Legge di Hofstadter](#legge-di-hofstadter) + +### Effetto di Ottimizzazione Prematura + +[Ottimizzazione Prematura su WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) + +> L'ottimizzazione prematura è la radice di ogni male. +> +> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) + + +Nella sua pubblicazione [Programmazione Strutturata con clausole Go To](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), +Donald Knuth scrisse: "I programmatori perdono un'enormità di tempo a preoccuparsi delle performance delle sezioni non critiche dei loro programmi, e i tentativi di efficientarle hanno in realtà un forte impatto negativo durante il debugging e la manutenzione. Dovremmo dimenticarci dei piccoli efficientamenti, che impattano circa il 97% del tempo di esecuzione: **l'ottimizzazione prematura è la radice di ogni male**. Di contro non dovremmo mai lasciarci sfuggire l'occasione di migliorare quel critico 3% del tempo di esecuzione." + +L'_Ottimizzazione Prematura_ può essere definita (in termini meno coloriti) come l'attività di efficientamento fatta prima di avere evidenza della sua necessità. + +### Legge di Putt + +[Legge di Putt su Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) + +> Il mondo della tecnologia è dominato da due tipi di persone: coloro che comprendono ciò che non gestiscono e coloro che gestiscono ciò che non comprendono. + +La Legge di Putt è spesso accompagnata dal Corollario di Putt: + +> Ogni gerarchia tecnica, genera un'inversione delle competenze con il passare del tempo. + +Queste frasi suggeriscono che, a causa di svariati criteri di selezione e trend con cui i gruppi di lavoro si organizzano, ci sarà un certo numero di persone di vasta esperienza con ruoli tecnici operativi e un certo numero di ruoli manageriali che non sono in grado di comprendere la complessità e le sfide del contesto lavorativo che sono chiamati a gestire. Ciò si spiega con fenomeni come il [Principio di Peter](#TODO) o [La Legge di Dilbert](#TODO). + +Tuttavia, è corretto specificare che Leggi come queste sono una grande generalizzazione e si applicano ad _alcuni_ tipi di organizzazione e non ad altri. + +Vedi anche: + +- [Principio di Peter](#TODO) +- [Legge di Dilbert](#TODO). + + +### Legge di Conservazione della Complessità (Legge di Tesler) + +[Legge di Conservazione della Complessità su Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) + +Le Legge dice che in ogni sistema esiste un certo livello di complessità che non può essere ridotto. + +Parte della complessità di un sistema è introdotta "inavvertitamente" ed è conseguenza della struttura imperfetta, degli errori o semplicemente di una modellizzazione errata del problema da risolvere. La complessità involontaria può essere ridotta (o eliminata). Tuttavia, parte della complessità è "intrinseca" ed è conseguenza della complessità inerente al problema da risolvere. Questa complessità può essere spostata ma non eliminata. + +Un elemento interessante di questa Legge è che ci dice che anche semplificando l'intero sistema, la complessità intrinseca non viene ridotta ma viene _spostata sull'utente_, che deve di conseguenza interagire in modo più sofisticato con il sistema. + + +### Legge dell'Astrazione Fallata + +[La Legge dell'Astrazione Fallata su Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) + +> Tutte le astrazioni non banali sono in qualche modo fallate. +> +> ([Joel Spolsky](https://twitter.com/spolsky)) + +Questa legge afferma che le astrazioni generalmente usate in informatica per semplificare l'uso di sistemi complessi, in certe situazioni, lasceranno "trapelare" il dettaglio dei sistemi sottostanti facendo così funzionare l'astrazione in modo inaspettato. + +Un esempio è l'apertura di un file e la lettura del suo contenuto. L'API di un file system è un'_astrazione_ del kernel di sistema, il quale è a sua volta un'astrazione dei processi fisici di modifica dei dati su un disco magnetico (o su una memoria flash nel caso di SSD). Nella maggior parte dei casi, l'astrazione di considerare il file come uno stream di dati binario funzionerà senza problemi. Tuttavia, nel caso di un disco magnetico, la lettura sequenziale dei dati sarà *significativamente* più veloce di un accesso random (per via dell'overhead dovuto ai page fault), ma nel caso di un disco SSD tale overhead non è presente. I dettagli implementativi dell'astrazione dovranno dunque essere compresi se si vuole gestire questo comportamento (ad esempio, i file indice di un database sono strutturati per ridurre l'overhead dell'accesso random), l'astrazione "fallata" lascerà trapelare questi dettagli che possono essere di interesse per il programmatore. + +L'esempio di cui sopra può diventare anche più complesso quando vengono introdotte astrazioni _multiple_. Il sistema operativo Linux consente di accedere file attraverso una rete, rappresentandoli localmente come file "normali". Questa astrazione "farà acqua" se la rete verrà interrotta. Se uno sviluppatore trattasse questi file come file "noemali", senza considerare il fatto che possono essere soggetti alla latenza e alle interruzioni della rete, la soluzione sviluppata avrà un baco. + +L'articolo che descrive questa Legge suggerisce che un'eccessiva fiducia nelle astrazioni, combinata con una scarsa comprensione del sistema sottostante, di fatto in alcuni casi _aumenta_ la complessità del problema da risolvere. + +Vedi anche: + +- [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite) + +Esempi dal mondo reale: + +- [Partenza lenta di Photoshop](https://forums.adobe.com/thread/376152) - problema incontrato nel passato su Photoshop, che a volta impiegava minuti per avviarsi. Sembra che il problema fosse che all'avvio Photoshop leggeva informazioni sulla stampante di default. Tuttavia, se la stampante era una stampante di rete, questa lettura poteva impiegare un tempo molto lungo. L'_astrazione_ per cui la stampante di rete era presentata al sistema esattamente come una stampante locale causava quindi una situazione di estrema lentezza per gli utenti in condizioni di rete lenta. + +### Legge di Irrilevanza + +[Legge di Irrilevanza su Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) + +La Legge afferma che i team di lavoro tendono a dedicare molto più tempo e attenzione a dettagli irrilevanti o legati alla cosmesi del lavoro piuttosto che alle questioni serie e sostanziali. + +Il tipico esempio fittizio usato per illustrare la Legge è quello di un comitato incaricato di approvare i piani per un impianto nucleare, che passa più tempo a discutere i dettagli del ripostiglio delle biciclette che a discutere il ben più importante design dell'impianto stesso. Può essere difficile a volte dare il giusto contributo quando si discute di argomenti grandi e complessi senza avere una preparazione o esperienza adeguata in merito. Tuttavia, le persone vogliono in genere mostrarsi attive nel collaborare fornendo input di valore. Da qui la tendenza a concentrarsi troppo sul dettaglio spiccio, che può essere discusso facilmente, ma non ha necessariamente rilevanza. + +L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza. + +### Filosofia Unix + +[La Filosofia Unix su Wikipedia](https://it.wikipedia.org/wiki/Filosofia_Unix) + +La Filosofia Unix predica che le componenti software debbano essere piccole e mirate a implementare bene un solo scopo. Ciò rende più semplice costruire sistemi mediante composizione di unità piccole, semplici e ben definite, piuttosto che mediante composizione di programmi grossi, complessi e multi-purpose. + +Le moderne prassi come le "Architettura a Microservizi" possono essere viste come applicazioni di questa Filosofia, per cui i servizi sono piccoli e focalizzati sul fare una cosa specifica, consentendo la creazione di comportamenti complessi mediante composizione di mattoni più semplici. + +### Il modello Spotify + +[Il modello Spotify su Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) + +Il modello Spotify è un approccio alla strutturazione del lavoro e dell'azienda che è stato reso popolare da Spotify. In questo modello, i team di lavoro sono organizzati attorno alle features invece che alle tecnologie. + +Il modello Spotify rende inoltre popolari i concetti di Tribù, Gilda, Capitolo, che sono altre componenti della struttura organizzativa. + + +### Legge di Wadler + +[Legge di Wadler su wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) + +> Nella progettazione di qualsiasi linguaggio, il tempo totale impiegato a discutere un elemento di questa lista è proporzionale a 2 elevato alla potenza corrispondente alla posizione dell'elemento: +> +> 0. Semantica +> 1. Sintassi +> 2. Sintassi lessicale +> 3. Sintassi lessicale dei commenti +> +> (In breve: per ogni ora spesa a discutere della semantica, 8 ore saranno spese sulla sintassi dei commenti). + +Similmente alla [Legge di Irrilevanza](#legge-di-irrilevanza), la Legge di Wadler afferma che nel design di un linguaggio di programmazione il tempo speso sulla discussione della struttura del linguaggio è sproporzionatamente alto se comparato con l'importanza delle feature discussa. + +Vedi anche: + +- [Legge di Irrilevanza](#legge-di-irrilevanza) + +## Principi + +I Principi sono in generale usabili come linee guida per il design. + + +### Principio di Pareto (regola dell'80-20) + +[Il Principio di Pareto su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_Pareto) + +> Nella vita, la maggior parte delle cose non è distribuita equamente. + +Il Principio di Pareto suggerisce che in alcuni casi, la maggior parte dei risultati è effetto di una minoranza degli input + +- l'80% di un software è scrivibile nel 20% del tempo totale allocato per la sua scrittura (di contro, il 20% del codice, ossia le parti più complicate di esso, impiega l'80% del tempo) +- il 20% dell'effort produce l'80% del risultato +- il 20% del lavoro genera l'80% della revenue +- il 20% dei bachi genera l'80% dei crash +- il 20% delle features soddisfa l'80% degli utenti + +Negli anni Quaranta l'ingegnere Americano-Rumeno Dr.Joseph Juran, che è riconosciuto universalmente come il padre del controllo di qualità, [iniziò ad applicare il Principio di Pareto alla quality assurance](https://en.wikipedia.org/wiki/Joseph_M._Juran) + +Questo Principio è anche noto come: Regola dell'80/20, Legge dei Pochi ma Vitali e il Principio della Scarsità dei Fattori. + +Esempi dal mondo reale: + +- Nel 2002 la Microsoft riferì che sistemando il 20% dei bachi nella lista tra i più segnalati vennero sistemati l'80% degli errori e dei crash correlati su Windows e Office ([Riferimento](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). + +### Principio di Robustezza (Legge di Postel) + +[Il Principio di Robustezza su Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) + +> Siate conservativi nelle vostre azioni, ma liberali in ciò che accettate dagli altri. + +Spesso applicato allo sviluppo di applicazioni lato server, questo principio afferma che ciò viene inviato alle terze parti dovrebbe essere il più contenuto e standard possibile, e di contro si dovrebbe accettare anche input non-standard - fintanto che è processabile - in arrivo dalle terze parti. + +L'obiettivo di questo principio è la costruzione di sistemi robusti in quanto possono gestire input malformato, a patto che l'intento degli input si possa ancora cogliere. Tuttavia l'accettazione di input malformati pone potenziali implicazioni a livello di sicurezza, soprattutto laddove non si testi a fondo l'ingestione di tali input. + +### SOLID + +SOLID è un acronimo: + +* S: [Principio di Singola Responsabilità](#principio-di-singola-responsabilita) +* O: [Principio dell'Open Closed](#principio-dell-open-closed) +* L: [Principio di Sotituzione di Liskov](#principio-di-sostituzione-di-liskov) +* I: [Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce) +* D: [Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze) + +These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems. + +### Principio di Singola Responsabilità + +[Principio di Singola Responsabilità su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_singola_responsabilit%C3%A0) + +> Ogni modulo o classe dovrebbe avere una sola responsabilità. + +Il primo dei Principi '[SOLID](#solid)'. Afferma che i moduli o le classi software dovrebbero fare una e una sola cosa. In termini più pratici, ciò significa che una piccola modifica ad una feature di un programma dovrebbe richiedere la corrispondente modifica di una sola sua componente. Per esempio, cambiare il modo in cui la complessità di una password viene validata dovrebbe richiedere la modifica di una sola parte del programma. + +In teoria, ciò dovrebbe garantire una maggiore robustezza del codice, con maggiore facilità di modifica. Sapere che un componente da cambiare ha una sola responsabilità ne semplifica grandemente il _testing_. Riprendendo l'esempio fatto prima, la modifica del componente che gestisce la validazione della password dovrebbe impattare solo le features di programma che sono correlate con la complessità della password. Di contro, testare un componente che ha svariate responsabilità diventa molto più difficoltoso. + +Vedi anche: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) + +### Principio dell'Open Closed + +[Il Principio dell'Open Closed su Wikipedia](https://it.wikipedia.org/wiki/Principio_aperto/chiuso) + +> Le entità software dovrebbero essere aperte all'estensione ma chiuse alla modifica. + +Il secondo dei Principi '[SOLID](#solid)' afferma che le entità software (classi, moduli, funzioni) dovrebbero incoraggiare la possibilità di _estendere_ il proprio comportamento e scoraggiare la modifica del loro _comportamento esistente_ + +Ad esempio, si prenda un modulo in grado di trasformare un documento Markdown in HTML. Se il modulo può essere esteso per gestire una nuova feature proposta per il Markdown, senza doverne modificare il funzionamento interno, allora può definirsi aperto all'estensione. Se al contrario il modulo _non_ può essere modificato dai consumer nel modo in cui gestisce le feature correnti di Markdown, allora sarebbe _chiuso_ alla modifica. + +Questo Principio è particolarmente rilevante nella programmazione orientata agli oggetti, dove è desiderabile progettare tipi di oggetti facilmente estendibili e il cui comportamento corrente non venga modificato in maniera inaspettata. + +Vedi anche: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) + +### Principio di Sotituzione di Liskov + +[Il Principio di Sotituzione di Liskov su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_sostituzione_di_Liskov) + +> Deve essere possibile sostituire l'istanza di un tipo con l'istanza di un suo sottotipo senza rompere il codice. + +Il terzo dei Principi '[SOLID](#solid)' afferma che se un componente software fà affidamento su un tipo, allora deve essere possibile utilizzare dei suoi sottotipi al suo posto senza causare errori né dover conoscere il dettaglio di quale sottotipo si sta utilizzando. + +A titolo di esempio, si immagini di avere un metodo che legge un documento XML da una struttura dati che rappresenta un file. Se il metodo accetta il tipo base 'file' come input, allora qualsiasi tipo derivi da 'file' dovrebbe poter essere utilizzato come input al metodo. Se 'file' supporta la ricerca dalla fine all'inizio e il parser XML usa tale funzione, ma il tipo derivato 'network file' non supporta tale funzione, allora 'network file' violerebbe il Principio. + +Il Principio ha particolare rilevanza nella programmazione orientata agli oggetti, dove le gerarchie di tipo devono essere modellizzate con cautela in modo da non generare confusione negli utilizzatori del codice. + +Vedi anche: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) + +### Principio di Segregazione delle Interfacce + +[Il Principio di Segregazione delle Interfacce su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_segregazione_delle_interfacce) + +> Nessun client dovrebbe dipendere da comportamenti che non usa. + +Il quarto dei Principi '[SOLID](#solid)' afferma che i consumer di una componente software non dovrebbero dipendere da funzionalità del componente che non utilizzano. + +Ad esempio, si immagini di avere un metodo che legge un documento XML da una struttura dati che rappresenta un file. Deve limitarsi a leggere i byte e a muoversi avanti/indietro sul file. Se tale metodo deve essere aggiornato perchè una caratteristica della struttura del file cambia in modo scorrelato (es. modifica al modello di permessi di sicurezza sul file), allora il Principio non viene rispettato. Sarebbe meglio a questo punto che il file implementasse un'interfaccia 'seekable-stream' e che il lettore XML la sfruttasse. + +Il Principio ha particolare rilevanza nella programmazione orientata agli oggetti, dove interfacce, gerarchie e tipi astratti sono utilizzati per [minimizzare l'accoppiamento](#todo) tra le diverse componenti software. Il [Duck typing](#todo) è un meccanismo che implementa il Principio attraverso l'eliminazione delle interfacce esplicite. + +Vedi anche: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) +- [Duck Typing](#todo) +- [Disaccoppiamento](#todo) + +### Principio di Inversione delle Dipendenze + +[Il Principio di Inversione delle Dipendenze su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_inversione_delle_dipendenze) + +> I moduli di alto livello non dovrebbero dipendere dalle implementazioni di basso livello. + + + + +Il quinto dei Principi '[SOLID](#solid)' afferma che le componenti di alto livello che orchestrano l'esecuzione non dovrebbero conoscere i dettagli delle loro dipendenze. + +Ad esempio, si immagini di avere un programma che legge metadati da un sito web. Si potrebbe pensare che le componenti principali debbano conoscere dell'esistenza di un componente adibito al download del contenuto di una pagina web e anche di un componente in grado di leggere i metadati. Tenendo conto dell'inversione delle dipendenze, il componente principale dipenderebbe solo su un componente astratto in grado di recuperare byte e su un componente astratto in grado di leggere i metadati da uno stram di byte. Il componente principale dunque non dovrebbe sapere nulla di TCP/IP, HTTP, HTML, etc. + +Questo Principio è complesso perchè sembra 'invertire' le dipendenze attese di un sistema (da qui il suo nome). In pratica, ciò significa anche che ci deve essere un componente orchestrante di alto livello per assicurare la corretta implementazione dei tipi astratti sui quali si dipende (eg. nell'esempio di prima, _qualcosa_ deve in ogni caso fornire al componente lettore di metadati un file downloader su HTTP e un lettore di metatag HTML). Questo porta all'uso di pattern come l'[Inversione del Controllo](#todo) e l'[Iniezione delle Dipendenze](#todo). + +Vedi anche: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) +- [Inversione del Controllo](#todo) +- [Iniezione delle Dipendenze](#todo) + +### Principio DRY + +[Il Principio DRY su Wikipedia](https://it.wikipedia.org/wiki/Don%27t_repeat_yourself) + +> Ogni elemento di conoscenza deve avere una sola, non ambigua, autorevole rappresentazione all'interno di un sistema. + +DRY è l'acronimo dell'inglese _Don't Repeat Yourself_ (Non Reinventare la Ruota). Questo Principio mira ad aiutare gli sviluppatori a ridurre le duplicazioni nel codice e mantenere le informazioni in un solo punto, e fu citato nel 1999 da Andrew Hunt e Dave Thomas nel libro [The Pragmatic Programmer](https://it.wikipedia.org/wiki/The_Pragmatic_Programmer) + +> Il contrario di DRY è _WET_ (Write Everything Twice or We Enjoy Typing - Scrivi Tutto In Doppio o Adoriamo Scrivere alla Tastiera). + +In pratica, se lo stesso elemento informativo si trova duplicato in due (o più) posti differenti, si può usare DRY per fondere insieme gli elementi in un solo posto e riusarlo laddove serva. + +Vedi anche: + +- [The Pragmatic Programmer](https://it.wikipedia.org/wiki/The_Pragmatic_Programmer) + +### YAGNI + +[YAGNI su Wikipedia](https://it.wikipedia.org/wiki/You_aren%27t_gonna_need_it) + +Si tratta dell'acronimo dell'inglese _**Y**ou **A**ren't **G**onna **N**eed **I**t_ (_Non Ne Avrai Bisogno_) + +> Scrivi una porzione di codice sempre e solo quando ne hai un bisogno reale, e mai quando sai solo prevedere il suo uso futuro. +> +> ([Ron Jeffries](https://twitter.com/RonJeffries)) (co-fondatore dell'eXtreme Programming e autore del libro "Extreme Programming Installed") + +Questo Principio dell'_Extreme Programming_ (XP) afferma che gli sviluppatore dovrebbero implementare solo le funzionalità che sono necessarie sulla base dei requisiti immediati ed evitare la tentazione di predire il futuro implementando funzionalità di cui potrebbero avere bisogno più avanti. + +L'aderenza a questo principio dovrebbe ridurre nella codebase la quantità di codice non utilizato, evitando così di sprecare tempo ed effort per sviluppare funzionalità che non portano valore immediato. + +Vedi anche: + +- [Reading List: Extreme Programming Installed](#reading-list) + + +## Reading List + +Se avete trovato questi concetti interessanti, potrebbero interessarvi anche i seguenti libri. + +- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Tratta i principi fondamentali dell'Extreme Programming. +- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Un grande classico sull'ingegneria del software. La [Legge di Brooks](#legge-di-brooks) è un tema centrale del libro. +- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Questo libro è difficile da classificare. La [Legge di Hofstadter](#legge-di-hofstadter) è presa da qui. + +## TODO + +Salve! Se vi trovate qui è perchè avete cliccato sul link ad un argomento che ancora non è stato trattato, mi dispiace - questa pagina è un cantiere aperto! + +Sentitevi liberi di [Segnalare un Problema](https://github.com/dwmkerr/hacker-laws/issues), richiedere più dettaglio o [Aprire una Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) per proporre la vostra definizione dell'argomento. diff --git a/translations/jp.md b/translations/jp.md new file mode 100644 index 00000000..4fd0e0e3 --- /dev/null +++ b/translations/jp.md @@ -0,0 +1,797 @@ +# 💻📖 ハッカーの法則 + +開発者が役に立つと思う法則、理論、原則、パターン。 + +[翻訳](#翻訳): [🇧🇷](../translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](../translations/de.md) [🇫🇷](../translations/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) [JP](../translations/jp.md) + +このプロジェクトが気に入りましたか？ぜひ私と[翻訳者](#%E7%BF%BB%E8%A8%B3)を支援すること[ご検討ください。](https://github.com/sponsors/dwmkerr) + +--- + + + +- [イントロダクション](#イントロダクション) +- [法則](#法則) + - [90-9-1 原則(1％ルール)](#90-9-1-原則1ルール) + - [アムダールの法則](#アムダールの法則) + - [割れ窓理論](#割れ窓理論) + - [ブルックスの法則](#ブルックスの法則) + - [コンウェイの法則](#コンウェイの法則) + - [カニンガムの法則](#カニンガムの法則) + - [ダンバー数](#ダンバー数) + - [ゴールの法則](#ゴールの法則) + - [グッドハートの法則](#グッドハートの法則) + - [ハンロンの剃刀](#ハンロンの剃刀) + - [ホフスタッターの法則](#ホフスタッターの法則) + - [ハーバーの法則](#ハーバーの法則) + - [ハイプサイクルとアマラの法則](#ハイプサイクルとアマラの法則) + - [ハイラムの法則（暗黙のインターフェースの法則）](#ハイラムの法則暗黙のインターフェースの法則) + - [カーニガンの法則](#カーニガンの法則) + - [メトカーフの法則](#メトカーフの法則) + - [ムーアの法則](#ムーアの法則) + - [マーフィーの法則/ソッドの法則](#マーフィーの法則ソッドの法則) + - [オッカムの剃刀](#オッカムの剃刀) + - [パーキンソンの法則](#パーキンソンの法則) + - [早すぎる最適化](#早すぎる最適化) + - [パットの法則](#パットの法則) + - [リードの法則](#リードの法則) + - [複雑性保存の法則（テスラーの法則）](#複雑性保存の法則テスラーの法則) + - [漏れのある抽象化の法則](#漏れのある抽象化の法則) + - [パーキンソンの凡俗法則](#パーキンソンの凡俗法則) + - [UNIX哲学](#unix哲学) + - [Spotifyモデル](#spotifyモデル) + - [ワドラーの法則](#ワドラーの法則) + - [ウィートンの法則](ウィートンの法則) +- [原則](#原則) + - [ディルバートの原理](#ディルバートの原理) + - [パレート原理（80/20ルール）](#パレート原理8020ルール) + - [ピーターの原則](#ピーターの原則) + - [堅牢性の原則（ポステルの法則）](#堅牢性の原則ポステルの法則) + - [SOLID](#solid) + - [単一責任の原則](#単一責任の原則) + - [開放/閉鎖原則](#開放閉鎖原則) + - [リスコフ代替原則](#リスコフの置換原則) + - [インターフェース分離の原則](#インターフェース分離の原則) + - [依存関係の逆転の原則](#依存性逆転の原則) + - [DRY原則](#dry原則) + - [KISS原則](#kissの原則) + - [YAGNI](#yagni) + - [分散コンピューティングの落とし穴](#分散コンピューティングの落とし穴) +- [関連書籍](#関連書籍) +- [翻訳](#翻訳) +- [関連プロジェクト](#関連プロジェクト) +- [貢献方法](#貢献方法) +- [TODO](#todo) + + + +## イントロダクション + +ソフトウェア開発の話をするときに話題にのぼる法則はたくさんありますよね。このレポジトリでは、その中でも最も一般的なものをリストアップしその概要を説明しています。ぜひ、シェアしたりプルリクエストしてください! + +❗: このリポジトリには、いくつかの法則や原則、パターンの説明が含まれていますが、このレポジトリはそれらを*推奨*するものではありません。適用すべきかどうかは、常に議論の余地がありますし、あなたが何に取り組んでいるかに大きく依存します。 + +## 法則 + +そして、ここからが本編! + +### 90-9-1 原則(1％ルール) + +[1%の法則-Wikipedia](https://ja.wikipedia.org/wiki/1%25%E3%81%AE%E6%B3%95%E5%89%87) + +90-9-1原則は、wikiのようなインターネットコミュニティ内では、参加者のうちコンテンツを閲覧しているだけの人が90%、コンテンツを編集や修正する人が9%、残りの1%がコンテンツを追加することを示唆しています。 + +実際の例: + +- 4つのデジタルヘルスソーシャルネットワークの2014年の調査によると、上位1％が投稿の73％を作成し、次の9％が平均約25％の投稿を作成し、残りの90％が平均2％を作成するという結果が示されてます。（ [参考文献](https://www.jmir.org/2014/2/e33/) ） + +関連項目： + +- [パレートの法則](#パレート原理8020ルール) + +### アムダールの法則 + +[アムダールの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A0%E3%83%80%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87) + +> アムダールの法則とは、リソースを追加した場合に、*期待できる性能向上*の程度です。通常、並列コンピューティングで使用され、プログラムの並列性によって制限されるプロセッサの数を増やすことによる実際の利益を予測することができます。 + +例を挙げて説明します。プログラムが、1つのプロセッサで実行されなければならないパートAと、並列化できるパートBの2つのパートで構成されている場合、プログラムを実行するシステムに複数のプロセッサを追加しても、限られた利益しか得られないことがわかります。パートBの速度を大幅に向上させることは可能ですが、パートAの速度は変わらないでしょう。 + +下記の図は、並列度増加と期待する速度改善の例を示しています。 + +Diagram: Amdahl's Law + +*（画像参照：英語版ウィキペディアのDaniels220、クリエイティブコモンズの表示-継承3.0非移植、https：//en.wikipedia.org/wiki/File：AmdahlsLaw.svg）* + +このように、50%の並列化が可能なプログラムであっても、10個の演算処理装置を超えるとほとんど恩恵を受けませんが、95%の並列化が可能なプログラムであれば、1000個以上の演算処理装置でも大幅な速度向上を達成することができます。 + +[ムーアの法則](#ムーアの法則)による性能向上が鈍化し、個々のプロセッサの処理速度の進化が遅くなると、並列化が性能向上の鍵となります。最新のシェーダベースのコンピューティングでは、個々のピクセルやフラグメントを並列にレンダリングすることができます。現代のグラフィックカードが何千もの処理コア（GPUやシェーダユニット）が搭載されている場合多い理由はこれです。 + +関連項目： + +- [ブルックスの法則](#ブルックスの法則) +- [ムーアの法則](#ムーアの法則) + +### 割れ窓理論 + +[割れ窓理論-Wikipedia](https://ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8C%E7%AA%93%E7%90%86%E8%AB%96) + +割れ窓理論は、目に見える犯罪の兆候（または環境整備の欠如）が、さらに深刻な犯罪（または環境のさらなる悪化）につながることを示唆しています。 + +この理論はソフトウェア開発に応用されており、質の低いコード(または [技術的負債](#TODO))は、品質を向上させる努力を無視したり、過小評価したりするという認識につながり、その結果、さらに質の低いコードの生産につながることを示唆しています。この効果は、時間の経過とともに品質を大きく低下させることにつながります。 + +関連項目: + +- [技術的負債](#TODO) + +例： + +- [実用的なプログラミング：ソフトウェアエントロピー](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy) +- [コーディングホラー：割れ窓理論](https://blog.codinghorror.com/the-broken-window-theory/) +- [オープンソース：プログラミングの喜び-割れ窓理論](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/) + +### ブルックスの法則 + +[ブルックスの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87) + +> 遅延しているソフトウェア開発プロジェクトに人材を追加するとプロジェクトがさらに遅延する。 + +この法則は、多くの場合、すでに遅れているプロジェクトを挽回させようとして、人的リソースを追加することで、プロジェクトが更に遅延することを示唆しています。ブルックスは、これが単純化しすぎであることを明らかにしていますが、一般的な推論としては、新しい人的リソースの立ち上げにかかる時間とコミュニケーションのオーバーヘッドを考えると、短期的には速度が低下するということです。また、多くのタスクは分割ないことがあり、リソース間で簡単にタスク分散されない可能性があり、期待するベロシティも得られなくなることを意味します。 + +出産でよく言われる「9人の女性は1ヶ月で子作りができない」という言葉は、ブルックスの法則、特にある種のタスクは分割や並列化できないという事実に関連しています。 + +これは、「 [人月の神話](#関連書籍) 」という本の中心的なテーマです。 + +関連項目: + +- [デスマーチ](#todo) +- [関連書籍：人月の神話](#関連書籍) + +### コンウェイの法則 + +[コンウェイの法則 Wikipedia(英語版)](https://en.wikipedia.org/wiki/Conway%27s_law) + +この法則は、システムの技術的な境界線が組織の構造を反映することを示唆しています。組織の改善を検討する際によく参考にされますが、コンウェイの法則では、組織が多くの小さな切り離されたユニットに構造化されている場合、その組織が生成するソフトウェアも小さな切り離されたユニットに構造になること示唆しています。もし組織が機能やサービスを中心とした「縦割り」に構築されているならば、ソフトウェアシステムもこれを反映し縦割りになります。 + +関連項目: + +- [Spotifyモデル](#spotifyモデル) + +### カニンガムの法則 + +[カニンガムの法則 - Meta - Meta-Wiki - Wikimedia](https://meta.wikimedia.org/wiki/Cunningham%27s_Law/ja) + +> インターネット上で正解を得るための最良の方法は、質問をすることではなく、間違った答えを投稿することです。 + +スティーブン・マクゲディによると、1980年代初頭にウォード・カニンガム氏が彼にこうアドバイスをしたそうです。「インターネットで正しい答えを得る最善の方法は、質問をすることではなく、間違った答えを投稿することだ」と。マクギーディはこれをカニンガムの法則と呼んでいますが、カニンガムはこの法則の所有権を否定しており、カニンガムはこれを「誤引用」と言っています。元々はUsenet上でのやりとりのこと指していたが、この法則は他のオンラインコミュニティ（例：Wikipedia、Reddit、Twitter、Facebook）の仕組みを説明するために使われてきました。 + +関連項目: + +- [XKCD 386：「デューティコール」](https://xkcd.com/386/) + +### ダンバー数 + +[ダンバー数-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%B3%E3%83%90%E3%83%BC%E6%95%B0) + +「ダンバーの数は、安定した社会的関係を維持できる人の数に対する認知的制限の提案です。つまり、個人が各人が誰であるか、そして各個人と他のすべての人との関係を知っている関係です。」正確な数にはいくつかの意見の相違があります。 「... [ダンバー]は、人間が快適に維持できるのは150人の安定した関係だけであると提案しました。 "彼はその数をより社会的なコンテキストで説明しています、「もしあなたがバーで偶然出会って、その場で突然一緒に酒を飲むことになったとしても、気まずさを感じない人数」。この数は一般的に100人から250人と言われています。 + +個人間の安定した関係と同様に、コードベースと開発者の関係を維持するには努力が必要です。大規模で複雑なプロジェクトに直面したとき、や多くのプロジェクトをかかえているとき、私たちは慣例やポリシー、モデル化された手順に頼ってスケールアップを図っています。ダンバーの数字は、オフィスが大きくなったときに心に留めておくことが重要であるだけでなく、チームの責任範囲を設定したり、システムがモデリングや理論的オーバーヘッドの自動化を支援するツールにいつ投資すべきかを決定するときにも重要です。この数字をエンジニアリングのコンテキストに当てはめると、オンコールローテーションに参加してサポートすることに自信を持てるプロジェクトの数（または単一プロジェクトの複雑さを正規化した数）です。 + +関連項目: + +- [コンウェイの法則](#コンウェイの法則) + +### ゴールの法則 + +[ゴールの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%B4%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87) + +> 動作する複雑なシステムは、必ず、動作していた単純なシステムから進化したものであることがわかります。ゼロから設計された複雑なシステムは決して動作しませんし、それを動作させるためにパッチを当てることもできません。機能するシンプルなシステムからやり直さなければなりません。 +> ([ジョン・ゴール(英語)](https://en.wikipedia.org/wiki/John_Gall_(author))) + +ゴール法則は、高度に複雑なシステムを*設計*しようとする試みが失敗する可能性が高いことを示唆している。高度に複雑なシステムが一度に構築されることはめったになく、より単純なシステムから進化するものです。 + +典型的な例は、world-wide-webです。今日では、これは高度に複雑なシステムですが、しかし、当初は学術機関間でコンテンツを共有するためのシンプルな方法として定義されていました。その目標を達成することに成功し、時間の経過とともにより複雑なものへと進化していきました。 + +関連項目: + +- [KISS (Keep It Simple, Stupid)](#kissの原則) + +### グッドハートの法則 + +[グッドハートの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Goodhart's_law) + +> 観察されたどのような統計的規則性も、管理する目的で圧力をかけると崩壊してしまう傾向があります。 +> *チャールズ・グッドハート* + +次のようにも一般的に参照されます： + +> 計測結果が目標になると、その計測自体が役に立たなくなります。 +> *マリリン・ストラザーン* + +この法則は、測定主導の最適化が測定結果自体の価値を下げることにつながる可能性があると述べています。プロセスに盲目的に適用された過度に選択的な一連の（ [KPI](https://en.wikipedia.org/wiki/Performance_indicator) ）は、歪んだ効果をもたらします。人々は、自分たちの行動の全体的な結果に注意を払うのではなく、特定のメトリックを満たすためにシステムを「ゲーム」することで部分的に最適化する傾向があります。 + +実際の例： + +- 十分にテストされたソフトウェアを作成することがコードカバレッジ測定の意図であったにもかかわらず、アサートなしのテストはコードカバレッジの基準を満たしています。 +- コミットされた行数によって開発者を評価するとは、無駄に肥大化したコードベースを作成することに繋がります。 + +関連項目: + +- [グッドハートの法則：間違ったものを測定することが不道徳な行動をどのように促進するか](https://coffeeandjunk.com/goodharts-campbells-law/) +- [バグのないソフトウェアのディルバート](https://dilbert.com/strip/1995-11-13) + +### ハンロンの剃刀 + +[ハンロンの剃刀-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%83%AD%E3%83%B3%E3%81%AE%E5%89%83%E5%88%80) + +> 無能で十分説明されることに悪意を見出すな。 +> ロバート・J・ハンロン + +この原則は、ネガティブな結果をもたらす行動は悪意の結果ではないことを示唆している。むしろネガティブな結果はそれらの行為や影響が完全に理解されていなかったことに起因する可能性が高い。 + +### ホフスタッターの法則 + +[ホフスタッターの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%80%E3%82%B0%E3%83%A9%E3%82%B9%E3%83%BB%E3%83%9B%E3%83%95%E3%82%B9%E3%82%BF%E3%83%83%E3%82%BF%E3%83%BC#%E3%83%9B%E3%83%95%E3%82%B9%E3%82%BF%E3%83%83%E3%82%BF%E3%83%BC%E3%81%AE%E6%B3%95%E5%89%87) + +> ホフスタッターの法則を考慮しても、いつも予想以上に時間がかかる。 +> （ダグラスホフスタッター） + +何かがどれくらいかかるかの見積もりを見るときに、この法則を聞いたことがあるかもしれません。ソフトウェア開発においては、納品にかかる時間を正確に見積もるのは人々はあまり得意ではない傾向にあります。 + +これは「 [ゲーデル、エッシャー、バッハ：永遠の金色の三つ編み](#関連書籍) 」という本からの引用です。 + +関連項目: + +- [関連書籍： ゲーデル、エッシャー、バッハ：永遠の金色の三つ編み](#関連書籍) + +### ハーバーの法則 + +[ハーバーの法則Wikipedia(英語版)](https://en.wikipedia.org/wiki/Hutber%27s_law) + +> 改善とは劣化を意味します。 +> （ [パトリックハットバー-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Patrick_Hutber) ） + +この法則は、システムを改善しようとして、他の部分の劣化につながったり、または他の劣化を隠し、全体的にシステムが現在の状態から劣化につながることを示唆しています。 + +例えば、特定のエンドポイントに対する応答遅延を減少させようとして、リクエストフローのさらに後フェーズのスループットやキャパシティの問題を増加させ、全く関係ないサブシステムに影響を与える可能性があります。 + +### ハイプ・サイクルとアマラの法則 + +[ハイプ・サイクル- Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%97%E3%83%BB%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB) + +> テクノロジーの効果を短期的には過大評価し、長期的には過小評価する傾向がある。 +> （ロイ・アマラ） + +ハイプ・サイクルは、元々はガートナー社によって作成された、時間をかけてテクノロジーの興奮と発展を視覚的に表現したものです。視覚的に表示するのが最適です。 + +![The Hype Cycle](../images/gartner_hype_cycle.png) + +*（画像参照：英語版ウィキペディアのJeremykemp著、CC BY-SA 3.0、https：//commons.wikimedia.org/w/index.php？curid = 10547051）* + +要するに、このサイクルは、一般的に新技術とその潜在的な影響力について興奮があることを示唆している。チームはしばしばこれらのテクノロジーにすぐに飛びつき、その結果に失望してしまうことがあります。これは、テクノロジーがまだ十分に成熟していなかったり、実世界でのアプリケーションがまだ十分に実現されていないからかもしれません。ある程度の時間が経つと、テクノロジーの能力が向上し、実際に使用する機会が増え、チームはようやく生産性を高めることができます。Roy Amaraのこの言葉は、このことを最も簡潔に要約しています。「私たちは、テクノロジーの効果を短期的には過大評価し、長期的には過小評価する傾向がある」。 + +### ハイラムの法則（暗黙のインターフェースの法則） + +[ハイラムの法則(英語)](http://www.hyrumslaw.com/) + +> あるAPIに十分なユーザー数がいれば、契約書で何を約束するかどうかは問題ではありません。 あなたのシステムのすべての観測可能な動作は、誰かに依存することになります。 +> （ハイラム・ライト） + +ハイラムの法則では、APIの*ユーザ数が十分に多い*場合、APIのすべての動作(公的契約の一部として定義されていないものであっても)は、最終的に誰かに依存するようになるということを述べています。些細な例としては、APIの応答時間などの非機能要件が挙げられます。もっと微妙な例は、APIのエラーの*タイプ*を判断するために、エラーメッセージに正規表現を適用することに依存しているユーザかもしれません。API の公開契約ではメッセージの内容について何も記述されておらず、ユーザーがメッセージではなくエラーコードを使用すべきでと明示していたとしても、*一部の*ユーザーがそれを無視してメッセージを使用する可能性があり、メッセージを変更することでそのようなユーザーのための API が本質的に壊れてしまうことになります。 + +関連項目: + +- [漏れのある抽象化の法則](#漏れのある抽象化の法則) +- [XKCD 1172](https://xkcd.com/1172/) + +### カーニガンの法則 + +> デバッギングはコーディングよりも2倍難しい。従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。 +> （ブライアン・カーニハン） + +カーニガンの法則は、 [ブライアンカーニハンに](https://en.wikipedia.org/wiki/Brian_Kernighan)ちなんで名付けられ、カーニハンとプラウガーの著書[「Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style) 」からの引用に基づいています。 + +> デバッグは、そもそもプログラムを書くことの2倍大変だということは誰もが知っています。では、コードを書いた時に同じくらい賢いとしたら、どうやってデバッグするのでしょうか？ + +双曲線的ではありますが、カーニガンの法則は、複雑なコードで発生した問題をデバッグするのはコストがかかるか、実現不可能な場合があるため、単純なコードは複雑なコードよりも優先されるべきであるということを言っています。 + +関連項目: + +- [KISSの原則](#kissの原則) +- [UNIX哲学](#unix哲学) +- [オッカムのかみそり](#オッカムの剃刀) + +### メトカーフの法則 + +[メトカーフの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%88%E3%82%AB%E3%83%BC%E3%83%95%E3%81%AE%E6%B3%95%E5%89%87) + +> ネットワーク理論では、システムの価値は、システムの利用者数の約2乗で成長します。 + +この法則は、システム内で可能なペアワイズ接続の数に基づいており、 [リードの法則](#リードの法則)と密接に関連しています。オドリズコらは、リードの法則とメトカーフの法則の両方が、ネットワーク効果に関する人間の認知の限界を考慮しないことによって、システムの価値を過大評価していると主張しています。 [ダンバー数を](#ダンバー数)参照してください。 + +関連項目: + +- [リードの法則](#リードの法則) +- [ダンバー数](#ダンバー数) + +### ムーアの法則 + +[ムーアの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A0%E3%83%BC%E3%82%A2%E3%81%AE%E6%B3%95%E5%89%87) + +> 集積回路のトランジスタ数は約2年ごとに倍増します。 + +この法則は半導体やチップ技術の進歩の速さを示すためによく使われますが、ムーアの予測は1970年代から2000年代後半にかけて非常に正確であることが証明されています。近年では、その傾向はわずかに変化していますが、その理由の一部には[コンポーネントを小型化できる程度の物理的な制限(トンネル効果)](https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%B3%E3%83%8D%E3%83%AB%E5%8A%B9%E6%9E%9C)があります。しかし、並列化の進歩や、半導体技術や量子コンピューティングにおける革命的な変化により、ムーアの法則が今後数十年にわたって真実であり続ける可能性があることを意味しています。 + +### マーフィーの法則/ソッドの法則 + +[マーフィーの法則-Wikipedia(](https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%83%95%E3%82%A3%E3%83%BC%E3%81%AE%E6%B3%95%E5%89%87) + +> 何をやってもうまくいかないものはうまくいかない。 + +[エドワード・A・マーフィー・ジュニア](https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%89%E3%83%AF%E3%83%BC%E3%83%89%E3%83%BBA%E3%83%BB%E3%83%9E%E3%83%BC%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%82%B8%E3%83%A5%E3%83%8B%E3%82%A2)に関連して、*マーフィーの法則*では、物事がうまくいかないことがあれば、それはうまくいかないだろうということが述べられています。 + +これは開発者の間でよくある格言です。開発中、テスト中、あるいは本番中にも予期せぬことが起こることがあります。これは、 *ソッドの法則* （イギリス英語ではより一般的）にも関連しています。 + +> 何かがうまくいかないことがあれば、最悪のタイミングでそうなる。 + +これらの「法則」は、一般的にコミカルな意味で使われています。ただし、 [*確証バイアス*](#TODO)や[*選択バイアス*](#TODO)などの現象は、人々がこれらの法則を強調しすぎてしまう可能性があります(物事がうまくいく時の大半は、彼らは気づかれないですが、失敗は、しかし、より顕著であり、より多くの議論を生みます)。 + +関連項目: + +- [確証バイアス](#TODO) +- [選択バイアス](#TODO) + +### オッカムの剃刀 + +[オッカムの剃刀-Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%83%E3%82%AB%E3%83%A0%E3%81%AE%E5%89%83%E5%88%80) + +> エンティティは必要なくして掛け算してはいけない。 +> オッカムのウィリアム + +オッカムの剃刀は、いくつかの可能な解決策の中で、最も可能性の高い解決策は、概念と仮定の数が最も少ないものであると言います。この解は最も単純で、与えられた問題だけを解決し、偶発的な複雑さや起こりうる負の結果を導入することはありません。 + +関連項目: + +- [YAGNI](#yagni) +- [銀の弾などない：偶発的な複雑さと本質的な複雑さ](https://ja.wikipedia.org/wiki/%E9%8A%80%E3%81%AE%E5%BC%BE%E3%81%AA%E3%81%A9%E3%81%AA%E3%81%84) + +例: + +- [リーンソフトウェア開発：無駄をなくす-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) + +### パーキンソンの法則 + +[パーキンソンの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%BD%E3%83%B3%E3%81%AE%E6%B3%95%E5%89%87) + +> 仕事の量は、与えられた時間を全て満たすまで膨張する。 + +元の文脈では、この法則は官僚機構の研究に基づいていた。この法則は、ソフトウェア開発の取り組みに悲観的に適用されるかもしれません。理論的には、チームは締め切りが近づくまで非効率的であり、その後、締め切りまでに仕事を完成させようと急ぐので、実際の締め切りはやや恣意的になるということです。 + +この法則が[ホフスタッターの法則](#ホフスタッターの法則)と組み合わされた場合、さらに悲観的な見方が得られます。作業は、その完了に利用できる時間を埋めるために拡大し*、予想よりも長くかかり*ます。 + +関連項目: + +- [ホフスタッターの法則](#ホフスタッターの法則) + +### 早すぎる最適化 + +[最適化する時期-Wikipedia](https://ja.wikipedia.org/wiki/%E6%9C%80%E9%81%A9%E5%8C%96_(%E6%83%85%E5%A0%B1%E5%B7%A5%E5%AD%A6)#%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%99%E3%82%8B%E6%99%82%E6%9C%9F) + +> 早すぎる最適化は諸悪の根源です。 +> [（ドナルドクヌース）](https://twitter.com/realdonaldknuth?lang=en) + +Donald Knuthの論文「 [Structured Programming With Go To Statements」で](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) 、彼は次のように書いています。「プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりして膨大な量の時間を浪費している。小さな効率性、つまり97%程度の効率性については忘れた方がいいでしょう。 **早すぎる最適化は諸悪の根源です** 。しかし、その重要な3％で機会を逃してはなりません。」 + +しかし、 *早すぎる最適化*は（負荷の低い用語で）、必要性を知る前に最適化することと定義することができます。 + +### パットの法則 + +[パットの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) + +> 技術は、管理しないことを理解している人と、理解していないことを管理している人の2つのタイプに支配されている。 + +よくパットの法則にはパットの帰結が続きます。 + +> すべての技術的な階層は、時間の経過とともに、能力の逆転を発生させます。 + +これらの記述は、グループがどのように組織化されるかという様々な選択基準や傾向のために、技術的な組織の実務レベルには熟練した人が多く、管理職には自分が管理している仕事の複雑さや課題を認識していない人が多くいることを示唆しています。これは[、ピーター原理](#ピーターの原則)や[ディルバート原理](#ディルバートの原理)などの現象が原因である可能性があります。 + +ただし、このような法則は広範に一般化されており、*特定*の一部の組織には適用されますが、他の組織には適用されない場合があることを強調しておく必要があります。 + +関連項目: + +- [ピーターの原則](#ピーターの原則) +- [ディルバートの原理](#ディルバートの原理) + +### リードの法則 + +[リードの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Reed's_law) + +> 大規模ネットワーク、特にソーシャルネットワークの効用は、ネットワークの大きさに応じて指数関数的にスケーリングする。 + +この法則はグラフ理論に基づいており、実用性は可能なサブグループの数に応じてスケールし、これは参加者の数や可能なペアワイズ接続の数よりも速くスケールします。オドリズコ氏らは、ネットワークの影響に対する人間の認識の限界を考慮しないことで、リードの法則がシステムの有用性を誇張していると主張しています。 [ダンバー数を](#ダンバー数)参照してください。 + +関連項目: + +- [メトカーフの法則](#メトカーフの法則) +- [ダンバー数](#ダンバー数) + +### 複雑性保存の法則（テスラーの法則） + +[The Law of Conservation of Complexity-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) + +この法則では、システムには削減できない一定の複雑さがあるとされています。 + +システムの複雑さの中には、「不注意」なものもあります。これは、構造の不備、ミス、または解決すべき問題のモデリングの不備の結果です。不注意な複雑さは、減らすことができます（または排除することができます）。しかし、いくつかの複雑さは、解決される問題に内在する複雑さの結果として「内在的」です。この複雑さは動かすことはできますが、排除することはできません。 + +この法則の興味深い側面は、システム全体を単純化しても、本質的な複雑さは軽減されず、より複雑な方法でシステムを動かす*ユーザーに複雑性が移される*という提案です。 + +### 漏れのある抽象化の法則 + +[漏れのある抽象化の法則 Joel on Software(英語)](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) + +> 自明でない抽象化はすべて、程度の差こそあれ、漏れがある。 +> （ [ジョエル・スポルスキー](https://twitter.com/spolsky) ） + +この法則では、複雑なシステムでの作業を簡略化するためにコンピューティングで一般的に使用される抽象化は、特定の状況では、基礎となるシステムの要素を「漏らし」、抽象化が予期しない方法で動作することになると述べています。 + +例としては、ファイルをロードしてその内容を読むことが挙げられます。ァイルシステム API は低レベルのカーネルシステムの *抽象化*であり、それ自体が磁気プラッター (または SSD のフラッシュメモリ) 上のデータの変更に関連する物理的なプロセスを抽象化したものです。ほとんどの場合、ファイルをバイナリデータのストリームのように扱うという抽象化が機能します。磁気ドライブの場合、データを連続的に読み込むと、ランダム・アクセスよりも（ページ・フォルトのオーバーヘッドが増加するため）*大幅に*速くなりますが、SSD ドライブの場合は、このオーバーヘッドは存在しません。この場合に対処するためには、基本的な詳細を理解する必要があります（例えば、データベースのインデックスファイルはランダムアクセスのオーバーヘッドを減らすために構造化されています）が、抽象化された実装の詳細は、開発者が注意する必要があるかもしれません。 + +上記の例は、より多くの抽象化が導入されると、*より*複雑になる可能性があります。Linux オペレーティングシステムでは、ネットワーク経由でファイルにアクセスすることができますが、ローカルでは「通常の」ファイルとして表現されます。この抽象化は、ネットワーク障害が発生した場合に「漏れ」ます。開発者がこれらのファイルをネットワークの遅延や障害の影響を受ける可能性があることを考慮せずに「通常の」ファイルとして扱ってしまうと、解決策がバグだらけになってしまいます。 + +この法則を説明している記事によると、抽象化への過度の依存は、基礎となるプロセスの理解不足と相まって、実際には手元にある問題への対処を、場合によっては*より*複雑なものにしてしまうことが示唆されています。 + +関連項目: + +- [ハイラムの法則](#ハイラムの法則暗黙のインターフェースの法則) + +実際の例： + +- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - 過去に遭遇した問題 Photoshopの起動が遅く、数分かかることもありました。問題は、起動時に現在のデフォルトプリンタに関する情報を読み取ることだったようです。しかし、そのプリンタが実際にネットワークプリンタである場合、これは非常に長い時間がかかる可能性があります。ネットワークプリンタがローカルプリンタと同様に*抽象化*してしまったことにより接続時間の問題を引き起こしました。 + +### パーキンソンの凡俗法則 + +[パーキンソンの凡俗法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%BD%E3%83%B3%E3%81%AE%E5%87%A1%E4%BF%97%E6%B3%95%E5%89%87) + +この法則は、グループが深刻で実質的なものよりも、些細な問題や表面上の問題にはるかに多くの時間と注意力を注ぐことを示唆しています。 + +よくある架空の例は、原子力発電所の計画を承認する委員会の例であり、彼らは発電所自体のはるかに重要な設計よりも、自転車小屋の構造について議論することに時間の大半を費やしている。非常に大きく複雑なテーマについての議論では、高度な専門知識や準備がなければ、意味のあるな意見を述べることは難しいかもしれません。しかし、人々は意味のある意見を発言していると見られたいと思う傾向があり、そのため、簡単に推論できるが、必ずしも特別な重要性があるわけではないような些細なことに時間を集中させてしまう傾向がある。 + +上記の架空の例では、些細な細部に時間を浪費するための表現として「自転車シェディング」という用語を使用しました。関連用語は「 [ヤクシェービング](https://ja.wiktionary.org/wiki/yak_shaving) 」です。これは、メインタスクの前提条件の長い連鎖の一部である、一見無関係な活動を意味します。 + +### UNIX哲学 + +[UNIX哲学-Wikipedia](https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6) + +UNIX理念は、ソフトウェアの構成要素は小さく、一つの特定のことをうまく行うことに集中すべきであるというものです。これは、大規模で複雑な多目的プログラムを使うのではなく、小さくてシンプルで、よく定義されたユニットを組み合わせてシステムを構築することを容易にすることができます。 + +現代における「マイクロサービス・アーキテクチャ」は、この法則の応用と考えることができ、サービスは小さく、焦点を絞って、特定の一つのことをしっかりと行うことで、複雑な動作をシンプルなビルディングブロックで構成することを可能にしています。 + +### Spotifyモデル + +[Spotifyモデル-Spotify Labs(英語)](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) + +Spotifyモデルとは、「Spotify」によって普及したチームと組織構造へのアプローチです。このモデルでは、チームはテクノロジーではなく機能を中心に組織されています。 + +また、Spotify モデルでは、組織構造の他の要素である部族、ギルド、チャプターの概念も普及しています。 + +### ワドラーの法則 + +[ワドラーの法則-wiki.haskell.org(英語)](https://wiki.haskell.org/Wadler's_Law) + +> どのような言語設計においても、このリストの特徴を議論するのに費やされた時間の合計は、その位置の累乗に2を上げることに比例します。 +> 1. 意味論 +> 2. 構文 +> 3. 字句構文 +> 4. コメントの字句構文 +> （要するに、意味論に1時間使うとすると、8時間はコメントの構文に費やされます）。 + +同様に[パーキンソンの凡俗法則](#パーキンソンの凡俗法則) 、和ドラーの法則は、言語を設計する際に、言語構造の重要性に比べて、言語構造に費やされる時間が不釣り合いに多いということが述べられています。 + +関連項目: + +- [パーキンソンの凡俗法則](#パーキンソンの凡俗法則) + +### ウィートンの法則 + +[リンク(英語)](http://www.wheatonslaw.com/) + +[公式日(英語)](https://dontbeadickday.com/) + +> 嫌な奴になるな +> *ウィル・ウィートン* + +ウィル・ウィートン（スタートレック：ネクスト・ジェネレーション、ビッグバン・セオリー）によって考案されたこのシンプルで簡潔で強力な法則は、専門的な組織内での調和と尊敬を高めることを目的としています。同僚との会話、コードレビューの実行、他の視点からの反論、批評、そして一般的に、ほとんどのプロフェッショナルな人間関係に適用することができます。 + +## 原則 + +一般に、原則は設計に関するガイドラインである可能性が高くなります。 + +### ディルバートの原理 + +[ディルバートの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%AB%E3%83%90%E3%83%BC%E3%83%88%E3%81%AE%E6%B3%95%E5%89%87) + +> 企業は、事業への損害を最小限にとどめるために、系統立てて無能な者から管理職に昇進させて行く傾向がある +> *スコットアダムス* + +スコット・アダムス（漫画「ディルバート」の作者）が開発した経営概念で、ディルバート原則は[、ピーター原則に](#ピーターの原則)触発されています。ディルバートの原則では、有能でない社員を管理職に昇格させることで、事業への損害を最小限にとどめる。 Adamsは、1995年のウォールストリートジャーナルの記事でこの原則を最初に説明し、1996年のビジネスブック、 [The Dilbert Principleで](#関連書籍)それを拡張しました。 + +関連項目: + +- [ピーターの原則](#ピーターの原則) +- [パットの法則](#パットの法則) + +### パレート原理（80/20ルール） + +[パレートの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%AC%E3%83%BC%E3%83%88%E3%81%AE%E6%B3%95%E5%89%87) + +> 人生のほとんどのものが均等に分配されていません。 + +パレートの原理は、いくつかのケースでは、結果の大部分は少数の入力から来ることを示唆している。 + +- 特定のソフトウェアの80％は、割り当てられた合計時間の20％で実装できます（逆に、コードの最も難しい20％部分を実装するのに時80％の時間がかかります） +- 2割の努力は8割の結果を生む +- 2割の仕事が8割の収益を生み出す +- 20%のバグが80%のクラッシュを引き起こす +- 20%の機能が80%の使用率を引き起こす + + 1940年代には、品質管理の父と広く信じられているアメリカ・ルーマニアのエンジニア、ジョセフ・ジュラン博士が[、パレートの原則を品質問題に適用し始めました](https://en.wikipedia.org/wiki/Joseph_M._Juran) 。 + +この原則は、次のようにも知られています。80/20ルール、バイタル・フューの法則、ファクター・スパーシティの原理。 + +実際の例： + +- 2002年に、Microsoftは、最も報告されたバグの上位20％を修正することにより、windowsやofficeの関連するエラーやクラッシュの80%が解消されると報告しています（ [参考文献](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm) ）。 + +### ピーターの原則 + +[ピーターの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%94%E3%83%BC%E3%82%BF%E3%83%BC%E3%81%AE%E6%B3%95%E5%89%87) + +> 階層社会では、人間は能力の極限まで出世する。 +> *ローレンス・J・ピーター* + +ローレンス・J・ピーターによって開発された経営概念で、ピーターの原則は、仕事が得意な人は、もはや成功しないレベル（彼らの「無能のレベル」）に達するまで、昇進すると観察しています。この時点では、彼らはより熟練であるため、組織から外される可能性は低く、彼らを成功に導いた元々のスキルが必ずしも新しい仕事に必要なスキルであるとは限らないため、彼らが本来持っているスキルがほとんどない役割に留まり続けることになります。 + +これは、最初はエンジニアとしてキャリアをスタートさせ、他のエンジニアの*管理に*つながるキャリアパスを描いているエンジニアにとって、特に興味深いものです。管理職には、根本的にエンジニアとは異なるスキルセットが必要です。 + +関連項目: + +- [ディルバートの原理](#ディルバートの原理) +- [パットの法則](#パットの法則) + +### 堅牢性の原則（ポステルの法則） + +[堅牢性の原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Robustness_principle) + +> 自分のやることは慎重に、他人から受け入れるときは自由に。 + +サーバーアプリケーションの開発によく適用されるこの原則は、他のシステムに送るものは可能な限り最小限にして、適合性のあるものにすべきであるが、処理できる場合には、適合性のない入力を許容することを目指すべきである、ということを述べています。 + +この原則の目標は、ハンドルできる場合には、不適合な入力を処理できるので、堅牢なシステムを構築することです。しかし、特にそのような入力の処理が十分にテストされていない場合には、不適合な入力を受け入れることにはセキュリティ上の問題がある可能性があります。 + +不適合な入力を許可すると、実装者が最終的にこの自由に依存して機能を構築するようになるため、プロトコルが進化する可能性が損なわれる場合があります。 + +関連項目: + +- [ハイラムの法則](#ハイラムの法則暗黙のインターフェースの法則) + +### SOLID + +これは以下を指す頭字語です。 + +- S： [単一責任の原則](#単一責任の原則) +- O： [開放/閉鎖原則](#開放閉鎖原則) +- L： [リスコフ代替原則](#リスコフの置換原則) +- I： [インターフェース分離の原則](#インターフェース分離の原則) +- D： [依存関係の逆転の原則](#依存性逆転の原則) + +これらは、 [オブジェクト指向プログラミングの](#todo)主要な原則です。このような設計原則は、開発者が保守しやすいシステムを構築するのに役立つはずです。 + +### 単一責任の原則 + +[単一責任原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Single_responsibility_principle) + +> すべてのモジュールやクラスは、単一の責任のみを持つべきです。 + +「 [SOLID](#solid) 」第一原則。この原則は、モジュールやクラスは一つのことを一つのことだけを行うべきだということを提案しています。より実用的な用語では、これはプログラムの機能への単一の小さな変更は、1つのコンポーネントのみの変更を必要とすることを意味します。例えば、パスワードの複雑さを検証する方法を変更するには、プログラムの一部分だけを変更する必要があります。 + +理論的には、これによりコードがより堅牢になり、変更が容易になるはずです。変更されるコンポーネントが単一の責任を持っていることを知ることは、その変更の*テスト*がより簡単になることを意味します。先ほどの例を使うと、パスワードの複雑さのコンポーネントを変更することは、パスワードの複雑さに関連する機能にのみ影響を与えることができるはずです。多くの責任を持つコンポーネントへの変更の影響を推論することは、はるかに難しいでしょう。 + +関連項目: + +- [オブジェクト指向プログラミング](#todo) +- [SOLID](#solid) + +### 開放/閉鎖原則 + +[開放/閉鎖原則-Wikipedia](https://ja.wikipedia.org/wiki/%E9%96%8B%E6%94%BE/%E9%96%89%E9%8E%96%E5%8E%9F%E5%89%87) + +> エンティティは拡張のために開かれ、修正のために閉じられるべきです。 + +「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*ることができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。 + +仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。ジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。 + +この原則は、オブジェクト指向プログラミングに特に関連しています。簡単に拡張するオブジェクトを設計するかもしれませんが、予期しない方法で変更された既存の動作を持つことができるオブジェクトを設計することを避けます。 + +関連項目: + +- [オブジェクト指向プログラミング](#todo) +- [SOLID](#solid) + +### リスコフの置換原則 + +[リスコフの置換原則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%B9%E3%82%B3%E3%83%95%E3%81%AE%E7%BD%AE%E6%8F%9B%E5%8E%9F%E5%89%87) + +> システムを壊すことなく、タイプをサブタイプに置き換えることができるはずです。 + +「 [SOLID](#solid) 」原則の3番目。この原則は、コンポーネントがタイプに依存している場合、システムに障害が発生したり、そのサブタイプが何であるかの詳細を知る必要なく、そのタイプのサブタイプを使用できるはずであると述べています。 + +例として、ファイルを表す構造からXMLドキュメントを読み取るメソッドがあるとします。メソッドが基本タイプ「ファイル」を使用する場合、「ファイル」から派生するものはすべて関数で使用できるはずです。 「ファイル」が逆方向のシークをサポートし、XMLパーサーがその関数を使用するが、逆型シークが試行されたときに派生型「ネットワークファイル」が失敗する場合、「ネットワークファイル」は原則に違反しています。 + +この原則は、オブジェクト指向プログラミングに特に関連しています。システムのユーザーを混乱させないように、型階層を注意深くモデル化する必要があります。 + +関連項目: + +- [オブジェクト指向プログラミング](#todo) +- [SOLID](#solid) + +### インターフェース分離の原則 + +[インターフェース分離原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Interface_segregation_principle) + +> 使用しないメソッドに依存することを強制されるクライアントはありません。 + +「 [SOLID](#solid) 」原則の4番目。この原則は、コンポーネントのコンシューマーが、実際に使用しないコンポーネントの機能に依存すべきではないと述べています。 + +例として、ファイルを表す構造体からXML文書を読み込むメソッドがあるとします。このメソッドが必要とするのは、ファイル内のバイトを読み込んだり、前に移動したり、後ろに移動したりすることだけです。ファイル構造体の無関係な機能が変更されたためにこのメソッドを更新する必要がある場合（ファイルのセキュリティを表現するために使用されるパーミッションモデルの更新など）、その原則は無効になっています。ファイルは「シーク可能なストリーム」インターフェースを実装し、XMLリーダーはそれを使用する方が良いでしょう + +この原則はオブジェクト指向プログラミングに特に関連性があり、インターフェイス、階層構造、抽象型が異なるコンポーネント間の結合を[最小限](#todo)にするために使用されます。[ダックタイピング](#todo)は、明示的なインターフェースを排除することでこの原則を強制する方法論です。 + +関連項目: + +- [オブジェクト指向プログラミング](#todo) +- [SOLID](#solid) +- [ダックタイピング](#todo) +- [デカップリング](#todo) + +### 依存性逆転の原則 + +[依存性逆転の原則-Wikipedia](https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E9%80%86%E8%BB%A2%E3%81%AE%E5%8E%9F%E5%89%87) + +> 高レベルのモジュールは、低レベルの実装に依存すべきではありません。 + +「 [SOLID](#solid) 」原則の5番目。この原則は、より高いレベルのオーケストレーションコンポーネントは、依存関係の詳細を知っている必要はないことを述べています。 + +例として、ウェブサイトからメタデータを読み取るプログラムがあるとします。メインコンポーネントは、ウェブページのコンテンツをダウンロードするためのコンポーネントについて知る必要があり、メタデータを読み取ることができるコンポーネントであると想定します。依存関係の逆転を考慮すると、メインコンポーネントは、バイトデータをフェッチできる抽象コンポーネントと、バイトストリームからメタデータを読み取ることができる抽象コンポーネントのみに依存します。メインコンポーネントは、TCP / IP、HTTP、HTMLなどについては認識しません。 + +この原則は複雑です。システムの予想される依存関係（したがって、名前）を「逆転」するように見える場合があるためです。実際には、別のオーケストレーションコンポーネントが抽象型の正しい実装が使用されていることを確認する必要があることも意味します（たとえば、前の例では、 *何か*がメタデータリーダーコンポーネントにHTTPファイルダウンローダーとHTMLメタタグリーダーを提供する必要があります）。次に、 [Inversion of Control](#todo)や[Dependency Injection](#todo)などのパターンに触れます。 + +関連項目: + +- [オブジェクト指向プログラミング](#todo) +- [SOLID](#solid) +- [制御の反転](#todo) +- [依存性注入](#todo) + +### DRY原則 + +[Don't repeat yourself-Wikipedia](https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself) + +> すべての知識は、システム内で単一の明確で信頼できる表現を持つ必要があります。 + +DRYは、 *Do n't Repeat Yourselfの*頭字語です。この原則は、開発者がコードの繰り返しを減らして情報を1か所に保管できるようにすることを目的としており、1999年にAndrew HuntとDave Thomasが 『 [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) 』で引用しています。 + +> DRYの反対は*WET* （すべてを2回書き込むか、タイピングを楽しむ）です。 + +実際には、2つ（またはそれ以上）の異なる場所に同じ情報がある場合、DRYを使用してそれらを1つの場所にマージし、必要な場所で必要に応じて再利用できます。 + +関連項目 + +- [実用的な開発者(英語)](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) + +### KISSの原則 + +[KISSの原則-Wikipedia](https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87) + +> 簡潔に単純にしておけ + +KISSの原則は、ほとんどのシステムは複雑にするのではなく、シンプルに保つことが最もよく機能するというもので、シンプルさは設計の重要な目標であり、不必要な複雑さは避けるべきだというものです。 1960年にアメリカ海軍で始まったこのフレーズは、航空機エンジニアのケリー・ジョンソンに関連しています。 + +この原則は、ジョンソンが設計エンジニアのチームに一握りの工具を渡し、設計しているジェット機は、現場の平均的な整備士がこれらの工具だけで戦闘状況下で修理可能なものでなければならないという課題を与えたという話に最もよく例示されています。したがって、「バカ」とは、技術者自身の能力ではなく、物の壊れ方と、それを修理するために利用できる道具の巧妙さの関係を指しています。 + +関連項目: + +- [ゴールの法則](#ゴールの法則) + +### YAGNI + +[YAGNI-Wikipedia](https://ja.wikipedia.org/wiki/YAGNI) + + ***Y**ou **A**in't **G**onna **N**eed **I**t*"縮めて YAGNI + +> 実際にそれらが必要なときに常に実装し、必要があると予測しただけでは決して実装しないでください。 +> （ [Ron Jeffries](https://twitter.com/RonJeffries) ）（XPの共同創設者であり、「Extreme Programming Installed」という本の著者） + +この*エクストリームプログラミング* （XP）の原則は、開発者は当面の要件に必要な機能のみを実装し、後で必要になる可能性のある機能を実装して将来を予測しようとする試みを避けることを示唆しています。 + +この原則を順守することで、コードベース内の未使用のコードの量を減らし、価値のない機能に時間と労力が浪費されるのを防ぐことができます。 + +関連項目 + +- [関連書籍：インストールされているExtremeプログラミング](#関連書籍) + +### 分散コンピューティングの落とし穴 + +[分散コンピューティングの落とし穴-Wikipedia](https://ja.wikipedia.org/wiki/%E5%88%86%E6%95%A3%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AE%E8%90%BD%E3%81%A8%E3%81%97%E7%A9%B4) + +「*ネットワークコンピューティングの落とし穴*」としても知られているこの落とし穴は、ソフトウェア開発の失敗につながる可能性のある、分散コンピューティングに関する思い込み(または信念)のリストです。仮定は以下の通りです。 + +- ネットワークは信頼できる +- 待ち時間はゼロです +- 帯域幅は無限です +- ネットワークは安全です +- トポロジーは変わらない +- 管理者が一人だけいます +- トランスポートコストはゼロ +- ネットワークは均一です + +最初の4つの項目は、1991年頃に[Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy)と[Tom Lyon](https://twitter.com/aka_pugs)によってリストされ、 [James Gosling](https://en.wikipedia.org/wiki/James_Gosling)によって最初に「ネットワークコンピューティングの失墜」として分類されました。 [L.ピータードイチュ](https://en.wikipedia.org/wiki/L._Peter_Deutsch)は、5、6、7番目の誤りを追加しました。 90年代後半、ゴスリングは8番目の誤りを追加しました。 + +このグループは、 [Sun Microsystemsの](https://en.wikipedia.org/wiki/Sun_Microsystems)内部で当時何が起こっていたかに触発されました。 + +これらの誤りは、弾力性のあるコードを設計するときに注意深く検討する必要があります。これらの誤りのいずれかが、分散システムの現実と複雑さに対処できない欠陥のあるロジックにつながる可能性があると仮定します。 + +関連項目: + +- [分散コンピューティングの落とし穴の採餌（パート1）-Vaidehi Joshi + 中(英語)](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53) +- [Deutsch's Fallacies、10年後(英語)](http://java.sys-con.com/node/38665) + +## 関連書籍: + +もっと興味を感じたなら、以下の本を参照してください。 + +- [インストールされているエクストリームプログラミング-ロンジェフリーズ、アンアンダーソン、チェットヘンドリクソン](https://www.goodreads.com/en/book/show/67834) -エクストリームプログラミングのコア原則をカバーしています。 +- [The Mythical Man Month-フレデリックP.ブルックスJr.-](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month)ソフトウェアエンジニアリングに関する古典的な巻。 [ブルックスの法則](#ブルックスの法則)は本の中心的なテーマです。 +- [ゲーデル、エッシャー、バッハ：永遠のゴールデンブレイド-ダグラスR.ホフスタッター。](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) -この本は分類するのが難しいです。 [ホフスタッターの法則](#ホフスタッターの法則)は本からです。 +- [ディルバートの原則-スコットアダムス](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - [ディルバートの原則](#ディルバートの原理)を作成した作者によるアメリカの企業の漫画の外観。 +- [ピーター原則-ローレンスJ.ピーター](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - [ピーター原則の](#ピーターの原則)出典である、より大きな組織と人々の管理の課題に関する別の漫画の見方。 + +## 翻訳 + +多くの素晴らしい投稿者のおかげで、ハッカーの法則は多くの言語で利用可能です。モデレーターのスポンサーもご検討ください。 + +言語 | モデレータ | ステータス +--- | --- | --- +[🇧🇷 Brasileiro / Brazilian](../translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [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) | 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)[](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) +[🇬🇷 ελληνικά / 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) | 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)[](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) | 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)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge) +| [JP 日本語 / Japanese](../translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)|Partially complete | + +翻訳を更新したい場合は、 [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls)するだけです。新しい言語を追加したい場合は、 [GitLocalize](https://gitlocalize.com/) にログインしてアカウントを作成し、言語の管理を依頼するためのissueを開いてください。また、上の表とファイルの先頭にあるリンクを更新するプルリクエストを開いていただけると、とても助かります。 + +## 関連プロジェクト + +- [今日のヒント(英語)](https://tips.darekkay.com/html/hacker-laws-en.html) -毎日ハッカーの法則/原則の更新を知ることができます。 +- [ハッカーの法則コマンド](https://github.com/umutphp/hacker-laws-cli)あなたの端末上でランダムな法則を一覧表示、表示、確認できます。 + +## 貢献方法 + +貢献してください! 追加や変更を提案したい場合は [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new)、変更を提案したい場合は [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare)t をご利用ください。 + +文章やスタイルなどの要件については、[Contributing Guidelines](./.github/contributing.md) を必ずお読みください。プロジェクトの議論に参加する際には、[Code of Conduct](./.github/CODE_OF_CONDUCT.md)を意識してください。 + +## TODO + +こんにちは！あなたがここに来たということは、私がまだ書き上げていないトピックへのリンクをクリックしたことにですね。 + +リクエストしたい場合は [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) rをクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。 diff --git a/translations/lv.md b/translations/lv.md new file mode 100644 index 00000000..dff74fab --- /dev/null +++ b/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)! + +--- + + + +* [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) + + + +## 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. + +Diagram: Amdahla likums + +*(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). diff --git a/translations/pt-BR.md b/translations/pt-BR.md new file mode 100644 index 00000000..ed996c7d --- /dev/null +++ b/translations/pt-BR.md @@ -0,0 +1,799 @@ +# 💻📖 hacker-laws + +Leis, teorias, princípios e padrões que desenvolvedores acharão úteis. + +[Traduções](#translations): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/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) [🇯🇵](./translations/jp.md) + +Gostou deste projeto? Por favor, considere [me apoiar](https://github.com/sponsors/dwmkerr) e [apoiar os tradutores](#traduções). + +--- + + + +* [Introdução](#introdução) +* [Leis](#leis) + * [Princípio 90-9-1 (Regra do 1%)](#princípio-90-9-1-regra-do-1) + * [Lei de Amdahl](#lei-de-amdahl) + * [Teoria das Janelas Quebradas](#teoria-das-janelas-quebradas) + * [Lei de Brook](#lei-de-brook) + * [Lei de Conway](#lei-de-conway) + * [Lei de Cunningham](#lei-de-cunningham) + * [Número de Dunbar](#número-de-dunbar) + * [Lei de Gall](#lei-de-gall) + * [Lei de Goodhart](#lei-de-goodhart) + * [Navalha de Hanlon](#navalha-de-hanlon) + * [Lei de Hofstadter](#lei-de-hofstadter) + * [Lei de Hutber](#lei-de-hutber) + * [O Ciclo Hype e Lei de Amara](#o-ciclo-hype-e-lei-de-amara) + * [Lei de Hyrum (Lei das Interfaces Implícitas)](#lei-de-hyrum-lei-das-interfaces-implícitas) + * [Lei de Kernighan](#lei-de-kernighan) + * [Lei de Metcalfe](#lei-de-metcalfe) + * [Lei de Moore](#lei-de-moore) + * [Lei de Murphy / Lei de Sod](#lei-de-murphy--lei-de-sod) + * [Navalha de Occam](#navalha-de-occam) + * [Lei de Parkinson](#lei-de-parkinson) + * [Efeito de Otimização Prematura](#efeito-de-otimização-prematura) + * [Lei de Putt](#lei-de-putt) + * [Lei de Reed](#lei-de-reed) + * [A Lei da Conservação da Complexidade (Lei de Tesler)](#a-lei-da-conservação-da-complexidade-lei-de-tesler) + * [A Lei das Abstrações Gotejantes](#a-lei-das-abstrações-gotejantes) + * [A Lei da Trivialidade](#a-lei-da-trivialidade) + * [A Filosofia Unix](#a-filosofia-unix) + * [O Modelo Spotify](#o-modelo-spotify) + * [Lei de Wadler](#lei-de-wadler) + * [Lei de Wheaton](#lei-de-wheaton) +* [Princípios](#princípios) + * [O Princípio Dilbert](#o-princípio-dilbert) + * [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020) + * [O Princípio de Peter](#o-princípio-de-peter) + * [O Princípio da Robustez (Lei de Postel)](#o-princípio-da-robustez-lei-de-postel) + * [SOLID](#solid) + * [O Princípio da Responsabilidade Única](#o-princípio-da-responsabilidade-única) + * [O Princípio do Aberto/Fechado](#o-princípio-do-abertofechado) + * [O Princípio da Substituição de Liskov](#o-princípio-da-substituição-de-liskov) + * [O Princípio da Segregação de Interface](#o-princípio-da-segregação-de-interface) + * [O Princípio da Inversão de Dependência](#o-princípio-da-inversão-de-dependência) + * [O Princípio DRY](#o-princípio-dry) + * [O Princípio KISS](#o-princípio-kiss) + * [YAGNI](#yagni) + * [As Falácias da Computação Distribuída](#as-falácias-da-computação-distribuída) +* [Lista de leitura](#lista-de-leitura) +* [Traduções](#traduções) +* [Projetos relacionados](#projetos-relacionados) +* [Contribuindo](#contribuindo) +* [Em construção](#em-construção) + + + +## Introdução + +Existem muitas leis sobre as quais as pessoas discutem quando falam sobre desenvolvimento. Este repositório é uma referência e uma visão global das mais comuns. Sinta-se a vontade para contribuir e compartilhar. + +❗: Este repositório contém explicações sobre algumas leis, princípios e padrões, mas não _advoga_ nenhum. Se eles devem ser aplicados é uma questão de discussão, e depende diretamente no que você está trabalhando. + +## Leis + +E lá vamos nós! + +### Princípio 90-9-1 (Regra do 1%) + +[1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)) + +O Princípio 90-9-1 sugere que em uma comunidade da internet, como uma wiki, 90% dos participantes apenas consomem o conteúdo, 9% editam ou modificam o conteúdo e 1% dos participantes adicionam novos conteúdos. + +Exemplos do mundo real: + +- Um estudo de 2014 de quatro redes sociais de saúde digital concluíram que 1% dos usuários criaram 73% das publicações, os próximos 9% foram responsáveis por cerca de ~25% e os 90% restantes por uma média de 2% ([Referência](https://www.jmir.org/2014/2/e33/)) + +Veja também: + +- [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020) + +### Lei de Amdahl + +[Lei de Amdahl na Wikipédia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl) + +> A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967. + +Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processaores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma. + +O diagrama abaixo mostra alguns exemplos de melhoria na velocidade: + +![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)* + +Como pode-se perceber, mesmo um programa que teve metade da sua implementação de forma paralela, o benefício é menos de 10 _processing units_. Porém, um programa 95% paralelo, o ganho pode passar de 20 _processing units_. + +### Teoria das Janelas Quebradas + +[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory) + +A Teoria das Janelas Quebradas sugere que sinais visíveis de crimes (ou a falta de cuidado por um ambiente) leva a crimes mais sérios (ou mais deterioração do ambiente). + +Essa teoria tem sido aplicada no desenvolvimento de software, sugerindo que a baixa qualidade do código (ou o [Débito Técnico](#TODO)) podem levar a percepção de que esforços para melhorar a qualidade talvez sejam ignorados ou desvalorizados, mantendo a baixa qualidade. Esse efeito de cascata leva a uma grande diminuição na qualidade através do tempo. + +Veja também: + +- [Débito Técnico](#TODO) + +Exemplos: + +- [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/) + +### Lei de Brook + +[Lei de Brooks na Wikipeia](https://en.wikipedia.org/wiki/Brooks%27s_law) + + +> Adicionar recursos humanos em um projeto, de desenvolvimento de sotware, atrasado, faz ficar ainda mais atrasado. + +Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adcionando mais pessoas atrasa ainda mais essa entrega. Brooke assume que essa afirmação é uma generalização excessiva, entretanto, o principal motivo para isso acontecer é dado pelo simples fato de adicionar pessoas requer um gasto com comunicação e construção de novos recursos para a equipe suportar novos membros. Logo, a curto prazo esse investimento não tem um retorno. Também existem tarefas que não podem ser dividias, portanto adicionar mais pessoas não vai fazer ela ser concluida mais rápido. + +"Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooke, principalmente porque algumas tarefas nao podem ser divididas. + + +Esse é um tema central do livro '[The Mythical Man Month](#lista-de-livros)'. + +Veja também: + +- [Death March](#em-progresso) +- [Livro: The Mythical Man Month](#lista-de-livros) + +### Lei de Conway + +[Lei de Conway na wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law) + +Essa lei sugere que limites técnicos de um sistema refletirão na estrutura da organização. Se uma organização é estruturada em pequenos setores, desconexas unidades, o sofware que ela produz sera assim também. Se uma organização é construida de forma vertical, em torno de funcionalidades e serviços, terá reflexo disso dentro do sistema. + +Veja também: + +- [Modelo do Spotify](#modelo-spotify) + +### Lei de Cunnigham + +[Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law) + +> A melhor forma de obter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada. + +De acordo com Steven McGeady, Ward Cunningham o aconselhou no início dos anos 80: "A melhor forma de ter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada." McGeady apelidou essa lei de "Lei de Cunningham", mesmo que Cunningham negue sua propriedade chamando-a de "citação". Mesmo originalmente se referindo a interações na Usenet, a lei tem sido utilizada para descrever como comunidades online funcionam (e.x.: Wikipedia, Reddit, Twitter, Facebook). + +Veja também: + +- [XKCD 386: "Duty Calls"](https://xkcd.com/386/) + +### Número de Dunbar + +[Número de Dunbar na Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number) + +Dunbar propós que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebiba se esbarrase com ela em um bar". Esse número geralmente está entra 100 e 250. + +Esse número é uma sugestão cognitiva limite para o número de pessoass para qual consegue-se manter uma relação social estável. + +Como uma relação entre pessoas, manter uma relação entre desenvolvedor e codigo requer esforço. É necessário usar politicas, padrões e procedimentos para encarar projetos complicados ou qualquer adversidade possível nesse tipo de relação. Número de Dunbar é importante em vários aspectos, não somente quando a empresa está em crescimento, mas também ao definir o escopo para os esforços da equipe ou decidir quando u msistema deve investir em ferramentas para axuliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingresssar em uma rotação de plantão de suporte. + +Veja também: + +- [Lei de Conway](#lei-de-conway) + +### Lei de Gall + +[Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) + +> Um sistema complexo que funciona é invariavelmente encontrado para ter evoluído a partir de um sistema simples que trabalhou. Um sistema complexo projetado a partir do zero nunca funciona e não pode ser remendado para fazê-lo funcionar. + +A Lei de Gall afirma que tentativas de projetar sistemas altamente complexos provavelmente falharão. Sistemas altamente complexos raramente são construídos em uma vez só, mas evoluem a partir de sistemas mais simples. + +Um exemplo clássico é a world-wide-web. Em seu estado atual, ela é um sistema altamente complexo. Contudo, ela foi definida inicialmente como uma forma simples de compartilhar conteúdo entre instituições acadêmicas. Ela foi tão bem-sucedida em atingir esses objetivos que evoluiu para se tornar algo mais complexo ao longo do tempo. + +Veja também: + +- [KISS (Keep It Simple, Stupid)](#o-princípio-kiss) + +### Lei de Goodhart + +[The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law) + +> Qualquer regularidade estatística observada tende a entrar em colapso quando a pressão é aplicada para fins de controle. +> +> _Charles Goodhart_ + + +Também referenciada como: + +> Quando uma medida torna-se uma meta (ou alvo), ela deixa de ser uma boa medida. +> +> _Marilyn Strathern_ + +A lei diz que otimizações orientadas por medidas podem levar à uma desvalorização do próprio resultado da medição. O conjunto de medidas excessivamente seletivo ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) aplicado cegamenta a um processo resulta em um efeito distorcido. As pessoas tentem a otimizar localmente "jogando com" o sistema para satisfazer métricas específicas ao invés de prestar atenção ao resultado holístico de suas ações. + +Exemplos do mundo real: +- Testes sem `assertions` atendem à cobertura de código esperada, apesar do objetivo da métrica era criar software bem testado +- A pontuação do desempenho de desenvolvedores é indicada pelo número de linhas `commitadas` leva a uma base de código injustificadamente inchada. + +Veja também: +- [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) + +### Navalha de Hanlon + +[Navalha de Hanlon na wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor) + +> Nunca atribua à malícia aquilo que é adequadamente explicado por estupidez. +> +> Robert J. Hanlon + +Esse principio sugeste que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuido à ações que não foram totalmente entendidas. + +### Lei de Hofstadter + +[Lei de Hofstadter na Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law) + + +> Sempre leva mais tempo do que esperado, mesmo quando se leva em conta a lei do Hofstadter. +> +> Douglas Hofstadter + +Você já deve ter ouvido sobre essa lei quando se fala em estimar tempo para fazer algo. Quando se fala em desenvolvimento de software parece obvio que nós tendemos a não sermos muitos precisos em estimar quando tempo levará para entregar alguma coisa. + +This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-livros)'. + +### Lei de Hutber + +[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) + +> Melhoria significa deterioração. +> +> _([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))_ + +Essa lei sugere que melhorias em um sistema irão levar à deterioração em outras partes, ou ela ocultarão outras deteriorações, levando a uma degradação do estado atual do sistema. + +Por exemplo, a diminuição na latência da resposta para um `end-point` particular pode causar um aumento na taxa de transferência e na capacidade ao longo de um fluxo de solicitação, afetando um subsistema totalmente diferente. + + +### O Ciclo Hype e Lei de Amara + +[The ciclo Hype on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle) + +> Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo. +> +> 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) + +*(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 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 (Lei das Interfaces Implícitas) + +[Lei de Hyrum site](http://www.hyrumslaw.com/) + +> Com um número suficientes de clientes de uma API, +> não importa a sua pré-condição no contato: +> todos os comportamentos observáveis do seu sistema +> serão dependentes de alguém. +> +> Hyrum Wright + +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: + +- [XKCD 1172](https://xkcd.com/1172/) + + +### Lei de Kernighan + +> A depuração é duplamente mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o sufiencte para depurá-lo. +> +> Brian Kernighan + +A Lei de Kerningham é nomeada por [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) e devivada de uma citação de Kerningham no livro [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style): + +> Todo mundo sabe que depurar é duplamente mais difícil do que programar em primeiro lugar. Então, se você é o mais inteligente possível quando escreve, como você conseguirá depurar o código? + +Enquanto hiperbólica, a Lei de Kerningham faz a argumentação de que código simples deve ser preferido ao invés de código complexo, porque depurar qualquer problema que poderá surgir em um código complexo pode ser custoso ou até mesmo inviável. + +Veja também: + +- [Princípio KISS](#o-princípio-kiss) +- [Filosofia Unix](#a-filosofia-unix) +- [Navalha de Occam](#navalha-de-occam) + + +### Lei de Metcalfe + +[Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law) + +> Na teoria das redes, o valor de um sistema cresce aproximadamente o quadrado do número de usuários daquele sistema. + +Esta lei é baseada no número de possíveis conexões pareadas dentro de um sistema e é relacionada com a [Lei de Reed](#lei-de-reed). Odlyzko e outros argumentaram que tanto a Lei de Reed e a Lei de Metcalfe exageram o valor do sistema, não levando em consideração os limites da cognição humana sobre os efeitos da rede; veja [Número de Dunbar](#número-de-dunbar). + +Veja também: +- [Lei de Reed](#lei-de-reed) +- [Número de Dunbar](#número-de-dunbar) + +### Lei de Moore + +[Lei de Moore na wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law) + +> O número de transistores dentro de um circuito integrado dobra a cada 2 anos, aproximadamente. + + +Até meados de 1965 não havia nenhuma previsão real sobre o futuro do hardware, quando Gordon E. Moore fez sua profecia, na qual o número de transistores dos chips teria um aumento de 100%, pelo mesmo custo, a cada período de 18 meses. Essa profecia tornou-se realidade e acabou ganhando o nome de Lei de Moore. + +Esta lei serve de parâmetro para uma elevada gama de dispositivos digitais, além das CPUs. Na verdade, qualquer chip está ligado a lei de Gordon E. Moore, até mesmo o CCD de câmeras fotográficas digitais (sensor que capta a imagem nas câmeras nuclear; ou CNCL, sensores que captam imagens nas câmeras fotográficas profissionais). + +Esse padrão continuou a se manter, e não se espera que pare até, no mínimo, 2021. + +### Lei de Murphy / Lei de Sod + +[Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law) + +> Tudo que poderá dar errado, irá dar errado. + +Relacionada com [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.), a _Lei de Murphy_ diz que se algo pode dar errado, isso dará errado. + +Isso é um ditado comum entre desenvolvedores. Muitas vezes o inesperado ocorre durante o desenvolvimento, testes ou até mesmo em produção. Essa lei também pode ser relacionada a Lei de Sod (mais comum no inglês britânico): + +> Se algo pode dar errado, dará errado, no pior momento possível. + +Essas 'leis' são geralmente utilizadas em um sentido cômico. Contudo, fenômenos como [_Confirmation Bias_](#TODO) e [_Selection Bias_](#TODO) podem pevar as pessoas a enfatizarem demais essas leis (na maioria das vezes quando as coisas funcionam, elas passam desapercebidas, as falhas são mais perceptíveis e atraem mais discussões). + +Veja também: + +- [Confirmation Bias](#TODO) +- [Selection Bias](#TODO) + +### Navalha de Occam + +[Navalha de Occam on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor) + +> Entidades não devem ser multiplicadas sem necessidade. +> +> William of Ockham + +A Navalha de Occam diz que em meio a várias possíveis soluções, a solução mais provável é aquela com menor número de conceitos e suposições. Essa solução é a mais simples e envolve apenas o problema em questão, sem introduzir complexidades acidentais e possíveis consequências negativas. + +Veja também: + +- [YAGNI](#yagni) +- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet) + +Exemplo: + +- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) + +### Lei de Parkinson + +[Lei de Parkinson](https://en.wikipedia.org/wiki/Parkinson%27s_law) + +>O trabalho se expande de modo a preencher o tempo disponível para a sua realização. + +A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso].Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final. + +### Efeito de Otimização Prematura + +[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) + +> Otimização prematura é a raiz de todo o mal. +> +> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) + +No artigo de Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: **otimização prematura é a raiz de todo o mal.** No entando, não devemos perder a oportunidade nesses 3% críticos". + +Contudo, _Otimização Prematura_ pode ser definida (em termos menos carregados) como otimizar antes de saber o que precisamos. + +### Lei de Putt + +[Lei de Putt na wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) + +> Tecnologia é dominada por dois tipos de pessoa. Aqueles que entendem o que não gerenciam e aqueles que gerenciam o que não entendem. + +A Lei de Putt é frequentemente seguida pelo Corolário de Putt: + +> Cada hierarquia técnica, no tempo, desenvolve uma inversão de competência. + +Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como (#em-progresso) + +Veja também: + +- [Principio de Peter](#o-princípio-de-peter) +- [Princípio de Dilbert](#o-princípio-dilbert) + +### Lei de Reed + +[Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law) + +> A utilidade de grandes redes, particularmente redes sociais, escalam exponencialmente com o tamanho da própria rede. + +Essa lei é baseada na teoria dos grafos, onde a utilidade é escalonada com o número de possíveis subgrupos, que é mais rápido que o número de participantes ou o número de possíveis conexões pareadas. Odlyzko e outros argumentam que a Lei de Reed exagera a utilidade de um sistema por não levar em conta os limites da cognição humana sobre os efeitos da rede; veja [Número de Dunbar](#número-de-dunbar). + +Veja também: +- [Lei de Metcalfe](##lei-de-metcalfe) +- [Número de Dunbar](#número-de-dunbar) + +### A Lei da Conservação da Complexidade (Lei de Tesler) + +[A lei da Conservação de Complexidade na wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) + +Essa lei sugere que em todos sitemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida. + +Alguma complexidade em um sistema é "inadvertida". É uma consequência da estrutura deficiente, erros ou apenas má modelagem de um problema a ser resolvido. A complexidade inadvertida pode ser reduzida (ou eliminada). No entanto, alguma complexidade é "intrínseca" como consequência da complexidade inerente ao problema a ser resolvido. Essa complexidade pode ser movida, mas não eliminada. + +Um elemento interessante para essa lei é a sugestão de que, mesmo simplificando todo o sistema, a complexidade intrínseca não é reduzida, ela é “movida para o usuário”, que deve se comportar de uma maneira mais complexa. + +### A Lei das Abstrações Gotejantes + +[The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) + +>Todas as abstrações não triviais, até certo ponto, são vazadas + +Essa lei afirma que abstrações, as quais são geralmente utilizadas na computação para simplificar um trabalho com sistemas complexos, em certas situações irão 'vazar' elementos do sistema subjacente, fazendo com que a abstração se comporte de maneira inesperada. + +Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significamente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente. + +O exemplo acima pode se tormar mais complexo quando _mais_ abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas. + +Veja também: + +- [Lei de Hyrum](#lei-de-hyrum-lei-das-interfaces-implícitas) + +Exemplos do mundo real: + +- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entando, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A _abstração_ de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade. + +### A Lei da Trivialidade + +[The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) + +Essa lei sugere que grupos irão dar maior atenção para problemas triviais ou cosméticos, do que para os problemas sérios e substanciais. + +O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entando, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular. + +O exemplo fictício acima levou ao uso do termo _'Bike Shedding'_ como uma expressão por gastar tempo em detalhes triviais. + + +### A Filosofia Unix + +[The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy) + +A Filosofia Unix prega que componentes de um software devem ser pequenos, e focados em fazer muito bem uma coisa específica. Isso torna mais fácil a construção de sistemas compondo unidades pequenas, simples e bem definidas, em vez de usar programas grandes, complexos e multiuso. + +Práticas modernas como a 'Arquitetura de Microsserviços' podem ser pensadas como uma aplicação dessa lei, onde os serviços são pequenos, focados em uma tarefa específica, permitindo que um comportamento complexo seja composto de blocos de construção simples. + +### O Modelo Spotify + +[The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) + +O Modelo Spotify é uma abordagem para a organização de equipes que foi popularizado pelo 'Spotify'. Neste modelo, times são organizados por funcionalidades, não por tecnologias. + +O Modelo Spotify também popularizou o conteido de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional. + +### Lei de Wadler + +[Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) + +> Em qualquer design de linguagem, o tempo total gasto discutindo a uma funcionalidade nessa lista é proporcional a dois elevados à potência de sua posição. +> +> 0. Semântica +> 1. Sintaxe +> 2. Sintaxe léxica +> 3. Sintaxe léxica de comentários +> +> (Em resumo, para cada hora gasta em semântica, 8 horas serão gastas na sintaxe de comentários) + +Semelhante à [Lei da Trivialidade](#a-lei-da-trivialidade), a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a imporância dessas funcionalidades. + +Veja também: + +- [The Law of Triviality](#the-law-of-triviality) + +### Lei de Wheaton + +[The Link](http://www.wheatonslaw.com/) + +[The Official Day](https://dontbeadickday.com/) + +> Não seja um babaca +> +> _Wil Wheaton_ + +Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros ponto de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si. + +## Princípios + +Os princípios são como diretrizes relacionadas à design. + +### O Princípio Dilbert + +[The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle) + +> Empresas tendem a promover sistematicamente funcionários incompetentes para a gerência para tirá-los do fluxo de trabalho. +> +> _Scott Adams_ + +Um conceito de gerência desenvolvido por Scott Adams (criador da tirinha Dilbert), o Princípio de Dilbert é inspirado pelo [Princípio de Peter](#o-princípio-de-peter). Sob o Princípio de Dilbert, funcionários que nunca foram competentes são promovidos para a gerência, para limitar o estrago que eles podem causar. Adams explicou esse princípio pela primeira vez um artigo no Wall Street Journal, em 1995, e o expandiu para seu livro de negócios em 1996, o [The Dilbert Principle](#lista-de-leitura). + +Veja também: + +- [Princípio de Peter](#o-princípio-de-peter) +- [Lei de Putt](#lei-de-putt) + +### O Princípio de Pareto (Regra do 80/20) + +[The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle) + +> A maioria das coisas na vida não são distribuídas de maneira uniforme. + +O Princípio de Pareto sugere que em alguns casos, a maioria dos resultados vem de uma minoria de insumos: + +- 80% de um certo pedaço de software pode ser escrito em 20% do tempo total alocado (inversamente, os 20% mais difíceis do código levam 80% do tempo) +- 20% do esforço produz 80% do resultado +- 20% do trabalho cria 80% da receita +- 20% dos bugs causam 80% das quebras +- 20% das funcionalidades causam 80% da utilização + +Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, [começou a aplicar o Princípio de Pareto a questões de qualidade]((https://en.wikipedia.org/wiki/Joseph_M._Juran)). + +Este princípio é também conhecido como: A Regra do 80/20, A Lei dos Poucos Vitais e O Princípio de Escassez do Fator. + +Exemplos do mundo real: + +- Em 2002 a Microsoft reportou que corrigindo 20% dos erros mais reportados, 80% dos erros e quebras relacionadas no Windows e no Office foram eliminados ([Referência](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). + +### O Princípio de Peter + +[The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle) + +> Pessoas em uma hierarquia tentem a subir ao seu "nível de incompetência". +> +> _Laurence J. Peter_ + +Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige. + +Isso é de interesse particular para engenheiros - que inicialmente começam em funções técnicas mas tem uma carreira que leva ao _gerenciamento_ de outros engenheiros - o que requer um conjunto de habilidades fundamentalmente diferente. + +Veja também: + +- [The Dilbert Principle](#the-dilbert-principle) +- [Putt's Law](#putts-law) + +### O Princípio da Robustez (Lei de Postel) + +[The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) + +> Seja conservador naquilo que você faz, seja liberal naquilo que você aceita dos outros. + +Geralmente aplicado no desenvolvimento de aplicativos para servidor, esse princípio afirma que o que você envia para outras pessoas deve ser o mínimo compatível possível, mas que você deve ter como objetivo permitir entradas fora de conformidade, se puderem ser processadas. + +O objetivo desse princípio é construir sistemas que são robustos, pois eles conseguem lidar com dados mal formatados se a intenção ainda puder ser entendida. No entanto, há potenciais implicações de segurança na aceitação de entradas mal formatadas, principalmente se o processamento dessas entradas não for bem testado. + +### SOLID + +É um acrônimo para: + +* S: [The Single Responsibility Principle](#the-single-responsibility-principle) +* O: [The Open/Closed Principle](#the-openclosed-principle) +* L: [The Liskov Substitution Principle](#the-liskov-substitution-principle) +* I: [The Interface Segregation Principle](#the-interface-segregation-principle) +* D: [The Dependency Inversion Principle](#the-dependency-inversion-principle) + +Esses são os princípios-chave da [Programação Orientada a Objetos](#todo). Os princípios de design como esses devem ajudar os desenvolvedores a criarem sistemas mais sustentáveis. + +### O Princípio da Responsabilidade Única + +[The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle) + +> Cada módulo ou classe deve possuir apenas uma única responsabilidade. + +O primeiro dos princípios '[SOLID](#solid)'. Esse princípio sugere que módulos ou classes devem fazer apenas uma única coisa. Em termos mais práticos, isso significa que uma mudança simples a uma funcionalidade de um programa deve exigir uma mudança em apenas um componente. Por exemplo, mudar como uma senha é validada por complexidade deve exigir uma mudança em apenas uma parte do programa. + +Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade siginfica que o _teste_ deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades. + +Veja também: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) + +### O Princípio do Aberto/Fechado + +[The Open/Closed Principle on Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) + +> Entidades devem estar aberta para extensão e fechadas para modificação + +O segundo princípio do '[SOLID](#solid)'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento _extendido_, mas que o comportamento já existente não poderá ser alterado. + +Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser extendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo _não_ pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará _fechado_ para modificações. + +Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente extendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas. + +Veja também: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) + +### O Princípio da Substituição de Liskov + +[The Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle) + +> Deve ser possível trocar um tipo por um subtipo, sem o sistema apresentar quebras. + +O terceiro princípio '[SOLID](#solid)'. O princípio afirma que se um componente confia em um tipo, então ele deverá estar apto para utilizar subtipos daquele tipo, sem que o sistema falhe ou que ele conheça os detalhes daquele subtipo. + +Como um exemplo, imagine que temos um método que lê um documento XML de uma estrutura que representa um arquivo. Se o método utiliza a base de um tipo 'arquivo', então qualquer coisa que seja derivada de 'arquivo' poderá ser utilizada na função. Se 'arquivo' suporta busca recursiva, e o interpretador de XML utiliza essa função, mas o tipo derivado 'arquivo de rede' falha quando tenta uma busca recursiva, então o tipo 'arquivo de rede' estaria violando o princípio. + +Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para envitar confusão entre usuaríos do sistema. + +Veja também: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) + +### O Princípio da Segregação de Interface + +[The Interface Segregation Principle on Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle) + +> Nenhum cliente deverá ser forçado a depender de métodos que ele não utilize. + +O quarto princípio do '[SOLID](#solid)'. Esse princípio afirma que os consumidores de um componente não devem depender de funções daquele componente, as quais eles atualmente não usem. + +Como um exemplo, imagine que um método lê um documento XML de uma estutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado. + +Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para [minimizar o acomplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que enforça esse princípio, eliminando interfaces explícitas. + +Veja também: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) +- [Duck Typing](#todo) +- [Decoupling](#todo) + +### O Princípio da Inversão de Dependência + +[The Dependency Inversion Principle on Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle) + +> Módulos de alto nível não devem ser dependentes de implementações de baixo nível. + +O quinto conceito do '[SOLID](#solid)'. Esse princípio afirma que componentes + +Como um exemplo, imagine que temos um programa que lê os metadados de um website. Nós devemos assumir que o componente principal precisa conhecer um componente que irá baixar a página, depois um outro componente que irá ler os metadados. Se fôssemos levar a inversão de dependências em conta, o componente principal deveria depender apenas de um componente abstrato que pode buscar pelos bytes, e depois outro componente abstrato que irá ler os metadados de um fluxo de bytes. O componente principal não sabe nada sobre TCP/IP, HTTP, HTML, etc. + +Esse princípio é complexo, pois pode "inverter" as dependências esperadas de um sistema (daí o nome). Na prática, isso também significa que um componente de orquestração separado deve garantir que as implementações corretas dos tipos abstratos sejam usadas (por exemplo, no caso anterior, _algo_ ainda deve fornecer ao componente de leitura dos de metadados um downloader de arquivos HTTP e um leitor de metatags HTML). Isso toca em padrões como [Inversão de controle](#todo) e [Injeção de dependência](#todo). + +Veja também: + +- [Object-Oriented Programming](#todo) +- [SOLID](#solid) +- [Inversion of Control](#todo) +- [Dependency Injection](#todo) + +### O Princípio DRY + +[The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) + +> Cada pedaço de código deve possuir uma representação única, inequívoca e autoritária dentro de um sistema. + +DRY é um acrônimo para _**D**on't **R**epeat **Y**ourself_ (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer). + +> O oposto de DRY seria WET (Write Everything Twice or We Enjoy Typing) - (Escreva tudo duas vezes ou Nós gostamos de digitar). + +Na prática, se você tem o mesmo pedaço de informação em dois (ou mais) lugares diferentes, você pode utilizar o DRY para centralizá-los em um único lugar, e reutilizar a informação onde necessário. + +Veja também: + +- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) + +### O Princípio KISS + +[KISS on Wikipedia](https://en.wikipedia.org/wiki/KISS_principle) + +> Mantenha simples, idiota + +KISS é um acrônimo para _**K**eep **i**t **s**imple, **s**tupid_. O princípio afirma que a maioria dos sistemas trabalham melhor se eles são mantidos simples ao invés de complicados. Portanto, simplicidade deve ser um objetivo no design, e complexidades desnecessárias devem ser evitadas. Originada na Marinha Americana em 1960, a frase foi associada com o engenheiro de aeronaves Kelly Johnson. + +O princípio é melhor exemplificado pela história de Johnson entregando a uma equipe de engenheiros de projeto algumas ferramentas, com o desafio de que as aeronaves a jato que estavam projetando deveriam ser reparadas por um mecânico comum em campo sob condições de combate apenas com essas ferramentas. Portanto, o "estúpido" refere-se à relação entre a maneira como as coisas quebram e a sofisticação das ferramentas disponíveis para repará-las, e não as capacidades dos próprios engenheiros. + +Veja também: + +- [Lei de Gall](#lei-de-gall) + +### YAGNI + +[YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) + +É um acrônimo para _**Y**ou **A**ren't **G**onna **N**eed **I**t_ - Você não vai precisar disto. + +> Sempre implemente as coisas quando você de fato precisar delas, nunca quando você prevê que precisará delas. +> +> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder e autor do livro "Extreme Programming Installed") + +Este princípio da _Extreme Programming_ (XP) sugere que os desenvolvedores apenas devem implementar funcionalidades quando elas forem necessárias, e evitar tentativas de prever o futuro e implementar uma funcionalidade que talvez seja necessária. + +Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo disperdiçados em funcionalidades que não agregam valor. + +Veja também: + +- [Reading List: Extreme Programming Installed](#lista-de-leitura) + +### As Falácias da Computação Distribuída + +[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) + +Também conhecidas como as _Falácias da Computação em rede_, as Falácias são uma lista de conjecturas (ou crenças) sobre a computação distribuídas, que podem levar a falhas no desenvolvimento de software. As suposições são: + +- A rede é confiável +- A latência é zero +- A largura de banda é infinita +- A rede é segura +- A topologia não muda +- Existe apenas um administrador +- Custo de transporte é zero +- A rede é homogênea + +Os primeiro quatro itens foram listados por [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) e [Tom Lyon](https://twitter.com/aka_pugs) por volta de 1991, e foram classificados por [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) como as "Falácias da Computação de rede". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) adicionou os itens 5, 6 e 7. No final dos anos 90, Gosling adicionou o item 8. + +O grupo foi inspirado pela situação que corria na época dentro da [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems). + +Essas falácias devem ser consideradas com cuidado ao projetar um código que seja resiliente; supondo que qualquer uma dessas falácias possa levar a uma lógica defeituosa que falha em lidar com as realidades e complexidades dos sistemas distribuídos + +Veja também: + +- [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) + +## Lista de leitura + + +Se você achou esses conceitos interessantes, você provavelmente vai gostar dos seguintes livros. + +- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Cobre os principais princípios do Extreme Programming. +- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Um volume clássico na engenharia de software. A [Lei de Brook](#brooks-law) é o tema central desse livro. +- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Esse livre é difícil de classificar. A [Lei de Hofstadter](#hofstadters-law) é desse livro. +- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Um olhar cômico sobre a América corporativa, do autor que criou o [Princípio Dilbert](#the-dilbert-principle). +- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Outro olhar cômico sobre os desafios de grandes organizações e sobre a gestão de pessoas, a fonte do [Princípio de Peter](#the-peter-principle). + +## Traduções + +Graças a contribuidores maravilhosos, Hacker Laws está disponível em vários idiomas. Por favor, considere em patrocinar os moderadores! + +| Idioma | Moderador | Status | +|----------|-----------|--------| +| [🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)](https://gitlocalize.com/repo/2513/id?utm_source=badge) | +| [🇧🇷 Português Brasileiro / Brazilian Portuguese](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [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) | Parcialmente completa | +| [🇩🇪 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](./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) | +| [🇬🇷 ελληνικά / 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) | Parcialmente completa | +| [🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)| [![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](https://gitlocalize.com/repo/2513/ja?utm_source=badge) | +| [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Parcialmente completa | +| [🇱🇻 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) | Parcialmente completa | +| [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Parcialmente completa | +| [🇹🇷 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) | + +Se você quer atualizar uma tradução, [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare). Se você quer adicionar um novo idioma, crie uma conta no [GitLocalize](https://gitlocalize.com/), depois abra uma issue pedindo ao administrador o idioma eu irei adicionar você no projeto! Seria muito útil se você conseguir abrir uma pull request que atualiza a tabela acima, adicionando link ao topo do arquivo. + +## Projetos relacionados + +- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receba diaramente uma lei ou princípio hacker. +- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Liste e visualize as leis de maneira aleatória no seu terminal! + +## Contribuindo + +Por favor, contribua! [Abra uma issue](https://github.com/dwmkerr/hacker-laws/issues/new) se você deseja ver aqui algum conteúdo novo, sugerir uma alteração/correção, ou então [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare) e proponha suas próprias modificações. + +Certifique-se de ler as [Diretrizes de Contribuição](../.github/contributing.md) para saber sobre os padrões de texto, estilo etc. Esteja ciente do [Código de Conduta](../.github/CODE_OF_CONDUCT.md) ao participar de discussões sobre o projeto. + +## Em construção + +Olá! Se você parou aqui, clicou em um link para um tópico que não foi escrito ainda. Desculpe por isso, este trabalho está em andamento! + +Sinta-se livre para [abrir uma issue](https://github.com/dwmkerr/hacker-laws/issues) solicitando mais detalhes, ou [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare) para submeter suas modificações. diff --git a/translations/tr.md b/translations/tr.md new file mode 100644 index 00000000..4ce69184 --- /dev/null +++ b/translations/tr.md @@ -0,0 +1,892 @@ +# 💻📖 hacker-laws + +Programcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler. + +[Çeviriler](#%C3%A7eviriler): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/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) [🇯🇵](./translations/jp.md) + +Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors/dwmkerr) düşünün! + +--- + + + +- [Giriş](#giri%C5%9F) +- [Yasalar](#yasalar) + - [90–9–1 Prensibi (1% Kuralı)](#9091-prensibi-1-kural%C4%B1) + - [Amdahl Yasası](#amdahl-yasas%C4%B1) + - [Kırık Camlar Teorisi](#the-broken-windows-theory) + - [Brooks Yasası](#brooks-law) + - [CAP Teorisi (Brewer Teorisi)](#cap-teroisi-brewer-teorisi) + - [Conway Yasası](#conways-law) + - [Cunningham Yasası](#cunninghams-law) + - [Dunbar Sayısı](#dunbars-number) + - [Fitt Yasası](#fitt-yasas%C4%B1) + - [Gall Yasası](#galls-law) + - [Goodhart Yasası](#goodharts-law) + - [Hanlon'un Usturası](#hanlons-razor) + - [Hick Yasası (Hick-Hyman Yasası)](#hick-yasas%C4%B1-hick-hyman-yasas%C4%B1) + - [Hofstadter Yasası](#hofstadters-law) + - [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ı](#kernighans-law) + - [Metcalfe Yasası](#metcalfes-law) + - [Moore Yasası](#moores-law) + - [Murphy Yasası / Sod Yasası](#murphys-law--sods-law) + - [Occam'ın Usturası](#occams-razor) + - [Parkinson Yasası](#parkinsons-law) + - [Olgunlaşmamış Optimizasyon Etkisi](#premature-optimization-effect) + - [Putt Yasası](#putts-law) + - [Reed Yasası](#reeds-law) + - [Karmaşıklığın Korunması Yasası (Tesler Yasası)](#the-law-of-conservation-of-complexity-teslers-law) + - [Demeter Yasası](#demeter-yasas%C4%B1) + - [Sızdıran Soyutlamalar Yasası](#the-law-of-leaky-abstractions) + - [Önemsizlik Yasası](#the-law-of-triviality) + - [Unix Felsefesi](#the-unix-philosophy) + - [Spotify Modeli](#the-spotify-model) + - [Wadler Yasası](#wadlers-law) + - [Wheaton Yasası](#wheatons-law) +- [Prensipler](#principles) + - [Ölü Deniz Etkisi](#%C3%B6l%C3%BC-deniz-etkisi) + - [Dilbert Prensibi](#the-dilbert-principle) + - [Pareto Prensibi (80/20 Kuralı)](#the-pareto-principle-the-8020-rule) + - [Peter Prensibi](#the-peter-principle) + - [Dayanıklılık Prensibi (Postel Yasası)](#the-robustness-principle-postels-law) + - [SOLID](#solid) + - [Tek Sorumluluk Prensibi](#the-single-responsibility-principle) + - [Açık/Kapalı Prensibi](#the-openclosed-principle) + - [Liskov Yerine Geçme Prensibi](#the-liskov-substitution-principle) + - [Arayüz Ayrım Prensibi](#the-interface-segregation-principle) + - [Bağımlılığın Ters Çevrilmesi](#the-dependency-inversion-principle) + - [DRY Prensibi](#the-dry-principle) + - [KISS prensibi](#the-kiss-principle) + - [YAGNI](#yagni) + - [Dağıtık Sistemlerin Yanılgıları](#da%C4%9F%C4%B1t%C4%B1k-sistemlerin-yan%C4%B1lg%C4%B1lar%C4%B1) +- [Ek Kaynaklar](#reading-list) +- [Çeviriler](#translations) +- [Katkıda Bulunmak İçin](#related-projects) +- [Katkıda Bulunmak İçin](#contributing) +- [TODO](#todo) + + + +## Giriş + +İnsanların geliştirme hakkında konuşurken tartıştıkları birçok yasa var. Bu depo, en yaygın olanlardan bazılarının referanslarını ve özetini barındırır. Katkıda bulunmak için PR açıp gönderebilirsiniz! + +❗: Bu depo yasaların, prensiplerin ve modellerin bilgi vermek amaçlı açıklamalarını içerir ve hiçbirini *savunma* amacı gütmez. Bunların hangisinin uygulanıp uygulanmayacağı tamamen tartışma konusudur ve yapılan işe bağlıdır.. + +## Yasalar + +Tek tek başlayalım! + +### 90–9–1 Prensibi (1% Kuralı) + +[Wikipedia'da 1% Kuralı](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)) + +90-9-1 prensibi der ki, bir internet topluluğunda (örneğin bir wiki) üyelerin %90'ı sadece içeriği okur, %9'u içeriği düzenleme ya da düzeltme yapar ve %1'i ise yeni içerik ekler. + +Gerçek dünyadan örnekler: + +- Dört dijital sağlık sosyal ağlarına ilişkin 2014 yılında yapılan bir araştırma, topluluğun %1'inin gönderilerin %73'ünü oluşturduğunu, %9'unun ortalama %25'ini ve geri kalan %90'ının da ortalama %2'sini oluşturduğunu buldu ([Referans](https://www.jmir.org/2014/2/e33/)). + +Ek kaynaklar: + +- [Pareto prensibi](#pareto-prensibi-8020-kural%C4%B1) + +### Amdahl Yasası + +[Wikipedia Amdahl Yasası](https://en.wikipedia.org/wiki/Amdahl%27s_law) + +> Amdahl Yasası kaynakları artırarak bir hesaplama işleminin *olası* hızlanma miktarını hesaplayan bir formülü tanımlar. Genellikle paralel işleme hesaplarında kullanılır ve işlemci sayısının artırılmasının programın paralelleştirilebilme kapasitesine bağlı olarak etkisinin doğru şekilde saplanmasını sağlar. + +En güzel şu örnekle anlatılabilir. Bir programın iki bölümden oluştuğunu düşünelim. Bölüm A sadece tek işlemci ile çalıştırılabilir. Bölüm B ise paralelleştirilebilecek şekilde yazılmış. Bu durumda bu programı çok işlemci ile çalıştırdığımızda Bölüm B'de oluşacak kadar bir kazanım sağlayabiliriz. Bölüm A'da her hangi bir katkı olamayacaktır. + +Aşağıdaki diyagram bazı olası hız geliştirmelerine örnekler içeriyor: + +Diagram: Amdahl's Law + +*(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)* + +Diyagramdaki örneklerden görüldüğü üzere, eğer bir programın sadece %50'si paralelleştirilebiliyorsa 10 işlemciden sonra işlemci eklemek hızda gözle görünür bir artış sağlamıyor ama %95 paralelleştirilebilen bir programda 1000 işlemciden sonra bile işlemci eklemenin hızı artırdığı gözlenebilir. + +[Moore Yasasında](#moores-law) söylenen artışın azalma eğiliminde olması ve aynı zamanda işlemci hızının artışında da ivme kaybı olması, paralelleştirilebilme özelliğini performans artışında anahtar duruma getirdi. Grafik programlama bu konuda en belirgin örnek. Shader tabanlı modern işleme ile pixel ve fragmanların paralel olarak render edilebilmesi sayesinde modern grafik kartlarında binlerce işlemci çekirdeği olabiliyor. + +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ç](#TODO) + +Ö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) + +> Gecikmesi kesinleşmiş projeye yeni insan kaynağı eklemek projeyi daha da geciktirir. + +Bu yasa, gecikmiş bir projeyi hızlandırmak için ek insan kaynağı koymanın projeyi daha geciktireceğini iddia ediyor. Brook'a göre bunun gereksiz bir sadeleştirme olduğu kesin. Yeni katılanların adapte edilmesi ve iletişim karmaşası hemen etkisini göstererek hızın yavaşlamasına sebep olur. Ayrıca, yapılacak işlerin birçoğu genellikle daha küçük parçalara bölünemez ve birden fazla kaynak bu işlerin yapılması için kullanılmaz. Bu durum beklenen artışın sağlanmaması ile sonuçlanır. + +Meşhur "Dokuz kadın ile 1 ayda doğum sağlanamaz" deyimi bu yasanın en pratik anlatımıdır. Bazı işlerin bölünemediği veya paralelleştirilemediği gerçeğini unutmamak lazım. + +'[The Mythical Man Month](#reading-list)' adlı kitabın ana konularından biri budur. + +Ek kaynaklar: + +- [Death March](#todo) +- [Reading List: The Mythical Man Month](#reading-list) + +### CAP Teorisi (Brewer Teorisi) + +CAP Teoremi (Eric Brewer tarafından tanımlanmıştır) dağıtılmış bir veri deposu için aşağıdaki üç garantiden sadece ikisinin (en fazla) sağlanabileceğini belirtmektedir: + +- Tutarlılık: verileri okurken, her istek verinin *en son* halini alır veya bir hata döndürülür +- Erişilebilirlik: veri okurken, her istek verinin *en son*hali olduğunu garanti etmeden *hata içermeyen bir yanıt* alır +- Parçalara Ayrılma Toleransı: Düğümler arasında belli bir sayıda ağ isteği başarısız olduğunda, sistem beklendiği gibi çalışmaya devam eder + +Tartışmanın özü şöyledir. Bir ağ paylaşımının olmayacağını garanti etmek imkansızdır (bkz. [Dağıtık Sistemlerin Yanılgıları ](#da%C4%9F%C4%B1t%C4%B1k-sistemlerin-yan%C4%B1lg%C4%B1lar%C4%B1)). Bu nedenle bir paylaşımlı yapı söz konusu olduğunda, işlemi iptal edebilir (tutarlılığı artırabilir ve kullanılabilirliği azaltabiliriz) veya devam edebiliriz (kullanılabilirliği artırabilir, tutarlılığı azaltabilir). + +Teorinin ismi, garanti edilmeye çalışılan kavramların ilk harflerinden (Consistency, Availability, Partition Tolerance) oluşturulmuştur. Bunun [*ACID*](#TODO) ile alakalı *olmayan* farklı bir tanımı olduğunu bilmenin çok önemli olduğunu unutmayın. Daha güncel olarak, ağın paylaşımlı *olmadığı* yapılarda (sistem beklendiği çalışmaya devam ederken) gecikmeye ve tutarlılığa bazı kısıtlamalar getiren [PACELC](#TODO) teoremi geliştirilmiştir. + +Çoğu modern veritabanı platformu, veritabanı kullanıcılarına yüksek düzeyde kullanılabilirlik ('kirli okuma' içerebilir) veya yüksek düzeyde tutarlık (örneğin 'yeterli çoğunlukla onaylanmış yazma') arasında seçim yapma seçeneği sunarak bu teoremi örtük olarak kabul eder. + +Gerçek dünyadan örnekler: + +- [Google Cloud Spanner ve CAP Teorisi](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) - İlk olarak CAP garantilerinin *hepsine* sahip gibi görünen, ancak kaputun altında bir CP sistemi olan Cloud Spanner'ın nasıl çalıştığının ayrıntıları anlatılıyor. + +Ek kaynaklar: + +- [ACID](#TODO) +- [Dağıtık Sistemlerin Yanılgıları](#the-fallacies-of-distributed-computing) +- [PACELC](#TODO) + +### Conway Yasası + +[Wikipedia'da Conway Yasası](https://en.wikipedia.org/wiki/Conway%27s_law) + +Conway yasası der ki; üretilen sistemler kendilerini üreten organizasyonun teknik sınırlarını yansıtır. Bu yasa daha çok organizasyon değişiklikleri sırasında dikkate alınır. Eğer bir organizasyon birbirinden bağımsız küçük birimlerden oluşuyorsa üretilen yazılımlar da buna uygun olacaktır. Eğer bu organizasyon servis odaklı dikey yapılandırılmışsa, yazılımlar bunu yansıtacaktır. + +Ek kaynaklar: + +- [Spotify Modeli](#the-spotify-model) + +### Cunningham Yasası + +[Wikipedia'da Cunningham Yasası](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law) + +> İnternette doğru cevabı almanın en iyi yolu, soru sormak değil, yanlış olan cevabı yazmaktır. + +Steven McGeady'ye göre, Ward Cunningham, 1980'lerin başında ona tavsiye olarak “İnternette doğru cevabı almanın en iyi yolu, bir soru sormak değil, yanlış olan cevabı yazmaktır” dedi. McGeady bunu Cunningham kanunu olarak adlandırdı, ancak Cunningham bu sahipliği bunun "yanlış bir alıntı" olduğunu nitelendirerek reddetti. Her ne kadar orjinalinde Usenet'teki etkileşimlerle ilgili olsa da, yasa diğer çevrimiçi toplulukların nasıl çalıştığını açıklamak için kullanılmıştır (örneğin, Wikipedia, Reddit, Twitter, Facebook). + +Ek kaynaklar: + +- [XKCD 386: "Duty Calls"](https://xkcd.com/386/) + +### Dunbar Sayısı + +[Wikipedia'da Dunbar Sayısı](https://en.wikipedia.org/wiki/Dunbar%27s_number) + +"Dunbar'ın sayısı, bir kişinin istikrarlı bir sosyal ilişkide bulunabileceği kişilerin sayısının kavramsal sınırıdır - bu ilişki bireyin ilişkide olduğu her bir kişinin kim olduğunu ve her bir kişinin diğer bir kişiler ile ilişkisini bildiği ilişkidir." Sayının tam değeri konusunda bir anlaşmazlık vardır. "... [Dunbar] insanların ancak 150 kişilik ilişkiler istikrarlı bir şekilde bulunabileceğini söylemiş."... Dunbar sayıyı daha sosyal bir bağlam içine koydu, "sayıyı bir barda içki içmeye davet edildiğinizde sıkılmadan ya da utanmadan kabul edebileceğiniz kişi sayısı olarak değerlendirdi". Bu da 100 ile 250 arasındaki bir sayı olarak düşünülebilir. + +Kişiler arası insani ilişkilerde olduğu gibi, insanlarla kod arasındaki ilişki de sürüdürülebilmek için çaba gerektirir. Karmaşık projelerle karşılaştığımızda ya da bu projeleri yönetmek sorunda kaldığımızda, projeyi ölçekleyebilmek için eğilimlere, politikalara ve modellenmiş prosedürlere yaslanmaya çalışırız. Dunbar sayısını sadece çalışan sayısı büyüdüğünde değil, takımın harcayacağı emeğin kapsamını belirlerken ya da sistemdeki lojistik ek yükün modellenmesine ve otomatikleştirilmesine yardımcı olmak için takımlara yatırım yaparken de göz önünde bulundurulmalıdır. Bir başka mühendislik bağlamında düşünürsek, bu sayı müşteri destek sisteminde nöbetçi olunurken sorumluluğunu alabileceğiniz proje/ürün sayısını belirlerken de rehber olabilir. + +Ek kaynaklar: + +- [Conway Yasası](#conways-law) + +### Fitt Yasası + +[Wikipedia'da Fitt Yasası](https://en.wikipedia.org/wiki/Fitts%27s_law) + +Fitts yasası, bir hedef alana gitmek için gereken sürenin hesaplanmasında, hedefe olan mesafenin hedefin genişliğine bölünmesinin bir işlevi olduğunu öngörür. + +The Hype Cycle + +*(Diagramın Kaynağı: By Foobar628 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)* + +Bu yasanın sonuçları, UX veya UI tasarlanırken etkileşimli öğelerin mümkün olduğunca büyük olması ve kullanıcıların dikkat alanı ile etkileşimli öğe arasındaki mesafenin mümkün olduğunca küçük olması gerektiğini ortaya çıkarır. Bunun tasarım üzerinde sonuçları vardır, örneğin birbirleriyle yakın kullanılan işlevlerin gruplanması gibi. + +Ayrıca, ekranın köşeleri için temel kullanıcı arayüzü öğelerinin yerleştirilebileceği 'sihirli köşeler' (bir kullanıcının farelerini kolayca vurabileceği ya da süpürebileceği) kavramını resmileştiriyor. Windows Başlat düğmesi sihirli bir köşede, seçmeyi kolaylaştırıyor ve ilginç bir kontrast olarak, MacOS'un 'pencereyi kapat' düğmesi sihirli bir köşede *değil*, yanlışlıkla tıklanmayı zorlaştırıyor. + +Ek kaynaklar: + +- [İnsan motor sisteminin hareket genliğini kontrol etme veri kapasitesi.](https://www.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d) + +### Gall Yasası + +[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.wikipedia.org/wiki/John_Gall_(author))) +> ([John Gall](https://en.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. + +En klasik örnek günümüzdeki internettir. Şu an çok karmaşık bir sistemdir. Aslında başlangıçta sadece akademik kurumlar arası içerik paylaşımı olarak tanımlanmıştı. Bu tanımı karşılamada çok başarılı oldu ve zamanla gelişerek bugünkü karmaşık halini aldı. + +Ek kaynaklar: + +- [KISS (Keep It Simple, Stupid)](#the-kiss-principle) + +### Goodhart Yasası + +[Wikipedia'da Goodhart Yasası](https://en.wikipedia.org/wiki/Goodhart's_law) + +> 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. + +Gerçek dünyadan örnekler: + +- "Asert" olmadan yazılan testler, ölçümün amacının iyi test edilmiş bir yazılım oluşturmak olmasına rağmen sadece kod kapsamı beklentisini karşılar. +- Yazılan satır sayısının gösterdiği geliştirici performans puanı haksız yere şişirilmiş kod tabanına yol açar. + +Ek kaynaklar: + +- [Goodhart Yasası: Yanlış Şeyleri Ölçmek Ahlaksız Davranışları Nasıl Yönlendirir?](https://coffeeandjunk.com/goodharts-campbells-law/) +- [Sorunsuz bir yazılım dünyasında Dilbert](https://dilbert.com/strip/1995-11-13) + +### Hanlon'un Usturası + +[Wikipedia'da Hanlon'un Usturası](https://en.wikipedia.org/wiki/Hanlon%27s_razor) + +> 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. + +### Hick Yasası (Hick-Hyman Yasası) + +[Wikipedia'da Hick Yasası](https://en.wikipedia.org/wiki/Hick%27s_law) + +> Karar verme süresi, seçebileceğiniz seçeneklerin sayısı ile logaritmik orantılı olarak büyür. +> William Edmund Hick and Ray Hyman + +Aşağıdaki denklemde, `T` karar verme zamanıdır, `n` seçenek sayısıdır ve `b` verilerin analizi ile belirlenen bir sabittir. + +![Hicks law](./images/hicks_law.svg) + +*(Diagramın Kaynağı: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)* + +Bu yasa yalnızca seçeneklerin sayısı *sıralandığında* (örneğin alfabetik olarak) geçerlidir. Bu, temel iki logaritmada ima edilir - bu, karar vericinin aslında bir *ikili arama* gerçekleştirdiğini ima eder. Seçenekler iyi sıralanmamışsa, deneyler geçen sürenin doğrusal olduğunu gösterir. + +Bunun UI tasarımında önemli bir etkisi vardır; kullanıcıların seçenekleri kolayca arayabilmelerini sağlamak daha hızlı karar almayı sağlar. + +Hick Yasasında IQ ile reaksiyon süresi arasında [Bilgi İşleme Hızı: Gelişimsel Değişim ve İstihbarat Bağlantıları](https://www.sciencedirect.com/science/article/pii/S0022440599000369) makalesinde bahsedildiği gibi bir korelasyon da gösterilmiştir. + +Ek kaynaklar: + +- [Fitts Yasası](#fitts-law) + +### Hofstadter Yasası + +[Wikipedia'da Hofstadter Yasası](https://en.wikipedia.org/wiki/Hofstadter%27s_law) + +> 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. + +'[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)' adlı kitaptan bir alıntı. + +Ek kaynaklar: + +- [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list) + +### Hutber Yasası + +[Wikipedia'da Hutber Yasası ](https://en.wikipedia.org/wiki/Hutber%27s_law) + +> İ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. + +Örneğin, bir servisin cevap verme zamanında bir geliştirme yapılıp hızlandırılırsa bu durum süreçteki diğer aşamalarda kapasite ve çıktı artışına sebep olabilir. Bu da sistemin diğer taraflarını olumsuz etkileyebilir. + +### Hype Döngüsü ve Amara Yasası + +[Wikipedia'da Hype Döngüsü](https://en.wikipedia.org/wiki/Hype_cycle) + +> Bir teknolojinin kısa vadede oluşacak etkisini abartıp, uzun vadede oluşacak etkisini hafife alıyoruz. (Roy Amara) (Roy Amara) +> (Roy Amara) + +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) + +*(Resmin Kaynağı: Jeremykemp tarafından İngilizce Wikipeda'da, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* + +Kısaca anlatmak gerekirse, bu döngü her yeni teknolojinin ilk zamanlarında teknolojinin kendisi ve olası etkisi üzerinde bir heyecan dalgası oluştuğunu iddia ediyor. Ekipler yeni teknolojiler hemen kullanmaya çalışıyorlar ve genelde kendilerini sonuçtan memnun olmamış bir halde buluyorlar. Bu ya teknolojinin henüz olgunlaşmamış olmasından, ya da uygulamanın tam anlamıyla gerçekleşmemiş olmasından olabilir. Belirli bir süre geçtikten sonra, teknolojinin yeterliliği ve pratik kullanım alanları artar ve ekipler daha üretken olmaya başlar. Roy Amara'nın sözü bu durumu en özlü şekilde toparlıyor diyebiliriz - "Bir teknolojinin kısa vadede oluşacak etkisini abartıp, uzun vadede oluşacak etkisini hafife alıyoruz". + +### Hyrum Yasası (Arabirimlerin Örtülü Hukuku) + +[Hyrum Yasası Web Sitesi](http://www.hyrumslaw.com/) + +> Belli sayıda kullanıcıya ulaştığında, servis sözleşmesinde ne demiş olduğunuzdan bağımsız olarak ürününüzün ya da sisteminizin bütün gözlemlenebilir davranışları artık üçüncü kişilere göre şekillenecektir. +> (Hyrum Wright) + +Hyrum Yasası göre, eğer bir API'nin *oldukça büyük sayılabilecek sayıda kullanıcısı* olduğunda, artık bütün sonuçlar ve davranışlar (API sözleşmesinde belirtilmemiş olsalar bile) kullanıcılara göre şekillenecektir. Buna bir örnek olarak bir API'nin tepki süresi olabilir. Daha kapsamlı bir örnek olarak kullanıcıların bir regex ile dönen cevap metninin içinden hatanın *tipini* ayıkladıkları bir senaryoyu düşünelim. API sözleşmesinde bu cevap metinleri ile ilgili bir şey belirtilmemiş olmasına ve kullanıcıların hata kodunu kullanmalarını belirtilmesine rağmen, cevap metnini değiştirmeniz *bazı* kullanıcıların metni kullanmalarından dolayı hata ile karşılaşmalarına sebep olacaktır. + +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) +> (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](#the-kiss-principle) +- [Unix Felsefesi](#the-unix-philosophy) +- [Occam'ın Usturası](#occams-razor) + +### Metcalfe Yasası + +[Wikipedia'da Metcalfe Yasası](https://en.wikipedia.org/wiki/Metcalfe's_law) + +> Ağ teorisinde, bir sistemin değeri yaklaşık olarak sistemin kullanıcı sayısının karesi ile orantılı olarak büyür. + +Bu yasa, bir sistem içindeki muhtemel çift bağlantıların sayısına dayanmaktadır ve [Reed Yasası](#reeds-law) ile yakından ilgilidir. Odlyzko ve diğerleri, hem Reed Yasası hem de Metcalfe Yasası'nın, insan bilişinin ağ etkileri üzerindeki sınırlarını hesaba katmayarak sistemin değerini abarttığını öne sürerler; [Dunbar Sayısı'na](#dunbars-number) bakınız. + +Ek kaynaklar: + +- [Reed Yasası](#reeds-law) +- [Dunbar Sayısı](#dunbars-number) + +### Moore Yasası + +[Wikipedia'da Moore Yasası](https://en.wikipedia.org/wiki/Moore%27s_law) + +> Entegre devre içerisindeki transistörlerin sayısı yaklaşık olarak iki yılda bir ikiye katlanır. + +Çoğu zaman yarı-iletken ve çip teknolojisinin gelişim hızını tahmin etmek için kullanılan Moore yasasının, 1970'lerden 2000'lerin sonlarına doğru oldukça doğru olduğu biliyoruz. Son yıllarda, [komponentlerin küçülmesinde fiziksel sınırlara](https://en.wikipedia.org/wiki/Quantum_tunnelling) ulaşıldığı için bu tahminlemenin tutmadığını da söyleyebiliriz. Ama paralelleştirmede uzmanlaşılması ve yarı-iletken teknolojilerindeki devrim potansiyelindeki değişiklikler Moore Yasası'nın yakın zamanda tekrar doğrulanacağını tahminler yapabileceğini düşünebiliriz. + +### Murphy Yasası / Sod Yasası + +[Wikipedia'da Murphy Yasası](https://en.wikipedia.org/wiki/Murphy%27s_law) + +> Eğer bir işin kötü gitme ihtimali varsa mutlaka kötü gider. + +İsmini [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.)'dan alan *Murphy Yasası* der ki eğer bir işin kötü gitme ihtimali varsa mutlaka kötü gider. + +Bu programcılar arasında çok kullanılan bir atasözüdür. Geliştirme yaparken, test ederken ya da canlı sistemlerde çoğunlukla hep beklenmedik sorunlar olur. Bu durum (İngiltere'de yaygın kullanılan) *Sod Yasası* ile de ilişkilendirilebilir: + +> Eğer bir işin kötü gitme ihtimali varsa, olabilecek en kötü zamanda kötüye gidecektir. + +Bu iki 'yasa' daha çok espri amaçlı kullanılır. Bunun yanında, [*Doğrulama Önyargısı*](#TODO) ve [*Seçim Tarafgirliği*](#TODO) gibi olgular bu yasaların insanlar tarafında çok fazla vurgulanmasına sebep olabilir (işler yolundayken hiçbirşeye dikkat etmeyiz, ama bunun yanında sorunlar yaşanınca herşey göze batmaya başlar ve tartışılır). + +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 +> 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) + +> Bir iş, daima, bitirilmesi için kendisine ayrılan sürenin hepsini kapsayacak şekilde uzar. + +Orijinal bağlamında, bu kanun bürokrasi alanındaki çalışmalara dayanıyordu. Kötümser bir bakış açısıyla yazılım geliştirme girişimleri için de söylenebilir. Şöyle ki ekipler genelde proje bitiş tarihi yaklaşana kadar düşük verimde çalışırlar, bitiş tarihi yaklaştıkça bitirmek için yoğun bir çaba içine girerler ve sonuç olarak aslında bitiş tarihini tutturmuş olurlar. + +Bu yasa ile [Hofstadter Yasası](#hofstadters-law) birleştirilirse, daha kötümser bir yasaya ulaşılır. Bir iş bitirilmesi için harcanması gereken zamanı kapsar ve *her zaman gecikir*. + +Ek kaynaklar: + +- [Hofstadter Yasası](#hofstadters-law) + +### Olgunlaşmamış Optimizasyon Etkisi + +[WikiWikiWeb'de Olgunlaşmamış Optimizasyon Etkisi](http://wiki.c2.com/?PrematureOptimization) + +> Vakti gelmeden gelmeden yapılan optimizasyon bütün kötülüklerin anasıdır. [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) +> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) + +Donald Knuth yazdığı [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) isimli makalede, "Programcılar, programlarının kritik olmayan bölümlerinin hızını düşünerek veya endişelenerek çok fazla zaman harcarlar ve bu bakış açısı ile yaptıkları verimlilik geliştirmelerin hata ayıklama ve bakım yapma aşamalarına çok olumsuz etkileri olur. Kesinlikle bu tarz küçük geliştirmeleri (zamanımızın %97'sini harcadığımız) göz ardı etmeliyiz, **Vakti gelmeden yapılan optimizasyon bütün kötülüklerin anasıdır** gerçeğini unutmamalılıyız. Yine de, geride kalan % 3'teki kritik fırsatları kaçırmamalıyız." + +Aslında, *olgunlaşmamış optimizasyonu* ihtiyacımızın ne olduğunu bilmeden yapılan optimizasyon olarak tanımlayabiliriz (daha basit kelimelerle). + +### Putt Yasası + +[Wikipedia'da Putt Yasası](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) + +> Teknolojide iki tür insan egemendir, yönetmedikleri şeyleri anlayanlar ve anlamadıkları şeyleri yönetenler. + +Putt yasasını çoğunlukla Putt sonucu takip eder: + +> Her teknik hiyerarşi, zaman içinde bir yetkinlik dönüşümü geliştirir. + +Bu iki cümle der ki grupların organiza olma şekillerindeki seçim kıstasları ve eğilimleri yüzünden bir zaman sonra teknik organizasyonun çalışma seviyelerinde bir grup yetenekli insan varken yönettikleri işin karmaşıklığından ve zorluklarından bihaber bir grup insan da yönetim kademelerini işgal edecektir. Bu durum [Peter Prensibi](#the-peter-principle) ya da [Dilbert Prensibi](#the-dilbert-principle) ile de açıklanabilir. + +Bununla birlikte, bunun gibi yasaların çok büyük genellemeler olduğu ve *bazı* organizasyon türleri için geçerli olabileceği gibi başkaları için geçerli olmayacağı unutulmamalıdır. + +Ek kaynaklar: + +- [Peter Prensibi](#the-peter-principle) +- [Dilbert Prensibi](#the-dilbert-principle) + +### Reed Yasası + +[Wikipedia'da Reed Yasası](https://en.wikipedia.org/wiki/Reed's_law) + +> Büyük ağların, özellikle sosyal ağların kullanımı, ağın boyutuna katlanarak ölçeklenir. + +Bu yasa, programın faydasının olası katılımcı veya ikili bağlantı sayısından daha hızlı olan olası alt grup sayısı olarak ölçeklendiği grafik teorisine dayanmaktadır. Odlyzko ve diğerleri, Reed Yasası'nın, insan bilişinin ağ etkileri üzerindeki sınırlarını hesaba katarak sistemin yararını abarttığını öne sürerler; [Dunbar Sayısı'na](#dunbars-number) bakınız. + +Ek kaynaklar: + +- [Metcalfe Yasası](#metcalfes-law) +- [Dunbar Sayısı](#dunbars-number) + +### Karmaşıklığın Korunması Yasası (Tesler Yasası) + +[Wikipedia'da Karmaşıklığın Korunması Yasası](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) + +Bu yasa der ki, her sistemde kesinlikle ayıklanamayacak bir miktarda karmaşıklık vardır. + +Bir sistem ve yazılımdaki karmaşıklıkların bazıları dikkatsizlik veya yanlışlıktan ortaya çıkar. Bu kötü kurgulanmış yapının, herhangi bir dikkatsizliğin, ya da problemin kötü modellenmesinin sonucu olabilir. Bu tarz karmaşıklıklar giderilebilir ve sistemden ayıklanabilir. Bunun yanında, bazı karmaşıklıklar sistemin gerçekleridir yani sistemin çözmeye çalıştığı problemin doğası gereği ortaya çıkarlar. Bu tarz karmaşıklıklar sistem içinde farklı yerlere taşınabilirler ama sistemden ayıklanmazlar. + +O yasanın farklı bir yansıması olarak şöyle düşünülebilir, eğer bir karmaşıklık esastan geliyorsa ve sistem sadeleştirilerek bile ayıklanamıyorsa, daha karmaşık bir şekilde davranması beklenen *kullanıcının tarafına taşınabilir*. + +### Demeter Yasası + +[Wikipedia'da Demeter Yasası](https://en.wikipedia.org/wiki/Law_of_Demeter) + +> Asla yabancılarla konuşma. + +"En Az Bilgi İlkesi" olarak da bilinen Demeter Yasası, yazılım tasarımı için, özellikle nesne tabanlı dillerle ilgili bir ilkedir. + +Bir yazılım biriminin sadece en yakın işbirlikçileriyle konuşması gerektiğini belirtir. `B` nesnesine bir referansı olan bir `A` nesnesi yöntemlerini çağırabilir, ancak `B` `C` nesnesine bir referansı varsa, `A` `C` yöntemlerini direk çağırmamalıdır. Yani, eğer `C` bir `doThing()` yöntemine sahipse, `A` doğrudan çağırmamalıdır; `B.getC().doThis()`. + +Bu ilkeyi izlemek, değişikliklerin kapsamını sınırlayarak gelecekte değiştirmelerin daha kolay ve daha güvenli olmasını sağlar. + +### Sızdıran Soyutlamalar Yasası + +[Sızdıran Soyutlamalar Yasası, Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) + +> Önemsiz sayılmayacak bütün soyutlamar belli ölçüde sızıntı içerir. ([Joel Spolsky](https://twitter.com/spolsky)) +> ([Joel Spolsky](https://twitter.com/spolsky)) + +Bu yasa, karmaşık sistemleri sadeleştirmek için kullandığımız soyutlamaların bazı durumlarda soyutlamanın altındaki sistemin öğelerini sorunları ile birlikte sızdırır ve bu da beklenmedik davranışlar ortaya çıkması ile sonuçlanır. + +Dosya açma ve okuma işlemlerini örneklemek için kullanabiliriz. Dosya sistemi arayüzleri altta yeralan çekirdek sistemlerinin bir *soyutlamasıdır*, ki çekirdek sistemleri de aslında manyetik plakalardaki (fash disk ya da SDD) veriyi fiziksel olarak değiştiren işlemlerin soyutlamasıdır. Çoğu durumda, bir dosyayı ikili sistemdeki verilerin akışı olarak soyutlamak işe yarar. Manyetik sürücüler sıralı okuma yapıldığında rastgele erişimli sürücülere göre *daha* hızlıdır (sayfalama hatalarının artmasından dolayı) ama bu durum SDD sürücülerle karşılaştırmada geçerli değildir. Bu durumun üstesinden gelmek için, detayların altında yatan bilgileri (yani geliştiricinin bilmesi gereken uygulama detaylarını) soyutlamanın sızdırıyor olacağı dikkate alınmalıdır. + +Yukarıda verdiğimiz örnek *daha fazla* soyutlanma göz önünde bulundurulursa daha da karmaşıklaşabilir. Linux işletim sistemi dosyalara bir ağ üzerinden erişilmesine olanak sağlıyor ama bu dosyalar sanki yerel dosyalarmış gibi gösterilir. Bu soyutlama da eğer bir network sorunu olursa sızıntı oluşturur. Eğer bir uygulama geliştirici bu tür dosyaları normal dosyalarmış gibi düşünerek geliştirme yaparsa, ağızda oluşan herhangi bir gecikme ya da sorun çözümü sorunlu hale getirecektir. + +Yasa savunmaya çalıştığı durum, herhangi bir soyutlamaya çok fazla güvenmenin alta yatan işlemleri de tam anlamamayla birleşince çözülmeye çalışılan problemin çoğunlukla *daha da* karmaşıklaşması ile sonuçlanacağıdır. + +Ek kaynaklar: + +- [Hyrum Yasası](#hyrums-law-the-law-of-implicit-interfaces) + +Gerçek dünyadan örnekler: + +- [Photoshop'taki yavaş açılma problemi](https://forums.adobe.com/thread/376152): Photoshop bir zamanlar çok yavaş açılırdı, hatta bazen açılması dakikalar sürerdi. Sorunun sebebi program her başlangıçta ön tanımlı yazıcı ile ilgili belli bilgileri çekmeye çalışması olarak gözüküyordu. Eğer yazıcı bir ağ yazıcısıysa açılma daha da uzun sürüyordu. Ağ yazıcılarının yerel yazıcıları gibi *soyutlanması* kullanıcılara bu kötü deneyimi yaşatmış oldu. + +### Önemsizlik Yasası + +[Wikipedia'da Önemsizlik Yasası](https://en.wikipedia.org/wiki/Law_of_triviality) + +Bu yasa diyor ki, ekipler önemsiz ve kozmetik sorunlara ciddi ve önemli sorunlara göre daha fazla zaman harcarlar. + +En çok kullanılan kurgu örnek nükleer enerji reaktörünü onaylayacak olan komitenin reaktörün genel tasarımını onaylama zamanından çok bisiklet parkının tasarımını onaylamak için zaman harcamasıdır. Çok büyük ve karmaşık konularla ilgili o alanda bir eğitime, tecrübeye ve hazırlığa sahip olmadan kayda değer yorum getirmek zordur. İnsanlar genelde değerli katkılar verdiklerinin görülmesini isterler. Dolayısıyla insanlar kolayca katkı verebilecekleri gerekli ve önemli olmasa bile küçük detaylara odaklanma eğilimi gösterirler. + +Bu kurgu örnek 'Bike Shedding' diye bir deyimin yaygınlaşmasına sebep olmuştur. Türkçe'deki 'pire için yorgan yakmak' ya da 'attığın taş ürküttüğün kurbağaya değsin' gibi deyimlere benzer. Alternatif bir terim 'Yak Shaving' de kullanılmaktadır. + +### Unix Felsefesi + +[Wikipedia'da Unix Felsefesi](https://en.wikipedia.org/wiki/Unix_philosophy) + +Unix felsefesi şöyle özetlenebilir; bir yazılım parçası olabildiğince küçük olmalı ve sadece bir işi yapmaya odaklanmalıdır. Bu felsefeye uymak sistemleri büyük, karmaşık ve çok amaçlı programlarla oluşturmak yerine küçük, basit ve iyi tanımlanmış parçalardan daha kolayca oluşturmayı sağlar. + +Modern yaklaşımlardan biri olan 'Mikro-service Mimarisi' de bu felsefenin uygulaması olarak düşünülebilir. Çünkü bu mimari ile servislerin küçük, amaç odaklı ve tek bir iş yapacak şekilde geliştirilmesi ve karmaşık yapıların küçük basit bloklar halinde oluşturulması hedefleniyor. + +### Spotify Modeli + +[Spotify Modeli, Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) + +Spotify Modeli Spotify'daki uygulamasından dolayı popüler olmuş ekip ve organizasyon yapıları için yeni bir yaklaşımdır. Model basitçe ekiplerin teknolojilere göre değil de özellikler etrafında organize edilmesidir. + +Spotify Modeli kabileler (Tribes), birlikler (Guilds) ve kısımlar (Chapter) gibi organizasyon yapısında kullanılacak öğeleri de yaygın hale getirdi. + +Organizasyonun üyeleri bu grupların gerçek anlamlarının zamanla değiştiğini, geliştiğini ve bunun devam eden bir deney olduğunu söylüyorlar. Modelin sabit bir modelden ziyade *hareket halinde bir süreç * olması, yapının değişen yorumlarına yol açmaya devam etmektedir (konferanslarda konuyla ilgili yapılan sunumlarına dayanarak söyleyebiliriz). Bu, 'anlık görüntülerin' üçüncü taraflar tarafından *sabit bir yapı * olarak yeniden paketlenebileceği anlamına gelir ve modelin dinamikliğinin kaybolmasına sebep olabilir. + +### Wadler Yasası + +[Wadler Yasası, wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) + +> Herhangi bir programlama dilini tasarlarken, aşağıdaki listedeki herhangi bir özelliği tartışmak için harcanan zaman iki üzeri özelliğin listeki sırası ile doğru orantılıdır. +> 1. Semantik +> 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. + +Ek kaynaklar: + +- [Önemsizlik Yasası](#the-law-of-triviality) + +### Wheaton Yasası + +[Link](http://www.wheatonslaw.com/) + +[Resmi Gün](https://dontbeadickday.com/) + +> Öküzlük yapmayın. *Wil Wheaton* *Wil Wheaton* +> *Wil Wheaton* + +Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory) tarafından oluşturulan bu basit, özlü ve güçlü yasa, profesyonel bir organizasyon içinde uyum ve saygının artmasını amaçlamaktadır. İş arkadaşlarınızla konuşurken, kod incelemeleri yaparken, diğer bakış açılarını öne sürerken, insanları eleştirirken ve genel olarak insanların birbirleriyle olan profesyonel etkileşimlerinin çoğunda uygulanabilir. + +## Prensipler + +Prensiplerin genellikle tasarıma ilişkin rehberlerdir. + +### Ölü Deniz Etkisi + +[Bruce F. Webster'e göre Ölü Deniz Etkisi](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/) + +> "... [E]n yetenekli ve verimli BT mühendisleri şirketleri terketmeye en yakın olanlardır, [kalıcı olma taraftarı olanlar] ise tortuya (daha az yetenekli ve verimsiz) benzetilebilir" *Bruce F. Webster* +> *Bruce F. Webster* + +"Ölü Deniz Etkisi" bir organizasyonda mühendislerin becerilerinin/yeteneklerinin/verimliliklerinin sıklıkla o organizasyonda harcadıkları zamanla ters orantılı olduğunu söyler. + +Genellikle, yüksek vasıflı mühendisler başka yerlerde iş bulması kolay kolay olan ve bunu ilk yapan kişilerdir. Eskimiş veya zayıf becerilere sahip mühendisler, başka bir yerde iş bulmak zor olduğu için şirkette kalma eğilimindedir. Bu, özellikle şirketteki zamanları boyunca artan ücret artışları elde ettikleri takdirde de geçerlidir, çünkü başka bir yerde eşdeğer ücret almaları zor olabilir. + +### Dilbert Prensibi + +[Wikipedia'da Dilbert Prensibi](https://en.wikipedia.org/wiki/Dilbert_principle) + +> Ş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 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: + +- [Peter Prensibi](#the-peter-principle) +- [Putt Yasası](#putts-law) + +### Pareto Prensibi (80/20 Kuralı) + +[Wikipedia'da Pareto Prensibi](https://en.wikipedia.org/wiki/Pareto_principle) + +> Hayattaki çoğu şey eşit dağılmaz. + +Pareto Prensibi der ki, çıktıların önemli bir çoğunluğu girdilerin çok azı tarafından oluşturulur: + +- Bir yazılımın 80%'i harcanan zamanın %20'sinde yazılır (bir başka deyişle, kodun en zor %20'lik bölümü haracanan zamanın %80'inde yazılır) +- Harcanan eforun %20'si sonucun %80'ini oluşturur +- Yapılan işin %20'si gelirin %80'ini oluşturur +- Koddaki hataların %20'si sistem sorunlarının %80'ini oluşturur +- Özelliklerin %20'si hizmetin %80'ini oluşturur + +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: + +- 2002'de Microsoft en çok rapor edilen hataların üstten %20'sini çözünce kullanıcıların yaşadığı sorunların %80'inin çözüldüğünü gözlemlemiş ([Referans](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). + +### Peter Prensibi + +[Wikipedia'da Peter Prensibi](https://en.wikipedia.org/wiki/Peter_principle) + +> Hiyerarşideki insanlar “yetersizlik seviyelerine” göre yükselme eğilimindedir. *Laurence J. Peter* *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. + +Bu, temelde farklı bir beceri kümesi gerektirdiğinden özellikle mühendislerle - kariyerine teknik rollerle başlayan ama sonra kariyer değiştirip diğer mühendisleri *yönetmeye* başlayan - alakalıdır. + +Ek kaynaklar: + +- [Dilbert Prensibi](#the-dilbert-principle) +- [Putt Yasası](#putts-law) + +### Dayanıklılık Prensibi (Postel Yasası) + +[Wikipedia'da Dayanıklılık Prensibi](https://en.wikipedia.org/wiki/Robustness_principle) + +> Yaptıklarınızda muhafazakar olun, başkalarından kabul ettiğiniz şeyler konusunda liberal olun. + +Genellikle sunucu uygulamaları geliştirirken uygulanabilir. Bu prensip der ki; kendi uygulamanızdan dışarıya veri gönderirken kılı kırk yararcasına dikkatli olun ama dışardan veri alırken mümkün olabilecek her durumda veriyi kabul etmeye çalışın. + +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ı](#hyrums-law-the-law-of-implicit-interfaces) + +### SOLID + +SOLID aşağıdaki beş prensibin baş harflerinden oluşan bir kısaltmadır; + +- S: [Tek Sorumluluk Prensibi - The Single Responsibility Principle](#the-single-responsibility-principle) +- O: [Açık/Kapalı Prensibi - The Open/Closed Principle](#the-openclosed-principle) +- L: [Liskov Yerine Geçme Prensibi - The Liskov Substitution Principle](#the-liskov-substitution-principle) +- I: [Arayüz Ayrım Prensibi - The Interface Segregation Principle](#the-interface-segregation-principle) +- D: [Bağımlılığın Ters Çevrilmesi - The Dependency Inversion Principle](#the-dependency-inversion-principle) + +Bunları [Nesne Tabanlı Proglamlama'nın](#todo) temel prensipleri olarak değerlendirilebilir ve bu prensiplerin programcılara geliştirilebilir ve desteklenebilir sistemler geliştirmelerinde yardımcı oldukları kesindir. + +### Tek Sorumluluk Prensibi + +[Wikipedia'da Tek Sorumluluk Prensibi](https://en.wikipedia.org/wiki/Single_responsibility_principle) + +> Her sistem parçasının ya da programlama sınıfının sadece bir sorumluluğu olmalı. + +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 *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: + +- [Nesne Tabanlı Programlama](#todo) +- [SOLID](#solid) + +### Açık/Kapalı Prensibi + +[Wikipedia'da Açık/Kapalı Prensibi](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) + +> Her sistem parçası (sınıf, modül, fonksiyon vs) genişletilmeye (türev alınmaya, miras alınma vs) açık olmalı ama değiştirilmeye (modifiye etme) kapalı olmalı. + +Bu '[SOLID](#solid)' prensiplerinin ikincisidir ve herhangi bir sistem parçasının *mevcut* davranışının değiştirilememesini ama kullanılarak/türetilerek *genişletilebilmesinin* gerekliliğini savunur. + +Ö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: + +- [Nesne Tabanlı Programlama](#todo) +- [SOLID](#solid) + +### Liskov Yerine Geçme Prensibi + +[Wikipedia'da Liskov Yerine Geçme Prensibi](https://en.wikipedia.org/wiki/Liskov_substitution_principle) + +> Bir sistemde var olan bir özellik kendinden türetilmiş türetilmiş bir özellikle herhangi bir sistemsel soruna sebep olmadan yer değiştirilebilmeli. + +'[SOLID](#solid)' prensiplerinin üçüncüsüdür. Bu prensibe göre herhangi bir bileşenin üzerine dayandığı bir özelliği (sınıf vs) o özelliklikten türetilmiş alt özellikle değiştirebilmeliyiz ve bu durumda bir sistem sorununa neden olunmaz ya da alt özelliğin bütün detaylarını bilmeye gerek kalmaz. + +Örneğin dosyayı temsil eden bir yapıdan XML verisi okuyan bir metod düşünelim. Eğer bu metod 'dosya' tipini kullanıyorsa, 'dosya' tipinden türeyen bütün tipleri de kullanabilmelidir. Eğer 'dosya' tipi geriye dönük aramayı destekliyorsa ama 'dosya' tipinden türetilmiş 'ağ dosyası' tipi bunu desteklemiyorsa o zaman 'ağ dosyası' tipi bu prensibi ihlal ediyor demektir. + +Bu prensip nesne-tabanlı programlamanın bağlı olduğu prensiplerden biridir ve geliştiricilerin kafasını karıştırmamak için sınıf hiyerarşisinin dikkatli tarasarlanması gerektiğini söyler. + +Ek kaynaklar: + +- [Nesne Tabanlı Programlama](#todo) +- [SOLID](#solid) + +### Arayüz Ayrım Prensibi + +[Wikipedia'da Arayüz Ayrım Prensibi](https://en.wikipedia.org/wiki/Interface_segregation_principle) + +> Hiçbir kullanıcı/müşteri/istemci, kullanmadığı yöntemlere bağlı kalmamalıdır. + +'[SOLID](#solid)' prensiplerinin dördüncüsüdür ve bir bileşenin kullanıcılarının, kullanmadığı bir bileşenin işlevlerine bağımlı olmaması gerektiğini belirtir. + +Örnek olarak dosyayı temsil eden bir yapıdan XML verisi okuyan bir metod düşünelim. Bu metod sadece dosyadan byte byte veri okumalı ve dosya içinde ileri ya da geri hareket etmeli. Eğer bu method dosya okuma dışında (dosya izinleri değişimi gibi) herhangi bir özellik değişiminden dolayı güncellenmek zorunda kalınıyorsa bu prensip ihlal edilmiş demektir. + +Bu prensip de nesne-tabanlı programlama ile direk ilişkilidir. 'interface' yapıları, sınıf hiyerarşileri ve soyut türler farklı bileşenler arası bağımlığı en aza indirmek için kullanılır. Duck typing de bu prensibi uygulamaya yardımcı olur. + +Ek kaynaklar: + +- [Nesne Tabanlı Programlama](#todo) +- [SOLID](#solid) +- [Duck Typing](#todo) +- [Ayrışma](#todo) + +### Bağımlılığın Ters Çevrilmesi + +[Wikipedia'da Bağımlılığın Ters Çevrilmesi](https://en.wikipedia.org/wiki/Dependency_inversion_principle) + +> Yüksek seviye modülleri, düşük seviye uygulamalarına bağlı olmamalıdır. + +'[SOLID](#solid)' prensiplerin beşincisidir. Bu ilke, daha üst seviye bileşenlerinin bağımlılıklarının ayrıntılarını bilmek zorunda olmadıklarını belirtir. + +Örnek olarak bir web sitesinden metadata okuyan bir program düşünelim. Bu programın ana bileşeninin web sitesinden içeriği indiren ve metadayı okuyan bileşenlerinden ne yaptığından haberdar olması gerekir. Eğer bu prensibe uyarsak ana bileşenin byte verisi okuyan ve byte verisinden metada çıkaran soyutlamalara bağımlı olması lazım. Ana bileşenin TCP/IP, HTTP ya da HTML hakında bir detaya hakim olmasına gerek yoktur. + +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) +- [SOLID](#solid) +- [Bağımlılığın Ters Çevrilmesi](#todo) +- [Bağımlılık Enjeksiyonu](#todo) + +### DRY Prensibi + +[Wikipedia'da DRY Prensibi](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) + +> Her bilgi parçasının bir sistem içinde tek, açık ve net bir temsiline sahip olması gerekir. + +*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. + +Ek kaynaklar: + +- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) + +### KISS prensibi + +[Wikipedia'da KISS](https://en.wikipedia.org/wiki/KISS_principle) + +> Olabildiğince basit ve aptal (Keep it simple, stupid) + +KISS prensibi, çoğu sistemin karmaşıklaştırılmak yerine basit tutulması durumunda en iyi şekilde çalışacağını belirtir; bu nedenle sadelik tasarımda kilit bir amaç olmalı ve gereksiz karmaşıklıktan kaçınılmalıdır. Bu 1960’da ABD Donanması’nda çalışan uçak mühendisi Kelly Johnson ile ilişkilendirilen bir cümle. + +Prensip, Johnson'ın bir tasarım mühendisleri ekibine bir avuç el aleti teslim etmesinin öyküsüyle en iyi örneklenmiştir, tasarladıkları jet uçağının sahadaki ortalama bir tamirci tarafından yalnızca bu aletlerle mücadele koşullarında tamir edilebilir olması zorunluluğu ile karşı karşıyadır. Bu nedenle, "aptal" kelimesi mühendislerin kendi yeteneklerini değil, işlerin kırılma şekli ile onları tamir etmek için mevcut araçların karmaşıklığı arasındaki ilişkiyi ifade eder. + +Ek kaynaklar: + +- [Gall Yasası](#galls-law) + +### YAGNI + +[Wikipedia'da YAGNI](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it) + +***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 co-founder and author of the book "Extreme Programming Installed") +> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed") + +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. + +Bu ilkeye bağlı kalmak, kod tabanındaki kullanılmayan kod miktarının ve hiçbir değer getirmeyen işlevlerde haracanan zamanın ve çabanın azalmasını sağlayacaktır. + +Ek kaynaklar: + +- [Reading List: Extreme Programming Installed](#reading-list) + +### Dağıtık Sistemlerin Yanılgıları + +[Wikipedia'da Dağıtık Sistemlerin Yanılgıları](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) + +*Ağ Tabanlı Sistemlerin Yanılgıları* olarak da bilinen yanılgılar dağıtık sistemleri geliştirme sırasında başarısızlıklara yol açabilecek varsayımların (veya inançların) bir listesidir. Varsayımlar: + +- Ağ güvenilirdir. +- Gecikme yoktur. +- Bant genişliği sonsuzdur. +- Ağ güvenlidir. +- Topoloji değişmez. +- Sadece bir tane yönetici vardır. +- Taşıma maaliyeti sıfırdır. +- Ağ homojendir. + +İlk dört madde 1991'de [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) ve [Tom Lyon](https://twitter.com/aka_pugs) tarafından listelenmiştir ve ilk önce [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) tarafından "Ağ Tabanlı Sistemlerin Yanılgıları" olarak sınıflandırılmıştır. [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) 5., 6. ve 7. yanılgıları ekledi. 90'lı yılların sonlarında Gosling 8. yanılgıyı ekledi. + +Grup [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems) içinde başlarına gelen olaydan ilham aldı. + +Dayanıklı sistemler tasarlarken bu yanılgılar dikkatlice ele alınmalı; bu yanılgılardan herhangi birinin varsayılması, dağıtılmış sistemlerin gerçeklikleri ve karmaşıklıkları ile başa çıkamayan hatalı bir mantığa yol açabilir. + +Ek kaynaklar: + +- [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) + +## Ek Kaynaklar + +Bu kavramları ilginç bulduysanız, aşağıdaki kitapların keyfini çıkarabilirsiniz. + +- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Extreme Programming kavramının temel prensiplerini içerir. +- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Yazılım mühendisliği klasiği sayılabilir. Brooks Yasası bu kitabın ana temasıdır. +- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Sınıflandırması zor bir kitap. Hofstadter Yasası bu kitaptan alıntıdır. +- [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 +--- | --- | --- +[🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg) +[🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg) +[🇨🇳 中文 / 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) | [](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)[![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge) +[🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [](https://gitlocalize.com/repo/2513/tr?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg) +[🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [](https://gitlocalize.com/repo/2513/ja?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)[![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](https://gitlocalize.com/repo/2513/ja?utm_source=badge) +[🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Kısmen tamamlandı +[🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara) | [](https://gitlocalize.com/repo/2513/fr?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg) +[🇰🇷 한국어 / 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) | [](https://gitlocalize.com/repo/2513/de?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg) +[🇷🇺 Русская версия / 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) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg) + +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. +- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Terminalden yasaları listeleyin, ve rastgele bir yasa görüntüleyin! + +## 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.