Repository: dwmkerr/hacker-laws Branch: main Commit: f13e2dc70f29 Files: 40 Total size: 679.5 KB Directory structure: gitextract_45dvjnqv/ ├── .all-contributorsrc ├── .github/ │ ├── CHANGELOG.md │ ├── CODE_OF_CONDUCT.md │ ├── FUNDING.yml │ ├── contributing.md │ ├── makefile │ ├── pull_request_template.md │ ├── release-please-config.json │ ├── release-please-manifest.json │ ├── website/ │ │ ├── backup/ │ │ │ ├── ideas.md │ │ │ ├── index2.html │ │ │ ├── index3.html │ │ │ └── index4.html │ │ ├── generate.py │ │ ├── makefile │ │ ├── requirements.txt │ │ └── src/ │ │ ├── index.html.jinja │ │ ├── script.js │ │ └── styles.css │ └── workflows/ │ └── cicd.yaml ├── .gitignore ├── LICENSE ├── README.md ├── assets/ │ ├── banner.psd │ ├── diagrams.bmpr │ └── site/ │ ├── index.html │ ├── index2.html │ ├── index3.html │ └── index4.html ├── scripts/ │ └── prepare-markdown-for-ebook.sh └── translations/ ├── es-ES.md ├── fr.md ├── id.md ├── it-IT.md ├── jp.md ├── lv.md ├── pl.md ├── pt-BR.md ├── tr.md └── vi.md ================================================ FILE CONTENTS ================================================ ================================================ FILE: .all-contributorsrc ================================================ { "files": [ "README.md" ], "imageSize": 100, "commit": false, "commitType": "docs", "commitConvention": "angular", "contributors": [ { "login": "hemmatt", "name": "Amir Hemmati", "avatar_url": "https://avatars.githubusercontent.com/u/22114089?v=4", "profile": "https://github.com/hemmatt", "contributions": [ "doc" ] } ], "contributorsPerLine": 7, "skipCi": true, "repoType": "github", "repoHost": "https://github.com", "projectName": "hacker-laws", "projectOwner": "dwmkerr" } ================================================ FILE: .github/CHANGELOG.md ================================================ # Changelog ## [0.5.0](https://github.com/dwmkerr/hacker-laws/compare/v0.4.0...v0.5.0) (2026-02-06) ### Features * add Jevons' Paradox ([4652447](https://github.com/dwmkerr/hacker-laws/commit/46524475b67a7b1766ba1e325ccff5f90e1738f8)) * add Jevons' Paradox ([607feeb](https://github.com/dwmkerr/hacker-laws/commit/607feeb3cb078454124f5507695ff4cf624026e4)), closes [#430](https://github.com/dwmkerr/hacker-laws/issues/430) ### Bug Fixes * broken all-contributors badge link ([ff24778](https://github.com/dwmkerr/hacker-laws/commit/ff24778aa8e3fda0eb514b1355eaaf6cdee63c54)) * convert badge to HTML for proper rendering ([f79f2c8](https://github.com/dwmkerr/hacker-laws/commit/f79f2c83c5886736e1de33714e2f4326bf71b2b7)) * remove all-contributors badge ([872a758](https://github.com/dwmkerr/hacker-laws/commit/872a7588b9042b3ac80ae5a7cea0b8b1e4877f71)) ## [0.4.0](https://github.com/dwmkerr/hacker-laws/compare/v0.3.2...v0.4.0) (2025-12-29) ### Features * add The Stochastic Parrot ([bd1f1f9](https://github.com/dwmkerr/hacker-laws/commit/bd1f1f92d680dd355c993375cd71f81f81f9cfc6)) * add The Stochastic Parrot ([286e57a](https://github.com/dwmkerr/hacker-laws/commit/286e57a0e6017845d811072d2e49b7b0c73619da)) ### Bug Fixes * correct mistranslation of Hyrum’s Law in Japanese ([ab076b3](https://github.com/dwmkerr/hacker-laws/commit/ab076b3c638460b1c792ef676b902ca74be3c763)) ## [0.3.2](https://github.com/dwmkerr/hacker-laws/compare/v0.3.1...v0.3.2) (2025-03-31) ### Bug Fixes * update ebook download link ([4546562](https://github.com/dwmkerr/hacker-laws/commit/454656237d9508c8fadafffbc1c1286fc134f8cf)) ## [0.3.1](https://github.com/dwmkerr/hacker-laws/compare/v0.3.0...v0.3.1) (2025-03-31) ### Bug Fixes * effective shell links ([6353fe4](https://github.com/dwmkerr/hacker-laws/commit/6353fe4b8f044456d66dac0af950e41989c56c5a)) ## [0.3.0](https://github.com/dwmkerr/hacker-laws/compare/v0.2.1...v0.3.0) (2025-03-31) ### Features * add Koomey's Law ([dcdcfdf](https://github.com/dwmkerr/hacker-laws/commit/dcdcfdfc25ee121b6bcb931a71e185fa7ffeedcd)) ## [0.2.1](https://github.com/dwmkerr/hacker-laws/compare/v0.2.0...v0.2.1) (2025-03-31) ### Bug Fixes * remove frontmatter ([2140429](https://github.com/dwmkerr/hacker-laws/commit/2140429b959a8284b452c3fa05e1c9fd03e5ebab)) ## [0.2.0](https://github.com/dwmkerr/hacker-laws/compare/v0.1.0...v0.2.0) (2025-03-31) ### Features * 90-90 rule ([4477907](https://github.com/dwmkerr/hacker-laws/commit/44779074caa6495198214100e5bd0a886cc1e680)) * add section for Kerckhoff's principle ([5f74607](https://github.com/dwmkerr/hacker-laws/commit/5f74607c63d3a76009ec0546ba515f8f7c1d3864)) * add ukranian language to README ([#320](https://github.com/dwmkerr/hacker-laws/issues/320)) ([015d251](https://github.com/dwmkerr/hacker-laws/commit/015d25197f808d66c4dfebcdd0b54675af6a3eae)), closes [#236](https://github.com/dwmkerr/hacker-laws/issues/236) * Dunning Kruger Effect ([3dbc237](https://github.com/dwmkerr/hacker-laws/commit/3dbc237c1f1c59e809969320cc0ae4347a4b45c3)) * Dunning-Kruger Effect ([#318](https://github.com/dwmkerr/hacker-laws/issues/318)) ([34c38d8](https://github.com/dwmkerr/hacker-laws/commit/34c38d87edba4b0e36d2ad9488b97d0c77f9b550)) * **pages:** update index.html and pages.yaml for deployment ([beb3d57](https://github.com/dwmkerr/hacker-laws/commit/beb3d57a6a5a3a38aa9e692ed13eb01060b85ded)) * principle of least astonishment ([4be4827](https://github.com/dwmkerr/hacker-laws/commit/4be482731b6a6009453af7d303d3cd2470a2e73e)) * principle of least astonishment ([e4662cb](https://github.com/dwmkerr/hacker-laws/commit/e4662cbc27d04fb968220837633034420b7fb11a)) * the scout rule ([716aef8](https://github.com/dwmkerr/hacker-laws/commit/716aef807e758bd8df976f323089db525da9f708)) * the scout rule ([c6fccf4](https://github.com/dwmkerr/hacker-laws/commit/c6fccf4978d9483637fba8c7887127abad3de581)), closes [#144](https://github.com/dwmkerr/hacker-laws/issues/144) * twyman's law ([b9ad4c6](https://github.com/dwmkerr/hacker-laws/commit/b9ad4c6f99f991a1bda9a2cfdddef62787e6ae82)) ### Bug Fixes * correct facebook link on website ([6f9b1e3](https://github.com/dwmkerr/hacker-laws/commit/6f9b1e33345bc1332428f0fba8c7aa2900147500)) * correct formatting around quote ([d83d439](https://github.com/dwmkerr/hacker-laws/commit/d83d439df89e8af50ae53bafa3a791f8d92a6991)) * Fix section's links ([#317](https://github.com/dwmkerr/hacker-laws/issues/317)) ([7b341fc](https://github.com/dwmkerr/hacker-laws/commit/7b341fc0d205f076e25ff8fedb972e652201c3c6)) * image paths ([692b7cc](https://github.com/dwmkerr/hacker-laws/commit/692b7cca1a97eb62384db170297b504f51ea408e)) * remove superfluous 'is' ([3b78ae6](https://github.com/dwmkerr/hacker-laws/commit/3b78ae65f02fca457bb8adbf113135e1ed042a46)) ================================================ FILE: .github/CODE_OF_CONDUCT.md ================================================ # Contributor Covenant Code of Conduct ## Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. ## Our Standards Examples of behavior that contributes to creating a positive environment include: * Using welcoming and inclusive language * Being respectful of differing viewpoints and experiences * Gracefully accepting constructive criticism * Focusing on what is best for the community * Showing empathy towards other community members Examples of unacceptable behavior by participants include: * The use of sexualized language or imagery and unwelcome sexual attention or advances * Trolling, insulting/derogatory comments, and personal or political attacks * Public or private harassment * Publishing others' private information, such as a physical or electronic address, without explicit permission * Other conduct which could reasonably be considered inappropriate in a professional setting ## Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. ## Scope This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at dwmkerr@gmail.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html [homepage]: https://www.contributor-covenant.org For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq ================================================ FILE: .github/FUNDING.yml ================================================ # Support 'GitHub Sponsors' funding. github: dwmkerr ================================================ FILE: .github/contributing.md ================================================ # Contributing Guidelines - [Goal of the Project](#goal-of-the-project) - [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions) - [Translations](#translations) - [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) - [Use of Images](#use-of-images) - [Developer Guide](#developer-guide) ## 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. 2. Include the original source. 3. Quote the law if possible, with the author's name. 4. Link to related laws in the 'See also' section. 5. Include real-world examples if possible in the 'Real-world examples' section. Some other tips: - It is fine to include laws which are humorous or not serious. - If a law does not obviously apply to development or coding, include a paragraph explaining the relevance to technologists. - Don't worry about managing the table of contents, I can generate it. - Feel free to include images, but aim to keep it down to one image per law. - 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: --- ## 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/) > All non-trivial abstractions, to some degree, are leaky. > > (Joel 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. An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of. The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network, but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy. The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases. See also: - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces) 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. ## Translations 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) If you would like to moderate a language, please follow the steps below: 1. Log in to [Git Localize](https://gitlocalize.com) with your GitHub account, this will create a GitLocalize account for you. 0. [Open an Issue](https://github.com/dwmkerr/hacker-laws/issues/new) with the name of the language you would like to moderate/translate. 0. [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/compare) that adds your details and the language details to the [Translators](https://github.com/dwmkerr/hacker-laws#translations) section of the README. 3. I will then make you a moderator of the language and ensure the language is listed properly. Thanks! ## 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?'. ## Use of Images Please make sure to attribute images properly if you are referencing them. Also, include a white background, as some viewers will be viewing the site in 'Dark Mode' which can make images with a transparent background difficult to read. ## Developer Guide Where possible, anything which is not the core `README.md` file is kept in the `.github/` folder to keep the landing page for the repository as clean as possible. To use the makefile, pass its path explicitly, e.g: ```bash make -f .github/makefile ``` Or create an alias: ```bash alias hlmake="make -f .github/makefile" ================================================ FILE: .github/makefile ================================================ default: help .PHONY: help help: # Show help for each of the Makefile recipes. @grep -E '^[a-zA-Z0-9 -]+:.*#' Makefile | sort | while read -r l; do printf "\033[1;32m$$(echo $$l | cut -f 1 -d':')\033[00m:$$(echo $$l | cut -f 2- -d'#')\n"; done .PHONY: prepare-markdown prepare-markdown: # Prepare the markdown for PDF output. ./scripts/prepare-markdown-for-ebook.sh "README.md" "hacker-laws.md" .PHONY: create-pdf create-pdf: # Create the PDF. docker run --rm \ --platform linux/amd64 \ -v ${PWD}:/data \ pandoc/latex:3.6 \ -V toc-title:"Table Of Contents" \ --toc \ --pdf-engine=lualatex \ --standalone \ --output hacker-laws.pdf \ hacker-laws.md ================================================ FILE: .github/pull_request_template.md ================================================ **Pull Request Checklist** Please double check the items below! - [ ] 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). - [ ] I am happy to have my changes merged, so that I appear as a contributor, but also the text altered if required to keep the language consistent in the project. And don't forget: - I can handle the table of contents, feel free to leave it out. - Check to see if other laws should link back to the law you have added. - Include your **Twitter Handle** if you want me to include you when tweeting this update! ================================================ FILE: .github/release-please-config.json ================================================ { "release-type": "simple", "bump-minor-pre-major": true, "packages": { ".": { "release-type": "simple", "extra-files": [ { "type": "generic", "path": "README.md" } ], "changelog-path": ".github/CHANGELOG.md" } } } ================================================ FILE: .github/release-please-manifest.json ================================================ { ".": "0.5.0" } ================================================ FILE: .github/website/backup/ideas.md ================================================ ================================================ FILE: .github/website/backup/index2.html ================================================ Hacker Laws

Hacker Laws

Laws, Theories, Principles and Patterns that developers will find useful.

Introduction

There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!

Note: This repo contains an explanation of some laws, principles and patterns, but does not advocate for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.

↑ Top

90–9–1 Principle (1% Rule)

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:

See Also: Pareto Principle

↑ Top

90–90 Rule

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

This is a wry reinterpretation of the Pareto Principle (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in Hofstadter's Law.

↑ Top
================================================ FILE: .github/website/backup/index3.html ================================================ Hacker Laws

Hacker Laws

Laws, Theories, Principles and Patterns that developers will find useful.

Introduction

There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!

Note: This repo contains an explanation of some laws, principles and patterns, but does not advocate for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.

↑ Top

90–9–1 Principle (1% Rule)

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:

See Also: Pareto Principle

↑ Top

90–90 Rule

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

This is a wry reinterpretation of the Pareto Principle (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in Hofstadter's Law.

↑ Top
================================================ FILE: .github/website/backup/index4.html ================================================ ================================================ FILE: .github/website/generate.py ================================================ """Generate the Hacker Laws website from the Hacker Laws README""" import argparse import os import shutil from jinja2 import Environment, FileSystemLoader import markdown from bs4 import BeautifulSoup def bisect_text(content: str, bisect_line: str) -> tuple[str, str]: lines = content.splitlines() head = [] tail = [] found = False for line in lines: if found is False and line == bisect_line: found = True continue if found: tail.append(line) else: head.append(line) return ("\n".join(head), "\n".join(tail)) def load_template(): """Load Jinja2 template from the specified directory.""" env = Environment(loader=FileSystemLoader(TEMPLATE_DIR)) return env.get_template(TEMPLATE_FILE) def prepare_markdown(path: str) -> str: """ Pre-process the README markdown by removing content we will not show in the final website. """ # Load the markdown content. with open(path, "r", encoding="utf-8") as f: content = f.read() return content def parse_markdown(markdown_content: str): (_, remains) = bisect_text(markdown_content, "---") (links, remains) = bisect_text(remains, "---") (_, content) = bisect_text(remains, "") md = markdown.Markdown(extensions=['toc']) links = md.convert(links) print(f"links: {links}") md.convert(content) toc = md.toc markdown_sections = content.split("\n#") # Split by Markdown headings sections = [] laws = [] for markdown_section in markdown_sections: if markdown_section.strip(): lines = markdown_section.split("\n", 1) title = lines[0].strip("# ").strip() content = md.convert(lines[1] if len(lines) > 1 else "") full_content = md.convert(markdown_section) id = title.lower().replace(" ", "-") laws.append({"title": title, "content": content, "id": id}) sections.append({ "title": title, "content": content, "id": id, "full_content": full_content }) return (links, toc, sections) def extract_static_files(html_content, output_dir): """ Extract linked CSS, JS, and image files and copy them to the output directory. """ soup = BeautifulSoup(html_content, "html.parser") files_to_copy = [] # Extract stylesheets for link in soup.find_all("link", href=True): href = link["href"] if not href.startswith(("http", "//")): # Ignore external links files_to_copy.append(href) # Extract

Hacker Laws

Laws, Theories, Principles and Patterns that developers will find useful.

{{ links }}
{{ toc }}
{% for section in sections %}
{{ section.full_content | safe }}
{% endfor %}
================================================ FILE: .github/website/src/script.js ================================================ $(document).ready(function() { $("h1, h2, h3, h4, h5, h6").each(function() { var $heading = $(this); var headingId = $heading.attr("id") || $heading.text().trim().toLowerCase().replace(/\s+/g, "-"); // Ensure a unique ID $heading.attr("id", headingId); // Create the anchor link var $anchor = $('') .attr("href", "#" + headingId) .addClass("header-link") .html("#"); // Append to the heading $heading.append($anchor); }); // Bootstrap requires that blockquote elements have the 'blockquote' class. $('blockquote').addClass('blockquote').addClass('.quote'); }); ================================================ FILE: .github/website/src/styles.css ================================================ html { scroll-behavior: auto !important; } body { font-family: 'Inter', sans-serif; background-color: #fff; color: #333; padding-top: 70px; } .container { max-width: 800px; } header { text-align: center; margin-bottom: 2rem; padding: 2rem 0; border-bottom: 1px solid #e5e5e5; } h1, h2, h3, h4, h5, h6 { font-family: 'Libre Baskerville', serif; /* Avoid scrolling under the sticky header. */ scroll-margin-top: 80px; } blockquote { font-style: italic; } .law-section { margin-bottom: 2rem; padding: 1.5rem; background-color: #fff; border-bottom: 1px solid #e5e5e5; position: relative; } .law-section h2 { position: relative; display: flex; align-items: center; } .law-section h2 a.anchor { text-decoration: none; color: #999; margin-left: 0.5rem; visibility: hidden; } .law-section:hover h2 a.anchor { visibility: visible; } .social-sharing a { margin-right: 0.75rem; font-size: 1.2rem; color: #555; text-decoration: none; } .social-sharing a:hover { color: #000; } .back-to-top { margin-top: 1rem; } /* Initially hide the hash link */ .header-link { text-decoration: none; margin-left: 12px; /* Increased left padding */ opacity: 0; transition: opacity 0.2s; font-size: inherit; /* Matches the heading size */ } /* Only show the hash when the whole section is hovered */ section:hover .header-link, article:hover .header-link, div:hover .header-link { opacity: 1; } ================================================ FILE: .github/workflows/cicd.yaml ================================================ name: CI/CD on: push: branches: [main] pull_request: workflow_dispatch: # Permissions to check contents and open PR (release pleases) and update pages. permissions: contents: write pull-requests: write pages: write id-token: write jobs: test-website-build: runs-on: ubuntu-24.04 steps: - name: Checkout uses: actions/checkout@v4 - name: Test Website Build run: | cd .github/website make install make build cp -r build/. '../pages' ls -al "../pages" release: needs: test-website-build runs-on: ubuntu-24.04 outputs: released: ${{ steps.release-please.outputs.release_created }} tag: ${{ steps.release-please.outputs.tag_name }} steps: - uses: googleapis/release-please-action@v4 id: release-please with: manifest-file: .github/release-please-manifest.json config-file: .github/release-please-config.json release-pdf: runs-on: ubuntu-24.04 needs: release if: ${{ needs.release.outputs.released }} steps: - name: Checkout uses: actions/checkout@v4 # Set a descriptive version. For PRs it'll be the short sha. - name: Check Version run: echo "${VERSION}" env: VERSION: ${{ needs.release.outputs.tag }} # Set a descriptive version. For PRs it'll be the short sha. - name: Prepare Markdown run: | # Set the env vars we use (version set for clarity). export DATE=$(date +%F) export VERSION="${VERSION}" make -f .github/makefile prepare-markdown env: VERSION: ${{ needs.release.outputs.tag }} # Create the PDF files. - name: Create PDF run: make -f .github/makefile create-pdf # Publish the PDF and intermediate markdown as an artifact. # - name: Publish PDF Artifact # uses: actions/upload-artifact@3 # with: # name: hacker-laws.pdf # path: hacker-laws.pdf - name: Attach assets to GitHub Release env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | gh release upload "${{ needs.release.outputs.tag }}" --clobber hacker-laws.pdf hacker-laws.md deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-24.04 needs: release if: ${{ needs.release.outputs.released }} steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Pages uses: actions/configure-pages@v5 - name: Build Website run: | cd .github/website make install make build cp -r build/. '../pages' ls -al "../pages" - name: Upload artifact uses: actions/upload-pages-artifact@v3 with: path: './.github/pages' - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4 ================================================ FILE: .gitignore ================================================ .DS_Store ================================================ FILE: LICENSE ================================================ Copyright (c) Dave Kerr 2021 # 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. ================================================ FILE: README.md ================================================

hacker-laws

🧠 Laws, Theories, Principles and Patterns for developers and technologists.

--- - 📖 My new book [Effective Shell (Online Version)](https://effective-shell.com) on [Amazon (Print/Kindle)](https://amzn.to/4ho0F91) - 🌍 Try [hacker-laws.com](https://hacker-laws.com) - 🧠 Check out my new project [Terminal AI](https://github.com/dwmkerr/terminal-ai) - ☕️ Like this project? Consider [buying me a coffee with a one-off donation](https://github.com/sponsors/dwmkerr?frequency=one-time) - 🎧 Listen to the podcast [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403) - 📖 Download the [PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) - 🌏 See the Translations: [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md) --- - [Introduction](#introduction) - [Laws](#laws) - [90–9–1 Principle (1% Rule)](#9091-principle-1-rule) - [90–90 Rule](#9090-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) - [Clarke's three laws](#clarkes-three-laws) - [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) - [Jevons' Paradox](#jevons-paradox) - [Input-Process-Output (IPO)](#input-process-output-ipo) - [Kernighan's Law](#kernighans-law) - [Koomey's Law](#koomeys-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 Bitter Lesson](#the-bitter-lesson) - [The Ringelmann Effect](#the-ringelmann-effect) - [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 the Instrument](#the-law-of-the-instrument) - [The Law of Triviality](#the-law-of-triviality) - [The Unix Philosophy](#the-unix-philosophy) - [The Scout Rule](#the-scout-rule) - [The Spotify Model](#the-spotify-model) - [The Two Pizza Rule](#the-two-pizza-rule) - [Twyman's law](#twymans-law) - [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) - [Chesterton's Fence](#chestertons-fence) - [Kerckhoffs's principle](#kerckhoffss-principle) - [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 Stochastic Parrot](#the-stochastic-parrot) - [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) - [The Open/Closed Principle](#the-openclosed-principle) - [The Liskov Substitution Principle](#the-liskov-substitution-principle) - [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) - [The Principle of Least Astonishment](#the-principle-of-least-astonishment) - [Reading List](#reading-list) - [Online Resources](#online-resources) - [PDF eBook](#pdf-ebook) - [Podcast](#podcast) - [Contributors](#contributors) ## Introduction There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs! Warning: This repo contains an explanation of some laws, principles and patterns, but does not _advocate_ for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on. ## Laws Laws can be opinions on inevitabilities in the world of software engineering, or wry observations on unavoidable realities. ### 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) ### 90–90 Rule [90-90 Rule on Wikipedia](https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule) > The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. A wry reinterpretation of the [Pareto Principe (or 80-20 rule)](#the-pareto-principle-the-8020-rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in [Hofstadter's Law](#hofstadters-law). See also: - [Hofstadter's Law](#hofstadters-law) - [The Pareto Principe](#the-pareto-principle-the-8020-rule) ### Amdahl's Law [Amdahl's Law on Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law) > Amdahl's Law is a formula which shows the _potential speedup_ of a computational task which can be achieved by increasing the resources of a system. Normally used in parallel computing, it can predict the actual benefit of increasing the number of processors, which is limited by the parallelisability of the program. Best illustrated with an example. If a program is made up of two parts, part A, which must be executed by a single processor, and part B, which can be parallelised, then we see that adding multiple processors to the system executing the program can only have a limited benefit. It can potentially greatly improve the speed of part B - but the speed of part A will remain unchanged. The diagram below shows some examples of potential improvements in speed: Diagram: Amdahl's Law 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. As [Moore's Law](#moores-law) slows, and the acceleration of individual processor speed slows, parallelisation is key to improving performance. Graphics programming is an excellent example - with modern Shader based computing, individual pixels or fragments can be rendered in parallel - this is why modern graphics cards often have many thousands of processing cores (GPUs or Shader Units). 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.wikipedia.org/wiki/Brooks%27s_law) > Adding human resources to a late software development project makes it later. This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp-up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower. The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks' Law, in particular, the fact that some kinds of work are not divisible or parallelisable. This is a central theme of the book '[The Mythical Man Month](#reading-list)'. 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) ### Clarke's three laws [Clarke's three laws on Wikipedia](https://en.wikipedia.org/wiki/Clarke's_three_laws) Arthur C. Clarke, an british science fiction writer, formulated three adages that are known as Clarke's three laws. The third law is the best known and most widely cited. These so-called laws are: - When a distinguished but elderly scientist states that something is possible, they are almost certainly right. When they state that something is impossible, they are very probably wrong. - The only way of discovering the limits of the possible is to venture a little way past them into the impossible. - Any sufficiently advanced technology is indistinguishable from magic. ### Conway's Law [Conway's Law on Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law) This law suggests that the technical boundaries of a system will reflect the structure of the organisation. It is commonly referred to when looking at organisation improvements, Conway's Law suggests that if an organisation is structured into many small, disconnected units, the software it produces will be. If an organisation is built more around 'verticals' which are oriented around features or services, the software systems will also reflect this. 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) "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, "the number of people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar." Estimates for the number generally lay between 100 and 250. Like stable relationships between individuals, a developer's relationship with a codebase takes effort to maintain. When faced with large complicated projects, or ownership of many projects, we lean on convention, policy, and modeled procedure to scale. Dunbar's number is not only important to keep in mind as an office grows, but also when setting the scope for team efforts or deciding when a system should invest in tooling to assist in modeling and automating logistical overhead. Putting the number into an engineering context, it is the number of projects (or normalized complexity of a single project) for which you would feel confident in joining an on-call rotation to support. 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 bias is that of [Illusory superiority](https://en.wikipedia.org/wiki/Illusory_superiority). Real-world examples: ### 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 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) > Never attribute to malice that which is adequately explained by stupidity. > > Robert J. Hanlon 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) 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) 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. This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'. 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) > We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. > > (Roy Amara) The Hype Cycle is a visual representation of the excitement and development of technology over time, originally produced by Gartner. It is best shown with a visual: ![The Hype Cycle](./images/gartner_hype_cycle.png) In short, this cycle suggests that there is typically a burst of excitement around new technology and its potential impact. Teams often jump into these technologies quickly, and sometimes find themselves disappointed with the results. This might be because the technology is not yet mature enough, or real-world applications are not yet fully realised. After a certain amount of time, the capabilities of the technology increase and practical opportunities to use it increase, and teams can finally become productive. Roy Amara's quote sums this up most succinctly - "We tend to overestimate the effect of a technology in the short run and underestimate in the long run". ### Hyrum's Law (The Law of Implicit Interfaces) [Hyrum's Law Online](http://www.hyrumslaw.com/) > With a sufficient number of users of an API, > it does not matter what you promise in the contract: > all observable behaviours of your system > will be depended on by somebody. > > (Hyrum Wright) See also: - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions) - [XKCD 1172](https://xkcd.com/1172/) ### Jevons' Paradox [Jevons' Paradox on Wikipedia](https://en.wikipedia.org/wiki/Jevons_paradox) > It is wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption. The very contrary is the truth. > > _William Stanley Jevons (1865)_ Named after economist William Stanley Jevons, who observed in 1865 that improvements in coal-burning engine efficiency led to *increased* coal consumption, not decreased. More efficient engines made coal economically attractive for more applications, driving overall demand higher. In software and technology: - Faster CPUs enable more resource-intensive software - Better compression algorithms lead to larger files being shipped - Faster networks result in heavier web pages The paradox suggests efficiency gains don't reduce resource usage, but in fact can lead in time to increased consumption. [Wirth's Law](https://en.wikipedia.org/wiki/Wirth%27s_law) and [Andy and Bill's Law](https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law) are also examples of Jevon's Paradox applied to computing. See also: - [Moore's Law](#moores-law) - [Koomey's Law](#koomeys-law) ### Input-Process-Output (IPO) [Input–Process–Output on Wikipedia](https://en.wikipedia.org/wiki/IPO_model) Systems can be incredibly complex, but can typically be broken down into smaller parts that follow a simple pattern: 1. Input is provided 2. Some kind of processing or transformation is performed 3. Output is returned A sort function in a programming language or system could be a classic example of the IPO pattern; where arbitrary input is sorted based on a predicate and returned back. A web server could be modelled as an IPO system, where HTTP requests are transformed into HTTP responses. A highly complex Generative AI system could likewise be modelled in this way, with user input being passed through a complex model and a response being generated. The IPO pattern is present in different forms across almost all technological domains, from [functional programming](https://en.wikipedia.org/wiki/Functional_programming) languages that explicitly follow IPO patterns to [The Unix Philosophy](#the-unix-philosophy), which suggests that highly complex systems can be built by chaining together many simple IPO programs. See also: - [The Unix Philosophy](#the-unix-philosophy) ### 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) ### Koomey's Law [Koomey's Law on Wikipedia](https://en.wikipedia.org/wiki/Koomey%27s_law) > ...at a fixed computing load, the amount of battery you need will fall by a factor of two every year and a half. > > (Jonathan Koomey) In 2010 Professor Jonathan Koomey discovered that the trend in number of computations per joule of energy dissipated had been remarkably stable. This trend became known as Koomey's Law - that the amount of battery needed for a given computing load would half each 2.5 years. Koomey performed a follow-up analysis in 2010 and found that this trend had slowed, similar to how [Moore's Law](#moores-law) had slowed. This seemed to be related to limitations around how small transistors can be made, as well as [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling). See also: - [Moore's Law](#moores-law) - [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling) ### 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) > The number of transistors in an integrated circuit doubles approximately every two years. 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. See also: - [Koomey's Law](#koomeys-law) ### 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) > Work expands so as to fill the time available for its completion. In its original context, this Law was based on studies of bureaucracies. It may be pessimistically applied to software development initiatives, the theory being that teams will be inefficient until deadlines near, then rush to complete work by the deadline, thus making the actual deadline somewhat arbitrary. See also: - [Hofstadter's Law](#hofstadters-law) ### Premature Optimization Effect [Premature Optimization on WikiWeb](http://wiki.c2.com/?PrematureOptimization) > Premature optimization is the root of all evil. > > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) 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) > Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand. 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](#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](#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 Bitter Lesson [The Bitter Lesson by Richard S. Sutton](http://www.incompleteideas.net/IncIdeas/BitterLesson.html) > The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin. > > Richard S. Sutton (2019) The "Bitter Lesson", stated by [Rich S. Sutton](https://en.wikipedia.org/wiki/Richard_S._Sutton), says that scale (in terms of both data and computational power) has driven the most significant advancements in AI research, rather than the intricacies of the research methods themselves. He goes on to suggest that this indicates we should stop trying to build simplified (or even complex) models of the mind as history has shown that these have always in the long term been failures compared to (as an example) scaling the capacity of neural networks and applying existing methods such as convolution. ### The Ringelmann Effect [The Ringelmann effect on Wikipedia](https://en.wikipedia.org/wiki/Ringelmann_effect) The Ringelmann Effect is the tendency of an individual to become increasingly inefficient as more and more people are involved in a task. In other words, as more individuals are added to a team, the more the average individual performance decreases. Multiple causes are believed to be at work, including loss of motivation ("[social loafing](https://en.wikipedia.org/wiki/Social_loafing)") and challenges related to coordination. See also: - [Brooks' Law](#brooks-law) ### The Law of Conservation of Complexity (Tesler's Law) [The Law of Conservation of Complexity on Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) This law states that there is a certain amount of complexity in a system which cannot be reduced. Some complexity in a system is 'inadvertent'. It is a consequence of poor structure, mistakes, or just bad modeling of a problem to solve. Inadvertent complexity can be reduced (or eliminated). However, some complexity is 'intrinsic' as a consequence of the complexity inherent in the problem being solved. This complexity can be moved, but not eliminated. 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](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. The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy. The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases. See also: - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces) 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. ### The Law of the Instrument [The Law of the Instrument](https://en.wikipedia.org/wiki/Law_of_the_instrument) > I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding. > > _Abraham Kaplan_ > If all you have is a hammer, everything looks like a nail. > > _Abraham Maslow_ In the context of computer programming, this law suggests that people tend to use tools that are familiar with, rather than the best possible tool. This over-reliance on a familiar tool is an anti-pattern referred to as 'the golden hammer'. See also: - [Avoiding the law of the instrument](https://josemdev.com/avoiding-the-law-of-the-instrument/) - [Anti-Pattern - The Golden Hammer](https://archive.org/details/antipatternsrefa0000unse/page/111/mode/2up) ### The Law of Triviality [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) This law suggests that groups will give far more time and attention to trivial or cosmetic issues rather than serious and substantial ones. 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. 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 [The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy) The Unix Philosophy is that software components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs. Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed of simple building blocks. ### The Scout Rule [The Scout Rule on O'Reilly](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) > Always leave the code better than you found it. > > (Robert C. Martin (Uncle Bob)) Based on the "Scout Rule", which is "always leave the campground cleaner than you found it", the Scout Rule in programming is simply "always leave the code cleaner than you found it". This was introduced in the first chapter of the book [Clean Code](https://www.goodreads.com/book/show/3735293-clean-code) by Bob Martin. The rule suggests that developers should perform 'optimistic refactoring', which means to endeavour to improve the overall quality of the code when you work on it. If you see a mistake, attempt to fix it or clean it up. However, when making changes to code which seems incorrect, it may be worth remembering [Chesterton's Fence](#chestertons-fence)! See also: - [Reading List: Clean Code](#reading-list) - [Chesterton's Fence](#chestertons-fence) - [The Broken Windows Theory](#broken-windows-theory) https://www.amazon.sg/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 ### The Spotify Model [The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) The Spotify Model is an approach to team and organisation structure which has been popularised by 'Spotify'. In this model, teams are organised around features, rather than technologies. 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 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 ### Twyman's law [Twyman's Law on Wikipedia](https://en.wikipedia.org/wiki/Twyman%27s_law) > The more unusual or interesting the data, the more likely they are to have been the result of an error of one kind or another. This law suggests that when there are particularly unusual data points, it is more likely that they are the result of errors or manipulation. For example, if a dataset of long-jump results from a sporting event showed a maximum value of 20 meters (more than twice the world record), it is more likely to be due to an error (such as recording a value in feet rather than meters) than due to an unusually long jump. It is also more likely in this case that the results could have been manipulated. See also: - [Sagan Standard](#TODO) ### 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. 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) ### Chesterton's Fence [Chesterton'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. Chesterton'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. Chesterton](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." ### Kerckhoffs's principle [Kerckhoffs's principle on Wikipedia](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle) > "...design your system assuming that your opponents know it in detail." > > _Steven M. Bellovin's formulation of Kerckhoff's Principle_ This principle of cryptography was an axiom created by cryptographer Auguste Kerckhoffs. He stated that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge. Not to be confused with [_"security through obscurity"_](#todo). The gold standard for any secret-keeping system is that implementation details should be publicly distributed, without sacrificing or compromising security of said system. The history of cryptography has shown that open discussion and analysis of cryptographic systems leads to better and more secure systems - as researchers are able to test for and expose potential vulnerabilities. - [Shannon's Maxim](#todo) ### 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) > Most things in life are not distributed evenly. The Pareto Principle suggests that in some cases, the majority of results come from a minority of inputs: - 80% of a certain piece of software can be written in 20% of the total allocated time (conversely, the hardest 20% of the code takes 80% of the time) - 20% of the effort produces 80% of the result - 20% of the work creates 80% of the revenue - 20% of the bugs cause 80% of the crashes - 20% of the features cause 80% of the usage 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. 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 Stochastic Parrot [On the Dangers of Stochastic Parrots - Bender, Gebru, et al. (2021)](https://dl.acm.org/doi/10.1145/3442188.3445922) > Contrary to how it may seem when we observe its output, an LM is a system for haphazardly stitching together sequences of linguistic forms it has observed in its vast training data, according to probabilistic information about how they combine, but without any reference to meaning: a stochastic parrot. > > _Emily M. Bender, Timnit Gebru, et al. (2021)_ The term argues that Large Language Models (LLMs) produce statistically likely sequences of text based on training data, without genuine comprehension. Essentially - confident-sounding output is not evidence of correctness or understanding. Models can (and do) "hallucinate" - producing plausible sounding output or confidently making statements which are demonstrably wrong. This does not devalue these models, but highlights important characteristics which must be accounted for when using them. See also: - [The Bitter Lesson](#the-bitter-lesson) - [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law) ### 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 skill 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 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) ### SOLID This is an acronym, which refers to: These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems. ### The Single Responsibility Principle [The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle) > Every module or class should have a single responsibility only. The first of the '[SOLID](#solid)' principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program. Theoretically, this should make the code more robust, and easier to change. Knowing that a component being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities. See also: - [Object-Oriented Programming](#todo) - [SOLID](#solid) ### The Open/Closed Principle [The Open/Closed Principle on Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) > Entities should be open for extension and closed for modification. 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. 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. See also: - [Object-Oriented Programming](#todo) - [SOLID](#solid) ### The Liskov Substitution Principle [The Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle) > It should be possible to replace a type with a subtype, without breaking the system. The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is. As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be usable in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle. This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system. See also: - [Object-Oriented Programming](#todo) - [SOLID](#solid) ### The Interface Segregation Principle [The Interface Segregation Principle on Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle) > No client should be forced to depend on methods it does not use. The fourth of the '[SOLID](#solid)' principles. This principle states that consumers of a component should not depend on functions of that component which it doesn't actually use. As an example, imagine we have a method which reads an XML document from a structure which represents a file. It only needs to read bytes, move forwards or move backwards in the file. If this method needs to be updated because an unrelated feature of the file structure changes (such as an update to the permissions model used to represent file security), then the principle has been invalidated. It would be better for the file to implement a 'seekable-stream' interface, and for the XML reader to use that. This principle has particular relevance for object-oriented programming, where interfaces, hierarchies and abstract types are used to [minimise the coupling](#todo) between different components. [Duck typing](#todo) is a methodology which enforces this principle by eliminating explicit interfaces. See also: - [Object-Oriented Programming](#todo) - [SOLID](#solid) - [Duck Typing](#todo) - [Decoupling](#todo) ### The 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. The fifth of the '[SOLID](#solid)' principles. This principle states that higher-level orchestrating components should not have to know the details of their dependencies. As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc. This principle is complex, as it can seem to 'invert' the expected dependencies of a system (hence the name). In practice, it also means that a separate orchestrating component must ensure the correct implementations of abstract types are used (e.g. in the previous example, _something_ must still provide the metadata reader component a HTTP file downloader and HTML meta tag reader). This then touches on patterns such as [Inversion of Control](#todo) and [Dependency Injection](#todo). See also: - [Object-Oriented Programming](#todo) - [SOLID](#solid) - [Inversion of Control](#todo) - [Dependency Injection](#todo) ### The DRY Principle [The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) > The opposite of DRY would be _WET_ (Write Everything Twice or We Enjoy Typing). In practice, if you have the same piece of information in two (or more) different places, you can use DRY to merge them into a single one and reuse it wherever you want/need. See also: - [The Pragmatic Programmer](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) > 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) ### The Principle of Least Astonishment [The Principle of Least Astonishment on Wikipedia](https://en.wikipedia.org/wiki/Principle_of_least_astonishment) > People are part of the system. The design should match the user's experience, expectations, and mental models. > > Frans Kaashoek This principle proposes that systems and interfaces should be designed in a way that features and functionality is easily discovered and matches users expectations. Features that 'surprise' users should be discouraged in favour of features that can be intuitively reasoned about based on existing patterns and practices. Many examples are present in user interfaces, such as a 'pull down' gesture on a mobile appliation to refresh content. Another example would be command line tools, where many standards exist for how parameters are named, common parameters that should be available and so on. See also: - [Convention Over Configuration](#todo) ## Reading List If you have found these concepts interesting, you may enjoy the following books. - [Clean Code - Robert C. Martin](https://www.goodreads.com/book/show/3735293-clean-code) - One of the most well respected books on how to write clean, maintainable code. - [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming. - [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. - [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. - [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 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. - [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). ## 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 ## Contributors Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)):
Amir Hemmati
Amir Hemmati
📖
This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome! ================================================ FILE: assets/site/index.html ================================================ Interactive Hacker Laws Stack
================================================ FILE: assets/site/index2.html ================================================ Interactive Hacker Laws Stack
================================================ FILE: assets/site/index3.html ================================================ Interactive Hacker Laws Stack
================================================ FILE: assets/site/index4.html ================================================ Interactive Hacker Laws Stack
================================================ FILE: scripts/prepare-markdown-for-ebook.sh ================================================ #!/usr/bin/env bash # Fail on errors. set -e -o pipefail # Check if parameters are provided input="$1" output="$2" if [ -z "${input}" ] || [ -z "${output}" ]; then echo "usage: $(basename "$0") " >&2 echo " input: source markdown file (usually README.md)" >&2 echo " output: output markdown file (usually hacker-laws.md)" >&2 exit 1 fi # Grab env vars used to configure output, fail if required are missing. export date="${DATE:-$(date +%F)}" export version="${VERSION?error: VERSION must be set}" # Update the input file to an intermedate. intermediate="${input}.temp" cat < "${intermediate}" --- title: "Hacker Laws" author: "Dave Kerr, github.com/dwmkerr/hacker-laws" subtitle: "Laws, Theories, Principles, and Patterns that developers will find useful. ${VERSION}, ${DATE}." version: ${VERSION} --- EOF cat "${input}" >> "${intermediate}" DATE="${date}" VERSION="${version}" envsubst < "${intermediate}" > "${output}" # Use a single `sed` command to clean up unwanted lines and emojis in one pass. sed -e '/💻📖.*/d' \ -e 's/❗/Warning/g' \ -e '/^\[Translations.*/d' \ -e '/\*.*/d' \ -e '/ \*.*/d' \ -e '/## Translations/,$d' "${output}" > "${intermediate}" mv "${intermediate}" "${output}" echo "${output} prepared successfully." ================================================ FILE: translations/es-ES.md ================================================ # 💻📖 hacker-laws Leyes, Teorías, Principios y Patrones que los desarrolladores encontrarán útiles. [traducciones](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md) ¿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. ================================================ FILE: translations/fr.md ================================================ # 💻📖 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/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md) 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 sous-estimer 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 limiter 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. ================================================ FILE: translations/id.md ================================================ # 💻📖 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). [terjemahan](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md) 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. ================================================ FILE: translations/it-IT.md ================================================ # 💻📖 hacker-laws Leggi, teorie, principi e pattern utili agli sviluppatori. [traduzioni](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md) --- * [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. ================================================ FILE: translations/jp.md ================================================ # 💻📖 ハッカーの法則 開発者が役に立つと思う法則、理論、原則、パターン。 [翻訳](#翻訳): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.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%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87) > 十分な目ん玉があれば、全てのバグは洗い出される。 > > _エリック・S・レイモンド_ この法則は簡単に言うと、あるプログラムを見る人が多ければ多いほど、誰かがその問題を以前に見て解決している可能性が高くなる、あるいはそれに非常に近い状況になる、というものです。 元々はプロジェクトのオープンソースモデルの価値を説明するために使われましたが、どんなソフトウェアプロジェクトにも当てはまります。プロセスにも拡大して適用できます。より多くのコードレビューや静的解析、また多角的なテストプロセスによって、問題をより可視化されて識別しやすくなります。 より格式ばって言うと以下のようになります。 > ベータテスターと共同開発者が十分多くいれば、ほとんど全ての問題はすぐに明確になり、似た問題に以前遭遇したことのある人によって解決されるだろう。 この法則は、エリック・S・レイモンドの著作『[伽藍とバザール](https://ja.wikipedia.org/wiki/%E4%BC%BD%E8%97%8D%E3%81%A8%E3%83%90%E3%82%B6%E3%83%BC%E3%83%AB)』の中で、[リーナス・トーバルズ](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%83%BB%E3%83%88%E3%83%BC%E3%83%90%E3%83%AB%E3%82%BA)に敬意を表して名付けられました。 ### メトカーフの法則 [メトカーフの法則-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) をご利用ください。 文章やスタイルなどの要件については、[Contributing Guidelines](./.github/contributing.md) を必ずお読みください。プロジェクトの議論に参加する際には、[Code of Conduct](./.github/CODE_OF_CONDUCT.md)を意識してください。 ## TODO こんにちは！あなたがここに来たということは、私がまだ書き上げていないトピックへのリンクをクリックしたことにですね。 リクエストしたい場合は [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) をクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。 ================================================ FILE: translations/lv.md ================================================ # 💻📖 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. [tulkojumi](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md) --- * [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). ================================================ FILE: translations/pl.md ================================================ # 💻📖 prawa-hakerskie Prawa, teorie, zasady i wzorce, które programiści uznają za przydatne. [Tłumaczenia](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇻🇳](./translations/vi.md) Podoba Ci się ten projekt? Proszę rozważyć [sponsorowanie mnie](https://github.com/sponsors/dwmkerr) i [tłumaczy](#translations) . Sprawdź również ten podcast na [The Changelog - Laws for Hackers to Live By,](https://changelog.com/podcast/403) aby dowiedzieć się więcej o projekcie! Możesz także [pobrać najnowszy e-book w formacie PDF](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) . Sprawdź [Przewodnik](./.github/contributing.md) dla twórców, jeśli chcesz wnieść swój wkład! --- - [Wstęp](#wstęp) - [Prawa](#prawa) - [Zasada 90-9-1 (zasada 1%)](#zasada-90-9-1-zasada-1) - [Prawo Amdahla](#prawo-amdahla) - [Teoria zepsutych okien](#teoria-zepsutych-okien) - [Prawo Brooksa](#prawo-brooksa) - [Twierdzenie CAP (Twierdzenie Brewera)](#twierdzenie-cap-twierdzenie-brewera) - [Prawo Conwaya](#prawo-conwaya) - [Prawo Cunninghama](#prawo-cunninghama) - [Numer Dunbara](#numer-dunbara) - [Efekt Dunninga-Krugera](#efekt-dunninga-krugera) - [Prawo Fittsa](#prawo-fittsa) - [Prawo Galla](#prawo-galla) - [Prawo Goodharta](#prawo-goodharta) - [Brzytwa Hanlona](#brzytwa-hanlona) - [Prawo Hicka (Prawo Hicka-Hymana)](#prawo-hicka-prawo-hicka-hymana) - [Prawo Hofstadtera](#prawo-hofstadtera) - [Prawo Hutbera](#prawo-hutbera) - [Cykl szumu i prawo Amary](#cykl-szumu-i-prawo-amary) - [Prawo Hyruma (prawo niejawnych interfejsów)](#prawo-hyruma-prawo-niejawnych-interfejsów) - [Prawo Kernighana](#prawo-kernighana) - [Prawo Linusa](#prawo-linusa) - [Prawo Metcalfego](#prawo-metcalfego) - [prawo Moore'a](#prawo-moorea) - [Prawo Murphy'ego / Prawo Soda](#prawo-murphyego--prawo-soda) - [Brzytwa Ockhama](#brzytwa-ockohama) - [Prawo Parkinsona](#prawo-parkinsona) - [Przedwczesny efekt optymalizacji](#przedwczesny-efekt-optymalizacji) - [Prawo Putta](#prawo-putta) - [Prawo Reeda](#prawo-reeda) - [Prawo zachowania złożoności (prawo Teslera)](#prawo-zachowania-złożoności-prawo-teslera) - [Prawo Demeter](#prawo-demeter) - [Prawo nieszczelnych abstrakcji](#prawo-nieszczelnych-abstrakcji) - [Prawo trywialności](#prawo-trywialności) - [Filozofia Uniksa](#filozofia-uniksa) - [Zasada Skauta](#zasada-skauta) - [Model Spotify](#model-spotify) - [Zasada dwóch pizzy](#zasada-dwóch-pizzy) - [Prawo Wadlera](#prawo-wadlera) - [Prawo Wheatona](#prawo-wheatona) - [Zasady](#zasady) - [Wszystkie modele są błędne (prawo George'a Boxa)](#wszystkie-modele-są-błędne-prawo-georgea-boxa) - [Płot Chestertona](#płot-chestertona) - [Efekt Morza Martwego](#efekt-morza-martwego) - [Zasada Dilberta](#zasada-dilberta) - [Zasada Pareto (Zasada 80/20)](#zasada-pareto-zasada-8020) - [Zasada Shirky](#zasada-shirky) - [Zasada Piotra](#zasada-piotra) - [Zasada solidności (prawo Postela)](#zasada-solidarności-prawo-postela) - [SOLID](#solid) - [Zasada pojedynczej odpowiedzialności](#zasada-pojedynczej-odpowiedzialności) - [Zasada otwarcia/zamknięcia](#zasada-otwarcia-zamknięcia) - [Zasada substytucji Liskov](#zasada-substytucji-liskov) - [Zasada segregacji interfejsów](#zasada-segregacji-interfejsów) - [Zasada odwrócenia zależności](#zasada-odwrócenia-zależności) - [Zasada DRY](#zasada-dry) - [Zasada KISS](#zasada-kiss) - [YAGNI](#yagni) - [Błędy przetwarzania rozproszonego](#błędy-przetwarzania-rozproszonego) - [Lista rzeczy do przeczytania](#lista-rzeczy-do-przeczytania) - [Zasoby online](#zasoby-online) - [eBook w formacie PDF](#ebook-w-formacie-pdf) - [Podcast](#podcast) - [Tłumaczenia](#tłumaczenia) - [Powiązane projekty](#powiązane-projekty) - [Przyczynianie się](#przyczynianie-się) - [DO ZROBIENIA](#do-zrobienia) ## Wstęp Istnieje wiele praw, o których ludzie dyskutują, mówiąc o rozwoju. To repozytorium jest odniesieniem i przeglądem niektórych z najczęstszych. Podziel się i prześlij PR! Odpowiedź: To repozytorium zawiera wyjaśnienie niektórych praw, zasad i wzorców, ale nie *zaleca* żadnego z nich. To, czy należy je zastosować, zawsze będzie kwestią dyskusyjną i w dużej mierze zależy od tego, nad czym pracujesz. ## Prawa No to zaczynamy! ### Zasada 90-9-1 (zasada 1%) [Reguła 1% na Wikipedii](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)) Zasada 90-9-1 sugeruje, że w społeczności internetowej, takiej jak wiki, 90% uczestników tylko korzysta z treści, 9% edytuje lub modyfikuje treść, a 1% uczestników dodaje treść. Przykłady ze świata rzeczywistego: - Badanie z 2014 roku czterech cyfrowych portali społecznościowych poświęconych zdrowiu wykazało, że 1% najpopularniejszych tworzy 73% postów, kolejne 9% stanowiło średnio ~25%, a pozostałe 90% stanowiło średnio 2% ( [Odniesienie](https://www.jmir.org/2014/2/e33/) ) Zobacz też: - [Zasada Pareto](#the-pareto-principle-the-8020-rule) ### Prawo Amdahla [Prawo Amdahla na Wikipedii](https://pl.wikipedia.org/wiki/Prawo_Amdahla) > Prawo Amdahla to wzór pokazujący *potencjalne przyspieszenie* zadania obliczeniowego, które można osiągnąć zwiększając zasoby systemu. Zwykle używany w obliczeniach równoległych, może przewidzieć rzeczywiste korzyści ze zwiększenia liczby procesorów, co jest ograniczone przez możliwość równoległości programu. Najlepiej zilustrowane przykładem. Jeśli program składa się z dwóch części, części A, która musi być wykonywana przez pojedynczy procesor, i części B, która może być zrównoleglona, to widzimy, że dodanie wielu procesorów do systemu wykonującego program może mieć tylko ograniczoną korzyść . Potencjalnie może znacznie poprawić prędkość części B - ale prędkość części A pozostanie niezmieniona. Poniższy diagram pokazuje kilka przykładów potencjalnej poprawy szybkości: Schemat: Prawo Amdahla *(Odniesienie do obrazu: Daniels219 z angielskiej Wikipedii, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* Jak widać, nawet program, który można zrównoleglać w 50%, przyniesie niewiele korzyści poza 10 jednostkami przetwarzania, podczas gdy program, który można zrównolelizować w 95%, nadal może osiągnąć znaczną poprawę szybkości przy ponad tysiącu jednostek przetwarzania. Ponieważ [prawo Moore'a](#moores-law) zwalnia, a przyspieszenie szybkości poszczególnych procesorów zwalnia, równoległość jest kluczem do poprawy wydajności. Programowanie graficzne jest doskonałym przykładem - przy nowoczesnych obliczeniach opartych na Shader, pojedyncze piksele lub fragmenty mogą być renderowane równolegle - dlatego współczesne karty graficzne często mają wiele tysięcy rdzeni przetwarzających (GPU lub Shader Units). Zobacz też: - [Prawo Brooksa](#brooks-law) - [prawo Moore'a](#moores-law) ### Teoria zepsutych okien [Teoria rozbitycg okien na Wikipedii](https://pl.wikipedia.org/wiki/Teoria_rozbitych_okien) Teoria rozbitych okien sugeruje, że widoczne oznaki przestępczości (lub braku dbałości o środowisko) prowadzą do kolejnych i poważniejszych przestępstw (lub dalszego pogorszenia stanu środowiska). Teoria ta została zastosowana do rozwoju oprogramowania, co sugeruje, że kod niskiej jakości (lub [dług techniczny](#TODO) ) może prowadzić do przekonania, że wysiłki na rzecz poprawy jakości mogą być ignorowane lub niedoceniane, co prowadzi do dalszej złej jakości kodu. Ten efekt kaskadowo prowadzi do znacznego spadku jakości z biegiem czasu. Zobacz też: - [Dług techniczny](#TODO) Przykłady: - [Programowanie pragmatyczne: entropia oprogramowania](https://flylib.com/books/en/1.315.1.15/1/) - [Horror kodowania: teoria rozbitego okna](https://blog.codinghorror.com/the-broken-window-theory/) - [OpenSource: Radość z programowania — teoria rozbitego okna](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/) ### Prawo Brooksa [Prawo Brooksa na Wikipedii](https://pl.wikipedia.org/wiki/Prawo_Brooksa) > Dodanie zasobów ludzkich do spóźnionego projektu rozwoju oprogramowania sprawia, że jest to później. Prawo to sugeruje, że w wielu przypadkach próba przyspieszenia realizacji projektu, który jest już spóźniony, poprzez dodanie większej liczby osób, spowoduje, że realizacja będzie jeszcze późniejsza. Brooks nie ma wątpliwości, że jest to nadmierne uproszczenie, jednak ogólne rozumowanie jest takie, że biorąc pod uwagę czas narastania nowych zasobów i ogólne koszty komunikacji, w krótkim czasie prędkość spada. Ponadto wiele zadań może nie być podzielnych, tj. łatwo rozdzielonych między więcej zasobów, co oznacza, że potencjalny wzrost prędkości jest również mniejszy. Powszechne zdanie przy porodzie „Dziewięć kobiet nie może spłodzić dziecka w ciągu jednego miesiąca” odnosi się do prawa Brooksa, w szczególności do faktu, że niektóre rodzaje pracy nie są podzielne ani równoległe. Jest to tematem przewodnim książki „ [Miesiąc mitycznego człowieka](#reading-list) ”. Zobacz też: - [Marsz śmierci](#todo) - [Lista lektur: Miesiąc Mitycznego Człowieka](#reading-list) ### Twierdzenie CAP (Twierdzenie Brewera) Twierdzenie CAP (zdefiniowane przez Erica Brewera) stwierdza, że w przypadku rozproszonego magazynu danych można uzyskać tylko dwie z trzech następujących gwarancji (co najwyżej): - Spójność: podczas odczytu danych każde żądanie otrzymuje *najnowsze* dane lub zwracany jest błąd - Dostępność: podczas odczytu danych każde żądanie otrzymuje *odpowiedź* bez błędu, bez gwarancji, że są to *najnowsze* dane - Tolerancja partycji: gdy dowolna liczba żądań sieciowych między węzłami nie powiedzie się, system nadal działa zgodnie z oczekiwaniami Sedno rozumowania jest następujące. Nie można zagwarantować, że partycja sieciowa nie wystąpi (zobacz [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing) ). Dlatego w przypadku partycji możemy albo anulować operację (zwiększając spójność i zmniejszając dostępność) albo kontynuować (zwiększając dostępność, ale zmniejszając spójność). Nazwa pochodzi od pierwszych liter gwarancji (spójność, dostępność, tolerancja partycji). Należy pamiętać, że bardzo ważne jest, aby mieć świadomość, że *nie* dotyczy to [*ACID*](#TODO) , który ma inną definicję spójności. Niedawno [opracowano](#TODO) twierdzenie PACELC, które dodaje ograniczenia dotyczące opóźnień i spójności, gdy sieć *nie* jest podzielona na partycje (tj. gdy system działa zgodnie z oczekiwaniami). Większość nowoczesnych platform bazodanowych potwierdza to twierdzenie pośrednio, oferując użytkownikowi bazy danych opcję wyboru między operacją o wysokiej dostępności (która może obejmować „brudny odczyt”) a operacją wysoce spójną (na przykład „zapis z potwierdzeniem kworum '). Przykłady ze świata rzeczywistego: - [Wewnątrz Google Cloud Spanner i twierdzenia CAP](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) – omawia szczegóły działania Cloud Spanner, które na pierwszy rzut oka wydaje się platformą, która ma *wszystkie* gwarancje CAP, ale pod maską jest zasadniczo system CP. Zobacz też: - [KWAS](#TODO) - [Błędy przetwarzania rozproszonego](#the-fallacies-of-distributed-computing) - [PACELC](#TODO) ### Prawo Conwaya [Prawo Conwaya na Wikipedii](https://en.wikipedia.org/wiki/Conway%27s_law) Prawo to sugeruje, że granice techniczne systemu będą odzwierciedlać strukturę organizacji. Często mówi się o tym, gdy patrzymy na ulepszenia organizacji. Prawo Conwaya sugeruje, że jeśli organizacja jest podzielona na wiele małych, niepowiązanych ze sobą jednostek, tak będzie tworzone oprogramowanie. Jeśli organizacja jest zbudowana bardziej wokół „branż”, które są zorientowane na funkcje lub usługi, systemy oprogramowania również to odzwierciedlą. Zobacz też: - [Model Spotify](#the-spotify-model) ### Prawo Cunninghama [Prawo Cunninghama na Wikipedii](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law) > Najlepszym sposobem na uzyskanie prawidłowej odpowiedzi w Internecie nie jest zadawanie pytań, ale zamieszczenie błędnej odpowiedzi. Według Stevena McGeady'ego Ward Cunningham poradził mu na początku lat 80.: „Najlepszym sposobem na uzyskanie prawidłowej odpowiedzi w Internecie jest nie zadawanie pytań, ale zamieszczenie złej odpowiedzi”. McGeady nazwał to prawo Cunninghama, chociaż Cunningham zaprzecza własności, nazywając to „błędem”. Chociaż pierwotnie odnosiło się do interakcji w Usenecie, prawo zostało użyte do opisania działania innych społeczności internetowych (np. Wikipedia, Reddit, Twitter, Facebook). Zobacz też: - [XKCD 386: „Wezwania do służby”](https://xkcd.com/386/) ### Numer Dunbara [Numer Dunbara na Wikipedii](https://en.wikipedia.org/wiki/Dunbar%27s_number) „Liczba Dunbara jest sugerowanym limitem poznawczym liczby osób, z którymi można utrzymywać stabilne relacje społeczne – relacje, w których jednostka wie, kim jest każda osoba i jak każda osoba odnosi się do każdej innej osoby”. Istnieje pewna niezgodność co do dokładnej liczby. „... [Dunbar] zaproponował, że ludzie mogą wygodnie utrzymywać tylko 150 stabilnych związków”. Umieścił tę liczbę w bardziej społecznym kontekście, „liczbę osób, których nie czulibyście się zawstydzeni dołączeniem do nieproszonych drinków, gdybyście wpadli na nich w barze”. Szacunki dotyczące liczby wahają się od 100 do 250. Podobnie jak w przypadku stabilnych relacji między jednostkami, utrzymanie relacji programisty z bazą kodu wymaga wysiłku. W obliczu dużych, skomplikowanych projektów lub posiadania wielu projektów opieramy się na konwencji, zasadach i modelowanych procedurach w celu skalowania. Liczba Dunbar jest ważna nie tylko w miarę rozwoju biura, ale także przy ustalaniu zakresu działań zespołu lub decydowaniu, kiedy system powinien zainwestować w narzędzia, które pomogą w modelowaniu i automatyzacji ogólnych kosztów logistycznych. Umieszczając liczbę w kontekście inżynierskim, jest to liczba projektów (lub znormalizowana złożoność pojedynczego projektu), w przypadku których możesz czuć się pewnie, dołączając do rotacji na wezwanie, aby wesprzeć. Zobacz też: - [Prawo Conwaya](#conways-law) ### Efekt Dunninga-Krugera [Efekt Dunninga-Krugera na Wikipedii](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) > Jeśli jesteś niekompetentny, nie możesz wiedzieć, że jesteś niekompetentny... Umiejętności potrzebne do uzyskania prawidłowej odpowiedzi to dokładnie te umiejętności, których potrzebujesz, aby rozpoznać, jaka jest właściwa odpowiedź. > > ( [Dawid Dunning](https://en.wikipedia.org/wiki/David_Dunning) ) Efekt Dunninga-Krugera to teoretyczne zniekształcenie poznawcze, które zostało opisane przez Davida Dunninga i Justina Krugera w badaniu psychologicznym i artykule z 1999 roku. Badanie sugeruje, że osoby o niskim poziomie umiejętności w zadaniu prawdopodobnie przeceniają swoją zdolność do zadania. Proponowaną przyczyną tego nastawienia jest to, że *wymagana jest wystarczająca świadomość* złożoności problemu lub dziedziny, aby osoba była w stanie wyrobić sobie świadomą opinię na temat swojej zdolności do pracy w tej dziedzinie. Efekt Dunninga-Krugera był czasami używany do opisania powiązanego, ale niekoniecznie dorozumianego efektu, który można opisać jako „Im mniej dana osoba rozumie daną dziedzinę, tym bardziej prawdopodobne jest, że uwierzy, że może łatwo rozwiązać problemy w tej dziedzinie, ponieważ są bardziej skłonni do postrzegania domeny jako *prostej* ”. Ten bardziej ogólny efekt jest bardzo istotny w technologii. Sugerowałoby to, że ludzie mniej zaznajomieni z daną domeną, na przykład nietechniczni członkowie zespołu lub mniej doświadczeni członkowie zespołu, częściej *nie doceniają* wysiłku wymaganego do rozwiązania problemu w tej przestrzeni. Wraz ze wzrostem zrozumienia i doświadczenia danej osoby w danej domenie, może ona napotkać inny efekt, który polega na tym, że mają tendencję do *przeceniania* zdolności *innych* lub *niedoceniania* własnych zdolności, ponieważ są tak doświadczeni w tej domenie. We wszystkich przypadkach skutki te są *zniekształceniami poznawczymi* . Podobnie jak w przypadku każdego uprzedzenia, zrozumienie, że może ono być obecne, często wystarczy, aby uniknąć wyzwań – ponieważ gdy istnieje świadomość uprzedzenia, można uwzględnić więcej danych wejściowych i opinii, aby spróbować wyeliminować te uprzedzenia. Ściśle pokrewnym jest nastawienie [iluzorycznej wyższości](https://pl.wikipedia.org/wiki/Z%C5%82udzenie_ponadprzeci%C4%99tno%C5%9Bci) . Przykłady ze świata rzeczywistego: - [Apple kontra FBI: Dlaczego ten Anti-Terror Hawk zmienił strony](https://fortune.com/2016/03/10/apple-fbi-lindsay-graham/) – w 2016 roku senator Lindsey Graham zmienił swoje stanowisko wobec Apple, tworząc „tylne drzwi” w szyfrowaniu urządzeń. Początkowo Graham był krytyczny wobec Apple kwestionującego prośbę o stworzenie „tylnych drzwi”, które uważał za konieczne do zbadania potencjalnych spisków terrorystycznych. Jednak, jak sam przyznał Graham, gdy dowiedział się więcej o technicznej złożoności tej domeny, zdał sobie sprawę, że założył, iż jest ona o wiele prostsza, niż sądził, i że takie tylne drzwi mogą mieć poważne negatywne konsekwencje. Potencjalnie można to uznać za przykład efektu Dunninga-Krugera – ekspert ds. cyberbezpieczeństwa prawdopodobnie natychmiast zrozumie, w jaki sposób można wykorzystać takie tylne drzwi, ponieważ mają dogłębne zrozumienie domeny, laik może założyć, że zabezpieczenia telefonu są bardziej podobne do *bezpieczeństwa fizycznego,* gdzie praktyka posiadania „klucza głównego” dla organów ścigania jest możliwa, ale ta analogia nie ma wystarczającego zastosowania do opisania współczesnego szyfrowania w cyberbezpieczeństwie. ### Prawo Fittsa [Prawo Fittsa na Wikipedii](https://pl.wikipedia.org/wiki/Prawo_Fittsa) Prawo Fittsa przewiduje, że czas potrzebny do przemieszczenia się do obszaru docelowego jest funkcją odległości do celu podzielonej przez szerokość celu. Schemat: Prawo dopasowania *(Odniesienie do obrazu: Foobar628 z angielskiej Wikipedii, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)* Konsekwencje tego prawa nakazują, aby przy projektowaniu UX czy UI elementy interaktywne były jak największe, a odległość między obszarem uwagi użytkownika a elementem interaktywnym była jak najmniejsza. Ma to konsekwencje dla projektu, takie jak grupowanie zadań, które są często używane blisko siebie. Formalizuje również koncepcję „magicznych rogów”, rogów ekranu, do których użytkownik może „przesuwać” myszą, aby łatwo trafić – czyli tam, gdzie można umieścić kluczowe elementy interfejsu użytkownika. Przycisk Start systemu Windows znajduje się w magicznym rogu, co ułatwia wybór, a jako interesujący kontrast, przycisk „zamknij okno” systemu MacOS *nie* znajduje się w magicznym rogu, co utrudnia przypadkowe trafienie. Zobacz też: - [Zdolność informacyjna układu ruchu człowieka w sterowaniu amplitudą ruchu.](https://www.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d) ### Prawo Galla [Prawo Galla na Wikipedii](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) > Niezmiennie okazuje się, że złożony system, który działa, wyewoluował z prostego systemu, który działał. Złożony system zaprojektowany od podstaw nigdy nie działa i nie można go załatać, aby działał. Musisz zacząć od nowa z działającym prostym systemem. > > ( [John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)) ) Prawo Galla sugeruje, że próby *zaprojektowania* bardzo złożonych systemów mogą się nie powieść. Bardzo złożone systemy rzadko są budowane za jednym razem, ale zamiast tego ewoluują z prostszych systemów. Klasycznym przykładem jest sieć ogólnoświatowa. W obecnym stanie jest to bardzo złożony system. Jednak początkowo został zdefiniowany jako prosty sposób udostępniania treści między instytucjami akademickimi. Odniósł duży sukces w realizacji tych celów i z czasem ewoluował, by stać się bardziej złożony. Zobacz też: - [KISS (Keep It Simple, Stupid)](#the-kiss-principle) ### Prawo Goodharta [Prawo Goodharta na Wikipedii](https://en.wikipedia.org/wiki/Goodhart's_law) > Jakakolwiek zaobserwowana prawidłowość statystyczna będzie miała tendencję do załamania się, gdy zostanie na nią nałożona presja w celach kontrolnych. > > *Karola Goodharta* Również powszechnie określany jako: > Kiedy miara staje się celem, przestaje być dobrą miarą. > > *Marilyn Strathern* Prawo stanowi, że optymalizacje oparte na pomiarach mogą prowadzić do dewaluacji samego wyniku pomiaru. Nadmiernie selektywny zestaw miar ( [KPI](https://en.wikipedia.org/wiki/Performance_indicator) ) zastosowany na ślepo do procesu powoduje zniekształcony efekt. Ludzie mają tendencję do optymalizacji lokalnie, „ogrywając” system w celu spełnienia określonych wskaźników, zamiast zwracać uwagę na całościowy wynik swoich działań. Przykłady ze świata rzeczywistego: - Testy bez asertywności spełniają oczekiwania dotyczące pokrycia kodu, mimo że intencją metryki było stworzenie dobrze przetestowanego oprogramowania. - Wynik wydajności programisty wskazywany przez liczbę zatwierdzonych wierszy prowadzi do nieuzasadnionego rozdęcia bazy kodu. Zobacz też: - [Prawo Goodharta: jak mierzenie niewłaściwych rzeczy prowadzi do niemoralnych zachowań](https://coffeeandjunk.com/goodharts-campbells-law/) - [Dilbert o oprogramowaniu wolnym od błędów](https://dilbert.com/strip/1995-11-13) ### Brzytwa Hanlona [Brzytwa Hanlona na Wikipedii](https://en.wikipedia.org/wiki/Hanlon%27s_razor) > Nigdy nie przypisuj złośliwości tego, co adekwatnie tłumaczy się głupotą. > > Robert J. Hanlon Zasada ta sugeruje, że działania prowadzące do negatywnych skutków nie były wynikiem złej woli. Zamiast tego negatywny wynik jest bardziej prawdopodobnie przypisywany tym działaniom i/lub wpływowi, który nie jest w pełni zrozumiały. ### Prawo Hicka (Prawo Hicka-Hymana) [Prawo Hicka na Wikipedii](https://en.wikipedia.org/wiki/Hick%27s_law) > Czas podejmowania decyzji rośnie logarytmicznie wraz z liczbą opcji do wyboru. > > William Edmund Hick i Ray Hyman W poniższym równaniu `T` to czas na podjęcie decyzji, `n` to liczba opcji, a `b` to stała określona na podstawie analizy danych. ![Prawo Hicksa](/images/hicks_law.svg) *(Odniesienie do obrazu: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)* To prawo ma zastosowanie tylko wtedy, gdy liczba opcji jest *uporządkowana* , na przykład alfabetycznie. Jest to implikowane w logarytmie o podstawie dwa, co oznacza, że osoba podejmująca decyzje zasadniczo przeprowadza *wyszukiwanie binarne* . Jeśli opcje nie są dobrze uporządkowane, eksperymenty pokazują, że czas potrzebny jest liniowy. Ma to znaczący wpływ na projektowanie interfejsu użytkownika; zapewnienie, że użytkownicy mogą łatwo przeszukiwać opcje, prowadzi do szybszego podejmowania decyzji. W prawie Hicka wykazano również korelację między IQ a czasem reakcji, jak pokazano w [Speed of Information Processing: Developmental Change and Links to Intelligence](https://www.sciencedirect.com/science/article/pii/S0022440599000369) . Zobacz też: - [Prawo Fittsa](#fitts-law) ### Prawo Hofstadtera [Prawo Hofstadtera na Wikipedii](https://en.wikipedia.org/wiki/Hofstadter%27s_law) > Zawsze trwa to dłużej niż się spodziewasz, nawet biorąc pod uwagę prawo Hofstadtera. > > (Douglas Hofstadter) Możesz usłyszeć to prawo, o którym mowa, patrząc na szacunki, jak długo coś potrwa. Wydaje się truizmem w tworzeniu oprogramowania, że nie jesteśmy zbyt dobrzy w dokładnym szacowaniu, ile czasu zajmie dostarczenie czegoś. To jest z książki ' [Gödel, Escher, Bach: Wieczny złoty warkocz](#reading-list) '. Zobacz też: - [Lista lektur: Gödel, Escher, Bach: wieczny złoty warkocz](#reading-list) ### Prawo Hutbera [Prawo Hutbera na Wikipedii](https://en.wikipedia.org/wiki/Hutber%27s_law) > Poprawa oznacza pogorszenie. > > ( [Patryk Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber) ) To prawo sugeruje, że ulepszenia systemu doprowadzą do pogorszenia innych części lub ukryją inne pogorszenie, prowadząc ogólnie do degradacji obecnego stanu systemu. Na przykład, zmniejszenie opóźnienia odpowiedzi dla określonego punktu końcowego może spowodować dalsze problemy z przepustowością i pojemnością w przepływie żądań, wpływając na zupełnie inny podsystem. ### Cykl szumu i prawo Amary [Cykl szumu na Wikipedii](https://en.wikipedia.org/wiki/Hype_cycle) > Mamy tendencję do przeceniania wpływu technologii na krótką metę i niedoceniania jej na dłuższą metę. > > (Roy Amara) Hype Cycle to wizualna reprezentacja ekscytacji i rozwoju technologii na przestrzeni czasu, pierwotnie wyprodukowana przez firmę Gartner. Najlepiej pokazać to za pomocą wizualizacji: ![Cykl szumu](/images/gartner_hype_cycle.png) *(Odniesienie do obrazu: Jeremykemp z angielskiej Wikipedii, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* Krótko mówiąc, ten cykl sugeruje, że nowa technologia i jej potencjalny wpływ zwykle budzi ogromne zainteresowanie. Zespoły często szybko wskakują w te technologie i czasami są rozczarowane wynikami. Może to być spowodowane tym, że technologia nie jest jeszcze wystarczająco dojrzała lub aplikacje w świecie rzeczywistym nie są jeszcze w pełni zrealizowane. Po pewnym czasie zwiększają się możliwości technologii i praktyczne możliwości jej wykorzystania, a zespoły mogą wreszcie stać się produktywne. Cytat Roya Amary podsumowuje to w najbardziej zwięzły sposób: „Mamy tendencję do przeceniania wpływu technologii na krótką metę i niedoceniania na dłuższą metę". ### Prawo Hyruma (prawo niejawnych interfejsów) [Prawo Hyruma w Internecie](http://www.hyrumslaw.com/) > Przy wystarczającej liczbie użytkowników API nie ma znaczenia, co obiecujesz w kontrakcie: wszystkie obserwowalne zachowania Twojego systemu będą przez kogoś zależne. > > (Hyrum Wright) Prawo Hyrum stanowi, że gdy masz *wystarczająco dużą liczbę konsumentów* API, wszystkie zachowania API (nawet te, które nie są zdefiniowane jako część umowy publicznej) w końcu staną się przez kogoś zależne. Trywialnym przykładem mogą być elementy niefunkcjonalne, takie jak czas odpowiedzi API. Bardziej subtelnym przykładem mogą być konsumenci, którzy polegają na zastosowaniu wyrażenia regularnego do komunikatu o błędzie w celu określenia *typu* błędu interfejsu API. Nawet jeśli kontrakt publiczny interfejsu API nie mówi nic o zawartości komunikatu, wskazując, że użytkownicy powinni użyć powiązanego kodu błędu, *niektórzy* użytkownicy mogą korzystać z komunikatu, a zmiana komunikatu zasadniczo przerywa interfejs API dla tych użytkowników. Zobacz też: - [Prawo nieszczelnych abstrakcji](#the-law-of-leaky-abstractions) - [XKCD 1172](https://xkcd.com/1172/) ### Prawo Kernighana > Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Dlatego, jeśli piszesz kod tak sprytnie, jak to tylko możliwe, z definicji nie jesteś wystarczająco sprytny, aby go debugować. > > (Brian Kernighan) Prawo Kernighana zostało nazwane na cześć [Briana Kernighana](https://en.wikipedia.org/wiki/Brian_Kernighan) i pochodzi z cytatu z książki Kernighana i Plaugera „ [Elementy stylu programowania”](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style) : > Każdy wie, że debugowanie jest dwa razy trudniejsze niż pisanie programu. Więc jeśli jesteś tak sprytny, jak potrafisz, kiedy to piszesz, jak możesz to kiedykolwiek debugować? Choć hiperboliczne, prawo Kernighana przedstawia argument, że prosty kod ma być lepszy od kodu złożonego, ponieważ debugowanie wszelkich problemów pojawiających się w kodzie złożonym może być kosztowne lub nawet niemożliwe. Zobacz też: - [Zasada KISS](#the-kiss-principle) - [Filozofia Uniksa](#the-unix-philosophy) - [Brzytwa Ockhama](#occams-razor) ### Prawo Linusa [Prawo Linusa na Wikipedii](https://en.wikipedia.org/wiki/Linus%27s_law) > Biorąc pod uwagę wystarczającą liczbę gałek ocznych, wszystkie błędy są płytkie. > > *Eric S. Raymond* To prawo po prostu mówi, że im więcej ludzi widzi problem, tym większe prawdopodobieństwo, że ktoś już wcześniej widział i rozwiązał problem lub coś bardzo podobnego. Chociaż pierwotnie był używany do opisywania wartości modeli open-source dla projektów, może być zaakceptowany dla każdego rodzaju projektu oprogramowania. Można go również rozszerzyć na procesy - więcej przeglądów kodu, więcej statycznej analizy i wielobranżowe procesy testowe sprawią, że problemy będą bardziej widoczne i łatwiejsze do zidentyfikowania. Bardziej formalnym oświadczeniem może być: > Mając wystarczająco dużą bazę beta-testerów i programistów, prawie każdy problem zostanie szybko scharakteryzowany i może zostać rozwiązany przez kogoś, kto już wcześniej spotkał się z podobnym problemem. Prawo to zostało nazwane na cześć [Linusa Torvaldsa](https://en.wikipedia.org/wiki/Linus_Torvalds) w książce Erica S. Raymonda „ [Katedra i bazar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) ”. ### Prawo Metcalfego [Prawo Metcalfe'a na Wikipedii](https://en.wikipedia.org/wiki/Metcalfe's_law) > W teorii sieci wartość systemu rośnie w przybliżeniu do kwadratu liczby użytkowników systemu. Prawo to opiera się na liczbie możliwych połączeń parami w systemie i jest ściśle związane [z prawem Reeda](#reeds-law) . Odlyzko i inni argumentowali, że zarówno prawo Reeda, jak i prawo Metcalfe'a zawyżają wartość systemu, nie uwzględniając granic ludzkiego poznania na efektach sieciowych; zobacz [Numer Dunbara](#dunbars-number) . Zobacz też: - [Prawo Reeda](#reeds-law) - [Numer Dunbara](#dunbars-number) ### prawo Moore'a [Prawo Moore'a na Wikipedii](https://en.wikipedia.org/wiki/Moore%27s_law) > Liczba tranzystorów w układzie scalonym podwaja się mniej więcej co dwa lata. Prognozy Moore'a, często używane do zilustrowania szybkości, z jaką poprawiła się technologia półprzewodników i chipów, okazały się bardzo dokładne w okresie od lat 70. do późnych lat 2000. W ostatnich latach trend nieznacznie się zmienił, częściowo ze względu na [fizyczne ograniczenia dotyczące stopnia miniaturyzacji komponentów](https://en.wikipedia.org/wiki/Quantum_tunnelling) . Jednak postępy w zrównoleglaniu i potencjalnie rewolucyjne zmiany w technologii półprzewodnikowej i obliczeniach kwantowych mogą oznaczać, że prawo Moore'a może nadal obowiązywać przez dziesięciolecia. ### Prawo Murphy'ego / Prawo Soda [Prawo Murphy'ego na Wikipedii](https://en.wikipedia.org/wiki/Murphy%27s_law) > Wszystko, co może pójść nie tak, pójdzie nie tak. Powiązane z [Edwardem A. Murphym, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) *Murphy's Law* stwierdza, że jeśli coś może pójść nie tak, to pójdzie nie tak. To powszechne powiedzenie wśród programistów. Czasami nieoczekiwane dzieje się podczas tworzenia, testowania, a nawet produkcji. Może to być również związane z (bardziej powszechnym w brytyjskim angielskim) *Prawie Soda* : > Jeśli coś może pójść nie tak, to w najgorszym możliwym momencie. Te „prawa” są na ogół używane w komicznym sensie. Jednak zjawiska takie jak błąd [*potwierdzenia*](#TODO) i błąd [*selekcji*](#TODO) mogą skłaniać ludzi do nadmiernego podkreślania tych praw (w większości przypadków, gdy coś działa, pozostają niezauważone, jednak niepowodzenia są bardziej zauważalne i wywołują więcej dyskusji). Zobacz też: - [Błąd potwierdzenia](#TODO) - [Odchylenie selekcji](#TODO) ### Brzytwa Ockhama [Brzytwa Ockhama na Wikipedii](https://en.wikipedia.org/wiki/Occam's_razor) > Nie należy mnożyć jednostek bez konieczności. > > Wilhelm z Ockhama Brzytwa Ockhama mówi, że spośród kilku możliwych rozwiązań najbardziej prawdopodobnym rozwiązaniem jest to, które ma najmniejszą liczbę koncepcji i założeń. To rozwiązanie jest najprostsze i rozwiązuje tylko zadany problem, bez wprowadzania przypadkowych złożoności i ewentualnych negatywnych konsekwencji. Zobacz też: - [YAGNI](#yagni) - [Brak srebrnej kuli: przypadkowa złożoność i zasadnicza złożoność](https://en.wikipedia.org/wiki/No_Silver_Bullet) Przykład: - [Rozwój oprogramowania szczupłego: eliminuj marnotrawstwo](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) ### Prawo Parkinsona [Prawo Parkinsona na Wikipedii](https://en.wikipedia.org/wiki/Parkinson%27s_law) > Praca rozwija się tak, aby wypełnić czas dostępny na jej wykonanie. W swoim pierwotnym kontekście ustawa ta opierała się na badaniach biurokracji. Można to pesymistycznie zastosować do inicjatyw rozwoju oprogramowania, zgodnie z teorią, że zespoły będą nieefektywne do czasu, gdy zbliżają się terminy, a następnie spieszą się, aby ukończyć pracę w terminie, co sprawia, że rzeczywisty termin jest nieco arbitralny. Gdyby to prawo zostało połączone z prawem [Hofstadtera](#hofstadters-law) , osiągnięto jeszcze bardziej pesymistyczny punkt widzenia - praca rozszerzy się, aby wypełnić czas dostępny na jej ukończenie i *nadal będzie trwać dłużej niż oczekiwano* . Zobacz też: - [Prawo Hofstadtera](#hofstadters-law) ### Przedwczesny efekt optymalizacji [Przedwczesna optymalizacja na WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) > Przedwcześnie optymalizacja jest źródłem wszelkiego zła. > > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) W artykule Donald Knuth's [Structured Programming with Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) napisał: „Programiści marnują ogromne ilości czasu na myślenie lub martwienie się o szybkość niekrytycznych części swoich programów, a te próby wydajności mają naprawdę silny negatywny wpływ podczas debugowania i konserwacja są brane pod uwagę. Powinniśmy zapomnieć o małych wydajnościach, powiedzmy w 97% przypadków: **przedwczesna optymalizacja jest źródłem wszelkiego zła** . Jednak nie powinniśmy przepuszczać naszych możliwości w tych krytycznych 3%.” Jednak *przedwczesną optymalizację* można zdefiniować (w mniej obciążonych terminach) jako optymalizację, zanim zorientujemy się, że jest to konieczne. ### Prawo Putta [Prawo Putta na Wikipedii](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) > Technologia jest zdominowana przez dwa typy ludzi, tych, którzy rozumieją to, czym nie zarządzają, i tych, którzy zarządzają tym, czego nie rozumieją. Po prawie Putta często następuje następstwo Putta: > Każda hierarchia techniczna z czasem rozwija inwersję kompetencji. Stwierdzenia te sugerują, że ze względu na różne kryteria selekcji i trendy w organizacji grup, na szczeblach pracy organizacji technicznych znajdzie się pewna liczba wykwalifikowanych osób oraz pewna liczba osób na stanowiskach kierowniczych, które nie są świadome złożoności i wyzwań związanych z pracę, którą zarządzają. Może to być spowodowane zjawiskami takimi jak [Zasada Petera](#the-peter-principle) lub [Zasada Dilberta](#the-dilbert-principle) . Należy jednak podkreślić, że takie przepisy są szerokimi uogólnieniami i mogą mieć zastosowanie do *niektórych* typów organizacji, a nie do innych. Zobacz też: - [Zasada Piotra](#the-peter-principle) - [Zasada Dilberta](#the-dilbert-principle) ### Prawo Reeda [Prawo Reeda na Wikipedii](https://en.wikipedia.org/wiki/Reed's_law) > Użyteczność dużych sieci, w szczególności sieci społecznościowych, rośnie wykładniczo wraz z rozmiarem sieci. Prawo to opiera się na teorii grafów, gdzie użyteczność skaluje się jako liczba możliwych podgrup, czyli szybciej niż liczba uczestników lub liczba możliwych połączeń parami. Odlyzko i inni argumentowali, że prawo Reeda zawyża użyteczność systemu, nie uwzględniając ograniczeń ludzkiego poznania w zakresie efektów sieciowych; zobacz [Numer Dunbara](#dunbars-number) . Zobacz też: - [Prawo Metcalfego](#metcalfes-law) - [Numer Dunbara](#dunbars-number) ### Prawo zachowania złożoności (prawo Teslera) [Prawo zachowania złożoności na Wikipedii](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) Prawo to mówi, że w systemie występuje pewna złożoność, której nie można zredukować. Pewna złożoność systemu jest „nieumyślna”. Jest to konsekwencja złej struktury, błędów lub po prostu złego zamodelowania problemu do rozwiązania. Przypadkową złożoność można zmniejszyć (lub wyeliminować). Jednak pewna złożoność jest „wewnętrzna” jako konsekwencja złożoności nieodłącznie związanej z rozwiązywanym problemem. Tę złożoność można przenieść, ale nie można jej wyeliminować. Ciekawym elementem tego prawa jest sugestia, że nawet uproszczenie całego systemu nie zmniejsza wewnętrznej złożoności, lecz *przenosi się na użytkownika* , który musi zachowywać się w bardziej złożony sposób. ### Prawo Demeter [Prawo Demeter na Wikipedii](https://en.wikipedia.org/wiki/Law_of_Demeter) > Nie rozmawiaj z nieznajomymi. Prawo Demeter, znane również jako „zasada najmniejszej wiedzy”, jest zasadą projektowania oprogramowania, szczególnie istotną w językach obiektowych. Stwierdza, że jednostka oprogramowania powinna rozmawiać tylko ze swoimi bezpośrednimi współpracownikami. Obiekt `A` z odwołaniem do obiektu `B` może wywoływać swoje metody, ale jeśli `B` ma odwołanie do obiektu `C` , `A` nie powinien wywoływać `C` s. Tak więc, jeśli `C` ma `doThing()` , `A` nie powinien wywoływać jej bezpośrednio; `B.getC().doThis()` . Przestrzeganie tej zasady ogranicza zakres zmian, czyniąc je łatwiejszymi i bezpieczniejszymi w przyszłości. ### Prawo nieszczelnych abstrakcji [Prawo nieszczelnych abstrakcji dotyczących Joela na oprogramowaniu](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) > Wszystkie nietrywialne abstrakcje są do pewnego stopnia nieszczelne. > > ( [Joel Spolsky](https://twitter.com/spolsky) ) Prawo to stanowi, że abstrakcje, które są zwykle używane w obliczeniach w celu uproszczenia pracy ze skomplikowanymi systemami, w pewnych sytuacjach „wyciekają” elementy systemu bazowego, co powoduje, że abstrakcja zachowuje się w nieoczekiwany sposób. Przykładem może być wczytanie pliku i odczytanie jego zawartości. Interfejsy API systemu plików są *abstrakcją* systemów jądra niższego poziomu, które same w sobie są abstrakcją fizycznych procesów związanych ze zmianą danych na talerzu magnetycznym (lub pamięci flash w przypadku dysku SSD). W większości przypadków zadziała abstrakcja traktowania pliku jako strumienia danych binarnych. Jednak w przypadku dysku magnetycznego sekwencyjny odczyt danych będzie *znacznie* szybszy niż dostęp losowy (ze względu na zwiększony narzut błędów stron), ale w przypadku dysku SSD ten narzut nie będzie obecny. Aby poradzić sobie z tym przypadkiem, należy zrozumieć podstawowe szczegóły (na przykład pliki indeksu bazy danych są skonstruowane tak, aby zmniejszyć obciążenie losowego dostępu), szczegóły implementacji „przecieków” abstrakcji, o których programista może być świadomy. Powyższy przykład może stać się bardziej złożony, gdy zostanie wprowadzonych *więcej abstrakcji.* System operacyjny Linux umożliwia dostęp do plików przez sieć, ale reprezentowane lokalnie jako „normalne” pliki. Ta abstrakcja „przecieka” w przypadku awarii sieci. Jeśli programista traktuje te pliki jako „normalne” pliki, nie biorąc pod uwagę faktu, że mogą one podlegać opóźnieniom i awariom sieci, rozwiązania będą zawierały błędy. Artykuł opisujący prawo sugeruje, że nadmierne poleganie na abstrakcjach w połączeniu ze słabym zrozumieniem procesów leżących u ich podstaw w rzeczywistości sprawia, że radzenie sobie z danym problemem w niektórych przypadkach *staje się bardziej złożone.* Zobacz też: - [Prawo Hyruma](#hyrums-law-the-law-of-implicit-interfaces) Przykłady ze świata rzeczywistego: - [Powolne uruchamianie programu Photoshop](https://forums.adobe.com/thread/376152) — problem, który napotkałem w przeszłości. Photoshop uruchamiałby się wolno, czasami zajmując kilka minut. Wydaje się, że problem polegał na tym, że podczas uruchamiania odczytuje informacje o bieżącej domyślnej drukarce. Jeśli jednak ta drukarka jest w rzeczywistości drukarką sieciową, może to zająć bardzo dużo czasu. *Abstrakcja* drukarki sieciowej prezentowanej systemowi podobnie do drukarki lokalnej powodowała problem dla użytkowników w sytuacjach słabej łączności. ### Prawo trywialności [Prawo trywialności na Wikipedii](https://en.wikipedia.org/wiki/Law_of_triviality) To prawo sugeruje, że grupy będą poświęcać znacznie więcej czasu i uwagi błahym lub kosmetycznym kwestiom niż poważnym i istotnym. Powszechnie używanym fikcyjnym przykładem jest komitet zatwierdzający plany elektrowni jądrowej, który spędza większość czasu na omawianiu struktury szopy na rowery, a nie na znacznie ważniejszym projekcie samej elektrowni. Wniesienie wartościowego wkładu w dyskusje na bardzo duże, złożone tematy może być trudne bez wysokiego poziomu wiedzy merytorycznej lub przygotowania. Jednak ludzie chcą być postrzegani jako wnoszący cenny wkład. Stąd tendencja do skupiania zbyt dużej ilości czasu na drobnych szczegółach, które można łatwo wytłumaczyć, ale niekoniecznie mają one szczególne znaczenie. Powyższy fikcyjny przykład doprowadził do użycia terminu „Zrzucanie rowerów” jako wyrażenia marnowania czasu na błahe szczegóły. Pokrewnym terminem jest „ [golenie](https://en.wiktionary.org/wiki/yak_shaving) jaka”, które oznacza pozornie nieistotną czynność, która jest częścią długiego łańcucha warunków wstępnych do głównego zadania. ### Filozofia Uniksa [Filozofia Uniksa na Wikipedii](https://en.wikipedia.org/wiki/Unix_philosophy) Filozofia Uniksa polega na tym, że komponenty oprogramowania powinny być małe i skoncentrowane na robieniu jednej konkretnej rzeczy dobrze. Może to ułatwić budowanie systemów poprzez komponowanie małych, prostych, dobrze zdefiniowanych jednostek, zamiast używania dużych, złożonych, wielozadaniowych programów. Nowoczesne praktyki, takie jak „architektura mikrousług”, można traktować jako zastosowanie tego prawa, w którym usługi są małe, skoncentrowane i wykonują jedną konkretną rzecz, umożliwiając złożone zachowanie złożone z prostych elementów konstrukcyjnych. ### Zasada Skauta [Reguła Skauta na O'Reilly](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) > Zawsze zostawiaj kod lepszy, niż go znalazłeś. > > (Robert C. Martin (Wujek Bob)) Oparta na „Zasadze Zwiadowcy”, która mówi, że „zawsze zostawiaj pole kempingowe czystsze, niż go znalazłeś”, zasada zwiadu w programowaniu to po prostu „zawsze pozostawiaj kod czystszy, niż go znalazłeś”. Zostało to wprowadzone w pierwszym rozdziale książki [Czysty kod](https://www.goodreads.com/book/show/3735293-clean-code) autorstwa Boba Martina. Reguła sugeruje, że programiści powinni przeprowadzać „optymistyczne refaktoryzację”, co oznacza dążenie do poprawy ogólnej jakości kodu podczas pracy nad nim. Jeśli zauważysz błąd, spróbuj go naprawić lub wyczyść. Jednak przy wprowadzaniu zmian w kodzie, który wydaje się niepoprawny, warto pamiętać [o płocie Chestertona](#chestertons-fence) ! Zobacz też: - [Lista lektur: czysty kod](#reading-list) - [Płot Chestertona](#chestertons-fence) - [Teoria zepsutych okien](#broken-windows-theory) https://www.amazon.sg/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 ### Model Spotify [Model Spotify w Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) Model Spotify to podejście do struktury zespołu i organizacji spopularyzowane przez „Spotify”. W tym modelu zespoły są zorganizowane wokół funkcji, a nie technologii. Model Spotify popularyzuje również koncepcje plemion, gildii, oddziałów, które są innymi elementami ich struktury organizacyjnej. Członkowie organizacji opisali, że rzeczywiste znaczenie tych grup zmienia się, ewoluuje i jest ciągłym eksperymentem. Fakt, że model jest *procesem w ruchu* , a nie stałym modelem, nadal prowadzi do różnych interpretacji struktury, które mogą opierać się na prezentacjach wygłaszanych przez pracowników na konferencjach. Oznacza to, że „migawki” mogą być „przepakowywane” przez osoby trzecie w *stałą strukturę* , co powoduje utratę dynamiki modelu. ### Zasada dwóch pizzy > Jeśli nie możesz nakarmić drużyny dwiema pizzami, jest za duża. > > (Jeff Bezos) Ta zasada sugeruje, że niezależnie od wielkości firmy, zespoły powinny być na tyle małe, aby mogły je nakarmić dwie pizze. Przekonanie to, przypisywane Jeffowi Bezosowi i Amazonowi, sugeruje, że duże zespoły są z natury nieefektywne. Potwierdza to fakt, że wraz ze wzrostem liczebności zespołu liniowo, powiązania między ludźmi rosną kwadratowo; w ten sposób koszt koordynacji i komunikacji również rośnie kwadratowo. Jeśli ten koszt koordynacji jest zasadniczo kosztowny, należy preferować mniejsze zespoły. Liczbę powiązań między ludźmi można wyrazić jako `n(n-1)/2` gdzie n = liczba osób. Kompletny wykres; Powiązania między ludźmi ### Prawo Wadlera [Prawo Wadlera na wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) > W każdym projekcie językowym całkowity czas poświęcony na omawianie funkcji z tej listy jest proporcjonalny do dwóch podniesionych do potęgi jej pozycji. > > 1. Semantyka > 2. Składnia > 3. Składnia leksykalna > 4. Składnia leksykalna komentarzy > > (W skrócie, na każdą godzinę spędzoną na semantyce, 8 godzin zostanie poświęconych na składnię komentarzy). Podobnie jak [Prawo](#the-law-of-triviality) trywialności, Prawo Wadlera mówi, że przy projektowaniu języka ilość czasu poświęcanego na struktury językowe jest nieproporcjonalnie duża w porównaniu z wagą tych cech. Zobacz też: - [Prawo trywialności](#the-law-of-triviality) ### Prawo Wheatona [Połączenie](http://www.wheatonslaw.com/) [Dzień Oficjalny](https://dontbeadickday.com/) > Nie bądź kutasem. > > *Wila Wheatona* Ukute przez Wila Wheatona (Star Trek: The Next Generation, The Big Bang Theory), to proste, zwięzłe i potężne prawo ma na celu zwiększenie harmonii i szacunku w profesjonalnej organizacji. Może być stosowany podczas rozmów ze współpracownikami, przeprowadzania przeglądów kodu, przeciwstawiania się innym punktom widzenia, krytykowania i ogólnie większości profesjonalnych interakcji między ludźmi. ## Zasady Zasady są zazwyczaj bardziej prawdopodobne jako wytyczne dotyczące projektowania. ### Wszystkie modele są złe (prawo George'a Boxa) [Wszystkie modele są złe](https://en.wikipedia.org/wiki/All_models_are_wrong) > Wszystkie modele są błędne, ale niektóre są przydatne. > > *George Box* Zasada ta sugeruje, że wszystkie modele systemów są wadliwe, ale dopóki nie są *zbyt* wadliwe, mogą być użyteczne. Zasada ta ma swoje korzenie w statystyce, ale odnosi się również do modeli naukowych i obliczeniowych. Podstawowym wymaganiem większości oprogramowania jest modelowanie pewnego rodzaju systemu. Niezależnie od tego, czy modelowany system jest siecią komputerową, biblioteką, wykresem powiązań społecznościowych czy jakimkolwiek innym systemem, projektant będzie musiał określić odpowiedni poziom szczegółowości modelowania. Nadmierna szczegółowość może prowadzić do zbyt dużej złożoności, zbyt mała szczegółowość może uniemożliwić funkcjonowanie modelu. Zobacz też: - [Prawo nieszczelnych abstrakcji](#the-law-of-leaky-abstractions) ### Płot Chestertona [Płot Chestertona na Wikipedii](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence) > Nie należy przeprowadzać reform, dopóki nie zrozumie się uzasadnienia istniejącego stanu rzeczy. Ta zasada jest istotna w inżynierii oprogramowania przy usuwaniu długu technicznego. Każda linia programu została z jakiegoś powodu napisana przez kogoś. Chesterton's Fence sugeruje, że należy starać się w pełni zrozumieć kontekst i znaczenie kodu przed jego zmianą lub usunięciem, nawet jeśli na pierwszy rzut oka wydaje się on zbyteczny lub niepoprawny. Nazwa tej zasady pochodzi od opowiadania [GK Chestertona](https://en.wikipedia.org/wiki/G._K._Chesterton) . Mężczyzna natrafia na płot przecinający środek drogi. Skarży się burmistrzowi, że to bezużyteczne ogrodzenie przeszkadza i prosi o jego usunięcie. Burmistrz pyta, dlaczego w ogóle jest tam ogrodzenie. Kiedy mężczyzna mówi, że nie wie, burmistrz mówi: „Jeśli nie znasz jego przeznaczenia, na pewno nie pozwolę ci go usunąć. to." ### Efekt Morza Martwego [Wpływ Morza Martwego na Bruce'a F. Webstera](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/) > „... [Z]iętniej utalentowani i skuteczni inżynierowie IT najczęściej odchodzą – by wyparować… [ci, którzy mają tendencję do pozostawania] w tyle [są] „pozostałościami” — najmniej utalentowanymi i skutecznymi inżynierami IT ”. > > *Bruce F. Webster* „Efekt Morza Martwego” sugeruje, że w każdej organizacji umiejętności/talent/skuteczność inżynierów są często odwrotnie proporcjonalne do ich czasu w firmie. Zazwyczaj wysoko wykwalifikowani inżynierowie łatwo znajdują zatrudnienie gdzie indziej i są to pierwsi. Inżynierowie, którzy mają przestarzałe lub słabe umiejętności, zwykle pozostają w firmie, ponieważ znalezienie pracy w innym miejscu jest trudne. Jest to szczególnie widoczne, jeśli w ciągu swojego czasu w firmie uzyskali dodatkowe podwyżki płac, ponieważ uzyskanie ekwiwalentnego wynagrodzenia w innym miejscu może być trudne. ### Zasada Dilberta [Zasada Dilberta na Wikipedii](https://en.wikipedia.org/wiki/Dilbert_principle) > Firmy mają tendencję do systematycznego awansowania niekompetentnych pracowników do kierownictwa, aby wydostać ich z przepływu pracy. > > *Scott Adams* Koncepcja zarządzania opracowana przez Scotta Adamsa (twórcę komiksu Dilberta), Zasada Dilberta jest inspirowana [Zasadą Petera](#the-peter-principle) . Zgodnie z Zasadą Dilberta pracownicy, którzy nigdy nie byli kompetentni, są awansowani na stanowiska kierownicze w celu ograniczenia szkód, jakie mogą wyrządzić. Adams po raz pierwszy wyjaśnił tę zasadę w artykule Wall Street Journal z 1995 r., a następnie rozwinął ją w swojej książce biznesowej z 1996 r. [„Zasada Dilberta”](#reading-list) . Zobacz też: - [Zasada Piotra](#the-peter-principle) - [Prawo Putta](#putts-law) ### Zasada Pareto (Zasada 80/20) [Zasada Pareto na Wikipedii](https://en.wikipedia.org/wiki/Pareto_principle) > Większość rzeczy w życiu nie jest rozłożona równomiernie. Zasada Pareto sugeruje, że w niektórych przypadkach większość wyników pochodzi z mniejszości danych wejściowych: - 80% określonego fragmentu oprogramowania można napisać w 20% całkowitego przydzielonego czasu (odwrotnie, najtrudniejsze 20% kodu zajmuje 80% czasu) - 20% wysiłku daje 80% rezultatu - 20% pracy tworzy 80% przychodów - 20% błędów powoduje 80% awarii - 20% funkcji powoduje 80% użytkowania W latach czterdziestych amerykańsko-rumuński inżynier dr Joseph Juran, powszechnie uważany za ojca kontroli jakości, [zaczął stosować zasadę Pareto do kwestii jakości](https://en.wikipedia.org/wiki/Joseph_M._Juran) . Ta zasada jest również znana jako: Reguła 80/20, Prawo Niewielu Witalnych oraz Zasada Rzadkości Czynników. Przykłady ze świata rzeczywistego: - W 2002 roku Microsoft poinformował, że naprawienie 20% najczęściej zgłaszanych błędów pozwoli wyeliminować 80% powiązanych błędów i awarii w Windows i Office ( [Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm) ). ### Zasada Shirky [Wyjaśnienie zasady Shirky](https://kk.org/thetechnium/the-shirky-prin/) > Instytucje będą starały się zachować problem, którego są rozwiązaniem. > > *Glina Shirky* Zasada Shirky sugeruje, że złożone rozwiązania – firma, branża lub technologia – mogą być tak skoncentrowane na problemie, który rozwiązują, że mogą nieumyślnie utrwalać sam problem. Może to być celowe (firma dążąca do znalezienia nowych niuansów problemu, które uzasadniają dalsze opracowywanie rozwiązania) lub nieumyślne (niezdolność lub niechęć do zaakceptowania lub zbudowania rozwiązania, które całkowicie rozwiąże problem lub go ominie). Związany z: - Słynny wiersz Uptona Sinclaira: *„Trudno jest sprawić, by człowiek coś zrozumiał, kiedy jego pensja zależy od tego, czy tego nie rozumie!”* - *Dylemat innowatora* Claya Christensena Zobacz też: - [Zasada Pareto](#the-pareto-principle-the-8020-rule) ### Zasada Piotra [Zasada Piotra na Wikipedii](https://en.wikipedia.org/wiki/Peter_principle) > Ludzie w hierarchii mają tendencję do wznoszenia się do swojego „poziomu niekompetencji”. > > *Laurence J. Peter* Koncepcja zarządzania opracowana przez Laurence'a J. Petera, Zasada Petera, wskazuje, że ludzie, którzy są dobrzy w swojej pracy, są awansowani, dopóki nie osiągną poziomu, na którym nie odnoszą już sukcesów (ich „poziom niekompetencji”). W tym momencie, ponieważ są bardziej starsi, jest mniej prawdopodobne, że zostaną usunięci z organizacji (chyba że osiągają spektakularnie złe wyniki) i nadal będą pełnić rolę, w której mają niewiele wrodzonych umiejętności, ponieważ ich oryginalne umiejętności, które ich uczyniły sukces niekoniecznie są umiejętnościami wymaganymi w nowej pracy. Jest to szczególnie interesujące dla inżynierów – którzy początkowo zaczynają od głęboko technicznych ról, ale często mają ścieżkę kariery, która prowadzi do *zarządzania* innymi inżynierami – co wymaga zasadniczo innego zestawu umiejętności. Zobacz też: - [Zasada Dilberta](#the-dilbert-principle) - [Prawo Putta](#putts-law) ### Zasada solidności (prawo Postela) [Zasada solidności na Wikipedii](https://en.wikipedia.org/wiki/Robustness_principle) > Bądź konserwatywny w tym, co robisz, bądź liberalny w tym, co akceptujesz od innych. Zasada ta, często stosowana w tworzeniu aplikacji serwerowych, mówi, że to, co wysyłasz do innych, powinno być jak najmniejsze i zgodne, ale powinieneś dążyć do umożliwienia niezgodnych danych wejściowych, jeśli można je przetworzyć. Celem tej zasady jest zbudowanie systemów, które są solidne, ponieważ mogą poradzić sobie ze źle sformułowanymi danymi wejściowymi, jeśli intencje mogą być nadal zrozumiałe. Jednak akceptowanie zniekształconych danych wejściowych może wiązać się z potencjalnymi implikacjami bezpieczeństwa, szczególnie jeśli przetwarzanie takich danych wejściowych nie jest dobrze przetestowane. Te implikacje i inne kwestie zostały opisane przez Erica Allmana w [Reconsidered The Robustness Principle Reconsidered](https://queue.acm.org/detail.cfm?id=1999945) . Dopuszczenie niezgodnych danych wejściowych z czasem może osłabić zdolność protokołów do ewolucji, ponieważ realizatorzy będą w końcu polegać na tej liberalności w budowaniu swoich funkcji. Zobacz też: - [Prawo Hyruma](#hyrums-law-the-law-of-implicit-interfaces) ### SOLID To jest akronim, który odnosi się do: - S: [Zasada pojedynczej odpowiedzialności](#the-single-responsibility-principle) - O: [Zasada otwarcia/zamknięcia](#the-openclosed-principle) - L: [Zasada substytucji Liskov](#the-liskov-substitution-principle) - I: [Zasada segregacji interfejsów](#the-interface-segregation-principle) - D: [Zasada odwrócenia zależności](#the-dependency-inversion-principle) Są to kluczowe zasady [programowania zorientowanego obiektowo](#todo) . Zasady projektowania, takie jak te, powinny być w stanie pomóc programistom w tworzeniu systemów łatwiejszych w utrzymaniu. ### Zasada pojedynczej odpowiedzialności [Zasada pojedynczej odpowiedzialności na Wikipedii](https://en.wikipedia.org/wiki/Single_responsibility_principle) > Każdy moduł lub klasa powinna mieć tylko jedną odpowiedzialność. Pierwsza z zasad „ [SOLID](#solid) ”. Ta zasada sugeruje, że moduły lub klasy powinny robić jedną rzecz i tylko jedną rzecz. W bardziej praktycznym ujęciu oznacza to, że pojedyncza, niewielka zmiana w funkcji programu powinna wymagać zmiany tylko w jednym komponencie. Na przykład zmiana sposobu sprawdzania poprawności hasła pod kątem złożoności powinna wymagać zmiany tylko w jednej części programu. Teoretycznie powinno to sprawić, że kod będzie bardziej niezawodny i łatwiejszy do zmiany. Wiedza, że zmieniany komponent ma tylko jedną odpowiedzialność, oznacza tylko, że *testowanie* tej zmiany powinno być łatwiejsze. Korzystając z wcześniejszego przykładu, zmiana składnika złożoności hasła powinna mieć wpływ tylko na funkcje związane ze złożonością hasła. O wiele trudniejsze może być uzasadnienie wpływu zmiany na element, który ma wiele obowiązków. Zobacz też: - [Programowanie obiektowe](#todo) - [SOLID](#solid) ### Zasada otwarcia/zamknięcia [Zasada otwarcia/zamknięcia na Wikipedii](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) > Encje powinny być otwarte na rozszerzenie i zamknięte na modyfikację. Druga z zasad „ [SOLID](#solid) ”. Zasada ta stwierdza, że encje (które mogą być klasami, modułami, funkcjami itd.) powinny mieć możliwość *rozszerzenia* ich zachowania, ale ich *istniejące* zachowanie nie powinno być modyfikowane. Jako hipotetyczny przykład wyobraź sobie moduł, który jest w stanie zamienić dokument Markdown w HTML. Teraz wyobraź sobie, że do specyfikacji Markdown dodano nową składnię, która dodaje obsługę równań matematycznych. Moduł powinien być *otwarty do rozbudowy w* celu wdrożenia nowej składni matematycznej. Jednak istniejące implementacje składni (takie jak akapity, punktory itp.) powinny zostać *zamknięte przed modyfikacją* . Już działają, nie chcemy, żeby ludzie je zmieniali. Ta zasada ma szczególne znaczenie w przypadku programowania obiektowego, w którym możemy projektować obiekty tak, aby można je było łatwo rozszerzać, ale unikamy projektowania obiektów, których istniejące zachowanie może zostać zmienione w nieoczekiwany sposób. Zobacz też: - [Programowanie obiektowe](#todo) - [SOLID](#solid) ### Zasada substytucji Liskov [Zasada substytucji Liskov na Wikipedii](https://en.wikipedia.org/wiki/Liskov_substitution_principle) > Powinna istnieć możliwość zamiany typu na podtyp bez naruszania systemu. Trzecia z zasad „ [SOLID](#solid) ”. Ta zasada mówi, że jeśli komponent opiera się na typie, powinien móc używać podtypów tego typu, bez awarii systemu lub konieczności poznania szczegółów tego podtypu. Jako przykład wyobraźmy sobie, że mamy metodę, która odczytuje dokument XML ze struktury reprezentującej plik. Jeśli metoda używa typu podstawowego „plik”, to wszystko, co pochodzi od „plik”, powinno być możliwe do użycia w funkcji. Jeśli „plik” obsługuje wyszukiwanie wsteczne, a parser XML korzysta z tej funkcji, ale typ pochodny „plik sieciowy” nie powiedzie się podczas próby wyszukiwania wstecznego, wówczas „plik sieciowy” narusza tę zasadę. Zasada ta ma szczególne znaczenie w przypadku programowania obiektowego, w którym hierarchie typów muszą być starannie modelowane, aby uniknąć dezorientacji użytkowników systemu. Zobacz też: - [Programowanie obiektowe](#todo) - [SOLID](#solid) ### Zasada segregacji interfejsów [Zasada segregacji interfejsów w Wikipedii](https://en.wikipedia.org/wiki/Interface_segregation_principle) > Żaden klient nie powinien być zmuszany do polegania na metodach, których nie używa. Czwarta z zasad „ [SOLID](#solid) ”. Zasada ta stanowi, że konsumenci komponentu nie powinni zależeć od funkcji tego komponentu, z którego faktycznie nie korzysta. Jako przykład wyobraźmy sobie, że mamy metodę, która odczytuje dokument XML ze struktury reprezentującej plik. Musi tylko czytać bajty, przesuwać się do przodu lub do tyłu w pliku. Jeśli ta metoda wymaga aktualizacji z powodu zmiany niepowiązanej cechy struktury pliku (takiej jak aktualizacja modelu uprawnień używanego do reprezentowania bezpieczeństwa plików), zasada została unieważniona. Byłoby lepiej, gdyby plik zaimplementował interfejs „przeszukiwanego strumienia” i aby czytnik XML go używał. Zasada ta ma szczególne znaczenie dla programowania obiektowego, w którym interfejsy, hierarchie i typy abstrakcyjne są używane w celu [zminimalizowania sprzężenia](#todo) między różnymi komponentami. [Wpisywanie kaczki](#todo) to metodologia, która wymusza tę zasadę, eliminując jawne interfejsy. Zobacz też: - [Programowanie obiektowe](#todo) - [SOLID](#solid) - [Pisanie kaczki](#todo) - [Oddzielenie](#todo) ### Zasada odwrócenia zależności [Zasada odwrócenia zależności na Wikipedii](https://en.wikipedia.org/wiki/Dependency_inversion_principle) > Moduły wysokopoziomowe nie powinny być zależne od implementacji niskopoziomowych. Piąta z zasad „ [SOLID](#solid) ”. Ta zasada stanowi, że komponenty orkiestrujące wyższego poziomu nie powinny znać szczegółów ich zależności. Jako przykład wyobraź sobie, że mamy program, który odczytuje metadane ze strony internetowej. Przyjęlibyśmy, że główny komponent musiałby wiedzieć o komponencie, aby pobrać zawartość strony internetowej, a następnie komponent, który może odczytać metadane. Gdybyśmy wzięli pod uwagę inwersję zależności, główny składnik zależałby tylko od abstrakcyjnego komponentu, który może pobierać dane bajtowe, a następnie od abstrakcyjnego komponentu, który byłby w stanie odczytać metadane ze strumienia bajtów. Główny komponent nie wiedziałby o TCP/IP, HTTP, HTML itp. Ta zasada jest złożona, ponieważ może się wydawać, że „odwraca” oczekiwane zależności systemu (stąd nazwa). W praktyce oznacza to również, że oddzielny składnik orkiestracji musi zapewniać prawidłowe implementacje typów abstrakcyjnych (np. w poprzednim przykładzie *coś* musi nadal zapewniać składnik czytnika metadanych — narzędzie do pobierania plików HTTP i czytnik metatagów HTML). Następnie dotyka wzorców, takich jak [Inversion of Control](#todo) i [Dependency Injection](#todo) . Zobacz też: - [Programowanie obiektowe](#todo) - [SOLID](#solid) - [Odwrócenie sterowania](#todo) - [Wstrzykiwanie zależności](#todo) ### Zasada DRY [Zasada DRY na Wikipedii](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) > Każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w ramach systemu. DRY to akronim od *Don't Repeat Yourself* . Ta zasada ma na celu pomóc programistom w zmniejszeniu powtarzalności kodu i utrzymaniu informacji w jednym miejscu i została przytoczona w 1999 roku przez Andrew Hunta i Dave'a Thomasa w książce [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) > Przeciwieństwem DRY byłoby *WET* (Write Everything Twice lub We Enjoy Typing). W praktyce, jeśli masz tę samą informację w dwóch (lub więcej) różnych miejscach, możesz użyć DRY, aby połączyć je w jedną i ponownie wykorzystać w dowolnym miejscu. Zobacz też: - [Pragmatyczny programista](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) ### Zasada KISS [KISS na Wikipedii](https://en.wikipedia.org/wiki/KISS_principle) > Niech to będzie możliwie proste Zasada KISS stwierdza, że większość systemów działa najlepiej, jeśli są proste, a nie skomplikowane; dlatego prostota powinna być kluczowym celem w projektowaniu i należy unikać niepotrzebnej złożoności. Pochodzące z US Navy w 1960 r. wyrażenie kojarzone jest z inżynierem lotniczym Kelly Johnson. Zasadę tę najlepiej ilustruje historia Johnsona przekazującego zespołowi konstruktorów garść narzędzi, z wyzwaniem, że projektowany przez nich samolot odrzutowy musi być naprawiany przez przeciętnego mechanika w terenie w warunkach bojowych za pomocą tylko tych narzędzi. Stąd „głupia” odnosi się do związku między sposobem, w jaki rzeczy się psują, a wyrafinowaniem dostępnych narzędzi do ich naprawy, a nie możliwościami samych inżynierów. Zobacz też: - [Prawo Galla](#galls-law) ### YAGNI [YAGNI na Wikipedii](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it) Jest skrótem dla ***Y** Ou **A** in't **G** onna **N** Id **i** t.* > Zawsze wdrażaj rzeczy, kiedy naprawdę ich potrzebujesz, nigdy tylko wtedy, gdy tylko przewidujesz, że ich potrzebujesz. > > ( [Ron Jeffries](https://twitter.com/RonJeffries) ) (współzałożyciel XP i autor książki „Zainstalowane programowanie ekstremalne”) Ta *zasada Extreme Programming* (XP) sugeruje, że programiści powinni wdrażać tylko te funkcje, które są potrzebne do natychmiastowych wymagań i unikać prób przewidywania przyszłości poprzez implementację funkcji, które mogą być potrzebne później. Przestrzeganie tej zasady powinno zmniejszyć ilość niewykorzystanego kodu w kodzie i uniknąć marnowania czasu i wysiłku na funkcjonalność, która nie przynosi żadnej wartości. Zobacz też: - [Lista lektur: Zainstalowano ekstremalne programowanie](#reading-list) ### Błędy przetwarzania rozproszonego [Błędy przetwarzania rozproszonego na Wikipedii](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) Znane również jako *Błędy Przetwarzania w Sieci* , Błędy to lista przypuszczeń (lub przekonań) na temat przetwarzania rozproszonego, które mogą prowadzić do niepowodzeń w rozwoju oprogramowania. Założenia to: - Sieć jest niezawodna - Opóźnienie wynosi zero - Przepustowość jest nieskończona - Sieć jest bezpieczna - Topologia się nie zmienia - Jest jeden administrator - Koszt transportu wynosi zero - Sieć jest jednorodna Pierwsze cztery pozycje zostały wymienione przez [Billa Joya](https://en.wikipedia.org/wiki/Bill_Joy) i [Toma Lyona](https://twitter.com/aka_pugs) około 1991 roku i po raz pierwszy sklasyfikowane przez [Jamesa Goslinga](https://en.wikipedia.org/wiki/James_Gosling) jako „Fallacies of Networked Computing”. [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) dodał błędy 5, 6 i 7. Pod koniec lat 90. Gosling dodał ósmy błąd. Grupa została zainspirowana tym, co działo się w tym czasie w [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems) . Te błędy powinny być uważnie brane pod uwagę podczas projektowania kodu, który jest odporny; zakładając, że którykolwiek z tych błędów może prowadzić do wadliwej logiki, która nie radzi sobie z rzeczywistością i złożonością systemów rozproszonych. Zobacz też: - [Poszukiwanie mitów rozproszonego przetwarzania (część 1) — Vaidehi Joshi na Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53) ## Lista rzeczy do przeczytania Jeśli te koncepcje Cię zainteresowały, mogą Ci się spodobać następujące książki. - [Czysty kod - Robert C. Martin](https://www.goodreads.com/book/show/3735293-clean-code) - Jedna z najbardziej szanowanych książek o tym, jak pisać czysty, łatwy w utrzymaniu kod. - [Zainstalowane programowanie ekstremalne — Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) — Obejmuje podstawowe zasady programowania ekstremalnego. - [Gödel, Escher, Bach: wieczny złoty warkocz - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Ta książka jest trudna do sklasyfikowania. [Prawo Hofstadtera](#hofstadters-law) pochodzi z książki. - [Struktura i interpretacja programów komputerowych — Harold Abelson, Gerald Jay Sussman, Julie Sussman](https://www.goodreads.com/book/show/43713) — Jeśli byłeś studentem informatyki lub inżynierii elektrycznej na MIT lub Cambridge, było to twoje wprowadzenie do programowania. Powszechnie opisywany jako punkt zwrotny w życiu ludzi. - [Katedra i Bazar - Eric S. Raymond](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) - zbiór esejów na temat open source. Ta książka była źródłem [Prawa Linusa](#linuss-law) . - [Zasada Dilberta — Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) — Komiczne spojrzenie na korporacyjną Amerykę autorstwa autora, który stworzył [Zasadę Dilberta](#the-dilbert-principle) . - [Miesiąc Mitycznego Człowieka — Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) — Klasyczny tom poświęcony inżynierii oprogramowania. [Prawo Brooksa](#brooks-law) jest centralnym tematem książki. - [Zasada Petera — Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) — Kolejne komiksowe spojrzenie na wyzwania większych organizacji i zarządzania ludźmi, źródło [Zasady Petera](#the-peter-principle) . ## Zasoby online Kilka przydatnych zasobów i lektur. - [CB Insights: 8 praw prowadzących do sukcesu w technologii: zasada 2 pizzy Amazona, zasada 80/20 i inne](https://www.cbinsights.com/research/report/tech-laws-success-failure) – interesujący opis niektórych praw, które miały duży wpływ na technologię. ## eBook w formacie PDF Projekt jest dostępny jako eBook PDF, [pobierz najnowszy eBook PDF za pomocą tego linku](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) lub sprawdź [stronę wydania](https://github.com/dwmkerr/hacker-laws/releases) starszych wersji. Nowa wersja eBooka jest tworzona automatycznie po przekazaniu znacznika nowej wersji. ## Podcast Hacker Laws pojawił się w [The Changelog](https://changelog.com/podcast/403) , możesz sprawdzić odcinek podcastu, korzystając z poniższego linku: ## Tłumaczenia Dzięki wielu wspaniałym współpracownikom, Hacker Laws jest dostępny w wielu językach. Proszę rozważyć sponsorowanie moderatorów! Język | Moderator | Status --- | --- | --- [🇮🇩 Bahasa Indonezja / indonezyjski](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge) [🇧🇷 Brasileiro/Brazylijski](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn) , [Leonardo Costa](https://github.com/leofc97) | [](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) [🇨🇳 中文 / chiński](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Częściowo ukończony [🇩🇪 Niemiecki / Niemiecki](./translations/de.md) | [Wiktor](https://github.com/viktodergunov) | [](https://gitlocalize.com/repo/2513/de?utm_source=badge) [🇫🇷 francuski / francuski](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [](https://gitlocalize.com/repo/2513/fr?utm_source=badge) [🇬🇷 ελληνικά / grecki](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [](https://gitlocalize.com/repo/2513/el?utm_source=badge) [🇮🇹 Włoski/Włoski](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Częściowo ukończony [🇯🇵 JP 日本語 / japoński](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara) | [](https://gitlocalize.com/repo/2513/ja?utm_source=badge) [🇰🇷 한국어 / koreański](https://github.com/codeanddonuts/hacker-laws-kr) | [Pączek](https://github.com/codeanddonuts) | Częściowo ukończony [🇱🇻 Latviešu Valoda / łotewski](./translations/lv.md) | [Artur Jansons](https://github.com/iegik) | [](https://gitlocalize.com/repo/2513/lv?utm_source=badge) [🇵🇱 Polski / Polish](./translations/pl.md) | [Mariusz Kogen](https://github.com/k0gen) | [](https://gitlocalize.com/repo/2513/pl?utm_source=badge) [🇷🇺 Русская версия / rosyjski](https://github.com/solarrust/hacker-laws) | [Alena Batitskaja](https://github.com/solarrust) | Częściowo ukończony [🇪🇸 Castellano / hiszpański](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ( [Sponsor](https://github.com/sponsors/manuel-rubio) ) | Częściowo ukończony [🇹🇷 Turecki / Turecki](https://github.com/umutphp/hacker-laws-tr) | [Umut Işik](https://github.com/umutphp) | [](https://gitlocalize.com/repo/2513/tr?utm_source=badge) [🇺🇦 українська мова / ukraiński](./translations/uk.md) | [Nazar](https://github.com/troyane) , [Helga Łastiwka](https://github.com/HelgaLastivka) | [](https://gitlocalize.com/repo/2513/uk?utm_source=badge) Jeśli chcesz zaktualizować tłumaczenie, postępuj zgodnie z [Przewodnikiem dla współtwórców tłumaczy](https://github.com/dwmkerr/hacker-laws/blob/main/.github/contributing.md#translations) . ## Powiązane projekty - [Porada dnia](https://tips.darekkay.com/html/hacker-laws-en.html) — otrzymuj codzienne przepisy/zasady hakerskie. - [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Lista, przeglądanie i oglądanie losowych przepisów z terminala! - [Działanie na podstawie przepisów hakerskich](https://github.com/marketplace/actions/hacker-laws-action) — dodaje losowe prawo hakerskie do żądania ściągnięcia jako drobny prezent dla współtwórcy, dzięki [Umut Işık](https://github.com/umutphp) ## Przyczynianie się Prosimy o wkład! [Zgłoś problem,](https://github.com/dwmkerr/hacker-laws/issues/new) jeśli chcesz zasugerować dodanie lub zmianę, lub [Otwórz żądanie ściągnięcia,](https://github.com/dwmkerr/hacker-laws/compare) aby zaproponować własne zmiany. [Koniecznie przeczytaj Wytyczne dotyczące wkładu](./.github/contributing.md) , aby poznać wymagania dotyczące tekstu, stylu i tak dalej. Prosimy o zapoznanie się z [Kodeksem postępowania](./.github/CODE_OF_CONDUCT.md) podczas dyskusji na temat projektu. ## DO ZROBIENIA Cześć! Jeśli wylądujesz tutaj, kliknąłeś link do tematu, którego jeszcze nie napisałem, przepraszam za to - prace w toku! Możesz [zgłosić problem,](https://github.com/dwmkerr/hacker-laws/issues) prosząc o więcej szczegółów lub [otworzyć pull request,](https://github.com/dwmkerr/hacker-laws/pulls) aby przesłać proponowaną definicję tematu. ================================================ FILE: translations/pt-BR.md ================================================ # 💻📖 hacker-laws Leis, teorias, princípios e padrões que desenvolvedores acharão úteis. [Traduções](#translations): [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.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 processadores 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 Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law) > Adicionar recursos humanos em um projeto, de desenvolvimento de software, atrasado, faz ficar ainda mais atrasado. Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adicionando mais pessoas atrasa ainda mais essa entrega. Brooks 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 concluída 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 Brooks, principalmente porque algumas tarefas não 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 software que ela produz sera assim também. Se uma organização é construída 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 bebida se esbarrasse 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 pessoas para qual consegue-se manter uma relação social estável. Como uma relação entre pessoas, manter uma relação entre desenvolvedor e código 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 um sistema deve investir em ferramentas para auxiliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingressar 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 cegamente 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 sugere que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuído à 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 elas 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 tecnologias de forma rápida e em alguns casos ficam desapontadas com os resultados. 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 depender 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 suficiente para depurá-lo. > > Brian Kernighan A Lei de Kerningham é nomeada por [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) e derivada 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 levar 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 entanto, 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 o [Princípio de Peter](#o-princípio-de-peter) ou o [Princípio Dilbert](#o-princípio-dilbert). No entanto, deve-se enfatizar que leis como essa são vastas generalizações e podem ser aplicáveis a alguns tipos de organizações, mas não a outras. 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 os sistemas 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á significantemente 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 tornar 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 entanto, 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 entanto, 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 conceito 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 importâ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 pontos 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 significa 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 _estendido_, 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 estendido 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 estendidos, 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 evitar confusão entre usuários 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 estrutura 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 acoplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que impõe 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 Programmer](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 Programmer](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 desperdiç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 diariamente 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. ================================================ FILE: translations/tr.md ================================================ # 💻📖 hacker-laws Programcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler. [Çeviriler](#%C3%A7eviriler): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.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. ================================================ FILE: translations/vi.md ================================================ # 💻📖 luật của hacker Các Luật, Lý thuyết, Nguyên tắc và Mẫu sẽ hữu ích cho các nhà phát triển phần mềm. [Bản dịch](#translations) : [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) Bạn thích dự án này? Vui lòng xem xét [tài trợ cho tôi](https://github.com/sponsors/dwmkerr) và các [dịch giả](#translations) . Ngoài ra, hãy xem podcast này trên [The Changelog - Luật để tin tặc tồn tại](https://changelog.com/podcast/403) để tìm hiểu thêm về dự án! Bạn cũng có thể [tải xuống sách điện tử PDF mới nhất](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) . Hãy xem [Hướng dẫn dành cho cộng tác viên](./.github/contributing.md) nếu bạn muốn đóng góp! --- - [Giới thiệu](#introduction) - [Định luật](#laws) - [Nguyên tắc 90–9–1 (Quy tắc 1%)](#9091-principle-1-rule) - [Định luật Amdahl](#amdahls-law) - [Lý thuyết cửa sổ vỡ](#the-broken-windows-theory) - [Luật Brooks](#brooks-law) - [Định lý CAP (Định lý Brewer)](#cap-theorem-brewers-theorem) - [Định luật Conway](#conways-law) - [Định luật Cunningham](#cunninghams-law) - [Số Dunbar](#dunbars-number) - [Hiệu ứng Dunning-Kruger](#the-dunning-kruger-effect) - [Luật phù hợp](#fitts-law) - [Luật Gall](#galls-law) - [Luật Goodhart](#goodharts-law) - [Hanlon Razor](#hanlons-razor) - [Luật Hick (Luật Hick-Hyman)](#hicks-law-hick-hyman-law) - [Định luật Hofstadter](#hofstadters-law) - [Định luật Hutber](#hutbers-law) - [Chu kỳ Hype & Định luật Amara](#the-hype-cycle--amaras-law) - [Luật Hyrum (Luật của các giao diện ngầm)](#hyrums-law-the-law-of-implicit-interfaces) - [Định luật Kernighan](#kernighans-law) - [Luật Linus](#linuss-law) - [Định luật Metcalfe](#metcalfes-law) - [Định luật Moore](#moores-law) - [Định luật Murphy / Định luật Sod](#murphys-law--sods-law) - [Dao cạo của Occam](#occams-razor) - [Định luật Parkinson](#parkinsons-law) - [Hiệu ứng tối ưu hóa sớm](#premature-optimization-effect) - [Định luật Putt](#putts-law) - [Luật Reed](#reeds-law) - [Định luật Bảo toàn Độ phức tạp (Định luật Tesler)](#the-law-of-conservation-of-complexity-teslers-law) - [Định luật Demeter](#the-law-of-demeter) - [Luật trừu tượng rò rỉ](#the-law-of-leaky-abstractions) - [Luật tầm thường](#the-law-of-triviality) - [Triết lý Unix](#the-unix-philosophy) - [Quy tắc hướng đạo](#the-scout-rule) - [Mô hình Spotify](#the-spotify-model) - [Quy tắc hai chiếc bánh pizza](#the-two-pizza-rule) - [Luật Wadler](#wadlers-law) - [Định luật Wheaton](#wheatons-law) - [Nguyên tắc](#principles) - [Tất cả các mô hình đều sai (Định luật George Box)](#all-models-are-wrong-george-boxs-law) - [Chesterton's Fence](#chestertons-fence) - [Hiệu ứng Biển Chết](#the-dead-sea-effect) - [Nguyên tắc Dilbert](#the-dilbert-principle) - [Nguyên tắc Pareto (Quy tắc 80/20)](#the-pareto-principle-the-8020-rule) - [Nguyên tắc Shirky](#the-shirky-principle) - [Nguyên tắc Peter](#the-peter-principle) - [Nguyên tắc Chắc chắn (Định luật Postel)](#the-robustness-principle-postels-law) - [SOLID](#solid) - [Nguyên tắc trách nhiệm duy nhất](#the-single-responsibility-principle) - [Nguyên tắc Mở / Đóng](#the-openclosed-principle) - [Nguyên tắc thay thế Liskov](#the-liskov-substitution-principle) - [Nguyên tắc phân tách giao diện](#the-interface-segregation-principle) - [Nguyên tắc đảo ngược phụ thuộc](#the-dependency-inversion-principle) - [Nguyên tắc DRY](#the-dry-principle) - [Nguyên tắc KISS](#the-kiss-principle) - [YAGNI](#yagni) - [Sự sụp đổ của máy tính phân tán](#the-fallacies-of-distributed-computing) - [Danh sách đọc](#reading-list) - [Những nguồn thông tin trên mạng](#online-resources) - [Sách điện tử PDF](#pdf-ebook) - [Tệp âm thanh](#podcast) - [Bản dịch](#translations) - [Các dự án liên quan](#related-projects) - [Đóng góp](#contributing) - [SẼ LÀM](#todo) ## Giới thiệu Có rất nhiều luật mà mọi người thảo luận khi nói về phát triển phân mềm. Kho lưu trữ này là tài liệu tham khảo và tổng quan về một số kho lưu trữ phổ biến nhất. Hãy chia sẻ và gửi bài PR! ❗: Kho lưu trữ này chứa giải thích về một số luật, nguyên tắc và khuôn mẫu, nhưng không _ủng hộ_ bất kỳ điều nào trong số đó. Liệu chúng có nên được áp dụng hay không sẽ luôn là vấn đề tranh luận và phụ thuộc rất nhiều vào những gì bạn đang làm. ## Luật Và chúng ta bắt đầu! ### Nguyên tắc 90–9–1 (Quy tắc 1%) [Quy tắc 1% trên Wikipedia]() Nguyên tắc 90-9-1 gợi ý rằng trong một cộng đồng internet như wiki, 90% người tham gia chỉ xem nội dung, 9% chỉnh sửa hoặc sửa đổi nội dung và 1% người tham gia thêm nội dung. Ví dụ trong thế giới thực: - Một nghiên cứu năm 2014 trên bốn mạng xã hội về sức khỏe cho thấy 1% hàng đầu tạo ra 73% bài đăng, 9% tiếp theo chiếm trung bình ~ 25% và 90% còn lại chiếm trung bình 2% ( [Tham khảo](https://www.jmir.org/2014/2/e33/) ) Xem thêm: - [Nguyên tắc Pareto](#the-pareto-principle-the-8020-rule) ### Định luật Amdahl [Luật Amdahl trên Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law) > Định luật Amdahl là một công thức cho thấy _tốc độ tiềm năng_ của một tác vụ tính toán có thể đạt được bằng cách tăng tài nguyên của một hệ thống. Thường được sử dụng trong tính toán song song, nó có thể dự đoán lợi ích thực tế của việc tăng số lượng bộ xử lý, điều này bị giới hạn bởi khả năng song song của chương trình. Minh họa tốt nhất với một ví dụ. Nếu một chương trình có hai phần: phần A, phần này chỉ có thể thực hiện bằng một bộ xử lý đơn lẻ và phần B, có thể được thực hiện song song trên nhiều bộ xử lý, thì chúng ta thấy rằng việc thêm nhiều bộ xử lý vào hệ thống thực thi chương trình chỉ có thể có một lợi ích hạn chế. Nó có khả năng cải thiện đáng kể tốc độ của phần B - nhưng tốc độ của phần A sẽ không thay đổi. Sơ đồ dưới đây cho thấy một số ví dụ về những cải tiến tiềm năng về tốc độ: Diagram: Amdahl's Law _(Tham khảo hình ảnh: Bởi Daniels219 tại Wikipedia tiếng Anh, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)_ Như có thể thấy, ngay cả một chương trình có thể chạy song song 50% sẽ được hưởng lợi rất ít khi vượt quá 10 đơn vị xử lý, trong khi một chương trình có thể song song 95% vẫn có thể đạt được những cải thiện tốc độ đáng kể với hơn một nghìn đơn vị xử lý. Như [Định luật Moore](#moores-law) chậm, và tốc độ tăng tốc của bộ xử lý đơn lẻ chậm lại, thì song song hóa là chìa khóa để cải thiện hiệu suất. Ví dụ như lập trình đồ họa - với tính toán dựa trên Shader hiện đại, các pixel hoặc mảnh riêng lẻ có thể được hiển thị song song - đây là lý do tại sao các card đồ họa hiện đại thường có hàng nghìn lõi xử lý (GPU hoặc Shader Units). Xem thêm: - [Luật Brooks](#brooks-law) - [định luật Moore](#moores-law) ### Lý thuyết cửa sổ vỡ [Lý thuyết cửa sổ vỡ trên Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory) Lý thuyết Cửa sổ Vỡ cho thấy rằng các dấu hiệu tội phạm có thể nhìn thấy (cửa sổ kính bị vỡ) dẫn đến tội phạm ngày càng nghiêm trọng hơn (hoặc làm suy thoái môi trường hơn nữa). Lý thuyết này đã được áp dụng cho phát triển phần mềm, cho thấy rằng mã chất lượng kém (hoặc [Nợ kỹ thuật](#TODO) ) có thể dẫn đến nhận thức rằng các nỗ lực cải thiện chất lượng có thể bị bỏ qua hoặc định giá thấp, do đó dẫn đến mã chất lượng kém hơn. Hiệu ứng này giảm dần dẫn đến chất lượng giảm mạnh theo thời gian. Xem thêm: - [Technical Debt](#TODO) Ví dụ: - [Lập trình thực dụng: Phần mềm Entropy](https://flylib.com/books/en/1.315.1.15/1/) - [Kinh dị mã hóa: Lý thuyết cửa sổ bị hỏng](https://blog.codinghorror.com/the-broken-window-theory/) - [OpenSource: Niềm vui của Lập trình - Lý thuyết Cửa sổ Vỡ](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/) ### Luật Brooks [Luật Brooks trên Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law) > Thêm nhân lực vào một dự án phát triển phần mềm bị chậm tiến độ sẽ làm nó chậm hơn. Luật này cho thấy rằng trong nhiều trường hợp, việc cố gắng đẩy nhanh tiến độ giao một dự án vốn đã bị chậm, bằng cách bổ sung thêm người, sẽ khiến việc giao dự án chậm hơn. Brooks rõ ràng rằng đây là một sự đơn giản hóa quá mức, tuy nhiên, lý do chung là với thời gian gia tăng của các nguồn tài nguyên mới và tổng chi phí liên lạc, tốc độ ngắn hạn tức thời sẽ giảm xuống. Ngoài ra, nhiều nhiệm vụ có thể không chia nhỏ được hơn nữa (chia nhỏ công việc là phân phối công việc ra các nguồn lực để xử lý) dẫn đến tốc độ tăng tiềm năng cũng thấp hơn. Cụm từ phổ biến trong giao hàng "Chín phụ nữ không thể sinh con trong một tháng" liên quan đến Luật Brooks, đặc biệt, thực tế là một số loại công việc không thể phân chia hoặc song song. Đây là chủ đề trung tâm của cuốn sách ' [The Mythical Man Month](#reading-list) '. Xem thêm: - [Thần chết xuất hiện](#todo) - [Danh sách đọc: Tháng người đàn ông thần thoại](#reading-list) ### Định lý CAP (Định lý Brewer) Định lý CAP (do Eric Brewer định nghĩa) tuyên bố rằng đối với một kho lưu trữ dữ liệu phân tán, chỉ có thể thực hiện hai trong ba bảo đảm sau (nhiều nhất): - Tính đồng bộ (Consistency): khi đọc dữ liệu, mọi yêu cầu đều nhận được _dữ liệu gần đây nhất_ hoặc lỗi được trả về - Tính sẵn sàng (Availability): khi đọc dữ liệu, mọi yêu cầu đều nhận được _phản hồi không lỗi_ , mà không cần đảm bảo rằng đó là dữ liệu _mới nhất_ - Chịu lỗi(P-Partition Tolerance): khi một số lượng tùy ý yêu cầu mạng giữa các nút không thành công, hệ thống tiếp tục hoạt động như thiết kế. Cốt lõi của lý do là như sau. Không thể đảm bảo sai biệt cục bộ không xảy ra (xem [Sự sụp đổ của Máy tính Phân tán](#the-fallacies-of-distributed-computing) ). Do đó, trong trường hợp sai biệt cục bộ, chúng ta có thể hoặc ngưng công việc (tăng tính đồng bộ và giảm tính sẵn sàng) hoặc tiếp tục công việc (tăng tính sẵn sàng nhưng giảm tính đồng bộ). Tên gọi xuất phát từ các chữ cái đầu tiên (Consistency, Availability, Partition Tolerance). Lưu ý rằng điều rất quan trọng cần lưu ý là điều này _không_ liên quan đến [_ACID_](#TODO) , có định nghĩa khác về tính đồng bộ. Gần đây hơn, [định lý PACELC](#TODO) đã được phát triển để bổ sung các ràng buộc về độ trễ và tính đồng bộ khi mạng _không bị_ sai biệt cục bộ (tức là khi hệ thống đang hoạt động như mong đợi). Hầu hết các nền tảng cơ sở dữ liệu hiện đại đều thừa nhận định lý này một cách ngầm định bằng cách cung cấp cho người dùng cơ sở dữ liệu tùy chọn để lựa chọn giữa việc họ muốn một hoạt động có tính khả dụng cao (có thể bao gồm 'đọc bẩn') hay một hoạt động nhất quán cao (ví dụ: một 'số đại biểu được thừa nhận ghi '). Ví dụ trong thế giới thực: - [Bên trong Google Cloud Spanner và Định lý CAP](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) - Đi vào chi tiết về cách hoạt động của Cloud Spanner, thoạt đầu có vẻ giống như một nền tảng có _tất cả_ các đảm bảo của CAP, nhưng bên dưới cơ bản là một hệ thống CP. Xem thêm: - [AXIT](#TODO) - [Sự sụp đổ của máy tính phân tán](#the-fallacies-of-distributed-computing) - [PACELC](#TODO) ### Định luật Conway [Luật Conway trên Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law) Luật này gợi ý rằng các biên giới kỹ thuật của một hệ thống sẽ phản ánh cấu trúc của tổ chức. Nó thường được nhắc đến khi xem xét các cải tiến của tổ chức, Luật Conway gợi ý rằng nếu một tổ chức được cấu trúc thành nhiều đơn vị nhỏ, không kết nối thì phần mềm mà nó tạo ra sẽ là như vậy. Nếu một tổ chức được xây dựng nhiều hơn xung quanh 'ngành dọc' được định hướng xung quanh các tính năng hoặc dịch vụ, hệ thống phần mềm cũng sẽ phản ánh điều này. Xem thêm: - [Mô hình Spotify](#the-spotify-model) ### Định luật Cunningham [Định luật Cunningham trên Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law) > Cách tốt nhất để có câu trả lời đúng trên Internet không phải là đặt câu hỏi, mà là hẫy đăng câu trả lời sai. Theo Steven McGeady, Ward Cunningham đã khuyên anh ta vào đầu những năm 1980: "Cách tốt nhất để có câu trả lời đúng trên Internet không phải là đặt một câu hỏi, mà là hẫy đăng câu trả lời sai." McGeady gọi đây là định luật Cunningham, mặc dù Cunningham phủ nhận quyền sở hữu gọi nó là "trích dẫn sai". Mặc dù ban đầu đề cập đến các tương tác trên Usenet, luật đã được sử dụng để mô tả cách hoạt động của các cộng đồng trực tuyến khác (ví dụ: Wikipedia, Reddit, Twitter, Facebook). Xem thêm: - [XKCD 386: "Cuộc gọi nghĩa vụ"](https://xkcd.com/386/) ### Số Dunbar [Số Dunbar trên Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number) "Con số của Dunbar là một giới hạn nhận thức được đề xuất cho số người mà một người có thể duy trì các mối quan hệ xã hội ổn định - các mối quan hệ trong đó một cá nhân biết mỗi người là ai và mối quan hệ của mỗi người với mọi người khác như thế nào." Không có một con số chính xác. "... [Dunbar] đề xuất rằng con người chỉ có thể thoải mái duy trì 150 mối quan hệ ổn định." Ông đặt con số vào một bối cảnh xã hội hơn, "số lượng người mà bạn sẽ không cảm thấy xấu hổ khi tham gia một cuộc uống không được mời nếu bạn tình cờ gặp họ trong một quán bar." Các ước tính cho con số thường nằm trong khoảng từ 100 đến 250. Giống như mối quan hệ ổn định giữa các cá nhân, mối quan hệ của nhà phát triển với cơ sở mã cần nỗ lực để duy trì. Khi đối mặt với các dự án lớn phức tạp, hoặc sở hữu nhiều dự án, chúng tôi dựa trên quy ước, chính sách và quy trình được mô hình hóa để mở rộng quy mô. Con số của Dunbar không chỉ quan trọng cần ghi nhớ khi văn phòng phát triển mà còn khi thiết lập phạm vi cho các nỗ lực của nhóm hoặc quyết định khi nào một hệ thống nên đầu tư vào công cụ để hỗ trợ mô hình hóa và tự động hóa chi phí hậu cần. Đặt con số vào bối cảnh kỹ thuật, đó là số lượng dự án (hoặc độ phức tạp được chuẩn hóa của một dự án) mà bạn cảm thấy tự tin khi tham gia vòng quay theo cuộc gọi để hỗ trợ. Xem thêm: - [Định luật Conway](#conways-law) ### Hiệu ứng Dunning-Kruger [Hiệu ứng Dunning-Kruger trên Wikipedia](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) > Nếu bạn không đủ năng lực, bạn không thể biết mình kém cỏi ... Kỹ năng cần để đưa ra một câu trả lời đúng, chính là kỹ năng cần để nhận ra một câu trả lời đúng. > > ( [David Dunning](https://en.wikipedia.org/wiki/David_Dunning) ) Hiệu ứng Dunning-Kruger là một khuynh hướng nhận thức lý thuyết được David Dunning và Justin Kruger mô tả trong một bài báo và nghiên cứu tâm lý năm 1999. Nghiên cứu cho thấy rằng những người có mức năng lực thấp trong một nhiệm vụ có khả năng đánh giá quá cao khả năng của họ trong nhiệm vụ. Lý do được đề xuất cho sự thiên vị này là một người cần có _nhận thức_ đầy đủ về mức độ phức tạp của một vấn đề hoặc lĩnh vực để có thể đưa ra ý kiến sáng suốt về khả năng làm việc của họ trong lĩnh vực đó. Hiệu ứng Dunning-Kruger đôi khi được sử dụng để mô tả một hiệu ứng có liên quan, nhưng không nhất thiết ngụ ý mà có thể được mô tả là "Một người càng ít hiểu về một vấn đề, họ càng tin rằng họ có thể dễ dàng giải quyết các vấn đề đó, như họ có nhiều khả năng thấy miền là _đơn giản_ ". Hiệu ứng tổng quát hơn này rất phù hợp trong công nghệ. Nó sẽ gợi ý rằng những người ít quen thuộc với một vấn đề, chẳng hạn như thành viên nhóm không chuyên về kỹ thuật hoặc thành viên nhóm ít kinh nghiệm, có nhiều khả năng _đánh giá thấp_ nỗ lực cần thiết để giải quyết một vấn đề trong không gian này. Khi sự hiểu biết và kinh nghiệm của một người trong một lĩnh vực tăng lên, họ cũng có thể gặp phải một tác động khác, đó là họ có xu hướng _đánh giá quá cao_ khả năng của _người khác_ hoặc _đánh giá thấp_ khả năng của chính họ, vì họ đã trở nên có kinh nghiệm trong lĩnh vực đó. Trong mọi trường hợp, những tác động này là _thành kiến về nhận thức_ . Như với bất kỳ sự thiên vị nào, sự hiểu biết rằng nó có thể có thường sẽ đủ để giúp tránh những thách thức - vì khi có nhận thức về sự thiên vị, nhiều đầu vào và ý kiến hơn có thể được đưa vào để cố gắng loại bỏ những thành kiến này. Một liên quan mật thiết là sự thiên vị về [ưu thế](https://en.wikipedia.org/wiki/Illusory_superiority) của Huyễn Ảnh. Ví dụ trong thế giới thực: - [Apple vs. FBI: Tại sao Diều hâu chống khủng bố này lại chuyển hướng](https://fortune.com/2016/03/10/apple-fbi-lindsay-graham/) - Năm 2016, Thượng nghị sĩ Lindsey Graham đã thay đổi lập trường của mình về việc Apple tạo ra một 'cửa sau' trong mã hóa thiết bị của họ. Ban đầu, Graham đã chỉ trích Apple thách thức yêu cầu tạo một 'cửa sau', mà ông cho là cần thiết để điều tra các âm mưu khủng bố tiềm ẩn. Tuy nhiên, nhờ sự thừa nhận của chính Graham, khi anh ấy hiểu thêm về độ phức tạp kỹ thuật của miền, anh ấy nhận ra rằng anh ấy đã cho rằng nó đơn giản hơn nhiều so với những gì anh ấy đã nhận ra và rằng một cửa hậu như vậy có thể gây ra những hậu quả tiêu cực nghiêm trọng. Đây có thể được coi là một ví dụ về hiệu ứng Dunning-Kruger - một chuyên gia an ninh mạng có thể sẽ hiểu ngay lập tức về cách một cửa hậu như vậy có thể bị khai thác, vì họ có hiểu biết sâu sắc về miền, một người dân có thể cho rằng bảo mật điện thoại tương tự hơn đối với _bảo mật vật lý_ khi có thể thực hiện được 'khóa chính' để thực thi pháp luật, nhưng sự tương tự này không áp dụng đủ tốt để mô tả mã hóa hiện đại trong an ninh mạng. ### Luật Fitts' [Luật phù hợp với Wikipedia](https://en.wikipedia.org/wiki/Fitts%27s_law) Định luật Fitts dự đoán rằng thời gian cần thiết để di chuyển đến một khu vực mục tiêu là một hàm của khoảng cách đến mục tiêu chia cho chiều rộng của mục tiêu. Diagram: Fitts Law _(Tham khảo hình ảnh: Bởi Foobar628 tại Wikipedia tiếng Anh, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)_ Hệ quả của luật này quy định rằng khi thiết kế UX hoặc UI, các phần tử tương tác phải càng lớn càng tốt và khoảng cách giữa vùng chú ý của người dùng và phần tử tương tác phải càng nhỏ càng tốt. Điều này có hậu quả về thiết kế, chẳng hạn như nhóm các nhiệm vụ thường được sử dụng với nhau. Nó cũng chính thức hóa khái niệm 'góc ma thuật', các góc của màn hình mà người dùng có thể 'quét' chuột của họ để dễ dàng nhấn - đó là nơi có thể đặt các phần tử giao diện người dùng chính. Nút Start của Windows nằm ở một góc kỳ diệu, giúp bạn dễ dàng lựa chọn và như một sự tương phản thú vị, nút 'đóng cửa sổ' của MacOS _không_ nằm ở một góc ma thuật, nên khó có thể nhấn nhầm. Xem thêm: - [Năng lực thông tin của hệ thống vận động của con người trong việc điều khiển biên độ vận động.](https://www.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d) ### Luật Gall [Luật Gall trên Wikipedia]() > Một hệ thống phức tạp luôn luôn được phát hiện là đã được phát triển từ một hệ thống đơn giản đã hoạt động. Một hệ thống phức tạp được thiết kế từ đầu không bao giờ hoạt động và không thể được vá để làm cho nó hoạt động. Bạn phải bắt đầu lại với một hệ thống hoạt động đơn giản. > > ( [John Gall]() ) Định luật Gall ngụ ý rằng những nỗ lực _thiết kế_ các hệ thống phức tạp có khả năng thất bại cao. Các hệ thống phức tạp cao hiếm khi được xây dựng trong một lần, mà thực tế là phát triển từ các hệ thống đơn giản hơn. Ví dụ cổ điển là world-wide-web. Ở trạng thái hiện tại, nó là một hệ thống rất phức tạp. Tuy nhiên, ban đầu nó được định nghĩa là một cách đơn giản để chia sẻ nội dung giữa các tổ chức học thuật. Nó đã rất thành công trong việc đáp ứng những mục tiêu này và ngày càng phát triển trở nên phức tạp hơn theo thời gian. Xem thêm: - [KISS (Giữ nó đơn giản, ngu ngốc)](#the-kiss-principle) ### Luật Goodhart [Định luật Goodhart trên Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law) > Mọi hệ thống có xu hướng sụp đổ khi chịu áp lực thống kê quan sát với mục đích kiểm soát đặt lên nó > > _Charles Goodhart_ Cũng thường được gọi là: > Khi đo lường trở thành mục tiêu, nó không còn là một đo lường tốt. > > _Marilyn Strathern_ Luật nói rằng các tối ưu hóa theo hướng đo lường, có thể dẫn đến việc giảm giá trị của chính kết quả đo lường. Việc áp dụng một cách mù quáng các bộ đo lường ( [KPI](https://en.wikipedia.org/wiki/Performance_indicator) ) cho một quy trình dẫn đến hiệu quả bị bóp méo. Mọi người có xu hướng tối ưu hóa cục bộ bằng cách "chơi" hệ thống để đáp ứng các chỉ số cụ thể, thay vì chú ý đến kết quả tổng thể của các hành động của họ. Ví dụ trong thế giới thực: - Các bài kiểm tra không có xác nhận đáp ứng kỳ vọng về độ bao phủ của mã, mặc dù thực tế là mục đích của số liệu là tạo ra phần mềm được kiểm tra tốt. - Khi điểm hiệu suất của nhà phát triển được tính bằng số dòng lệnh được cam kết, sẽ dẫn đến số dòng lệnh bị phình ra một cách vô cớ. Xem thêm: - [Luật Goodhart: Cách đo lường những điều sai trái thúc đẩy hành vi trái đạo đức](https://coffeeandjunk.com/goodharts-campbells-law/) - [Dilbert trên phần mềm không có lỗi](https://dilbert.com/strip/1995-11-13) ### Hanlon Razor [Hanlon Razor trên Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor) > Kết quả xấu không thể giải thích được bằng ác ý, mà bằng sự ngu dốt > > Robert J. Hanlon Nguyên tắc này gợi ý rằng những hành động dẫn đến một kết quả xấu không phải là do ý chí xấu. Thay vào đó, kết quả xấu có nhiều khả năng là do những hành động hoặc tác động không được hiểu một cách đầy đủ. ### Luật Hick (Luật Hick-Hyman) [Luật Hick trên Wikipedia](https://en.wikipedia.org/wiki/Hick%27s_law) > Thời gian quyết định tăng theo logarit với số lượng tùy chọn bạn có thể chọn. > > William Edmund Hick và Ray Hyman Trong phương trình dưới đây, `T` là thời gian để đưa ra quyết định, `n` là số lựa chọn và `b` là hằng số được xác định bằng phân tích dữ liệu. ![Luật Hicks](./images/hicks_law.svg) _(Hình ảnh tham khảo: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)_ Luật này chỉ áp dụng khi số lượng tùy chọn được _sắp xếp_ , ví dụ, theo thứ tự bảng chữ cái. Điều này được ngụ ý trong lôgarit cơ số hai - ngụ ý người ra quyết định về cơ bản đang thực hiện _tìm kiếm nhị phân_ . Nếu các tùy chọn không được sắp xếp hợp lý, các thử nghiệm cho thấy thời gian thực hiện là tuyến tính. Điều này có tác động đáng kể trong thiết kế giao diện người dùng; đảm bảo rằng người dùng có thể dễ dàng tìm kiếm thông qua các tùy chọn dẫn đến việc ra quyết định nhanh hơn. Một mối tương quan cũng đã được chỉ ra trong Định luật Hick giữa chỉ số IQ và thời gian phản ứng như được thể hiện trong [Tốc độ xử lý thông tin: Thay đổi phát triển và liên kết với trí thông minh](https://www.sciencedirect.com/science/article/pii/S0022440599000369) . Xem thêm: - [Luật Fitts](#fitts-law) ### Định luật Hofstadter [Hofstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law) > Nó luôn mất nhiều thời gian hơn bạn dự tính, ngay cả khi bạn tính đến Định luật Hofstadter. > > (Douglas Hofstadter) Bạn có thể nghe thấy luật này được đề cập đến khi xem xét các ước tính về thời gian. Có vẻ như một sự sai lầm trong phát triển phần mềm là chúng ta có xu hướng không giỏi trong việc ước tính chính xác thời gian một thứ gì đó sẽ được phân phối. Đây là từ cuốn sách ' [Gödel, Escher, Bach: Một bím tóc vàng vĩnh cửu](#reading-list) '. Xem thêm: - [Danh sách đọc: Gödel, Escher, Bach: Một bím tóc vàng vĩnh cửu](#reading-list) ### Định luật Hutber [Luật Hutber trên Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) > Cải tiến nghĩa là xấu đi. > > ( [Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber) ) Luật này gợi ý rằng những cải tiến đối với một hệ thống sẽ dẫn đến sự hư hỏng ở các bộ phận khác, hoặc nó sẽ che giấu sự hư hỏng khác, dẫn đến sự suy thoái về tổng thể so với trạng thái hiện tại của hệ thống. Ví dụ: giảm độ trễ phản hồi cho một điểm cuối cụ thể có thể gây ra các vấn đề về thông lượng và dung lượng tăng thêm trong luồng yêu cầu, ảnh hưởng đến một hệ thống con hoàn toàn khác. ### Chu kỳ Hype & Định luật Amara [Chu kỳ cường điệu hóa trên Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle) > Chúng ta có xu hướng đánh giá cao hiệu quả của một công nghệ trong ngắn hạn và đánh giá thấp hiệu quả về lâu dài. > > (Roy Amara) Hype Cycle là hình ảnh đại diện cho sự sôi động và phát triển của công nghệ theo thời gian, ban đầu được sản xuất bởi Gartner. Nó được hiển thị tốt nhất bằng hình ảnh: ![Chu kỳ Hype](./images/gartner_hype_cycle.png) _(Tham khảo hình ảnh: Bởi Jeremykemp tại Wikipedia tiếng Anh, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)_ Nói tóm lại, chu kỳ này cho thấy rằng thường có sự bùng nổ về công nghệ mới và tác động tiềm tàng của nó. Các đội thường nhanh chóng tham gia vào các công nghệ này, và đôi khi cảm thấy thất vọng với kết quả. Điều này có thể là do công nghệ chưa đủ trưởng thành hoặc các ứng dụng trong thế giới thực vẫn chưa được thực hiện đầy đủ. Sau một khoảng thời gian nhất định, khả năng của công nghệ tăng lên và các cơ hội thực tế để sử dụng nó cũng tăng lên, và các nhóm cuối cùng có thể trở nên hiệu quả. Câu nói của Roy Amara tóm tắt điều này một cách ngắn gọn nhất - "Chúng ta có xu hướng đánh giá quá cao tác dụng của một công nghệ trong ngắn hạn và đánh giá thấp về lâu dài". ### Luật Hyrum (Luật của các giao diện ngầm) [Luật trực tuyến của Hyrum](http://www.hyrumslaw.com/) > Với đủ số lượng người dùng đủ lớn, điều bạn cam kết trong đặc tả không quan trọng: tất cả các hành vi có thể quan sát được trên hệ thống của bạn sẽ phụ thuộc vào ai đó. > > (Hyrum Wright) Luật của Hyrum tuyên bố rằng khi bạn có một _số lượng đủ lớn lời gọi đến bộ_ API, tất cả các hành vi của API (ngay cả những hành vi không được định nghĩa là một phần của hợp đồng công khai) cuối cùng sẽ phụ thuộc vào ai đó. Ví dụ đơn giản có thể là các tính phi chức năng, như thời gian phản hồi của một API. Một ví dụ tinh tế hơn có thể là người tiêu dùng đang dựa vào việc áp dụng regex cho một thông báo lỗi để xác định _loại_ lỗi của một API. Ngay cả khi hợp đồng công khai của API không nêu gì về nội dung của thông báo, cho biết người dùng nên sử dụng mã lỗi liên quan, _một số_ người dùng có thể sử dụng thông báo và việc thay đổi thông báo về cơ bản sẽ phá vỡ API đối với những người dùng đó. Xem thêm: - [Luật trừu tượng rò rỉ](#the-law-of-leaky-abstractions) - [XKCD 1172](https://xkcd.com/1172/) ### Định luật Kernighan > Gỡ lỗi khó gấp đôi so với viết mã ngay từ đầu. Do đó, nếu bạn viết mã một cách khéo léo nhất có thể, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi nó. > > (Brian Kernighan) Định luật Kernighan được đặt tên cho [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) và bắt nguồn từ một trích dẫn từ cuốn sách [Các yếu tố của phong cách lập trình của](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style) Kernighan và Plauger: > Mọi người đều biết rằng việc gỡ lỗi khó gấp đôi so với việc viết một chương trình ngay từ đầu. Vì vậy, nếu bạn thông minh hết mức có thể khi bạn viết nó, làm thế nào bạn sẽ gỡ lỗi nó? Mặc dù hyperbolic, Luật Kernighan đưa ra lập luận rằng mã đơn giản được ưu tiên hơn mã phức tạp, bởi vì việc gỡ lỗi bất kỳ vấn đề nào phát sinh trong mã phức tạp có thể tốn kém hoặc thậm chí không khả thi. Xem thêm: - [Nguyên tắc KISS](#the-kiss-principle) - [Triết lý Unix](#the-unix-philosophy) - [Dao cạo của Occam](#occams-razor) ### Luật Linus [Luật Linus trên Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law) > Càng nhiều người nhìn vào sẽ lấy ra nhiều lỗi. > > _Eric S. Raymond_ Luật này chỉ đơn giản nói rằng càng nhiều người có thể nhìn thấy một vấn đề, thì khả năng một người nào đó đã nhìn thấy và giải quyết vấn đề đó trước đây, hoặc một cái gì đó tương tự. Mặc dù ban đầu nó được sử dụng để mô tả giá trị của các mô hình mã nguồn mở cho các dự án, nó có thể được chấp nhận cho bất kỳ loại dự án phần mềm nào. Nó cũng có thể được mở rộng cho các quy trình - nhiều đánh giá mã hơn, phân tích tĩnh hơn và các quy trình kiểm tra đa nguyên tắc sẽ làm cho các vấn đề hiển thị và dễ xác định hơn. Một tuyên bố chính thức hơn có thể là: > Với cơ sở người thử nghiệm beta và đồng phát triển đủ lớn, hầu hết mọi vấn đề sẽ được xác định một cách nhanh chóng và có thể được giải quyết bởi những người đã từng gặp sự cố tương tự trước đây. Luật này được đặt tên để vinh danh [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) trong cuốn sách " [The Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) " của Eric S. Raymond. ### Định luật Metcalfe [Luật Metcalfe trên Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law) > Trong lý thuyết mạng, giá trị của một hệ thống tăng lên xấp xỉ bình phương của số lượng người dùng của hệ thống. Luật này dựa trên số lượng các kết nối theo cặp có thể có trong một hệ thống và có liên quan chặt chẽ với Định [luật Reed](#reeds-law) . Odlyzko và những người khác đã lập luận rằng cả Định luật Reed và Định luật Metcalfe đều phóng đại giá trị của hệ thống bằng cách không tính đến giới hạn nhận thức của con người về hiệu ứng mạng; xem [Số của Dunbar](#dunbars-number) . Xem thêm: - [Luật Reed](#reeds-law) - [Số Dunbar](#dunbars-number) ### Định luật Moore [Định luật Moore trên Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law) > Số lượng bóng bán dẫn trong một mạch tích hợp tăng gấp đôi khoảng hai năm một lần. Thường được sử dụng để minh họa tốc độ tuyệt đối mà công nghệ bán dẫn và chip đã được cải thiện, dự đoán của Moore đã được chứng minh là có độ chính xác cao trong khoảng thời gian từ những năm 1970 đến cuối những năm 2000. Trong những năm gần đây, xu hướng đã thay đổi một chút, một phần do [những hạn chế vật lý về mức độ thu nhỏ của các thành phần](https://en.wikipedia.org/wiki/Quantum_tunnelling) . Tuy nhiên, những tiến bộ trong quá trình song song hóa và những thay đổi có khả năng mang tính cách mạng trong công nghệ bán dẫn và điện toán lượng tử có thể có nghĩa là Định luật Moore có thể tiếp tục đúng trong nhiều thập kỷ tới. ### Định luật Murphy / Sod [Định luật Murphy trên Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law) > Điều gì có thể xảy ra sai sót sẽ xảy ra sai sót. Liên quan đến [Edward A. Murphy, Định luật Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Murphy_ nói rằng nếu cái gì sai, nó sẽ lòi ra. Đây là một câu châm ngôn phổ biến giữa các nhà phát triển. Đôi khi điều không mong muốn xảy ra khi phát triển, thử nghiệm hoặc thậm chí trong quá trình sản xuất. Điều này cũng có thể liên quan đến Định _luật Sod_ (phổ biến hơn trong tiếng Anh Anh): > Nếu điều gì đó có thể xảy ra, nó sẽ xảy ra vào thời điểm tồi tệ nhất có thể. Những 'luật' này thường được sử dụng theo nghĩa truyện tranh. Tuy nhiên, các hiện tượng như [_Thiên lệch xác nhận_](#TODO) và [_Thiên lệch lựa chọn_](#TODO) có thể khiến mọi người có lẽ quá nhấn mạnh các định luật này (phần lớn khi mọi thứ hoạt động, chúng không được chú ý, tuy nhiên, thất bại lại được chú ý nhiều hơn và thu hút nhiều thảo luận hơn). Xem thêm: - [Khuynh hướng xác nhận](#TODO) - [Xu hướng lựa chọn](#TODO) ### Occam's Razor [Occam's Razor trên Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor) > Các thực thể không nên được nhân lên khi không cần thiết. > > William của Ockham Occam nói rằng trong số một số giải pháp khả thi, giải pháp khả dĩ nhất là giải pháp có ít khái niệm và giả định nhất. Giải pháp này là giải pháp đơn giản nhất và chỉ giải quyết được vấn đề đã cho, mà không tạo ra sự phức tạp ngẫu nhiên và hậu quả tiêu cực có thể xảy ra. Xem thêm: - [YAGNI](#yagni) - [Không có viên đạn bạc: Sự phức tạp tình cờ và sự phức tạp thiết yếu](https://en.wikipedia.org/wiki/No_Silver_Bullet) Thí dụ: - [Phát triển phần mềm tinh gọn: Loại bỏ lãng phí](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) ### Định luật Parkinson [Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law) > Công việc mở rộng để lấp đầy thời gian có sẵn để hoàn thành. Trong bối cảnh ban đầu, Luật này dựa trên các nghiên cứu về các bộ máy quan liêu. Nó có thể được áp dụng một cách bi quan cho các sáng kiến phát triển phần mềm, lý thuyết cho rằng các nhóm sẽ hoạt động kém hiệu quả cho đến khi thời hạn gần kề, sau đó vội vàng hoàn thành công việc trước thời hạn, do đó làm cho thời hạn thực tế hơi tùy tiện. Nếu luật này được kết hợp với Định luật [Hofstadter](#hofstadters-law) , một quan điểm thậm chí còn bi quan hơn - công việc sẽ mở rộng để lấp đầy thời gian có sẵn để hoàn thành và _vẫn mất nhiều thời gian hơn dự kiến_ . Xem thêm: - [Định luật Hofstadter](#hofstadters-law) ### Hiệu ứng tối ưu hóa sớm [Tối ưu hóa sớm trên WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) > Tối ưu sớm là gốc rễ của mọi xấu xa. > > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) Trong bài báo của Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) , ông đã viết: "Các lập trình viên lãng phí rất nhiều thời gian để suy nghĩ hoặc lo lắng về tốc độ của các phần không quan trọng trong chương trình của họ và những nỗ lực về hiệu quả này thực sự có tác động tiêu cực mạnh khi gỡ lỗi và bảo trì được xem xét. Chúng ta nên quên đi những hiệu quả nhỏ, nói rằng khoảng 97% thời gian: **tối ưu hóa sớm là gốc rễ của mọi điều xấu** . Tuy nhiên, chúng ta không nên bỏ qua cơ hội của mình trong 3% quan trọng đó. " Tuy nhiên, _Tối ưu hóa sớm_ có thể được định nghĩa (theo thuật ngữ ít tải hơn) là tối ưu hóa trước khi chúng ta biết rằng chúng ta cần phải làm như vậy. ### Định luật Putt [Luật Putt trên Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) > Công nghệ bị chi phối bởi hai loại người, những người hiểu những gì họ không quản lý và những người quản lý những gì họ không hiểu. Định luật Putt thường được tuân theo bởi Hệ quả Putt: > Mọi hệ thống phân cấp kỹ thuật, theo thời gian, phát triển một sự nghịch đảo năng lực. Những tuyên bố này cho thấy rằng do các tiêu chí lựa chọn khác nhau và xu hướng trong cách tổ chức nhóm, sẽ có một số người có kỹ năng ở các cấp làm việc của một tổ chức kỹ thuật và một số người trong vai trò quản lý không nhận thức được sự phức tạp và thách thức của công việc mà họ đang quản lý. Điều này có thể là do các hiện tượng như [Nguyên tắc Peter](#the-peter-principle) hoặc [Nguyên tắc Dilbert](#the-dilbert-principle) . Tuy nhiên, cần nhấn mạnh rằng các Luật như thế này là khái quát rộng lớn và có thể áp dụng cho _một số_ loại hình tổ chức và không áp dụng cho các loại hình tổ chức khác. Xem thêm: - [Nguyên tắc Peter](#the-peter-principle) - [Nguyên tắc Dilbert](#the-dilbert-principle) ### Luật Reed [Luật Reed trên Wikipedia](https://en.wikipedia.org/wiki/Reed's_law) > Tiện ích trên các mạng lớn, đặc biệt là mạng xã hội, sẽ có quy mô theo cấp số nhân so với quy mô của mạng. Luật này dựa trên lý thuyết đồ thị, trong đó tiện ích mở rộng theo số lượng các nhóm con, nhanh hơn số lượng người tham gia hoặc số lượng các kết nối theo cặp có thể có. Odlyzko và những người khác đã lập luận rằng Định luật Reed phóng đại quá mức tiện ích của hệ thống bằng cách không tính đến các giới hạn nhận thức của con người về các hiệu ứng mạng; xem [Số của Dunbar](#dunbars-number) . Xem thêm: - [Định luật Metcalfe](#metcalfes-law) - [Số Dunbar](#dunbars-number) ### Định luật Bảo toàn Độ phức tạp (Định luật Tesler) [Luật bảo tồn sự phức tạp trên Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) Luật này nói rằng có một lượng phức tạp nhất định trong một hệ thống và chúng không thể giảm bớt. Một số phức tạp trong một hệ thống là 'vô tình'. Đó là hệ quả của cấu trúc kém, sai lầm hoặc chỉ là mô hình hóa vấn đề cần giải quyết một cách tồi tệ. Sự phức tạp do sơ ý có thể được giảm bớt (hoặc loại bỏ). Tuy nhiên, một số phức tạp là 'nội tại' là hệ quả của sự phức tạp vốn có trong vấn đề đang được giải quyết. Sự phức tạp này có thể được di chuyển, nhưng không được loại bỏ. Một yếu tố thú vị đối với luật này là gợi ý rằng ngay cả khi đơn giản hóa toàn bộ hệ thống, độ phức tạp nội tại vẫn không giảm, nó được _chuyển đến người dùng_ , người phải hành xử theo cách phức tạp hơn. ### Định luật Demeter [Định luật Demeter trên Wikipedia](https://en.wikipedia.org/wiki/Law_of_Demeter) > Đừng nói chuyện với người lạ. Định luật Demeter, còn được gọi là "Nguyên tắc của kiến thức ít nhất" là một nguyên tắc cho thiết kế phần mềm, đặc biệt thích hợp trong các ngôn ngữ hướng đối tượng. Nó nói rằng một đơn vị phần mềm chỉ nên nói chuyện với các cộng tác viên trực tiếp của nó. Một đối tượng `A` có tham chiếu đến đối tượng `B` có thể gọi các phương thức của nó, nhưng nếu `B` có tham chiếu đến đối tượng `C` , `A` không nên gọi các phương thức của `C` Vì vậy, nếu `C` có phương thức `doThing()` `A` không nên gọi nó trực tiếp; `B.getC().doThis()` . Việc tuân theo nguyên tắc chính này sẽ giới hạn phạm vi thay đổi, giúp chúng dễ dàng hơn và an toàn hơn trong tương lai. ### Luật trừu tượng rò rỉ [Luật về sự tóm tắt rò rỉ trên Joel trên phần mềm](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) > Tất cả những thiết kế trừu tượng không tầm thường, ở một mức độ nào đó, đều bị rò rỉ. > > ( [Joel Spolsky](https://twitter.com/spolsky) ) Luật này quy định rằng trừu tượng, thường được sử dụng trong máy tính để đơn giản hóa làm việc với các hệ thống phức tạp, trong một số tình huống nhất định sẽ làm 'rò rỉ' các phần tử của hệ thống cơ bản, điều này làm cho trừu tượng hoạt động theo cách không mong muốn. Một ví dụ có thể đang tải một tệp và đọc nội dung của nó. Các API hệ thống tệp là một phần _trừu tượng_ của các hệ thống nhân cấp thấp hơn, bản thân chúng là một phần trừu tượng đối với các quá trình vật lý liên quan đến việc thay đổi dữ liệu trên đĩa từ tính (hoặc bộ nhớ flash cho SSD). Trong hầu hết các trường hợp, việc xử lý một tệp như một luồng dữ liệu nhị phân sẽ hoạt động. Tuy nhiên, đối với ổ đĩa từ tính, việc đọc dữ liệu tuần tự sẽ _nhanh hơn đáng kể_ so với truy cập ngẫu nhiên (do lỗi trang tăng lên), nhưng đối với ổ đĩa SSD, chi phí này sẽ không xuất hiện. Cần phải hiểu chi tiết cơ bản để đối phó với trường hợp này (ví dụ: các tệp chỉ mục cơ sở dữ liệu được cấu trúc để giảm chi phí truy cập ngẫu nhiên), chi tiết triển khai 'rò rỉ' trừu tượng mà nhà phát triển có thể cần phải biết. Ví dụ trên có thể trở nên phức tạp _hơn khi có nhiều nội dung_ trừu tượng hơn. Hệ điều hành Linux cho phép các tệp được truy cập qua mạng nhưng được trình bày cục bộ dưới dạng tệp 'bình thường'. Tóm tắt này sẽ 'rò rỉ' nếu có lỗi mạng. Nếu nhà phát triển coi các tệp này là tệp 'bình thường' mà không xem xét đến thực tế là chúng có thể phải chịu độ trễ và lỗi mạng, thì các giải pháp sẽ có lỗi. Bài báo mô tả luật cho thấy rằng việc phụ thuộc quá nhiều vào những điều trừu tượng, kết hợp với sự hiểu biết kém về các quy trình cơ bản, thực sự khiến việc xử lý vấn đề trong một số trường hợp _trở nên phức tạp hơn._ Xem thêm: - [Định luật Hyrum](#hyrums-law-the-law-of-implicit-interfaces) Ví dụ trong thế giới thực: - [Photoshop khởi động chậm](https://forums.adobe.com/thread/376152) - một vấn đề tôi gặp phải trong quá khứ. Photoshop khởi động chậm, đôi khi mất vài phút. Có vẻ như vấn đề là khi khởi động, nó đọc một số thông tin về máy in mặc định hiện tại. Tuy nhiên, nếu máy in đó thực sự là một máy in mạng, thì quá trình này có thể mất rất nhiều thời gian. Sự _trừu tượng_ của một máy in mạng được trình bày cho hệ thống tương tự như một máy in cục bộ đã gây ra sự cố cho người dùng trong các tình huống kết nối kém. ### Luật về Sự tầm thường [Luật Sự Tầm Thường trên Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) Luật này gợi ý rằng các nhóm sẽ dành nhiều thời gian và sự chú ý hơn cho những vấn đề nhỏ nhặt hoặc thẩm mỹ hơn là những vấn đề nghiêm trọng và thực chất. Ví dụ hư cấu phổ biến được sử dụng là một ủy ban phê duyệt kế hoạch cho nhà máy điện hạt nhân, họ dành phần lớn thời gian để thảo luận về cấu trúc của nhà để xe đạp, thay vì thiết kế quan trọng hơn nhiều cho chính nhà máy điện. Có thể khó đưa ra ý kiến đóng góp có giá trị cho các cuộc thảo luận về các chủ đề rất lớn, phức tạp nếu không có sự chuẩn bị hoặc chuyên môn cao về chủ đề. Tuy nhiên, mọi người muốn được xem là đóng góp ý kiến đóng góp có giá trị. Do đó, có xu hướng tập trung quá nhiều thời gian vào những chi tiết nhỏ, có thể dễ dàng lý giải, nhưng không nhất thiết phải có tầm quan trọng đặc biệt. Ví dụ hư cấu ở trên đã dẫn đến việc sử dụng thuật ngữ 'lo thiết kế nhà để xe đạp' như một cách diễn đạt cho việc lãng phí thời gian vào những chi tiết nhỏ nhặt. Một thuật ngữ liên quan là ' [Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving) ', có nghĩa là một hoạt động dường như không liên quan nhưng là một phần của chuỗi dài các điều kiện tiên quyết đối với nhiệm vụ chính. ### Triết lý Unix [Triết lý Unix trên Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy) Triết lý của Unix là các thành phần phần mềm phải nhỏ và tập trung vào làm tốt một việc cụ thể. Điều này có thể giúp dễ dàng hơn trong việc xây dựng hệ thống bằng cách biên soạn các đơn vị nhỏ, đơn giản, được xác định rõ ràng, thay vì sử dụng các chương trình lớn, phức tạp, đa mục đích. Các thực hành hiện đại như 'Kiến trúc Microservice' có thể được coi là một ứng dụng của luật này, trong đó các dịch vụ nhỏ, tập trung và thực hiện một việc cụ thể, cho phép hành vi phức tạp bao gồm các khối xây dựng đơn giản. ### Quy tắc Scout [Quy tắc hướng đạo sinh trên O'Reilly](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) > Luôn để lại mã tốt hơn khi bạn tìm thấy. > > (Robert C. Martin (Uncle Bob)) Dựa trên "Quy tắc Hướng đạo", là "luôn để khu cắm trại sạch sẽ hơn khi bạn đến", Quy tắc Hướng đạo trong lập trình chỉ đơn giản là "luôn để mã sạch hơn những gì bạn tìm thấy". Điều này đã được giới thiệu trong chương đầu tiên của cuốn sách [Clean Code](https://www.goodreads.com/book/show/3735293-clean-code) của Bob Martin. Quy tắc gợi ý rằng các nhà phát triển nên thực hiện 'tái cấu trúc lạc quan', có nghĩa là cố gắng cải thiện chất lượng tổng thể của mã khi bạn làm việc trên nó. Nếu bạn thấy lỗi, hãy cố gắng sửa chữa hoặc làm sạch nó. Tuy nhiên, khi thực hiện các thay đổi đối với mã có vẻ không chính xác, bạn nên nhớ [Chesterton's Fence](#chestertons-fence) ! Xem thêm: - [Danh sách đọc: Mã sạch](#reading-list) - [Chesterton's Fence](#chestertons-fence) - [Lý thuyết cửa sổ bị hỏng](#broken-windows-theory) https://www.amazon.sg/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 ### Mô hình Spotify [Mô hình Spotify trên Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) Mô hình Spotify là một phương pháp tiếp cận cấu trúc tổ chức và nhóm đã được phổ biến bởi 'Spotify'. Trong mô hình này, các nhóm được tổ chức xung quanh các tính năng, thay vì công nghệ. Mô hình Spotify cũng phổ biến các khái niệm về Bộ lạc, Bang hội, Chi hội, là các thành phần khác trong cơ cấu tổ chức của chúng. Các thành viên của tổ chức đã mô tả rằng ý nghĩa thực tế của các nhóm này thay đổi, phát triển và là một thử nghiệm đang diễn ra. Thực tế là mô hình là một _quá trình đang vận động_ , chứ không phải là một mô hình cố định tiếp tục dẫn đến các cách hiểu khác nhau về cấu trúc, có thể dựa trên các bài thuyết trình của nhân viên tại các hội nghị. Điều này có nghĩa là 'ảnh chụp nhanh' có thể được bên thứ ba 'đóng gói lại' như một _cấu trúc cố định_ , với thực tế là mô hình động sẽ bị mất. ### Quy tắc hai chiếc bánh pizza > Nếu một 2 chiếc bánh pizza không đủ cho một nhóm, thì nhóm đó đã quá lớn > > (Jeff Bezos) Quy tắc này cho thấy rằng bất kể quy mô của công ty, các đội nên đủ nhỏ để có thể ăn hai chiếc pizza. Được gán cho Jeff Bezos và Amazon, niềm tin này cho thấy rằng các đội lớn vốn đã kém hiệu quả. Điều này được hỗ trợ bởi thực tế là khi quy mô nhóm tăng tuyến tính, liên kết giữa mọi người sẽ tăng theo bậc hai; do đó chi phí phối hợp và giao tiếp cũng tăng theo bậc hai. Nếu chi phí phối hợp này về cơ bản là tổng chi phí, thì các nhóm nhỏ hơn nên được ưu tiên hơn. Số lượng liên kết giữa mọi người có thể được biểu thị bằng `n(n-1)/2` trong đó n = số người. Đồ thị hoàn chỉnh; Liên kết giữa mọi người ### Luật Wadler [Luật của Wadler trên wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) > Trong bất kỳ thiết kế ngôn ngữ nào, tổng thời gian dành để thảo luận về một tính năng trong danh sách này tỷ lệ thuận với hai phần được nâng lên với sức mạnh của vị trí của nó. > > 1. Ngữ nghĩa học > 2. Cú pháp > 3. Cú pháp từ vựng > 4. Cú pháp đơn giản của nhận xét > > (Nói tóm lại, cứ mỗi giờ dành cho ngữ nghĩa thì 8 giờ sẽ dành cho cú pháp của chú thích). Tương tự như [Định luật về tính tầm thường](#the-law-of-triviality) , Định luật của Wadler cho biết khi thiết kế một ngôn ngữ, lượng thời gian dành cho các cấu trúc ngôn ngữ cao hơn một cách tương xứng so với tầm quan trọng của những tính năng đó. Xem thêm: - [Luật tầm thường](#the-law-of-triviality) ### Định luật Wheaton [Liên kết](http://www.wheatonslaw.com/) [Ngày chính thức](https://dontbeadickday.com/) > Đừng khôn kiểu ranh ma. > > _Wil Wheaton_ Được đặt ra bởi Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), luật đơn giản, ngắn gọn và mạnh mẽ này nhằm mục đích tăng cường sự hòa hợp và tôn trọng trong một tổ chức chuyên nghiệp. Nó có thể được áp dụng khi nói chuyện với đồng nghiệp, thực hiện đánh giá mã, phản bác các quan điểm khác, phê bình và nói chung, hầu hết các tương tác chuyên nghiệp mà con người có với nhau. ## Nguyên tắc Các nguyên tắc thường có nhiều khả năng là các hướng dẫn liên quan đến thiết kế. ### Tất cả các mô hình đều sai (Định luật George Box) [Tất cả các mô hình đều sai](https://en.wikipedia.org/wiki/All_models_are_wrong) > Tất cả các mô hình đều sai, nhưng một số mô hình hữu ích. > > _George Box_ Nguyên tắc này cho thấy rằng tất cả các mô hình hệ thống đều có sai sót, nhưng miễn là chúng không _quá_ sai sót thì chúng có thể hữu ích. Nguyên tắc này có nguồn gốc từ thống kê nhưng cũng áp dụng cho các mô hình khoa học và máy tính. Yêu cầu cơ bản của hầu hết các phần mềm là mô hình hóa một hệ thống nào đó. Bất kể hệ thống được mô hình hóa là mạng máy tính, thư viện, biểu đồ kết nối xã hội hay bất kỳ loại hệ thống nào khác, nhà thiết kế sẽ phải quyết định mức độ chi tiết thích hợp để mô hình hóa. Quá nhiều chi tiết có thể dẫn đến quá nhiều phức tạp, quá ít chi tiết có thể khiến mô hình không hoạt động được. Xem thêm: - [Luật trừu tượng rò rỉ](#the-law-of-leaky-abstractions) ### Chesterton's Fence [Chesterton's Fence trên Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence) > Không nên cải cách cho đến khi hiểu được lý do đằng sau tình trạng hiện tại. Nguyên tắc này có liên quan trong kỹ thuật phần mềm khi loại bỏ nợ kỹ thuật. Mỗi dòng của một chương trình ban đầu được viết bởi một người nào đó vì một lý do nào đó. Chesterton's Fence gợi ý rằng người ta nên cố gắng hiểu ngữ cảnh và ý nghĩa của mã một cách đầy đủ, trước khi thay đổi hoặc loại bỏ nó, ngay cả khi thoạt nhìn nó có vẻ thừa hoặc không chính xác. Tên của nguyên tắc này bắt nguồn từ một câu chuyện của [GK Chesterton](https://en.wikipedia.org/wiki/G._K._Chesterton) . Một người đàn ông băng qua hàng rào giữa đường. Anh ta phàn nàn với thị trưởng rằng hàng rào vô dụng này đang cản trở, và yêu cầu dỡ bỏ nó. Thị trưởng hỏi tại sao lại có hàng rào ngay từ đầu. Khi người đàn ông nói rằng anh ta không biết, thị trưởng nói, "Nếu bạn không biết mục đích của nó, tôi chắc chắn sẽ không để bạn gỡ bỏ nó. Hãy đi tìm hiểu công dụng của nó, và sau đó tôi có thể cho phép bạn phá hủy. nó." ### Hiệu ứng Biển Chết [Hiệu ứng Biển Chết với Bruce F. Webster](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/) > Các kỹ sư CNTT tài năng là những người có nhiều khả năng ra đi, ... [những người có xu hướng] ở lại [là] - những kỹ sư CNTT kém tài năng và hiệu quả. > > _Bruce F. Webster_ "Hiệu ứng Biển Chết" cho thấy rằng trong bất kỳ tổ chức nào, kỹ năng / tài năng / hiệu quả của các kỹ sư thường tỷ lệ nghịch với thời gian của họ trong công ty. Thông thường, các kỹ sư có tay nghề cao sẽ dễ dàng kiếm được việc làm ở nơi khác và là những người đầu tiên làm như vậy. Những kỹ sư có kỹ năng lạc hậu hoặc yếu kém sẽ có xu hướng ở lại công ty, vì rất khó tìm việc làm ở nơi khác. Điều này đặc biệt rõ ràng nếu họ nhận được mức lương tăng dần theo thời gian làm việc tại công ty, vì việc nhận được mức thù lao tương đương ở những nơi khác có thể là một thách thức. ### Nguyên tắc Dilbert [Nguyên tắc Dilbert trên Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle) > Các công ty có xu hướng thăng chức một cách có hệ thống những nhân viên không đủ năng lực lên ban quản lý để đưa họ ra khỏi quy trình làm việc. > > _Scott Adams_ Là một khái niệm quản lý được phát triển bởi Scott Adams (tác giả của bộ truyện tranh Dilbert), Nguyên tắc Dilbert được lấy cảm hứng từ [Nguyên tắc Peter](#the-peter-principle) . Theo Nguyên tắc Dilbert, những nhân viên chưa từng có năng lực sẽ được thăng chức lên cấp quản lý để hạn chế thiệt hại mà họ có thể gây ra. Adams lần đầu tiên giải thích nguyên tắc này trong một bài báo trên Tạp chí Phố Wall năm 1995, và mở rộng nó trong cuốn sách kinh doanh năm 1996 của ông, [Nguyên tắc Dilbert](#reading-list) . Xem thêm: - [Nguyên tắc Peter](#the-peter-principle) - [Định luật Putt](#putts-law) ### Nguyên tắc Pareto (Quy tắc 80/20) [Nguyên tắc Pareto trên Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle) > Hầu hết mọi thứ trong cuộc sống không được phân bổ đồng đều. Nguyên tắc Pareto gợi ý rằng trong một số trường hợp, phần lớn kết quả đến từ một số ít đầu vào: - 80% một phần mềm nhất định có thể được viết trong 20% tổng thời gian được phân bổ (ngược lại, 20% mã khó nhất chiếm 80% thời gian) - 20% nỗ lực tạo ra 80% kết quả - 20% công việc tạo ra 80% doanh thu - 20% lỗi gây ra 80% sự cố - 20% tính năng được dùng 80% Vào những năm 1940, kỹ sư người Mỹ-Romania, Tiến sĩ Joseph Juran, người được công nhận rộng rãi là cha đẻ của kiểm soát chất lượng, [đã bắt đầu áp dụng nguyên tắc Pareto cho các vấn đề chất lượng](https://en.wikipedia.org/wiki/Joseph_M._Juran) . Nguyên tắc này còn được gọi là: Quy tắc 80/20, Quy luật số ít và Nguyên tắc về yếu tố thưa thớt. Ví dụ trong thế giới thực: - Vào năm 2002, Microsoft đã báo cáo rằng bằng cách sửa 20% lỗi được báo cáo nhiều nhất, 80% lỗi liên quan và sự cố trong windows và office sẽ bị loại bỏ ( [Tham khảo](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm) ). ### Nguyên tắc Shirky [Nguyên tắc Shirky được giải thích như sau](https://kk.org/thetechnium/the-shirky-prin/) > Các tổ chức sẽ cố gắng duy trì vấn đề mà họ là giải pháp. > > _Clay Shirky_ Nguyên tắc Shirky gợi ý rằng các giải pháp phức tạp - một công ty, một ngành hoặc một công nghệ - có thể trở nên quá tập trung vào vấn đề mà họ đang giải quyết, đến nỗi chúng có thể vô tình kéo dài vấn đề. Điều này có thể là cố ý (một công ty đang cố gắng tìm ra những sắc thái mới cho một vấn đề để biện minh cho việc tiếp tục phát triển một giải pháp), hoặc vô tình (không thể hoặc không sẵn sàng chấp nhận hoặc xây dựng một giải pháp giải quyết được hoàn toàn hoặc loại bỏ nó). Có quan hệ với: - Câu nói nổi tiếng của Upton Sinclair, _"Rất khó để khiến một người đàn ông hiểu điều gì đó, khi mức lương của anh ta phụ thuộc vào việc anh ta không hiểu điều đó!"_ - Clay Christensen's _The Innovator's Dilemma_ Xem thêm: - [Nguyên tắc Pareto](#the-pareto-principle-the-8020-rule) ### Nguyên tắc Peter [Nguyên tắc Peter trên Wikipedia](https://en.wikipedia.org/wiki/Peter_principle) > Những người trong một công ty có xu hướng nâng cao đến "mức độ kém cỏi" của họ. > > _Laurence J. Peter_ Một khái niệm quản lý được phát triển bởi Laurence J. Peter, Nguyên tắc Peter quan sát rằng những người làm tốt công việc của họ được thăng chức, cho đến khi họ đạt đến mức độ mà họ không còn thành công nữa ("mức độ kém cỏi" của họ). Tại thời điểm này, khi họ cao cấp hơn, họ ít có khả năng bị loại khỏi tổ chức hơn (trừ khi làm quá sai) và sẽ tiếp tục ở một vai trò mà họ có ít kỹ năng nội lực, như những kỹ năng ngày đầu đã tạo ra họ thành công, những kỹ năng cũ này không nhất thiết phải có cho công việc mới của họ. Điều này đặc biệt quan tâm đến các kỹ sư - những người ban đầu bắt đầu với vai trò kỹ thuật sâu sắc, nhưng thường có con đường sự nghiệp dẫn đến _quản lý_ các kỹ sư khác - đòi hỏi một bộ kỹ năng cơ bản khác. Xem thêm: - [Nguyên tắc Dilbert](#the-dilbert-principle) - [Định luật Putt](#putts-law) ### Nguyên tắc mạnh mẽ (Định luật Postel) [Nguyên tắc Vững Chắc trên Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) > Bảo thủ trong những gì bạn làm, tự do trong những gì bạn chấp nhận từ người khác. Thường được áp dụng trong phần mềm Ứng Dụng Máy Chủ, nguyên tắc này nói rằng những gì bạn trả về cho Đầu Vào phải tối thiểu và phù hợp nhất có thể, nhưng Ứng Dụng Máy Chủ có thể xử lý được các Đầu Vào không đúng định dạng. Mục tiêu của nguyên tắc này là xây dựng các hệ thống mạnh mẽ, vì chúng có thể xử lý Lời Gọi kém. Tuy nhiên, cân nhắc những tác động tiềm ẩn về bảo mật của việc chấp nhận đầu vào không đúng định dạng, đặc biệt nếu quá trình xử lý đầu vào đó không được kiểm tra tốt. Những tác động này và các vấn đề khác được Eric Allman mô tả trong [Nguyên tắc Vững Chắc được xem xét lại](https://queue.acm.org/detail.cfm?id=1999945) . Việc cho phép Đầu Vào không tuân thủ theo thời gian có thể làm suy yếu khả năng phát triển vì những người triển khai cuối cùng sẽ dựa vào tính tự do này để xây dựng các tính năng của chúng. Xem thêm: - [Định luật Hyrum](#hyrums-law-the-law-of-implicit-interfaces) ### SOLID Đây là một từ viết tắt, dùng để chỉ: - S: [The Single Responsibility Principle - Nguyên tắc Đúng Một Trách nhiệm](#the-single-responsibility-principle) - O: [The Open/Closed Principle - Nguyên tắc Mở / Đóng](#the-openclosed-principle) - L: [The Liskov Substitution Principle - Nguyên tắc thay thế Liskov ](#the-liskov-substitution-principle) - I: [The Interface Segregation Principle - Nguyên tắc phân tách giao diện](#the-interface-segregation-principle) - D: [The Dependency Inversion Principle - Nguyên tắc đảo ngược phụ thuộc](#the-dependency-inversion-principle) Đây là những nguyên tắc chính trong [Lập trình hướng đối tượng](#todo) . Các nguyên tắc thiết kế như vậy sẽ có thể hỗ trợ các nhà phát triển xây dựng các hệ thống dễ bảo trì hơn. ### Nguyên tắc Đúng Một Trách Nhiệm [Nguyên tắc Đúng Một Trách Nhiệm trên Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle) > Mỗi mô-đun hoặc lớp chỉ nên có một trách nhiệm duy nhất và trách nhiệm này chỉ do mô-đun hoặc lớp đó thực hiện. Nguyên tắc đầu tiên trong số các nguyên tắc ' [SOLID'.](#solid) Nguyên tắc này gợi ý rằng các mô-đun hoặc lớp chỉ nên làm một việc và một việc duy nhất và ngược lại trách nhiệm này chỉ do mô-đun hoặc lớp đó thực hiện. Cụ thể, có nghĩa là một thay đổi nhỏ, đơn lẻ đối với một tính năng của chương trình sẽ chỉ yêu cầu một sự thay đổi trong một thành phần. Ví dụ: việc thay đổi cách mật khẩu được xác thực về độ phức tạp sẽ chỉ yêu cầu thay đổi một phần của chương trình. Về mặt lý thuyết, điều này sẽ làm cho mã mạnh hơn và dễ thay đổi hơn. Biết rằng một thành phần đang được thay đổi chỉ có một trách nhiệm duy nhất có nghĩa là việc _kiểm tra_ sự thay đổi đó sẽ dễ dàng hơn. Sử dụng ví dụ trước đó, việc thay đổi thành phần độ phức tạp của mật khẩu chỉ có thể ảnh hưởng đến các tính năng liên quan đến độ phức tạp của mật khẩu. Có thể khó hơn nhiều để lập luận về tác động của một thay đổi đối với một thành phần có nhiều trách nhiệm. Xem thêm: - [Lập trình hướng đối tượng](#todo) - [SOLID](#solid) ### Nguyên tắc Mở / Đóng [Nguyên tắc Mở / Đóng trên Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) > Các Thực Thể phần mềm phải thiết kế sao cho dễ để thêm mới, thay mới và không cần sửa đổi mã cũ. Nguyên tắc thứ hai của nguyên tắc ' [SOLID'.](#solid) Nguyên tắc này nói rằng các Thực Thể (có thể là lớp, mô-đun, chức năng, v.v.) sẽ có thể dễ dàng _mở rộng_, nhưng _hành vi hiện tại_ của chúng không bị ảnh hưởng, khó bị thay đổi một cách vô ý. Nên khi thay đổi, ta chỉ cần thêm cái mới mà không sửa cái cũ. Như một ví dụ giả định, hãy tưởng tượng một mô-đun có thể chuyển tài liệu Markdown thành HTML. Bây giờ hãy tưởng tượng có một cú pháp mới được thêm vào đặc tả Markdown, bổ sung hỗ trợ cho các phương trình toán học. Mô-đun nên được _mở để mở rộng_ để triển khai cú pháp toán học mới. Tuy nhiên, các triển khai cú pháp hiện có (như đoạn văn, dấu đầu dòng, v.v.) nên được _đóng lại để sửa đổi_ . Chúng đã hoạt động, chúng tôi không muốn mọi người thay đổi chúng. Nguyên tắc này có liên quan đặc biệt đối với lập trình hướng đối tượng, nơi chúng ta có thể thiết kế các đối tượng để dễ dàng mở rộng, nhưng sẽ tránh thiết kế các đối tượng có thể làm thay đổi hành vi hiện tại của chúng theo những cách không mong muốn. Xem thêm: - [Lập trình hướng đối tượng](#todo) - [SOLID](#solid) ### Nguyên tắc thay thế Liskov [Nguyên tắc thay thế Liskov trên Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle) > Chương trình thiết kế để có thể thay thế một lớp bằng một lớp con mở rộng của lớp đó mà không làm hỏng chương trình. Nguyên tắc thứ ba của nguyên tắc ' [SOLID'.](#solid) Nguyên tắc này nói rằng nếu một thành phần phụ thuộc vào một kiểu, thì nó sẽ có thể sử dụng các kiểu con của kiểu đó mà hệ thống không bị lỗi hoặc phải biết chi tiết về kiểu con đó là gì. Ví dụ, hãy tưởng tượng chúng ta có một phương thức đọc tài liệu XML từ một cấu trúc đại diện cho một tệp. Nếu phương thức sử dụng loại cơ sở là 'tệp', thì bất kỳ thứ gì bắt nguồn từ 'tệp' sẽ có thể được sử dụng trong hàm. Nếu 'tệp' hỗ trợ tìm kiếm ngược lại và trình phân tích cú pháp XML sử dụng chức năng đó, nhưng loại dẫn xuất 'tệp mạng' không thành công khi tìm kiếm ngược lại, thì 'tệp mạng' sẽ vi phạm nguyên tắc. Nguyên tắc này có liên quan đặc biệt đối với lập trình hướng đối tượng, trong đó phân cấp kiểu phải được mô hình hóa cẩn thận để tránh gây nhầm lẫn cho người dùng hệ thống. Xem thêm: - [Lập trình hướng đối tượng](#todo) - [SOLID](#solid) ### Nguyên tắc phân tách giao diện [Nguyên tắc phân tách giao diện trên Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle) > Không một Ứng Dụng Khách nào buộc phải phụ thuộc vào các Phương Thức mà nó không sử dụng. Nguyên tắc thứ tư của nguyên tắc ' [SOLID'.](#solid) Nguyên tắc này nói rằng Ứng Dụng Khách không nên phụ thuộc vào các chức năng của thành phần đó mà nó không sử dụng. Ví dụ, hãy tưởng tượng chúng ta có một phương thức đọc tài liệu XML từ một cấu trúc đại diện cho một tệp. Nó chỉ cần đọc byte, chuyển tới hoặc lùi trong tệp. Nếu phương pháp này cần được cập nhật vì một tính năng không liên quan của cấu trúc tệp thay đổi (chẳng hạn như bản cập nhật cho mô hình quyền được sử dụng để đại diện cho bảo mật tệp), thì nguyên tắc đó đã bị vô hiệu. Tệp sẽ tốt hơn nếu triển khai giao diện 'luồng có thể tìm kiếm' và trình đọc XML sử dụng giao diện đó. Nguyên tắc này có liên quan đặc biệt đối với lập trình hướng đối tượng, trong đó các giao diện, cấu trúc phân cấp và các kiểu trừu tượng được sử dụng để [giảm thiểu sự ghép nối](#todo) giữa các thành phần khác nhau. [Kiểu Duck](#todo) là một phương pháp thực thi nguyên tắc này bằng cách loại bỏ các giao diện rõ ràng. Xem thêm: - [Lập trình hướng đối tượng](#todo) - [SOLID](#solid) - [duck typing](#todo) - [Tách rời](#todo) ### Nguyên tắc đảo ngược phụ thuộc [Nguyên tắc đảo ngược phụ thuộc trên Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle) > Các mô-đun mức phác thảo không bị phụ thuộc vào các triển khai cụ thể. Nguyên tắc thứ năm của nguyên tắc ' [SOLID'.](#solid) Nguyên tắc này nói rằng các thành phần thiết kế mức cao - trừu tượng, không cần phải biết cụ thể các thành phần mà chúng phụ thuộc. Chữ "đảo ngược" trong nguyên tắc này có lẽ lấy từ chuỗi thức ăn trong tự nhiên: trong tự nhiên các sinh vật cấp cao trong chuỗi thức ăn phụ-thuộc vào các sinh vật cấp thấp. Ví dụ, hãy tưởng tượng chúng ta có một chương trình đọc dữ liệu từ một trang web. Chúng tôi giả định rằng thành phần chính sẽ phải biết về một thành phần tải xuống nội dung trang web, sau đó là một thành phần có thể đọc siêu dữ liệu. Nếu nhìn theo Nghịch Đảo Phụ Thuộc, thì thành phần chính [1] sẽ nhìn vào một thành phần trừu tượng có thể "nạp dữ liệu" [2], và [2] sẽ nhìn vào một thành phần trừu tượng khác có thể "đọc siêu dữ liệu từ một luồng byte". Thành phần chính [1] sẽ không biết về TCP / IP, HTTP, HTML, v.v. Trong thực tế, điều đó cũng có nghĩa là một thành phần điều phối riêng biệt phải đảm bảo việc triển khai chính xác các kiểu trừu tượng được sử dụng (ví dụ: trong ví dụ trước, _một cái gì đó_ vẫn phải cung cấp cho thành phần trình đọc siêu dữ liệu một trình tải xuống tệp HTTP và trình đọc thẻ meta HTML). Sau đó, điều này chạm vào các mẫu như [Inversion of Control](#todo) và [Dependency Injection](#todo) . Xem thêm: - [Lập trình hướng đối tượng](#todo) - [SOLID](#solid) - [Đảo ngược kiểm soát](#todo) - [Tiêm phụ thuộc](#todo) ### Nguyên tắc DRY [Nguyên tắc DRY trên Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) > Trong một hệ thống, mỗi phần kiến thức có: một đại diện duy nhất, rõ ràng, có thẩm quyền. DRY là từ viết tắt của _Don't Repeat Yourself_ . Nguyên tắc này nhằm mục đích giúp các nhà phát triển giảm thiểu việc lặp lại mã và giữ thông tin ở một nơi duy nhất và được trích dẫn vào năm 1999 bởi Andrew Hunt và Dave Thomas trong cuốn sách [Nhà phát triển thực dụng.](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) > Ngược lại với DRY sẽ là _WET_ (Viết mọi thứ hai lần hoặc mỉa mai là Chúng tôi thích đánh máy). Trên thực tế, nếu bạn có cùng một phần thông tin ở hai (hoặc nhiều) nơi khác nhau, bạn có thể sử dụng DRY để hợp nhất chúng thành một thông tin duy nhất và sử dụng lại bất cứ nơi nào bạn muốn / cần. Xem thêm: - [Nhà phát triển thực dụng](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) ### Nguyên tắc KISS [KISS trên Wikipedia](https://en.wikipedia.org/wiki/KISS_principle) > Giữ cho nó thật đơn giản, ngốc cũng làm được Nguyên tắc KISS nói rằng hầu hết các hệ thống hoạt động tốt nhất nếu chúng được giữ đơn giản thay vì phức tạp; do đó, sự đơn giản nên là mục tiêu chính trong thiết kế và nên tránh sự phức tạp không cần thiết. Bắt nguồn từ Hải quân Hoa Kỳ vào năm 1960, cụm từ này đã được gắn liền với kỹ sư máy bay Kelly Johnson. Nguyên tắc này được thể hiện rõ nhất qua câu chuyện về việc Johnson giao cho một nhóm kỹ sư thiết kế một số công cụ, với thách thức rằng chiếc máy bay phản lực mà họ đang thiết kế phải được sửa chữa bởi một thợ cơ khí trung bình trong điều kiện chiến đấu chỉ với những công cụ này. Do đó, "ngu ngốc" đề cập đến mối quan hệ giữa cách mọi thứ bị hỏng và sự tinh vi của các công cụ có sẵn để sửa chữa chúng, chứ không phải khả năng của chính các kỹ sư. Xem thêm: - [Luật Gall](#galls-law) ### YAGNI [YAGNI trên Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it) Đây là từ viết tắt của **\*Y**ou **A**in't **G**onna **N**eed **I**t\* . > Chỉ làm khi bạn thực sự cần, không bao giờ làm khi bạn nghĩ rằng bạn cần chúng. > > ( [Ron Jeffries](https://twitter.com/RonJeffries) ) (Đồng sáng lập XP và tác giả của cuốn sách "Cài đặt lập trình cực đoan") _Nguyên tắc Lập trình Cực đoan_ (XP) này đề xuất các nhà phát triển chỉ triển khai chức năng cần thiết cho các yêu cầu trước mắt và tránh triển khai chức năng mà do dự đoán tương lai nghĩ ra. Tuân thủ nguyên tắc này sẽ giảm số lượng mã không sử dụng trong cơ sở mã và tránh lãng phí thời gian và công sức vào chức năng không mang lại giá trị. Xem thêm: - [Danh sách đọc: Lập trình cực đoan đã được cài đặt](#reading-list) ### Sự sụp đổ của máy tính phân tán [Sự sụp đổ của máy tính phân tán trên Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) Còn được gọi là Các lỗi _của Máy tính Nối mạng_ , Các Sai lầm là một danh sách các phỏng đoán (hoặc niềm tin) về máy tính phân tán, có thể dẫn đến thất bại trong quá trình phát triển phần mềm. Các giả định là: - Mạng đáng tin cậy - Độ trễ bằng 0 - Băng thông là vô hạn - Mạng an toàn - Cấu trúc liên kết không thay đổi - Có một quản trị viên - Chi phí vận chuyển bằng 0 - Mạng đồng nhất Bốn mục đầu tiên đã được liệt kê bởi [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) và [Tom Lyon](https://twitter.com/aka_pugs) vào khoảng năm 1991 và lần đầu tiên được [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) xếp vào danh sách "Các di sản của Máy tính nối mạng". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) đã thêm vào các ngụy biện thứ 5, 6 và 7. Vào cuối những năm 90, Gosling đã thêm vào sự nguỵ biện thứ 8. Nhóm được truyền cảm hứng từ những gì đang xảy ra tại thời điểm đó bên trong [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems) . Những ngụy biện này cần được xem xét cẩn thận khi thiết kế mã có khả năng phục hồi; giả sử bất kỳ lỗi ngụy biện nào trong số này có thể dẫn đến logic sai sót không giải quyết được các thực tế và sự phức tạp của hệ thống phân tán. Xem thêm: - [Tìm kiếm sự sụp đổ của máy tính phân tán (Phần 1) - Vaidehi Joshi trên phương tiện](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53) ## Danh sách đọc Nếu bạn thấy những khái niệm này thú vị, bạn có thể thưởng thức những cuốn sách sau đây. - [Mã sạch - Robert C. Martin](https://www.goodreads.com/book/show/3735293-clean-code) - Một trong những cuốn sách được đánh giá cao nhất về cách viết mã sạch, có thể bảo trì. - [Cài đặt Lập trình Cực đoan - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Trình bày các nguyên tắc cốt lõi của Lập trình Cực đoan. - [Gödel, Escher, Bach: Một bím tóc vàng vĩnh cửu - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Sách này khó phân loại. [Hofstadter's Law](#hofstadters-law) là từ cuốn sách. - [Cấu trúc và diễn giải các chương trình máy tính - Harold Abelson, Gerald Jay Sussman, Julie Sussman](https://www.goodreads.com/book/show/43713) - Nếu bạn là một sinh viên khoa học tổng hợp hoặc kỹ thuật điện tử tại MIT hoặc Cambridge, đây là phần giới thiệu của bạn về lập trình. Được báo cáo rộng rãi như là một bước ngoặt trong cuộc đời của mọi người. - [The Cathedral and the Bazaar - Eric S. Raymond](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) - một bộ sưu tập các bài tiểu luận trên mã nguồn mở. Cuốn sách này là nguồn gốc của [Luật Linus](#linuss-law) . - [Nguyên tắc Dilbert - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Một cái nhìn truyện tranh về doanh nghiệp nước Mỹ, của tác giả đã tạo ra [Nguyên tắc Dilbert](#the-dilbert-principle) . - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Một bộ sách kinh điển về kỹ thuật phần mềm. [Luật của Brooks](#brooks-law) là chủ đề trung tâm của cuốn sách. - [Nguyên tắc Peter - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Một truyện tranh khác về những thách thức của các tổ chức lớn hơn và quản lý con người, nguồn gốc của [Nguyên tắc Peter](#the-peter-principle) . ## Những nguồn thông tin trên mạng Một số tài nguyên hữu ích và đọc. - [CB Insights: 8 quy luật thúc đẩy thành công trong lĩnh vực công nghệ: Quy tắc 2 chiếc bánh Pizza của Amazon, Nguyên tắc 80/20, & hơn thế nữa](https://www.cbinsights.com/research/report/tech-laws-success-failure) - một bản viết thú vị về một số quy luật có ảnh hưởng lớn trong lĩnh vực công nghệ. ## Sách điện tử PDF Dự án có sẵn dưới dạng sách điện tử PDF, hãy [tải xuống sách điện tử PDF mới nhất bằng liên kết này](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) hoặc kiểm tra [trang phát hành](https://github.com/dwmkerr/hacker-laws/releases) để biết các phiên bản cũ hơn. Phiên bản sách điện tử mới được tạo tự động khi thẻ phiên bản mới được đẩy. ## Tệp âm thanh Luật Hacker đã được giới thiệu trong [The Changelog](https://changelog.com/podcast/403) , bạn có thể xem tập Podcast bằng liên kết bên dưới: ## Bản dịch Nhờ một số cộng tác viên tuyệt vời, Luật Hacker có sẵn ở một số ngôn ngữ. Vui lòng xem xét tài trợ cho người điều hành! | Ngôn ngữ | Người điều hành | Trạng thái | | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | [🇮🇩 Bahasa Indonesia / Indonesia](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge) | | [🇧🇷 Brasileiro / Brazil](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn) , [Leonardo Costa](https://github.com/leofc97) | [](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) | | [🇨🇳 中文 / tiếng Trung](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Hoàn thành một phần | | [🇩🇪 Deutsch / tiếng Đức](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [](https://gitlocalize.com/repo/2513/de?utm_source=badge) | | [🇫🇷 Français / tiếng Pháp](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [](https://gitlocalize.com/repo/2513/fr?utm_source=badge) | | [🇬🇷 ελληνικά / tiếng Hy Lạp](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [](https://gitlocalize.com/repo/2513/el?utm_source=badge) | | [🇮🇹 Italiano / Ý](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Hoàn thành một phần | | [🇯🇵 JP 日本語 / tiếng Nhật](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara) | [](https://gitlocalize.com/repo/2513/ja?utm_source=badge) | | [🇰🇷 한국어 / tiếng Hàn Quốc](https://github.com/codeanddonuts/hacker-laws-kr) | [Bánh vòng](https://github.com/codeanddonuts) | Hoàn thành một phần | | [🇱🇻 Latviešu Valoda / Latvia](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [](https://gitlocalize.com/repo/2513/lv?utm_source=badge) | | [🇷🇺 Русская версия / tiếng Nga](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Hoàn thành một phần | | [🇪🇸 Castellano / tiếng Tây Ban Nha](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ( [Nhà tài trợ](https://github.com/sponsors/manuel-rubio) ) | Hoàn thành một phần | | [🇹🇷 Türkçe / tiếng Thổ Nhĩ Kỳ](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [](https://gitlocalize.com/repo/2513/tr?utm_source=badge) | | [🇺🇦 українська мова / tiếng Ukraina](./translations/uk.md) | [Nazar](https://github.com/troyane) , [Helga Lastivka](https://github.com/HelgaLastivka) | [](https://gitlocalize.com/repo/2513/uk?utm_source=badge) | | [🇻🇳 Tiếng Việt / Vietnamese](./translations/vu.md) | [Nguyên](https://github.com/truonghoangnguyen), [Trương Hoàng](https://github.com/truonghoangnguyen) | [![gitlocalized ](https://gitlocalize.com/repo/2513/vi/badge.svg)](https://gitlocalize.com/repo/2513/vi?utm_source=badge) | Nếu bạn muốn cập nhật bản dịch, chỉ cần [mở một yêu cầu kéo](https://github.com/dwmkerr/hacker-laws/pulls) . Nếu bạn muốn thêm ngôn ngữ mới, hãy đăng nhập vào [GitLocalize](https://gitlocalize.com/) để tạo tài khoản, sau đó mở một vấn đề yêu cầu quản lý ngôn ngữ và tôi sẽ thêm bạn vào dự án! Nó cũng sẽ rất hữu ích nếu bạn có thể mở một yêu cầu kéo để cập nhật bảng ở trên và liên kết ở đầu tệp. ## Các dự án liên quan - [Mẹo trong ngày](https://tips.darekkay.com/html/hacker-laws-en.html) - Nhận luật / nguyên tắc của hacker hàng ngày. - [Luật Hacker CLI](https://github.com/umutphp/hacker-laws-cli) - Liệt kê, xem và xem các luật ngẫu nhiên từ thiết bị đầu cuối! - [Hành động của Luật Hacker](https://github.com/marketplace/actions/hacker-laws-action) - Thêm Luật Hacker ngẫu nhiên vào một yêu cầu kéo như một món quà nhỏ cho người đóng góp, cảm ơn [Umut Işık](https://github.com/umutphp) ## Đóng góp Hãy đóng góp! [Nêu vấn đề](https://github.com/dwmkerr/hacker-laws/issues/new) nếu bạn muốn đề xuất bổ sung hoặc thay đổi hoặc [Mở yêu cầu kéo](https://github.com/dwmkerr/hacker-laws/compare) để đề xuất các thay đổi của riêng bạn. Hãy nhớ đọc [Nguyên tắc đóng góp](./.github/contributing.md) để biết các yêu cầu về văn bản, văn phong, v.v. Vui lòng lưu ý [Quy tắc Ứng xử](./.github/CODE_OF_CONDUCT.md) khi tham gia vào các cuộc thảo luận về dự án. ## SẼ LÀM Chào! Nếu bạn đến đây, bạn đã nhấp vào một liên kết đến một chủ đề mà tôi chưa viết lên, xin lỗi về điều này - đây là công việc đang được tiến hành! Vui lòng nêu [vấn đề](https://github.com/dwmkerr/hacker-laws/issues) yêu cầu thêm chi tiết hoặc [Mở yêu cầu kéo](https://github.com/dwmkerr/hacker-laws/pulls) để gửi định nghĩa đề xuất của bạn về chủ đề.