├── .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 │ ├── build │ │ └── .gitignore │ ├── generate.py │ ├── makefile │ ├── requirements.txt │ └── src │ │ ├── favicon.svg │ │ ├── index.html.jinja │ │ ├── script.js │ │ └── styles.css └── workflows │ └── cicd.yaml ├── .gitignore ├── LICENSE ├── README.md ├── assets ├── banner.png ├── banner.psd ├── diagrams.bmpr ├── repository-open-graph-template.png └── site │ ├── index.html │ ├── index2.html │ ├── index3.html │ └── index4.html ├── images ├── Fitts_Law.svg ├── amdahls_law.png ├── changelog-podcast.png ├── complete_graph.png ├── gartner_hype_cycle.png ├── gitlocalize.png └── hicks_law.svg ├── 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 /.all-contributorsrc: -------------------------------------------------------------------------------- 1 | { 2 | "files": [ 3 | "README.md" 4 | ], 5 | "imageSize": 100, 6 | "commit": false, 7 | "commitType": "docs", 8 | "commitConvention": "angular", 9 | "contributors": [ 10 | { 11 | "login": "hemmatt", 12 | "name": "Amir Hemmati", 13 | "avatar_url": "https://avatars.githubusercontent.com/u/22114089?v=4", 14 | "profile": "https://github.com/hemmatt", 15 | "contributions": [ 16 | "doc" 17 | ] 18 | } 19 | ], 20 | "contributorsPerLine": 7, 21 | "skipCi": true, 22 | "repoType": "github", 23 | "repoHost": "https://github.com", 24 | "projectName": "hacker-laws", 25 | "projectOwner": "dwmkerr" 26 | } 27 | -------------------------------------------------------------------------------- /.github/CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # Changelog 2 | 3 | ## [0.3.2](https://github.com/dwmkerr/hacker-laws/compare/v0.3.1...v0.3.2) (2025-03-31) 4 | 5 | 6 | ### Bug Fixes 7 | 8 | * update ebook download link ([4546562](https://github.com/dwmkerr/hacker-laws/commit/454656237d9508c8fadafffbc1c1286fc134f8cf)) 9 | 10 | ## [0.3.1](https://github.com/dwmkerr/hacker-laws/compare/v0.3.0...v0.3.1) (2025-03-31) 11 | 12 | 13 | ### Bug Fixes 14 | 15 | * effective shell links ([6353fe4](https://github.com/dwmkerr/hacker-laws/commit/6353fe4b8f044456d66dac0af950e41989c56c5a)) 16 | 17 | ## [0.3.0](https://github.com/dwmkerr/hacker-laws/compare/v0.2.1...v0.3.0) (2025-03-31) 18 | 19 | 20 | ### Features 21 | 22 | * add Koomey's Law ([dcdcfdf](https://github.com/dwmkerr/hacker-laws/commit/dcdcfdfc25ee121b6bcb931a71e185fa7ffeedcd)) 23 | 24 | ## [0.2.1](https://github.com/dwmkerr/hacker-laws/compare/v0.2.0...v0.2.1) (2025-03-31) 25 | 26 | 27 | ### Bug Fixes 28 | 29 | * remove frontmatter ([2140429](https://github.com/dwmkerr/hacker-laws/commit/2140429b959a8284b452c3fa05e1c9fd03e5ebab)) 30 | 31 | ## [0.2.0](https://github.com/dwmkerr/hacker-laws/compare/v0.1.0...v0.2.0) (2025-03-31) 32 | 33 | 34 | ### Features 35 | 36 | * 90-90 rule ([4477907](https://github.com/dwmkerr/hacker-laws/commit/44779074caa6495198214100e5bd0a886cc1e680)) 37 | * add section for Kerckhoff's principle ([5f74607](https://github.com/dwmkerr/hacker-laws/commit/5f74607c63d3a76009ec0546ba515f8f7c1d3864)) 38 | * 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) 39 | * Dunning Kruger Effect ([3dbc237](https://github.com/dwmkerr/hacker-laws/commit/3dbc237c1f1c59e809969320cc0ae4347a4b45c3)) 40 | * Dunning-Kruger Effect ([#318](https://github.com/dwmkerr/hacker-laws/issues/318)) ([34c38d8](https://github.com/dwmkerr/hacker-laws/commit/34c38d87edba4b0e36d2ad9488b97d0c77f9b550)) 41 | * **pages:** update index.html and pages.yaml for deployment ([beb3d57](https://github.com/dwmkerr/hacker-laws/commit/beb3d57a6a5a3a38aa9e692ed13eb01060b85ded)) 42 | * principle of least astonishment ([4be4827](https://github.com/dwmkerr/hacker-laws/commit/4be482731b6a6009453af7d303d3cd2470a2e73e)) 43 | * principle of least astonishment ([e4662cb](https://github.com/dwmkerr/hacker-laws/commit/e4662cbc27d04fb968220837633034420b7fb11a)) 44 | * the scout rule ([716aef8](https://github.com/dwmkerr/hacker-laws/commit/716aef807e758bd8df976f323089db525da9f708)) 45 | * the scout rule ([c6fccf4](https://github.com/dwmkerr/hacker-laws/commit/c6fccf4978d9483637fba8c7887127abad3de581)), closes [#144](https://github.com/dwmkerr/hacker-laws/issues/144) 46 | * twyman's law ([b9ad4c6](https://github.com/dwmkerr/hacker-laws/commit/b9ad4c6f99f991a1bda9a2cfdddef62787e6ae82)) 47 | 48 | 49 | ### Bug Fixes 50 | 51 | * correct facebook link on website ([6f9b1e3](https://github.com/dwmkerr/hacker-laws/commit/6f9b1e33345bc1332428f0fba8c7aa2900147500)) 52 | * correct formatting around quote ([d83d439](https://github.com/dwmkerr/hacker-laws/commit/d83d439df89e8af50ae53bafa3a791f8d92a6991)) 53 | * Fix section's links ([#317](https://github.com/dwmkerr/hacker-laws/issues/317)) ([7b341fc](https://github.com/dwmkerr/hacker-laws/commit/7b341fc0d205f076e25ff8fedb972e652201c3c6)) 54 | * image paths ([692b7cc](https://github.com/dwmkerr/hacker-laws/commit/692b7cca1a97eb62384db170297b504f51ea408e)) 55 | * remove superfluous 'is' ([3b78ae6](https://github.com/dwmkerr/hacker-laws/commit/3b78ae65f02fca457bb8adbf113135e1ed042a46)) 56 | -------------------------------------------------------------------------------- /.github/CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at dwmkerr@gmail.com. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # Support 'GitHub Sponsors' funding. 2 | github: dwmkerr 3 | -------------------------------------------------------------------------------- /.github/contributing.md: -------------------------------------------------------------------------------- 1 | # Contributing Guidelines 2 | 3 | 4 | 5 | - [Goal of the Project](#goal-of-the-project) 6 | - [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions) 7 | - [Translations](#translations) 8 | - [How do I know if a law is relevant?](#how-do-i-know-if-a-law-is-relevant) 9 | - [How do I know if a law is 'well known' enough?](#how-do-i-know-if-a-law-is-well-known-enough) 10 | - [Use of Images](#use-of-images) 11 | - [Developer Guide](#developer-guide) 12 | 13 | 14 | 15 | ## Goal of the Project 16 | 17 | 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: 18 | 19 | 1. Short - one or two paragraphs. 20 | 2. Include the original source. 21 | 3. Quote the law if possible, with the author's name. 22 | 4. Link to related laws in the 'See also' section. 23 | 5. Include real-world examples if possible in the 'Real-world examples' section. 24 | 25 | Some other tips: 26 | 27 | - It is fine to include laws which are humorous or not serious. 28 | - If a law does not obviously apply to development or coding, include a paragraph explaining the relevance to technologists. 29 | - Don't worry about managing the table of contents, I can generate it. 30 | - Feel free to include images, but aim to keep it down to one image per law. 31 | - Be careful not to copy-and-paste content (unless it is explicitly quoted), as it might violate copyright. 32 | - Include hyperlinks to referenced material. 33 | - 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. 34 | - 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. 35 | 36 | An example law is shown below, which covers most of the key points: 37 | 38 | --- 39 | 40 | ## Example Law: The Law of Leaky Abstractions 41 | 42 | [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 43 | 44 | > All non-trivial abstractions, to some degree, are leaky. 45 | > 46 | > (Joel Spolsky) 47 | 48 | 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. 49 | 50 | 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. 51 | 52 | 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. 53 | 54 | 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. 55 | 56 | See also: 57 | 58 | - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces) 59 | 60 | Real-world examples: 61 | 62 | - [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. 63 | 64 | ## Translations 65 | 66 | 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: 67 | 68 | ![GitLocalize Screenshot](../images/gitlocalize.png) 69 | 70 | If you would like to moderate a language, please follow the steps below: 71 | 72 | 1. Log in to [Git Localize](https://gitlocalize.com) with your GitHub account, this will create a GitLocalize account for you. 73 | 0. [Open an Issue](https://github.com/dwmkerr/hacker-laws/issues/new) with the name of the language you would like to moderate/translate. 74 | 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. 75 | 3. I will then make you a moderator of the language and ensure the language is listed properly. 76 | 77 | Thanks! 78 | 79 | 80 | ## How do I know if a law is relevant? 81 | 82 | In general, it should be reasonably applicable to the world of computer sciences, IT or coding in general. 83 | 84 | ## How do I know if a law is 'well known' enough? 85 | 86 | A good test is 'If I search for it on Google, will I find it in the first few results?'. 87 | 88 | ## Use of Images 89 | 90 | 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. 91 | 92 | ## Developer Guide 93 | 94 | 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. 95 | 96 | To use the makefile, pass its path explicitly, e.g: 97 | 98 | ```bash 99 | make -f .github/makefile 100 | ``` 101 | 102 | Or create an alias: 103 | 104 | ```bash 105 | alias hlmake="make -f .github/makefile" 106 | -------------------------------------------------------------------------------- /.github/makefile: -------------------------------------------------------------------------------- 1 | default: help 2 | 3 | .PHONY: help 4 | help: # Show help for each of the Makefile recipes. 5 | @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 6 | 7 | .PHONY: prepare-markdown 8 | prepare-markdown: # Prepare the markdown for PDF output. 9 | ./scripts/prepare-markdown-for-ebook.sh "README.md" "hacker-laws.md" 10 | 11 | .PHONY: create-pdf 12 | create-pdf: # Create the PDF. 13 | docker run --rm \ 14 | --platform linux/amd64 \ 15 | -v ${PWD}:/data \ 16 | pandoc/latex:3.6 \ 17 | -V toc-title:"Table Of Contents" \ 18 | --toc \ 19 | --pdf-engine=lualatex \ 20 | --standalone \ 21 | --output hacker-laws.pdf \ 22 | hacker-laws.md 23 | -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | **Pull Request Checklist** 2 | 3 | Please double check the items below! 4 | 5 | - [ ] I have read the [Contributor Guidelines](https://github.com/dwmkerr/hacker-laws/blob/master/.github/contributing.md). 6 | - [ ] I have not directly copied text from another location (unless explicitly indicated as a quote) or violated copyright. 7 | - [ ] I have linked to the original Law. 8 | - [ ] I have quote the law (if possible) and the author's name (if possible). 9 | - [ ] 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. 10 | 11 | And don't forget: 12 | 13 | - I can handle the table of contents, feel free to leave it out. 14 | - Check to see if other laws should link back to the law you have added. 15 | - Include your **Twitter Handle** if you want me to include you when tweeting this update! 16 | -------------------------------------------------------------------------------- /.github/release-please-config.json: -------------------------------------------------------------------------------- 1 | { 2 | "release-type": "simple", 3 | "bump-minor-pre-major": true, 4 | "packages": { 5 | ".": { 6 | "release-type": "simple", 7 | "extra-files": [ 8 | { 9 | "type": "generic", 10 | "path": "README.md" 11 | } 12 | ], 13 | "changelog-path": ".github/CHANGELOG.md" 14 | } 15 | } 16 | } 17 | 18 | 19 | -------------------------------------------------------------------------------- /.github/release-please-manifest.json: -------------------------------------------------------------------------------- 1 | { 2 | ".": "0.3.2" 3 | } 4 | -------------------------------------------------------------------------------- /.github/website/backup/ideas.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/.github/website/backup/ideas.md -------------------------------------------------------------------------------- /.github/website/backup/index2.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Hacker Laws 7 | 8 | 9 | 10 | 11 | 60 | 61 | 62 | 63 | 89 | 90 | 91 |
92 |

Hacker Laws

93 |

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

94 |
95 | 96 | 97 |
98 | 99 |
100 |

Introduction

101 |

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!

102 |

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.

103 | 104 | 105 | 110 | 111 | 112 |
113 | ↑ Top 114 | 120 |
121 |
122 | 123 | 124 |
125 |

90–9–1 Principle (1% Rule)

126 |

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.

127 |

Real-world examples:

128 | 131 |

See Also: Pareto Principle

132 | 133 | 134 | 139 | 140 | 141 |
142 | ↑ Top 143 |
144 |
145 | 146 | 147 |
148 |

90–90 Rule

149 |

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.

150 |

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.

151 | 152 | 153 | 158 | 159 | 160 |
161 | ↑ Top 162 |
163 |
164 | 165 | 166 |
167 | 168 | 169 | 172 | 173 | 174 | 175 | 187 | 188 | 189 | 190 | -------------------------------------------------------------------------------- /.github/website/backup/index3.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Hacker Laws 7 | 8 | 9 | 10 | 11 | 12 | 13 | 73 | 74 | 75 | 76 | 102 | 103 | 104 |
105 |

Hacker Laws

106 |

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

107 |
108 | 109 | 110 |
111 | 112 |
113 |

Introduction

114 |

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!

115 |

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.

116 | 117 | 118 | 123 | 124 | 125 |
126 | ↑ Top 127 |
128 |
129 | 130 | 131 |
132 |

90–9–1 Principle (1% Rule)

133 |

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.

134 |

Real-world examples:

135 | 138 |

See Also: Pareto Principle

139 | 140 | 141 | 146 | 147 | 148 |
149 | ↑ Top 150 |
151 |
152 | 153 | 154 |
155 |

90–90 Rule

156 |

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.

157 |

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.

158 | 159 | 160 | 165 | 166 | 167 |
168 | ↑ Top 169 |
170 |
171 |
172 | 173 | 174 | 177 | 178 | 179 | 180 | 192 | 193 | 194 | 195 | -------------------------------------------------------------------------------- /.github/website/backup/index4.html: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/.github/website/backup/index4.html -------------------------------------------------------------------------------- /.github/website/build/.gitignore: -------------------------------------------------------------------------------- 1 | * 2 | -------------------------------------------------------------------------------- /.github/website/generate.py: -------------------------------------------------------------------------------- 1 | """Generate the Hacker Laws website from the Hacker Laws README""" 2 | 3 | import argparse 4 | import os 5 | import shutil 6 | from jinja2 import Environment, FileSystemLoader 7 | import markdown 8 | from bs4 import BeautifulSoup 9 | 10 | 11 | def bisect_text(content: str, bisect_line: str) -> tuple[str, str]: 12 | lines = content.splitlines() 13 | head = [] 14 | tail = [] 15 | found = False 16 | for line in lines: 17 | if found is False and line == bisect_line: 18 | found = True 19 | continue 20 | if found: 21 | tail.append(line) 22 | else: 23 | head.append(line) 24 | 25 | return ("\n".join(head), "\n".join(tail)) 26 | 27 | 28 | def load_template(): 29 | """Load Jinja2 template from the specified directory.""" 30 | env = Environment(loader=FileSystemLoader(TEMPLATE_DIR)) 31 | return env.get_template(TEMPLATE_FILE) 32 | 33 | 34 | def prepare_markdown(path: str) -> str: 35 | """ 36 | Pre-process the README markdown by removing content we will not show in 37 | the final website. 38 | """ 39 | 40 | # Load the markdown content. 41 | with open(path, "r", encoding="utf-8") as f: 42 | content = f.read() 43 | return content 44 | 45 | 46 | def parse_markdown(markdown_content: str): 47 | (_, remains) = bisect_text(markdown_content, "---") 48 | (links, remains) = bisect_text(remains, "---") 49 | (_, content) = bisect_text(remains, "") 50 | 51 | md = markdown.Markdown(extensions=['toc']) 52 | links = md.convert(links) 53 | print(f"links: {links}") 54 | md.convert(content) 55 | toc = md.toc 56 | 57 | markdown_sections = content.split("\n#") # Split by Markdown headings 58 | sections = [] 59 | laws = [] 60 | for markdown_section in markdown_sections: 61 | if markdown_section.strip(): 62 | lines = markdown_section.split("\n", 1) 63 | title = lines[0].strip("# ").strip() 64 | content = md.convert(lines[1] if len(lines) > 1 else "") 65 | full_content = md.convert(markdown_section) 66 | id = title.lower().replace(" ", "-") 67 | laws.append({"title": title, "content": content, "id": id}) 68 | sections.append({ 69 | "title": title, 70 | "content": content, 71 | "id": id, 72 | "full_content": full_content 73 | }) 74 | 75 | return (links, toc, sections) 76 | 77 | 78 | def extract_static_files(html_content, output_dir): 79 | """ 80 | Extract linked CSS, JS, and image files and copy them to the output 81 | directory. 82 | """ 83 | soup = BeautifulSoup(html_content, "html.parser") 84 | files_to_copy = [] 85 | 86 | # Extract stylesheets 87 | for link in soup.find_all("link", href=True): 88 | href = link["href"] 89 | if not href.startswith(("http", "//")): # Ignore external links 90 | files_to_copy.append(href) 91 | 92 | # Extract 9 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 42 | 43 |
44 |

Hacker Laws

45 |

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

46 |
47 | 48 |
49 | 50 | {{ links }} 51 |
52 | 53 | {{ toc }} 54 |
55 | 56 | 57 | {% for section in sections %} 58 |
59 | {{ section.full_content | safe }} 60 | 64 |
65 | {% endfor %} 66 | 67 |
68 | 69 | 72 | 73 | 74 | 75 | 76 | 77 | -------------------------------------------------------------------------------- /.github/website/src/script.js: -------------------------------------------------------------------------------- 1 | $(document).ready(function() { 2 | $("h1, h2, h3, h4, h5, h6").each(function() { 3 | var $heading = $(this); 4 | var headingId = $heading.attr("id") || $heading.text().trim().toLowerCase().replace(/\s+/g, "-"); 5 | 6 | // Ensure a unique ID 7 | $heading.attr("id", headingId); 8 | 9 | // Create the anchor link 10 | var $anchor = $('') 11 | .attr("href", "#" + headingId) 12 | .addClass("header-link") 13 | .html("#"); 14 | 15 | // Append to the heading 16 | $heading.append($anchor); 17 | }); 18 | 19 | // Bootstrap requires that blockquote elements have the 'blockquote' class. 20 | $('blockquote').addClass('blockquote').addClass('.quote'); 21 | }); 22 | -------------------------------------------------------------------------------- /.github/website/src/styles.css: -------------------------------------------------------------------------------- 1 | html { 2 | scroll-behavior: auto !important; 3 | } 4 | 5 | body { 6 | font-family: 'Inter', sans-serif; 7 | background-color: #fff; 8 | color: #333; 9 | padding-top: 70px; 10 | } 11 | .container { 12 | max-width: 800px; 13 | } 14 | 15 | header { 16 | text-align: center; 17 | margin-bottom: 2rem; 18 | padding: 2rem 0; 19 | border-bottom: 1px solid #e5e5e5; 20 | } 21 | 22 | h1, h2, h3, h4, h5, h6 { 23 | font-family: 'Libre Baskerville', serif; 24 | /* Avoid scrolling under the sticky header. */ 25 | scroll-margin-top: 80px; 26 | } 27 | 28 | blockquote { 29 | font-style: italic; 30 | } 31 | 32 | .law-section { 33 | margin-bottom: 2rem; 34 | padding: 1.5rem; 35 | background-color: #fff; 36 | border-bottom: 1px solid #e5e5e5; 37 | position: relative; 38 | } 39 | .law-section h2 { 40 | position: relative; 41 | display: flex; 42 | align-items: center; 43 | } 44 | .law-section h2 a.anchor { 45 | text-decoration: none; 46 | color: #999; 47 | margin-left: 0.5rem; 48 | visibility: hidden; 49 | } 50 | .law-section:hover h2 a.anchor { 51 | visibility: visible; 52 | } 53 | .social-sharing a { 54 | margin-right: 0.75rem; 55 | font-size: 1.2rem; 56 | color: #555; 57 | text-decoration: none; 58 | } 59 | .social-sharing a:hover { 60 | color: #000; 61 | } 62 | .back-to-top { 63 | margin-top: 1rem; 64 | } 65 | 66 | /* Initially hide the hash link */ 67 | .header-link { 68 | text-decoration: none; 69 | margin-left: 12px; /* Increased left padding */ 70 | opacity: 0; 71 | transition: opacity 0.2s; 72 | font-size: inherit; /* Matches the heading size */ 73 | } 74 | 75 | /* Only show the hash when the whole section is hovered */ 76 | section:hover .header-link, 77 | article:hover .header-link, 78 | div:hover .header-link { 79 | opacity: 1; 80 | } 81 | -------------------------------------------------------------------------------- /.github/workflows/cicd.yaml: -------------------------------------------------------------------------------- 1 | name: CI/CD 2 | 3 | on: 4 | push: 5 | branches: [main] 6 | pull_request: 7 | workflow_dispatch: 8 | 9 | # Permissions to check contents and open PR (release pleases) and update pages. 10 | permissions: 11 | contents: write 12 | pull-requests: write 13 | pages: write 14 | id-token: write 15 | 16 | jobs: 17 | test-website-build: 18 | runs-on: ubuntu-24.04 19 | steps: 20 | - name: Checkout 21 | uses: actions/checkout@v4 22 | 23 | - name: Test Website Build 24 | run: | 25 | cd .github/website 26 | make install 27 | make build 28 | cp -r build/. '../pages' 29 | ls -al "../pages" 30 | 31 | release: 32 | needs: test-website-build 33 | runs-on: ubuntu-24.04 34 | outputs: 35 | released: ${{ steps.release-please.outputs.release_created }} 36 | tag: ${{ steps.release-please.outputs.tag_name }} 37 | steps: 38 | - uses: googleapis/release-please-action@v4 39 | id: release-please 40 | with: 41 | manifest-file: .github/release-please-manifest.json 42 | config-file: .github/release-please-config.json 43 | 44 | release-pdf: 45 | runs-on: ubuntu-24.04 46 | needs: release 47 | if: ${{ needs.release.outputs.released }} 48 | steps: 49 | - name: Checkout 50 | uses: actions/checkout@v4 51 | 52 | # Set a descriptive version. For PRs it'll be the short sha. 53 | - name: Check Version 54 | run: echo "${VERSION}" 55 | env: 56 | VERSION: ${{ needs.release.outputs.tag }} 57 | 58 | # Set a descriptive version. For PRs it'll be the short sha. 59 | - name: Prepare Markdown 60 | run: | 61 | # Set the env vars we use (version set for clarity). 62 | export DATE=$(date +%F) 63 | export VERSION="${VERSION}" 64 | make -f .github/makefile prepare-markdown 65 | env: 66 | VERSION: ${{ needs.release.outputs.tag }} 67 | 68 | # Create the PDF files. 69 | - name: Create PDF 70 | run: make -f .github/makefile create-pdf 71 | 72 | # Publish the PDF and intermediate markdown as an artifact. 73 | # - name: Publish PDF Artifact 74 | # uses: actions/upload-artifact@3 75 | # with: 76 | # name: hacker-laws.pdf 77 | # path: hacker-laws.pdf 78 | 79 | - name: Attach assets to GitHub Release 80 | env: 81 | GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 82 | run: | 83 | gh release upload "${{ needs.release.outputs.tag }}" --clobber hacker-laws.pdf hacker-laws.md 84 | 85 | deploy: 86 | environment: 87 | name: github-pages 88 | url: ${{ steps.deployment.outputs.page_url }} 89 | runs-on: ubuntu-24.04 90 | needs: release 91 | if: ${{ needs.release.outputs.released }} 92 | steps: 93 | - name: Checkout 94 | uses: actions/checkout@v4 95 | - name: Setup Pages 96 | uses: actions/configure-pages@v5 97 | - name: Build Website 98 | run: | 99 | cd .github/website 100 | make install 101 | make build 102 | cp -r build/. '../pages' 103 | ls -al "../pages" 104 | - name: Upload artifact 105 | uses: actions/upload-pages-artifact@v3 106 | with: 107 | path: './.github/pages' 108 | - name: Deploy to GitHub Pages 109 | id: deployment 110 | uses: actions/deploy-pages@v4 111 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright (c) Dave Kerr 2021 2 | 3 | # Attribution-ShareAlike 4.0 International 4 | 5 | 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. 6 | 7 | ### Using Creative Commons Public Licenses 8 | 9 | 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. 10 | 11 | * __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). 12 | 13 | * __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). 14 | 15 | ## Creative Commons Attribution-ShareAlike 4.0 International Public License 16 | 17 | 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. 18 | 19 | ### Section 1 – Definitions. 20 | 21 | 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. 22 | 23 | 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. 24 | 25 | 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. 26 | 27 | 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. 28 | 29 | 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. 30 | 31 | 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. 32 | 33 | 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. 34 | 35 | h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 36 | 37 | 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. 38 | 39 | j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License. 40 | 41 | 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. 42 | 43 | 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. 44 | 45 | m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 46 | 47 | ### Section 2 – Scope. 48 | 49 | a. ___License grant.___ 50 | 51 | 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: 52 | 53 | A. reproduce and Share the Licensed Material, in whole or in part; and 54 | 55 | B. produce, reproduce, and Share Adapted Material. 56 | 57 | 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. 58 | 59 | 3. __Term.__ The term of this Public License is specified in Section 6(a). 60 | 61 | 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. 62 | 63 | 5. __Downstream recipients.__ 64 | 65 | 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. 66 | 67 | 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. 68 | 69 | 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. 70 | 71 | 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). 72 | 73 | b. ___Other rights.___ 74 | 75 | 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. 76 | 77 | 2. Patent and trademark rights are not licensed under this Public License. 78 | 79 | 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. 80 | 81 | ### Section 3 – License Conditions. 82 | 83 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 84 | 85 | a. ___Attribution.___ 86 | 87 | 1. If You Share the Licensed Material (including in modified form), You must: 88 | 89 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 90 | 91 | 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); 92 | 93 | ii. a copyright notice; 94 | 95 | iii. a notice that refers to this Public License; 96 | 97 | iv. a notice that refers to the disclaimer of warranties; 98 | 99 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 100 | 101 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 102 | 103 | 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. 104 | 105 | 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. 106 | 107 | 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. 108 | 109 | b. ___ShareAlike.___ 110 | 111 | In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 112 | 113 | 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. 114 | 115 | 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. 116 | 117 | 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. 118 | 119 | ### Section 4 – Sui Generis Database Rights. 120 | 121 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 122 | 123 | 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; 124 | 125 | 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 126 | 127 | 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. 128 | 129 | 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. 130 | 131 | ### Section 5 – Disclaimer of Warranties and Limitation of Liability. 132 | 133 | 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.__ 134 | 135 | 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.__ 136 | 137 | 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. 138 | 139 | ### Section 6 – Term and Termination. 140 | 141 | 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. 142 | 143 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 144 | 145 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 146 | 147 | 2. upon express reinstatement by the Licensor. 148 | 149 | 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. 150 | 151 | 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. 152 | 153 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 154 | 155 | ### Section 7 – Other Terms and Conditions. 156 | 157 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 158 | 159 | 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. 160 | 161 | ### Section 8 – Interpretation. 162 | 163 | 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. 164 | 165 | 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. 166 | 167 | 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. 168 | 169 | 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. 170 | 171 | > 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. 172 | > 173 | > Creative Commons may be contacted at creativecommons.org. 174 | -------------------------------------------------------------------------------- /assets/banner.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/assets/banner.png -------------------------------------------------------------------------------- /assets/banner.psd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/assets/banner.psd -------------------------------------------------------------------------------- /assets/diagrams.bmpr: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/assets/diagrams.bmpr -------------------------------------------------------------------------------- /assets/repository-open-graph-template.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/assets/repository-open-graph-template.png -------------------------------------------------------------------------------- /assets/site/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Interactive Hacker Laws Stack 6 | 50 | 51 | 52 |
53 | 54 | 110 | 111 | 117 | 118 | 119 | 120 | -------------------------------------------------------------------------------- /assets/site/index2.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Interactive Hacker Laws Stack 7 | 51 | 52 | 53 |
54 | 55 | 107 | 108 | 109 | 110 | 111 | -------------------------------------------------------------------------------- /assets/site/index3.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Interactive Hacker Laws Stack 6 | 55 | 56 | 57 |
58 |
59 |
60 | 61 | 124 | 125 | 126 | 127 | 128 | -------------------------------------------------------------------------------- /assets/site/index4.html: -------------------------------------------------------------------------------- 1 | 26 | 27 | 28 | 29 | 30 | 31 | Interactive Hacker Laws Stack 32 | 81 | 82 | 83 |
84 |
85 |
86 | 87 | 155 | 156 | 157 | 158 | 159 | -------------------------------------------------------------------------------- /images/Fitts_Law.svg: -------------------------------------------------------------------------------- 1 | 2 | 13 | 15 | 33 | 38 | 45 | 46 | 47 | 49 | Layer 1 51 | 54 | 64 | 74 | 84 | 94 | 106 | 118 | 119 | 121 | 133 | 145 | 156 | Target 171 | 172 | W 187 | 189 | 200 | 211 | 222 | 233 | 244 | 245 | 248 | 260 | D 275 | 277 | 288 | 299 | 310 | 321 | 332 | 333 | 345 | 357 | 358 | 359 | 363 | 364 | -------------------------------------------------------------------------------- /images/amdahls_law.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/images/amdahls_law.png -------------------------------------------------------------------------------- /images/changelog-podcast.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/images/changelog-podcast.png -------------------------------------------------------------------------------- /images/complete_graph.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/images/complete_graph.png -------------------------------------------------------------------------------- /images/gartner_hype_cycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/images/gartner_hype_cycle.png -------------------------------------------------------------------------------- /images/gitlocalize.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/images/gitlocalize.png -------------------------------------------------------------------------------- /images/hicks_law.svg: -------------------------------------------------------------------------------- 1 | 2 | {\displaystyle T=b\cdot \log _{2}(n+1)} 3 | 4 | 19 | 36 | -------------------------------------------------------------------------------- /scripts/prepare-markdown-for-ebook.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | 3 | # Fail on errors. 4 | set -e -o pipefail 5 | 6 | # Check if parameters are provided 7 | input="$1" 8 | output="$2" 9 | if [ -z "${input}" ] || [ -z "${output}" ]; then 10 | echo "usage: $(basename "$0") " >&2 11 | echo " input: source markdown file (usually README.md)" >&2 12 | echo " output: output markdown file (usually hacker-laws.md)" >&2 13 | exit 1 14 | fi 15 | 16 | # Grab env vars used to configure output, fail if required are missing. 17 | export date="${DATE:-$(date +%F)}" 18 | export version="${VERSION?error: VERSION must be set}" 19 | 20 | 21 | # Update the input file to an intermedate. 22 | intermediate="${input}.temp" 23 | cat < "${intermediate}" 24 | --- 25 | title: "Hacker Laws" 26 | author: "Dave Kerr, github.com/dwmkerr/hacker-laws" 27 | subtitle: "Laws, Theories, Principles, and Patterns that developers will find useful. ${VERSION}, ${DATE}." 28 | version: ${VERSION} 29 | --- 30 | 31 | EOF 32 | cat "${input}" >> "${intermediate}" 33 | DATE="${date}" VERSION="${version}" envsubst < "${intermediate}" > "${output}" 34 | 35 | # Use a single `sed` command to clean up unwanted lines and emojis in one pass. 36 | sed -e '/💻📖.*/d' \ 37 | -e 's/❗/Warning/g' \ 38 | -e '/^\[Translations.*/d' \ 39 | -e '/\*.*/d' \ 40 | -e '/ \*.*/d' \ 41 | -e '/## Translations/,$d' "${output}" > "${intermediate}" 42 | mv "${intermediate}" "${output}" 43 | 44 | echo "${output} prepared successfully." 45 | -------------------------------------------------------------------------------- /translations/it-IT.md: -------------------------------------------------------------------------------- 1 | # 💻📖 hacker-laws 2 | 3 | Leggi, teorie, principi e pattern utili agli sviluppatori. 4 | 5 | [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) 6 | 7 | --- 8 | 9 | 10 | 11 | * [Introduzione](#introduzione) 12 | * [Leggi](#leggi) 13 | * [Legge di Amdahl](#legge-di-amdahl) 14 | * [Legge di Brooks](#legge-di-brooks) 15 | * [Legge di Conway](#legge-di-conway) 16 | * [Numero di Dunbar](#numero-di-dunbar) 17 | * [Legge di Gall](#legge-di-gall) 18 | * [Rasoio di Hanlon](#rasoio-di-hanlon) 19 | * [Legge di Hofstadter](#legge-di-hofstadter) 20 | * [Legge di Hutber](#legge-di-hutber) 21 | * [Hype Cycle e Legge di Amara](#hype-cycle-e-legge-di-amara) 22 | * [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite) 23 | * [Legge di Moore](#legge-di-moore) 24 | * [Legge di Parkinson](#legge-di-parkinson) 25 | * [Ottimizzazione Prematura](#effetto-di-ottimizzazione-prematura) 26 | * [Legge di Putt](#legge-di-putt) 27 | * [Legge di Conservazione della Complessità (Legge di Tesler)](#legge-di-conservazione-della-complessita-legge-di-tesler) 28 | * [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata) 29 | * [Legge di Irrilevanza](#legge-di-irrilevanza) 30 | * [Filosofia Unix](#filosofia-unix) 31 | * [Il modello Spotify](#il-modello-spotify) 32 | * [Legge di Wadler](#legge-di-wadler) 33 | * [Principi](#principi) 34 | * [Il Principo di Pareto (La regola dell'80/20)](#principio-di-pareto-regola-dell-80-20) 35 | * [Il Principio di Robustezza (Legge di Postel's)](#principio-di-robustezza-legge-di-postel) 36 | * [SOLID](#solid) 37 | * [Il Principio di Singola Responsabilità](#principio-di-singola-responsabilita) 38 | * [Il Principio dell'Aperto/Chiuso](#principio-dell-open-closed) 39 | * [Il Principio di Sostituzione di Liskov](#principio-di-sostituzione-di-liskov) 40 | * [Il Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce) 41 | * [Il Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze) 42 | * [Il Principio DRY](#principio-dry) 43 | * [YAGNI](#yagni) 44 | * [Reading List](#reading-list) 45 | * [TODO](#todo) 46 | 47 | 48 | 49 | ## Introduzione 50 | 51 | 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! 52 | 53 | 54 | ❗: 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. 55 | 56 | ## Leggi 57 | 58 | Si parte! 59 | 60 | ### Legge di Amdahl 61 | 62 | [Legge di Amdahl su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Amdahl) 63 | 64 | > 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. 65 | 66 | 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. 67 | 68 | Il diagramma sotto riportato illustra gli andamenti nel tempo della velocità di esecuzione in alcuni casi: 69 | 70 | ![Diagram: Amdahl's Law](./images/amdahls_law.png) 71 | 72 | *(Crediti Immagine: Daniels220 su Wikipedia in lingua inglese, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* 73 | 74 | 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. 75 | 76 | 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) 77 | 78 | Vedi anche: 79 | 80 | - [Legge di Brooks](#legge-di-brooks) 81 | - [Legge di Moore](#legge-di-moore) 82 | 83 | ### Legge di Brooks 84 | 85 | [Legge di Brooks su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Brooks) 86 | 87 | > L'aggiunta di risorse umane ad un progetto di sviluppo software già in ritardo lo fa tardare ancora di più. 88 | 89 | 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. 90 | 91 | 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. 92 | 93 | Questo è un tema centrale del libro '[The Mythical Man Month](#reading-list)'. 94 | 95 | Vedi anche: 96 | 97 | - [Death March](#todo) 98 | - [Reading List: The Mythical Man Month](#reading-list) 99 | 100 | ### Legge di Conway 101 | 102 | [Legge di Conway su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Conway) 103 | 104 | 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. 105 | 106 | Vedi anche: 107 | 108 | - [Il modello Spotify](#il-modello-spotify) 109 | 110 | ### Numero di Dunbar 111 | 112 | [Numero di Dunbar su Wikipedia](https://it.wikipedia.org/wiki/Numero_di_Dunbar) 113 | "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. 114 | 115 | 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. 116 | 117 | Vedi anche: 118 | 119 | - [Legge di Conway](#legge-di-conway) 120 | 121 | ### Legge di Gall 122 | 123 | [Legge di Gall su Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) 124 | 125 | > 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. 126 | > 127 | > ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author))) 128 | 129 | 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. 130 | 131 | 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. 132 | 133 | Vedi anche: 134 | 135 | - [KISS (Keep It Simple, Stupid)](#TODO) 136 | 137 | ### Rasoio di Hanlon 138 | 139 | [Rasoio di Hanlon su Wikipedia](https://it.wikipedia.org/wiki/Rasoio_di_Hanlon) 140 | 141 | > Non attribuire mai a malafede quel che si può ragionevolmente spiegare con la stupidità. 142 | > 143 | > Robert J. Hanlon 144 | 145 | 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. 146 | 147 | ### Legge di Hofstadter 148 | 149 | [Legge di Hofstadter su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Hofstadter) 150 | 151 | > Per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter. 152 | > 153 | > (Douglas Hofstadter) 154 | 155 | 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. 156 | 157 | La legge viene dal libro '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'. 158 | 159 | Vedi anche: 160 | 161 | - [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list) 162 | 163 | ### Legge di Hutber 164 | 165 | [Legge di Hutber su Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) 166 | 167 | > I miglioramenti spesso celano altri peggioramenti. 168 | > 169 | > ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber)) 170 | 171 | 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. 172 | 173 | 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. 174 | 175 | ### Hype Cycle e Legge di Amara 176 | 177 | [Hype Cycle su Wikipedia](https://it.wikipedia.org/wiki/Hype_cycle) 178 | 179 | > Tendiamo a sovrastimare l'impatto di una tecnologia sul breve termine e nel sottostimarlo sul lungo termine. 180 | > 181 | > (Roy Amara) 182 | 183 | L'Hype Cycle è una rappresentazione visuale del clamore attorno allo sviluppo di una tecnologia nel tempo, originariamente ideata da Gartner. Un esempio: 184 | 185 | ![The Hype Cycle](./images/gartner_hype_cycle.png) 186 | 187 | *(Crediti Immagine: Jeremykemp su Wikipedia in lingua inglese, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* 188 | 189 | 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". 190 | 191 | ### Legge di Hyrum (Legge delle Interfacce Implicite) 192 | 193 | [Legge di Hyrum Online](http://www.hyrumslaw.com/) 194 | 195 | > Dato un numero sufficientementa elevato di utenti di un'API, 196 | > il contenuto del contratto di interfaccia non conta: 197 | > tutti i comportamenti osservabili del sistema che espone l'API 198 | > saranno utilizzati da questi utenti. 199 | > 200 | > (Hyrum Wright) 201 | 202 | 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. 203 | 204 | Vedi anche: 205 | 206 | - [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata) 207 | - [XKCD 1172](https://xkcd.com/1172/) 208 | 209 | ### Legge di Moore 210 | 211 | [Legge di Moore su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Moore) 212 | 213 | > Il numero di transistor in un circuito integrato raddoppia approssimativamente ogni due anni. 214 | 215 | 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. 216 | 217 | ### Legge di Parkinson 218 | 219 | [Legge di Parkinson su Wikipedia](https://it.wikipedia.org/wiki/La_legge_di_Parkinson) 220 | 221 | > Il lavoro tende ad espandersi fino ad impiegare tutto il tempo disponibile per svolgerlo. 222 | 223 | 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. 224 | 225 | 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*. 226 | 227 | Vedi anche: 228 | 229 | - [Legge di Hofstadter](#legge-di-hofstadter) 230 | 231 | ### Effetto di Ottimizzazione Prematura 232 | 233 | [Ottimizzazione Prematura su WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) 234 | 235 | > L'ottimizzazione prematura è la radice di ogni male. 236 | > 237 | > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) 238 | 239 | 240 | Nella sua pubblicazione [Programmazione Strutturata con clausole Go To](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), 241 | 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." 242 | 243 | L'_Ottimizzazione Prematura_ può essere definita (in termini meno coloriti) come l'attività di efficientamento fatta prima di avere evidenza della sua necessità. 244 | 245 | ### Legge di Putt 246 | 247 | [Legge di Putt su Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) 248 | 249 | > 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. 250 | 251 | La Legge di Putt è spesso accompagnata dal Corollario di Putt: 252 | 253 | > Ogni gerarchia tecnica, genera un'inversione delle competenze con il passare del tempo. 254 | 255 | 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). 256 | 257 | Tuttavia, è corretto specificare che Leggi come queste sono una grande generalizzazione e si applicano ad _alcuni_ tipi di organizzazione e non ad altri. 258 | 259 | Vedi anche: 260 | 261 | - [Principio di Peter](#TODO) 262 | - [Legge di Dilbert](#TODO). 263 | 264 | 265 | ### Legge di Conservazione della Complessità (Legge di Tesler) 266 | 267 | [Legge di Conservazione della Complessità su Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) 268 | 269 | Le Legge dice che in ogni sistema esiste un certo livello di complessità che non può essere ridotto. 270 | 271 | 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. 272 | 273 | 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. 274 | 275 | 276 | ### Legge dell'Astrazione Fallata 277 | 278 | [La Legge dell'Astrazione Fallata su Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 279 | 280 | > Tutte le astrazioni non banali sono in qualche modo fallate. 281 | > 282 | > ([Joel Spolsky](https://twitter.com/spolsky)) 283 | 284 | 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. 285 | 286 | 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. 287 | 288 | 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. 289 | 290 | 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. 291 | 292 | Vedi anche: 293 | 294 | - [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite) 295 | 296 | Esempi dal mondo reale: 297 | 298 | - [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. 299 | 300 | ### Legge di Irrilevanza 301 | 302 | [Legge di Irrilevanza su Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) 303 | 304 | 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. 305 | 306 | 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. 307 | 308 | L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza. 309 | 310 | ### Filosofia Unix 311 | 312 | [La Filosofia Unix su Wikipedia](https://it.wikipedia.org/wiki/Filosofia_Unix) 313 | 314 | 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. 315 | 316 | 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. 317 | 318 | ### Il modello Spotify 319 | 320 | [Il modello Spotify su Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) 321 | 322 | 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. 323 | 324 | Il modello Spotify rende inoltre popolari i concetti di Tribù, Gilda, Capitolo, che sono altre componenti della struttura organizzativa. 325 | 326 | 327 | ### Legge di Wadler 328 | 329 | [Legge di Wadler su wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) 330 | 331 | > 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: 332 | > 333 | > 0. Semantica 334 | > 1. Sintassi 335 | > 2. Sintassi lessicale 336 | > 3. Sintassi lessicale dei commenti 337 | > 338 | > (In breve: per ogni ora spesa a discutere della semantica, 8 ore saranno spese sulla sintassi dei commenti). 339 | 340 | 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. 341 | 342 | Vedi anche: 343 | 344 | - [Legge di Irrilevanza](#legge-di-irrilevanza) 345 | 346 | ## Principi 347 | 348 | I Principi sono in generale usabili come linee guida per il design. 349 | 350 | 351 | ### Principio di Pareto (regola dell'80-20) 352 | 353 | [Il Principio di Pareto su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_Pareto) 354 | 355 | > Nella vita, la maggior parte delle cose non è distribuita equamente. 356 | 357 | Il Principio di Pareto suggerisce che in alcuni casi, la maggior parte dei risultati è effetto di una minoranza degli input 358 | 359 | - 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) 360 | - il 20% dell'effort produce l'80% del risultato 361 | - il 20% del lavoro genera l'80% della revenue 362 | - il 20% dei bachi genera l'80% dei crash 363 | - il 20% delle features soddisfa l'80% degli utenti 364 | 365 | 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) 366 | 367 | Questo Principio è anche noto come: Regola dell'80/20, Legge dei Pochi ma Vitali e il Principio della Scarsità dei Fattori. 368 | 369 | Esempi dal mondo reale: 370 | 371 | - 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)). 372 | 373 | ### Principio di Robustezza (Legge di Postel) 374 | 375 | [Il Principio di Robustezza su Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) 376 | 377 | > Siate conservativi nelle vostre azioni, ma liberali in ciò che accettate dagli altri. 378 | 379 | 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. 380 | 381 | 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. 382 | 383 | ### SOLID 384 | 385 | SOLID è un acronimo: 386 | 387 | * S: [Principio di Singola Responsabilità](#principio-di-singola-responsabilita) 388 | * O: [Principio dell'Open Closed](#principio-dell-open-closed) 389 | * L: [Principio di Sotituzione di Liskov](#principio-di-sostituzione-di-liskov) 390 | * I: [Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce) 391 | * D: [Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze) 392 | 393 | These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems. 394 | 395 | ### Principio di Singola Responsabilità 396 | 397 | [Principio di Singola Responsabilità su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_singola_responsabilit%C3%A0) 398 | 399 | > Ogni modulo o classe dovrebbe avere una sola responsabilità. 400 | 401 | 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. 402 | 403 | 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. 404 | 405 | Vedi anche: 406 | 407 | - [Object-Oriented Programming](#todo) 408 | - [SOLID](#solid) 409 | 410 | ### Principio dell'Open Closed 411 | 412 | [Il Principio dell'Open Closed su Wikipedia](https://it.wikipedia.org/wiki/Principio_aperto/chiuso) 413 | 414 | > Le entità software dovrebbero essere aperte all'estensione ma chiuse alla modifica. 415 | 416 | 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_ 417 | 418 | 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. 419 | 420 | 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. 421 | 422 | Vedi anche: 423 | 424 | - [Object-Oriented Programming](#todo) 425 | - [SOLID](#solid) 426 | 427 | ### Principio di Sotituzione di Liskov 428 | 429 | [Il Principio di Sotituzione di Liskov su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_sostituzione_di_Liskov) 430 | 431 | > Deve essere possibile sostituire l'istanza di un tipo con l'istanza di un suo sottotipo senza rompere il codice. 432 | 433 | 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. 434 | 435 | 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. 436 | 437 | 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. 438 | 439 | Vedi anche: 440 | 441 | - [Object-Oriented Programming](#todo) 442 | - [SOLID](#solid) 443 | 444 | ### Principio di Segregazione delle Interfacce 445 | 446 | [Il Principio di Segregazione delle Interfacce su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_segregazione_delle_interfacce) 447 | 448 | > Nessun client dovrebbe dipendere da comportamenti che non usa. 449 | 450 | Il quarto dei Principi '[SOLID](#solid)' afferma che i consumer di una componente software non dovrebbero dipendere da funzionalità del componente che non utilizzano. 451 | 452 | 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. 453 | 454 | 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. 455 | 456 | Vedi anche: 457 | 458 | - [Object-Oriented Programming](#todo) 459 | - [SOLID](#solid) 460 | - [Duck Typing](#todo) 461 | - [Disaccoppiamento](#todo) 462 | 463 | ### Principio di Inversione delle Dipendenze 464 | 465 | [Il Principio di Inversione delle Dipendenze su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_inversione_delle_dipendenze) 466 | 467 | > I moduli di alto livello non dovrebbero dipendere dalle implementazioni di basso livello. 468 | 469 | 470 | 471 | 472 | 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. 473 | 474 | 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. 475 | 476 | 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). 477 | 478 | Vedi anche: 479 | 480 | - [Object-Oriented Programming](#todo) 481 | - [SOLID](#solid) 482 | - [Inversione del Controllo](#todo) 483 | - [Iniezione delle Dipendenze](#todo) 484 | 485 | ### Principio DRY 486 | 487 | [Il Principio DRY su Wikipedia](https://it.wikipedia.org/wiki/Don%27t_repeat_yourself) 488 | 489 | > Ogni elemento di conoscenza deve avere una sola, non ambigua, autorevole rappresentazione all'interno di un sistema. 490 | 491 | 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) 492 | 493 | > Il contrario di DRY è _WET_ (Write Everything Twice or We Enjoy Typing - Scrivi Tutto In Doppio o Adoriamo Scrivere alla Tastiera). 494 | 495 | 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. 496 | 497 | Vedi anche: 498 | 499 | - [The Pragmatic Programmer](https://it.wikipedia.org/wiki/The_Pragmatic_Programmer) 500 | 501 | ### YAGNI 502 | 503 | [YAGNI su Wikipedia](https://it.wikipedia.org/wiki/You_aren%27t_gonna_need_it) 504 | 505 | Si tratta dell'acronimo dell'inglese _**Y**ou **A**ren't **G**onna **N**eed **I**t_ (_Non Ne Avrai Bisogno_) 506 | 507 | > Scrivi una porzione di codice sempre e solo quando ne hai un bisogno reale, e mai quando sai solo prevedere il suo uso futuro. 508 | > 509 | > ([Ron Jeffries](https://twitter.com/RonJeffries)) (co-fondatore dell'eXtreme Programming e autore del libro "Extreme Programming Installed") 510 | 511 | 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. 512 | 513 | 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. 514 | 515 | Vedi anche: 516 | 517 | - [Reading List: Extreme Programming Installed](#reading-list) 518 | 519 | 520 | ## Reading List 521 | 522 | Se avete trovato questi concetti interessanti, potrebbero interessarvi anche i seguenti libri. 523 | 524 | - [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Tratta i principi fondamentali dell'Extreme Programming. 525 | - [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. 526 | - [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. 527 | 528 | ## TODO 529 | 530 | 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! 531 | 532 | 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. 533 | -------------------------------------------------------------------------------- /translations/jp.md: -------------------------------------------------------------------------------- 1 | # 💻📖 ハッカーの法則 2 | 3 | 開発者が役に立つと思う法則、理論、原則、パターン。 4 | 5 | [翻訳](#翻訳): [🇧🇷](./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) 6 | 7 | このプロジェクトが気に入りましたか?ぜひ私と[翻訳者](#%E7%BF%BB%E8%A8%B3)を支援すること[ご検討ください。](https://github.com/sponsors/dwmkerr) 8 | 9 | --- 10 | 11 | 12 | 13 | - [イントロダクション](#イントロダクション) 14 | - [法則](#法則) 15 | - [90-9-1 原則(1%ルール)](#90-9-1-原則1ルール) 16 | - [アムダールの法則](#アムダールの法則) 17 | - [割れ窓理論](#割れ窓理論) 18 | - [ブルックスの法則](#ブルックスの法則) 19 | - [コンウェイの法則](#コンウェイの法則) 20 | - [カニンガムの法則](#カニンガムの法則) 21 | - [ダンバー数](#ダンバー数) 22 | - [ゴールの法則](#ゴールの法則) 23 | - [グッドハートの法則](#グッドハートの法則) 24 | - [ハンロンの剃刀](#ハンロンの剃刀) 25 | - [ホフスタッターの法則](#ホフスタッターの法則) 26 | - [ハーバーの法則](#ハーバーの法則) 27 | - [ハイプサイクルとアマラの法則](#ハイプサイクルとアマラの法則) 28 | - [ハイラムの法則(暗黙のインターフェースの法則)](#ハイラムの法則暗黙のインターフェースの法則) 29 | - [カーニガンの法則](#カーニガンの法則) 30 | - [リーナスの法則](#リーナスの法則) 31 | - [メトカーフの法則](#メトカーフの法則) 32 | - [ムーアの法則](#ムーアの法則) 33 | - [マーフィーの法則/ソッドの法則](#マーフィーの法則ソッドの法則) 34 | - [オッカムの剃刀](#オッカムの剃刀) 35 | - [パーキンソンの法則](#パーキンソンの法則) 36 | - [早すぎる最適化](#早すぎる最適化) 37 | - [パットの法則](#パットの法則) 38 | - [リードの法則](#リードの法則) 39 | - [複雑性保存の法則(テスラーの法則)](#複雑性保存の法則テスラーの法則) 40 | - [漏れのある抽象化の法則](#漏れのある抽象化の法則) 41 | - [パーキンソンの凡俗法則](#パーキンソンの凡俗法則) 42 | - [UNIX哲学](#unix哲学) 43 | - [Spotifyモデル](#spotifyモデル) 44 | - [ワドラーの法則](#ワドラーの法則) 45 | - [ウィートンの法則](ウィートンの法則) 46 | - [原則](#原則) 47 | - [ディルバートの原理](#ディルバートの原理) 48 | - [パレート原理(80/20ルール)](#パレート原理8020ルール) 49 | - [ピーターの原則](#ピーターの原則) 50 | - [堅牢性の原則(ポステルの法則)](#堅牢性の原則ポステルの法則) 51 | - [SOLID](#solid) 52 | - [単一責任の原則](#単一責任の原則) 53 | - [開放/閉鎖原則](#開放閉鎖原則) 54 | - [リスコフ代替原則](#リスコフの置換原則) 55 | - [インターフェース分離の原則](#インターフェース分離の原則) 56 | - [依存関係の逆転の原則](#依存性逆転の原則) 57 | - [DRY原則](#dry原則) 58 | - [KISS原則](#kissの原則) 59 | - [YAGNI](#yagni) 60 | - [分散コンピューティングの落とし穴](#分散コンピューティングの落とし穴) 61 | - [関連書籍](#関連書籍) 62 | - [翻訳](#翻訳) 63 | - [関連プロジェクト](#関連プロジェクト) 64 | - [貢献方法](#貢献方法) 65 | - [TODO](#todo) 66 | 67 | 68 | 69 | ## イントロダクション 70 | 71 | ソフトウェア開発の話をするときに話題にのぼる法則はたくさんありますよね。このレポジトリでは、その中でも最も一般的なものをリストアップしその概要を説明しています。ぜひ、シェアしたりプルリクエストしてください! 72 | 73 | ❗: このリポジトリには、いくつかの法則や原則、パターンの説明が含まれていますが、このレポジトリはそれらを*推奨*するものではありません。適用すべきかどうかは、常に議論の余地がありますし、あなたが何に取り組んでいるかに大きく依存します。 74 | 75 | ## 法則 76 | 77 | そして、ここからが本編! 78 | 79 | ### 90-9-1 原則(1%ルール) 80 | 81 | [1%の法則-Wikipedia](https://ja.wikipedia.org/wiki/1%25%E3%81%AE%E6%B3%95%E5%89%87) 82 | 83 | 90-9-1原則は、wikiのようなインターネットコミュニティ内では、参加者のうちコンテンツを閲覧しているだけの人が90%、コンテンツを編集や修正する人が9%、残りの1%がコンテンツを追加することを示唆しています。 84 | 85 | 実際の例: 86 | 87 | - 4つのデジタルヘルスソーシャルネットワークの2014年の調査によると、上位1%が投稿の73%を作成し、次の9%が平均約25%の投稿を作成し、残りの90%が平均2%を作成するという結果が示されてます。( [参考文献](https://www.jmir.org/2014/2/e33/) ) 88 | 89 | 関連項目: 90 | 91 | - [パレートの法則](#パレート原理8020ルール) 92 | 93 | ### アムダールの法則 94 | 95 | [アムダールの法則-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) 96 | 97 | > アムダールの法則とは、リソースを追加した場合に、*期待できる性能向上*の程度です。通常、並列コンピューティングで使用され、プログラムの並列性によって制限されるプロセッサの数を増やすことによる実際の利益を予測することができます。 98 | 99 | 例を挙げて説明します。プログラムが、1つのプロセッサで実行されなければならないパートAと、並列化できるパートBの2つのパートで構成されている場合、プログラムを実行するシステムに複数のプロセッサを追加しても、限られた利益しか得られないことがわかります。パートBの速度を大幅に向上させることは可能ですが、パートAの速度は変わらないでしょう。 100 | 101 | 下記の図は、並列度増加と期待する速度改善の例を示しています。 102 | 103 | Diagram: Amdahl's Law 104 | 105 | *(画像参照:英語版ウィキペディアのDaniels220、クリエイティブコモンズの表示-継承3.0非移植、https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* 106 | 107 | このように、50%の並列化が可能なプログラムであっても、10個の演算処理装置を超えるとほとんど恩恵を受けませんが、95%の並列化が可能なプログラムであれば、1000個以上の演算処理装置でも大幅な速度向上を達成することができます。 108 | 109 | [ムーアの法則](#ムーアの法則)による性能向上が鈍化し、個々のプロセッサの処理速度の進化が遅くなると、並列化が性能向上の鍵となります。最新のシェーダベースのコンピューティングでは、個々のピクセルやフラグメントを並列にレンダリングすることができます。現代のグラフィックカードが何千もの処理コア(GPUやシェーダユニット)が搭載されている場合多い理由はこれです。 110 | 111 | 関連項目: 112 | 113 | - [ブルックスの法則](#ブルックスの法則) 114 | - [ムーアの法則](#ムーアの法則) 115 | 116 | ### 割れ窓理論 117 | 118 | [割れ窓理論-Wikipedia](https://ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8C%E7%AA%93%E7%90%86%E8%AB%96) 119 | 120 | 割れ窓理論は、目に見える犯罪の兆候(または環境整備の欠如)が、さらに深刻な犯罪(または環境のさらなる悪化)につながることを示唆しています。 121 | 122 | この理論はソフトウェア開発に応用されており、質の低いコード(または [技術的負債](#TODO))は、品質を向上させる努力を無視したり、過小評価したりするという認識につながり、その結果、さらに質の低いコードの生産につながることを示唆しています。この効果は、時間の経過とともに品質を大きく低下させることにつながります。 123 | 124 | 関連項目: 125 | 126 | - [技術的負債](#TODO) 127 | 128 | 例: 129 | 130 | - [実用的なプログラミング:ソフトウェアエントロピー](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy) 131 | - [コーディングホラー:割れ窓理論](https://blog.codinghorror.com/the-broken-window-theory/) 132 | - [オープンソース:プログラミングの喜び-割れ窓理論](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/) 133 | 134 | ### ブルックスの法則 135 | 136 | [ブルックスの法則-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) 137 | 138 | > 遅延しているソフトウェア開発プロジェクトに人材を追加するとプロジェクトがさらに遅延する。 139 | 140 | この法則は、多くの場合、すでに遅れているプロジェクトを挽回させようとして、人的リソースを追加することで、プロジェクトが更に遅延することを示唆しています。ブルックスは、これが単純化しすぎであることを明らかにしていますが、一般的な推論としては、新しい人的リソースの立ち上げにかかる時間とコミュニケーションのオーバーヘッドを考えると、短期的には速度が低下するということです。また、多くのタスクは分割出来ないことがあり、リソース間で簡単にタスク分散されない可能性があり、期待するベロシティも得られなくなることを意味します。 141 | 142 | 出産でよく言われる「9人の女性は1ヶ月で子作りができない」という言葉は、ブルックスの法則、特にある種のタスクは分割や並列化できないという事実に関連しています。 143 | 144 | これは、「 [人月の神話](#関連書籍) 」という本の中心的なテーマです。 145 | 146 | 関連項目: 147 | 148 | - [デスマーチ](#todo) 149 | - [関連書籍:人月の神話](#関連書籍) 150 | 151 | ### コンウェイの法則 152 | 153 | [コンウェイの法則 Wikipedia(英語版)](https://en.wikipedia.org/wiki/Conway%27s_law) 154 | 155 | この法則は、システムの技術的な境界線が組織の構造を反映することを示唆しています。組織の改善を検討する際によく参考にされますが、コンウェイの法則では、組織が多くの小さな切り離されたユニットに構造化されている場合、その組織が生成するソフトウェアも小さな切り離されたユニットに構造になること示唆しています。もし組織が機能やサービスを中心とした「縦割り」に構築されているならば、ソフトウェアシステムもこれを反映し縦割りになります。 156 | 157 | 関連項目: 158 | 159 | - [Spotifyモデル](#spotifyモデル) 160 | 161 | ### カニンガムの法則 162 | 163 | [カニンガムの法則 - Meta - Meta-Wiki - Wikimedia](https://meta.wikimedia.org/wiki/Cunningham%27s_Law/ja) 164 | 165 | > インターネット上で正解を得るための最良の方法は、質問をすることではなく、間違った答えを投稿することです。 166 | 167 | スティーブン・マクゲディによると、1980年代初頭にウォード・カニンガム氏が彼にこうアドバイスをしたそうです。「インターネットで正しい答えを得る最善の方法は、質問をすることではなく、間違った答えを投稿することだ」と。マクギーディはこれをカニンガムの法則と呼んでいますが、カニンガムはこの法則の所有権を否定しており、カニンガムはこれを「誤引用」と言っています。元々はUsenet上でのやりとりのこと指していたが、この法則は他のオンラインコミュニティ(例:Wikipedia、Reddit、Twitter、Facebook)の仕組みを説明するために使われてきました。 168 | 169 | 関連項目: 170 | 171 | - [XKCD 386:「デューティコール」](https://xkcd.com/386/) 172 | 173 | ### ダンバー数 174 | 175 | [ダンバー数-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%B3%E3%83%90%E3%83%BC%E6%95%B0) 176 | 177 | 「ダンバーの数は、安定した社会的関係を維持できる人の数に対する認知的制限の提案です。つまり、個人が各人が誰であるか、そして各個人と他のすべての人との関係を知っている関係です。」正確な数にはいくつかの意見の相違があります。 「... [ダンバー]は、人間が快適に維持できるのは150人の安定した関係だけであると提案しました。 "彼はその数をより社会的なコンテキストで説明しています、「もしあなたがバーで偶然出会って、その場で突然一緒に酒を飲むことになったとしても、気まずさを感じない人数」。この数は一般的に100人から250人と言われています。 178 | 179 | 個人間の安定した関係と同様に、コードベースと開発者の関係を維持するには努力が必要です。大規模で複雑なプロジェクトに直面したとき、や多くのプロジェクトをかかえているとき、私たちは慣例やポリシー、モデル化された手順に頼ってスケールアップを図っています。ダンバーの数字は、オフィスが大きくなったときに心に留めておくことが重要であるだけでなく、チームの責任範囲を設定したり、システムがモデリングや理論的オーバーヘッドの自動化を支援するツールにいつ投資すべきかを決定するときにも重要です。この数字をエンジニアリングのコンテキストに当てはめると、オンコールローテーションに参加してサポートすることに自信を持てるプロジェクトの数(または単一プロジェクトの複雑さを正規化した数)です。 180 | 181 | 関連項目: 182 | 183 | - [コンウェイの法則](#コンウェイの法則) 184 | 185 | ### ゴールの法則 186 | 187 | [ゴールの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%B4%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87) 188 | 189 | > 動作する複雑なシステムは、必ず、動作していた単純なシステムから進化したものであることがわかります。ゼロから設計された複雑なシステムは決して動作しませんし、それを動作させるためにパッチを当てることもできません。機能するシンプルなシステムからやり直さなければなりません。 190 | > ([ジョン・ゴール(英語)](https://en.wikipedia.org/wiki/John_Gall_(author))) 191 | 192 | ゴール法則は、高度に複雑なシステムを*設計*しようとする試みが失敗する可能性が高いことを示唆している。高度に複雑なシステムが一度に構築されることはめったになく、より単純なシステムから進化するものです。 193 | 194 | 典型的な例は、world-wide-webです。今日では、これは高度に複雑なシステムですが、しかし、当初は学術機関間でコンテンツを共有するためのシンプルな方法として定義されていました。その目標を達成することに成功し、時間の経過とともにより複雑なものへと進化していきました。 195 | 196 | 関連項目: 197 | 198 | - [KISS (Keep It Simple, Stupid)](#kissの原則) 199 | 200 | ### グッドハートの法則 201 | 202 | [グッドハートの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Goodhart's_law) 203 | 204 | > 観察されたどのような統計的規則性も、管理する目的で圧力をかけると崩壊してしまう傾向があります。 205 | > *チャールズ・グッドハート* 206 | 207 | 次のようにも一般的に参照されます: 208 | 209 | > 計測結果が目標になると、その計測自体が役に立たなくなります。 210 | > *マリリン・ストラザーン* 211 | 212 | この法則は、測定主導の最適化が測定結果自体の価値を下げることにつながる可能性があると述べています。プロセスに盲目的に適用された過度に選択的な一連の( [KPI](https://en.wikipedia.org/wiki/Performance_indicator) )は、歪んだ効果をもたらします。人々は、自分たちの行動の全体的な結果に注意を払うのではなく、特定のメトリックを満たすためにシステムを「ゲーム」することで部分的に最適化する傾向があります。 213 | 214 | 実際の例: 215 | 216 | - 十分にテストされたソフトウェアを作成することがコードカバレッジ測定の意図であったにもかかわらず、アサートなしのテストはコードカバレッジの基準を満たしています。 217 | - コミットされた行数によって開発者を評価するとは、無駄に肥大化したコードベースを作成することに繋がります。 218 | 219 | 関連項目: 220 | 221 | - [グッドハートの法則:間違ったものを測定することが不道徳な行動をどのように促進するか](https://coffeeandjunk.com/goodharts-campbells-law/) 222 | - [バグのないソフトウェアのディルバート](https://dilbert.com/strip/1995-11-13) 223 | 224 | ### ハンロンの剃刀 225 | 226 | [ハンロンの剃刀-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) 227 | 228 | > 無能で十分説明されることに悪意を見出すな。 229 | > ロバート・J・ハンロン 230 | 231 | この原則は、ネガティブな結果をもたらす行動は悪意の結果ではないことを示唆している。むしろネガティブな結果はそれらの行為や影響が完全に理解されていなかったことに起因する可能性が高い。 232 | 233 | ### ホフスタッターの法則 234 | 235 | [ホフスタッターの法則-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) 236 | 237 | > ホフスタッターの法則を考慮しても、いつも予想以上に時間がかかる。 238 | > (ダグラスホフスタッター) 239 | 240 | 何かがどれくらいかかるかの見積もりを見るときに、この法則を聞いたことがあるかもしれません。ソフトウェア開発においては、納品にかかる時間を正確に見積もるのは人々はあまり得意ではない傾向にあります。 241 | 242 | これは「 [ゲーデル、エッシャー、バッハ:永遠の金色の三つ編み](#関連書籍) 」という本からの引用です。 243 | 244 | 関連項目: 245 | 246 | - [関連書籍: ゲーデル、エッシャー、バッハ:永遠の金色の三つ編み](#関連書籍) 247 | 248 | ### ハーバーの法則 249 | 250 | [ハーバーの法則Wikipedia(英語版)](https://en.wikipedia.org/wiki/Hutber%27s_law) 251 | 252 | > 改善とは劣化を意味します。 253 | > ( [パトリックハットバー-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Patrick_Hutber) ) 254 | 255 | この法則は、システムを改善しようとして、他の部分の劣化につながったり、または他の劣化を隠し、全体的にシステムが現在の状態から劣化につながることを示唆しています。 256 | 257 | 例えば、特定のエンドポイントに対する応答遅延を減少させようとして、リクエストフローのさらに後フェーズのスループットやキャパシティの問題を増加させ、全く関係ないサブシステムに影響を与える可能性があります。 258 | 259 | ### ハイプ・サイクルとアマラの法則 260 | 261 | [ハイプ・サイクル- 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) 262 | 263 | > テクノロジーの効果を短期的には過大評価し、長期的には過小評価する傾向がある。 264 | > (ロイ・アマラ) 265 | 266 | ハイプ・サイクルは、元々はガートナー社によって作成された、時間をかけてテクノロジーの興奮と発展を視覚的に表現したものです。視覚的に表示するのが最適です。 267 | 268 | ![The Hype Cycle](../images/gartner_hype_cycle.png) 269 | 270 | *(画像参照:英語版ウィキペディアのJeremykemp著、CC BY-SA 3.0、https://commons.wikimedia.org/w/index.php?curid = 10547051)* 271 | 272 | 要するに、このサイクルは、一般的に新技術とその潜在的な影響力について興奮があることを示唆している。チームはしばしばこれらのテクノロジーにすぐに飛びつき、その結果に失望してしまうことがあります。これは、テクノロジーがまだ十分に成熟していなかったり、実世界でのアプリケーションがまだ十分に実現されていないからかもしれません。ある程度の時間が経つと、テクノロジーの能力が向上し、実際に使用する機会が増え、チームはようやく生産性を高めることができます。Roy Amaraのこの言葉は、このことを最も簡潔に要約しています。「私たちは、テクノロジーの効果を短期的には過大評価し、長期的には過小評価する傾向がある」。 273 | 274 | ### ハイラムの法則(暗黙のインターフェースの法則) 275 | 276 | [ハイラムの法則(英語)](http://www.hyrumslaw.com/) 277 | 278 | > あるAPIに十分なユーザー数がいれば、契約で何を約束するかどうかは問題ではありません。 あなたのシステムのすべての観測可能な動作は、誰かに依存されることになります。 279 | > (ハイラム・ライト) 280 | 281 | ハイラムの法則では、APIの*ユーザ数が十分に多い*場合、APIのすべての動作(公的契約の一部として定義されていないものであっても)は、最終的に誰かに依存されるようになるということを述べています。些細な例としては、APIの応答時間などの非機能要件が挙げられます。もっと微妙な例は、APIのエラーの*タイプ*を判断するために、エラーメッセージに正規表現を適用することに依存しているユーザかもしれません。API の公開契約ではメッセージの内容について何も記述されておらず、ユーザーがメッセージではなくエラーコードを使用すべきでと明示していたとしても、*一部の*ユーザーがそれを無視してメッセージを使用する可能性があり、メッセージを変更することでそのようなユーザーのための API が本質的に壊れてしまうことになります。 282 | 283 | 関連項目: 284 | 285 | - [漏れのある抽象化の法則](#漏れのある抽象化の法則) 286 | - [XKCD 1172](https://xkcd.com/1172/) 287 | 288 | ### カーニガンの法則 289 | 290 | > デバッギングはコーディングよりも2倍難しい。従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。 291 | > (ブライアン・カーニハン) 292 | 293 | カーニガンの法則は、 [ブライアンカーニハンに](https://en.wikipedia.org/wiki/Brian_Kernighan)ちなんで名付けられ、カーニハンとプラウガーの著書[「Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style) 」からの引用に基づいています。 294 | 295 | > デバッグは、そもそもプログラムを書くことの2倍大変だということは誰もが知っています。では、コードを書いた時に同じくらい賢いとしたら、どうやってデバッグするのでしょうか? 296 | 297 | 双曲線的ではありますが、カーニガンの法則は、複雑なコードで発生した問題をデバッグするのはコストがかかるか、実現不可能な場合があるため、単純なコードは複雑なコードよりも優先されるべきであるということを言っています。 298 | 299 | 関連項目: 300 | 301 | - [KISSの原則](#kissの原則) 302 | - [UNIX哲学](#unix哲学) 303 | - [オッカムのかみそり](#オッカムの剃刀) 304 | 305 | ### リーナスの法則 306 | 307 | [リーナスの法則-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) 308 | 309 | > 十分な目ん玉があれば、全てのバグは洗い出される。 310 | > 311 | > _エリック・S・レイモンド_ 312 | 313 | この法則は簡単に言うと、あるプログラムを見る人が多ければ多いほど、誰かがその問題を以前に見て解決している可能性が高くなる、あるいはそれに非常に近い状況になる、というものです。 314 | 315 | 元々はプロジェクトのオープンソースモデルの価値を説明するために使われましたが、どんなソフトウェアプロジェクトにも当てはまります。プロセスにも拡大して適用できます。より多くのコードレビューや静的解析、また多角的なテストプロセスによって、問題をより可視化されて識別しやすくなります。 316 | 317 | より格式ばって言うと以下のようになります。 318 | 319 | > ベータテスターと共同開発者が十分多くいれば、ほとんど全ての問題はすぐに明確になり、似た問題に以前遭遇したことのある人によって解決されるだろう。 320 | 321 | この法則は、エリック・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)に敬意を表して名付けられました。 322 | 323 | ### メトカーフの法則 324 | 325 | [メトカーフの法則-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) 326 | 327 | > ネットワーク理論では、システムの価値は、システムの利用者数の約2乗で成長します。 328 | 329 | この法則は、システム内で可能なペアワイズ接続の数に基づいており、 [リードの法則](#リードの法則)と密接に関連しています。オドリズコらは、リードの法則とメトカーフの法則の両方が、ネットワーク効果に関する人間の認知の限界を考慮しないことによって、システムの価値を過大評価していると主張しています。 [ダンバー数を](#ダンバー数)参照してください。 330 | 331 | 関連項目: 332 | 333 | - [リードの法則](#リードの法則) 334 | - [ダンバー数](#ダンバー数) 335 | 336 | ### ムーアの法則 337 | 338 | [ムーアの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A0%E3%83%BC%E3%82%A2%E3%81%AE%E6%B3%95%E5%89%87) 339 | 340 | > 集積回路のトランジスタ数は約2年ごとに倍増します。 341 | 342 | この法則は半導体やチップ技術の進歩の速さを示すためによく使われますが、ムーアの予測は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)があります。しかし、並列化の進歩や、半導体技術や量子コンピューティングにおける革命的な変化により、ムーアの法則が今後数十年にわたって真実であり続ける可能性があることを意味しています。 343 | 344 | ### マーフィーの法則/ソッドの法則 345 | 346 | [マーフィーの法則-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) 347 | 348 | > 何をやってもうまくいかないものはうまくいかない。 349 | 350 | [エドワード・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)に関連して、*マーフィーの法則*では、物事がうまくいかないことがあれば、それはうまくいかないだろうということが述べられています。 351 | 352 | これは開発者の間でよくある格言です。開発中、テスト中、あるいは本番中にも予期せぬことが起こることがあります。これは、 *ソッドの法則* (イギリス英語ではより一般的)にも関連しています。 353 | 354 | > 何かがうまくいかないことがあれば、最悪のタイミングでそうなる。 355 | 356 | これらの「法則」は、一般的にコミカルな意味で使われています。ただし、 [*確証バイアス*](#TODO)や[*選択バイアス*](#TODO)などの現象は、人々がこれらの法則を強調しすぎてしまう可能性があります(物事がうまくいく時の大半は、彼らは気づかれないですが、失敗は、しかし、より顕著であり、より多くの議論を生みます)。 357 | 358 | 関連項目: 359 | 360 | - [確証バイアス](#TODO) 361 | - [選択バイアス](#TODO) 362 | 363 | ### オッカムの剃刀 364 | 365 | [オッカムの剃刀-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) 366 | 367 | > エンティティは必要なくして掛け算してはいけない。 368 | > オッカムのウィリアム 369 | 370 | オッカムの剃刀は、いくつかの可能な解決策の中で、最も可能性の高い解決策は、概念と仮定の数が最も少ないものであると言います。この解は最も単純で、与えられた問題だけを解決し、偶発的な複雑さや起こりうる負の結果を導入することはありません。 371 | 372 | 関連項目: 373 | 374 | - [YAGNI](#yagni) 375 | - [銀の弾などない:偶発的な複雑さと本質的な複雑さ](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) 376 | 377 | 例: 378 | 379 | - [リーンソフトウェア開発:無駄をなくす-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) 380 | 381 | ### パーキンソンの法則 382 | 383 | [パーキンソンの法則-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) 384 | 385 | > 仕事の量は、与えられた時間を全て満たすまで膨張する。 386 | 387 | 元の文脈では、この法則は官僚機構の研究に基づいていた。この法則は、ソフトウェア開発の取り組みに悲観的に適用されるかもしれません。理論的には、チームは締め切りが近づくまで非効率的であり、その後、締め切りまでに仕事を完成させようと急ぐので、実際の締め切りはやや恣意的になるということです。 388 | 389 | この法則が[ホフスタッターの法則](#ホフスタッターの法則)と組み合わされた場合、さらに悲観的な見方が得られます。作業は、その完了に利用できる時間を埋めるために拡大し*、予想よりも長くかかり*ます。 390 | 391 | 関連項目: 392 | 393 | - [ホフスタッターの法則](#ホフスタッターの法則) 394 | 395 | ### 早すぎる最適化 396 | 397 | [最適化する時期-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) 398 | 399 | > 早すぎる最適化は諸悪の根源です。 400 | > [(ドナルドクヌース)](https://twitter.com/realdonaldknuth?lang=en) 401 | 402 | Donald Knuthの論文「 [Structured Programming With Go To Statements」で](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) 、彼は次のように書いています。「プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりして膨大な量の時間を浪費している。小さな効率性、つまり97%程度の効率性については忘れた方がいいでしょう。 **早すぎる最適化は諸悪の根源です** 。しかし、その重要な3%で機会を逃してはなりません。」 403 | 404 | しかし、 *早すぎる最適化*は(負荷の低い用語で)、必要性を知る前に最適化することと定義することができます。 405 | 406 | ### パットの法則 407 | 408 | [パットの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) 409 | 410 | > 技術は、管理しないことを理解している人と、理解していないことを管理している人の2つのタイプに支配されている。 411 | 412 | よくパットの法則にはパットの帰結が続きます。 413 | 414 | > すべての技術的な階層は、時間の経過とともに、能力の逆転を発生させます。 415 | 416 | これらの記述は、グループがどのように組織化されるかという様々な選択基準や傾向のために、技術的な組織の実務レベルには熟練した人が多く、管理職には自分が管理している仕事の複雑さや課題を認識していない人が多くいることを示唆しています。これは[、ピーター原理](#ピーターの原則)や[ディルバート原理](#ディルバートの原理)などの現象が原因である可能性があります。 417 | 418 | ただし、このような法則は広範に一般化されており、*特定*の一部の組織には適用されますが、他の組織には適用されない場合があることを強調しておく必要があります。 419 | 420 | 関連項目: 421 | 422 | - [ピーターの原則](#ピーターの原則) 423 | - [ディルバートの原理](#ディルバートの原理) 424 | 425 | ### リードの法則 426 | 427 | [リードの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Reed's_law) 428 | 429 | > 大規模ネットワーク、特にソーシャルネットワークの効用は、ネットワークの大きさに応じて指数関数的にスケーリングする。 430 | 431 | この法則はグラフ理論に基づいており、実用性は可能なサブグループの数に応じてスケールし、これは参加者の数や可能なペアワイズ接続の数よりも速くスケールします。オドリズコ氏らは、ネットワークの影響に対する人間の認識の限界を考慮しないことで、リードの法則がシステムの有用性を誇張していると主張しています。 [ダンバー数を](#ダンバー数)参照してください。 432 | 433 | 関連項目: 434 | 435 | - [メトカーフの法則](#メトカーフの法則) 436 | - [ダンバー数](#ダンバー数) 437 | 438 | ### 複雑性保存の法則(テスラーの法則) 439 | 440 | [The Law of Conservation of Complexity-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) 441 | 442 | この法則では、システムには削減できない一定の複雑さがあるとされています。 443 | 444 | システムの複雑さの中には、「不注意」なものもあります。これは、構造の不備、ミス、または解決すべき問題のモデリングの不備の結果です。不注意な複雑さは、減らすことができます(または排除することができます)。しかし、いくつかの複雑さは、解決される問題に内在する複雑さの結果として「内在的」です。この複雑さは動かすことはできますが、排除することはできません。 445 | 446 | この法則の興味深い側面は、システム全体を単純化しても、本質的な複雑さは軽減されず、より複雑な方法でシステムを動かす*ユーザーに複雑性が移される*という提案です。 447 | 448 | ### 漏れのある抽象化の法則 449 | 450 | [漏れのある抽象化の法則 Joel on Software(英語)](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 451 | 452 | > 自明でない抽象化はすべて、程度の差こそあれ、漏れがある。 453 | > ( [ジョエル・スポルスキー](https://twitter.com/spolsky) ) 454 | 455 | この法則では、複雑なシステムでの作業を簡略化するためにコンピューティングで一般的に使用される抽象化は、特定の状況では、基礎となるシステムの要素を「漏らし」、抽象化が予期しない方法で動作することになると述べています。 456 | 457 | 例としては、ファイルをロードしてその内容を読むことが挙げられます。ファイルシステム API は低レベルのカーネルシステムの *抽象化*であり、それ自体が磁気プラッター (または SSD のフラッシュメモリ) 上のデータの変更に関連する物理的なプロセスを抽象化したものです。ほとんどの場合、ファイルをバイナリデータのストリームのように扱うという抽象化が機能します。磁気ドライブの場合、データを連続的に読み込むと、ランダム・アクセスよりも(ページ・フォルトのオーバーヘッドが増加するため)*大幅に*速くなりますが、SSD ドライブの場合は、このオーバーヘッドは存在しません。この場合に対処するためには、基本的な詳細を理解する必要があります(例えば、データベースのインデックスファイルはランダムアクセスのオーバーヘッドを減らすために構造化されています)が、抽象化された実装の詳細は、開発者が注意する必要があるかもしれません。 458 | 459 | 上記の例は、より多くの抽象化が導入されると、*より*複雑になる可能性があります。Linux オペレーティングシステムでは、ネットワーク経由でファイルにアクセスすることができますが、ローカルでは「通常の」ファイルとして表現されます。この抽象化は、ネットワーク障害が発生した場合に「漏れ」ます。開発者がこれらのファイルをネットワークの遅延や障害の影響を受ける可能性があることを考慮せずに「通常の」ファイルとして扱ってしまうと、解決策がバグだらけになってしまいます。 460 | 461 | この法則を説明している記事によると、抽象化への過度の依存は、基礎となるプロセスの理解不足と相まって、実際には手元にある問題への対処を、場合によっては*より*複雑なものにしてしまうことが示唆されています。 462 | 463 | 関連項目: 464 | 465 | - [ハイラムの法則](#ハイラムの法則暗黙のインターフェースの法則) 466 | 467 | 実際の例: 468 | 469 | - [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - 過去に遭遇した問題 Photoshopの起動が遅く、数分かかることもありました。問題は、起動時に現在のデフォルトプリンタに関する情報を読み取ることだったようです。しかし、そのプリンタが実際にネットワークプリンタである場合、これは非常に長い時間がかかる可能性があります。ネットワークプリンタがローカルプリンタと同様に*抽象化*してしまったことにより接続時間の問題を引き起こしました。 470 | 471 | ### パーキンソンの凡俗法則 472 | 473 | [パーキンソンの凡俗法則-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) 474 | 475 | この法則は、グループが深刻で実質的なものよりも、些細な問題や表面上の問題にはるかに多くの時間と注意力を注ぐことを示唆しています。 476 | 477 | よくある架空の例は、原子力発電所の計画を承認する委員会の例であり、彼らは発電所自体のはるかに重要な設計よりも、自転車小屋の構造について議論することに時間の大半を費やしている。非常に大きく複雑なテーマについての議論では、高度な専門知識や準備がなければ、意味のあるな意見を述べることは難しいかもしれません。しかし、人々は意味のある意見を発言していると見られたいと思う傾向があり、そのため、簡単に推論できるが、必ずしも特別な重要性があるわけではないような些細なことに時間を集中させてしまう傾向がある。 478 | 479 | 上記の架空の例では、些細な細部に時間を浪費するための表現として「自転車シェディング」という用語を使用しました。関連用語は「 [ヤクシェービング](https://ja.wiktionary.org/wiki/yak_shaving) 」です。これは、メインタスクの前提条件の長い連鎖の一部である、一見無関係な活動を意味します。 480 | 481 | ### UNIX哲学 482 | 483 | [UNIX哲学-Wikipedia](https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6) 484 | 485 | UNIX理念は、ソフトウェアの構成要素は小さく、一つの特定のことをうまく行うことに集中すべきであるというものです。これは、大規模で複雑な多目的プログラムを使うのではなく、小さくてシンプルで、よく定義されたユニットを組み合わせてシステムを構築することを容易にすることができます。 486 | 487 | 現代における「マイクロサービス・アーキテクチャ」は、この法則の応用と考えることができ、サービスは小さく、焦点を絞って、特定の一つのことをしっかりと行うことで、複雑な動作をシンプルなビルディングブロックで構成することを可能にしています。 488 | 489 | ### Spotifyモデル 490 | 491 | [Spotifyモデル-Spotify Labs(英語)](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) 492 | 493 | Spotifyモデルとは、「Spotify」によって普及したチームと組織構造へのアプローチです。このモデルでは、チームはテクノロジーではなく機能を中心に組織されています。 494 | 495 | また、Spotify モデルでは、組織構造の他の要素である部族、ギルド、チャプターの概念も普及しています。 496 | 497 | ### ワドラーの法則 498 | 499 | [ワドラーの法則-wiki.haskell.org(英語)](https://wiki.haskell.org/Wadler's_Law) 500 | 501 | > どのような言語設計においても、このリストの特徴を議論するのに費やされた時間の合計は、その位置の累乗に2を上げることに比例します。 502 | > 1. 意味論 503 | > 2. 構文 504 | > 3. 字句構文 505 | > 4. コメントの字句構文 506 | > (要するに、意味論に1時間使うとすると、8時間はコメントの構文に費やされます)。 507 | 508 | 同様に[パーキンソンの凡俗法則](#パーキンソンの凡俗法則) 、和ドラーの法則は、言語を設計する際に、言語構造の重要性に比べて、言語構造に費やされる時間が不釣り合いに多いということが述べられています。 509 | 510 | 関連項目: 511 | 512 | - [パーキンソンの凡俗法則](#パーキンソンの凡俗法則) 513 | 514 | ### ウィートンの法則 515 | 516 | [リンク(英語)](http://www.wheatonslaw.com/) 517 | 518 | [公式日(英語)](https://dontbeadickday.com/) 519 | 520 | > 嫌な奴になるな 521 | > *ウィル・ウィートン* 522 | 523 | ウィル・ウィートン(スタートレック:ネクスト・ジェネレーション、ビッグバン・セオリー)によって考案されたこのシンプルで簡潔で強力な法則は、専門的な組織内での調和と尊敬を高めることを目的としています。同僚との会話、コードレビューの実行、他の視点からの反論、批評、そして一般的に、ほとんどのプロフェッショナルな人間関係に適用することができます。 524 | 525 | ## 原則 526 | 527 | 一般に、原則は設計に関するガイドラインである可能性が高くなります。 528 | 529 | ### ディルバートの原理 530 | 531 | [ディルバートの法則-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) 532 | 533 | > 企業は、事業への損害を最小限にとどめるために、系統立てて無能な者から管理職に昇進させて行く傾向がある 534 | > *スコットアダムス* 535 | 536 | スコット・アダムス(漫画「ディルバート」の作者)が開発した経営概念で、ディルバート原則は[、ピーター原則に](#ピーターの原則)触発されています。ディルバートの原則では、有能でない社員を管理職に昇格させることで、事業への損害を最小限にとどめる。 Adamsは、1995年のウォールストリートジャーナルの記事でこの原則を最初に説明し、1996年のビジネスブック、 [The Dilbert Principleで](#関連書籍)それを拡張しました。 537 | 538 | 関連項目: 539 | 540 | - [ピーターの原則](#ピーターの原則) 541 | - [パットの法則](#パットの法則) 542 | 543 | ### パレート原理(80/20ルール) 544 | 545 | [パレートの法則-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) 546 | 547 | > 人生のほとんどのものが均等に分配されていません。 548 | 549 | パレートの原理は、いくつかのケースでは、結果の大部分は少数の入力から来ることを示唆している。 550 | 551 | - 特定のソフトウェアの80%は、割り当てられた合計時間の20%で実装できます(逆に、コードの最も難しい20%部分を実装するのに時80%の時間がかかります) 552 | - 2割の努力は8割の結果を生む 553 | - 2割の仕事が8割の収益を生み出す 554 | - 20%のバグが80%のクラッシュを引き起こす 555 | - 20%の機能が80%の使用率を引き起こす 556 | 557 | 1940年代には、品質管理の父と広く信じられているアメリカ・ルーマニアのエンジニア、ジョセフ・ジュラン博士が[、パレートの原則を品質問題に適用し始めました](https://en.wikipedia.org/wiki/Joseph_M._Juran) 。 558 | 559 | この原則は、次のようにも知られています。80/20ルール、バイタル・フューの法則、ファクター・スパーシティの原理。 560 | 561 | 実際の例: 562 | 563 | - 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) )。 564 | 565 | ### ピーターの原則 566 | 567 | [ピーターの法則-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) 568 | 569 | > 階層社会では、人間は能力の極限まで出世する。 570 | > *ローレンス・J・ピーター* 571 | 572 | ローレンス・J・ピーターによって開発された経営概念で、ピーターの原則は、仕事が得意な人は、もはや成功しないレベル(彼らの「無能のレベル」)に達するまで、昇進すると観察しています。この時点では、彼らはより熟練であるため、組織から外される可能性は低く、彼らを成功に導いた元々のスキルが必ずしも新しい仕事に必要なスキルであるとは限らないため、彼らが本来持っているスキルがほとんどない役割に留まり続けることになります。 573 | 574 | これは、最初はエンジニアとしてキャリアをスタートさせ、他のエンジニアの*管理に*つながるキャリアパスを描いているエンジニアにとって、特に興味深いものです。管理職には、根本的にエンジニアとは異なるスキルセットが必要です。 575 | 576 | 関連項目: 577 | 578 | - [ディルバートの原理](#ディルバートの原理) 579 | - [パットの法則](#パットの法則) 580 | 581 | ### 堅牢性の原則(ポステルの法則) 582 | 583 | [堅牢性の原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Robustness_principle) 584 | 585 | > 自分のやることは慎重に、他人から受け入れるときは自由に。 586 | 587 | サーバーアプリケーションの開発によく適用されるこの原則は、他のシステムに送るものは可能な限り最小限にして、適合性のあるものにすべきであるが、処理できる場合には、適合性のない入力を許容することを目指すべきである、ということを述べています。 588 | 589 | この原則の目標は、ハンドルできる場合には、不適合な入力を処理できるので、堅牢なシステムを構築することです。しかし、特にそのような入力の処理が十分にテストされていない場合には、不適合な入力を受け入れることにはセキュリティ上の問題がある可能性があります。 590 | 591 | 不適合な入力を許可すると、実装者が最終的にこの自由に依存して機能を構築するようになるため、プロトコルが進化する可能性が損なわれる場合があります。 592 | 593 | 関連項目: 594 | 595 | - [ハイラムの法則](#ハイラムの法則暗黙のインターフェースの法則) 596 | 597 | ### SOLID 598 | 599 | これは以下を指す頭字語です。 600 | 601 | - S: [単一責任の原則](#単一責任の原則) 602 | - O: [開放/閉鎖原則](#開放閉鎖原則) 603 | - L: [リスコフ代替原則](#リスコフの置換原則) 604 | - I: [インターフェース分離の原則](#インターフェース分離の原則) 605 | - D: [依存関係の逆転の原則](#依存性逆転の原則) 606 | 607 | これらは、 [オブジェクト指向プログラミングの](#todo)主要な原則です。このような設計原則は、開発者が保守しやすいシステムを構築するのに役立つはずです。 608 | 609 | ### 単一責任の原則 610 | 611 | [単一責任原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Single_responsibility_principle) 612 | 613 | > すべてのモジュールやクラスは、単一の責任のみを持つべきです。 614 | 615 | 「 [SOLID](#solid) 」第一原則。この原則は、モジュールやクラスは一つのことを一つのことだけを行うべきだということを提案しています。より実用的な用語では、これはプログラムの機能への単一の小さな変更は、1つのコンポーネントのみの変更を必要とすることを意味します。例えば、パスワードの複雑さを検証する方法を変更するには、プログラムの一部分だけを変更する必要があります。 616 | 617 | 理論的には、これによりコードがより堅牢になり、変更が容易になるはずです。変更されるコンポーネントが単一の責任を持っていることを知ることは、その変更の*テスト*がより簡単になることを意味します。先ほどの例を使うと、パスワードの複雑さのコンポーネントを変更することは、パスワードの複雑さに関連する機能にのみ影響を与えることができるはずです。多くの責任を持つコンポーネントへの変更の影響を推論することは、はるかに難しいでしょう。 618 | 619 | 関連項目: 620 | 621 | - [オブジェクト指向プログラミング](#todo) 622 | - [SOLID](#solid) 623 | 624 | ### 開放/閉鎖原則 625 | 626 | [開放/閉鎖原則-Wikipedia](https://ja.wikipedia.org/wiki/%E9%96%8B%E6%94%BE/%E9%96%89%E9%8E%96%E5%8E%9F%E5%89%87) 627 | 628 | > エンティティは拡張のために開かれ、修正のために閉じられるべきです。 629 | 630 | 「 [SOLID](#solid) 」第二原則。この原則では、エンティティー(クラス、モジュール、関数など)は動作を*拡張*することができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。 631 | 632 | 仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。モジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。 633 | 634 | この原則は、オブジェクト指向プログラミングに特に関連しています。簡単に拡張するオブジェクトを設計するかもしれませんが、予期しない方法で変更された既存の動作を持つことができるオブジェクトを設計することを避けます。 635 | 636 | 関連項目: 637 | 638 | - [オブジェクト指向プログラミング](#todo) 639 | - [SOLID](#solid) 640 | 641 | ### リスコフの置換原則 642 | 643 | [リスコフの置換原則-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) 644 | 645 | > システムを壊すことなく、タイプをサブタイプに置き換えることができるはずです。 646 | 647 | 「 [SOLID](#solid) 」原則の3番目。この原則は、コンポーネントがタイプに依存している場合、システムに障害が発生したり、そのサブタイプが何であるかの詳細を知る必要なく、そのタイプのサブタイプを使用できるはずであると述べています。 648 | 649 | 例として、ファイルを表す構造からXMLドキュメントを読み取るメソッドがあるとします。メソッドが基本タイプ「ファイル」を使用する場合、「ファイル」から派生するものはすべて関数で使用できるはずです。 「ファイル」が逆方向のシークをサポートし、XMLパーサーがその関数を使用するが、逆型シークが試行されたときに派生型「ネットワークファイル」が失敗する場合、「ネットワークファイル」は原則に違反しています。 650 | 651 | この原則は、オブジェクト指向プログラミングに特に関連しています。システムのユーザーを混乱させないように、型階層を注意深くモデル化する必要があります。 652 | 653 | 関連項目: 654 | 655 | - [オブジェクト指向プログラミング](#todo) 656 | - [SOLID](#solid) 657 | 658 | ### インターフェース分離の原則 659 | 660 | [インターフェース分離原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Interface_segregation_principle) 661 | 662 | > 使用しないメソッドに依存することを強制されるクライアントはありません。 663 | 664 | 「 [SOLID](#solid) 」原則の4番目。この原則は、コンポーネントのコンシューマーが、実際に使用しないコンポーネントの機能に依存すべきではないと述べています。 665 | 666 | 例として、ファイルを表す構造体からXML文書を読み込むメソッドがあるとします。このメソッドが必要とするのは、ファイル内のバイトを読み込んだり、前に移動したり、後ろに移動したりすることだけです。ファイル構造体の無関係な機能が変更されたためにこのメソッドを更新する必要がある場合(ファイルのセキュリティを表現するために使用されるパーミッションモデルの更新など)、その原則は無効になっています。ファイルは「シーク可能なストリーム」インターフェースを実装し、XMLリーダーはそれを使用する方が良いでしょう 667 | 668 | この原則はオブジェクト指向プログラミングに特に関連性があり、インターフェイス、階層構造、抽象型が異なるコンポーネント間の結合を[最小限](#todo)にするために使用されます。[ダックタイピング](#todo)は、明示的なインターフェースを排除することでこの原則を強制する方法論です。 669 | 670 | 関連項目: 671 | 672 | - [オブジェクト指向プログラミング](#todo) 673 | - [SOLID](#solid) 674 | - [ダックタイピング](#todo) 675 | - [デカップリング](#todo) 676 | 677 | ### 依存性逆転の原則 678 | 679 | [依存性逆転の原則-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) 680 | 681 | > 高レベルのモジュールは、低レベルの実装に依存すべきではありません。 682 | 683 | 「 [SOLID](#solid) 」原則の5番目。この原則は、より高いレベルのオーケストレーションコンポーネントは、依存関係の詳細を知っている必要はないことを述べています。 684 | 685 | 例として、ウェブサイトからメタデータを読み取るプログラムがあるとします。メインコンポーネントは、ウェブページのコンテンツをダウンロードするためのコンポーネントについて知る必要があり、メタデータを読み取ることができるコンポーネントであると想定します。依存関係の逆転を考慮すると、メインコンポーネントは、バイトデータをフェッチできる抽象コンポーネントと、バイトストリームからメタデータを読み取ることができる抽象コンポーネントのみに依存します。メインコンポーネントは、TCP / IP、HTTP、HTMLなどについては認識しません。 686 | 687 | この原則は複雑です。システムの予想される依存関係(したがって、名前)を「逆転」するように見える場合があるためです。実際には、別のオーケストレーションコンポーネントが抽象型の正しい実装が使用されていることを確認する必要があることも意味します(たとえば、前の例では、 *何か*がメタデータリーダーコンポーネントにHTTPファイルダウンローダーとHTMLメタタグリーダーを提供する必要があります)。次に、 [Inversion of Control](#todo)や[Dependency Injection](#todo)などのパターンに触れます。 688 | 689 | 関連項目: 690 | 691 | - [オブジェクト指向プログラミング](#todo) 692 | - [SOLID](#solid) 693 | - [制御の反転](#todo) 694 | - [依存性注入](#todo) 695 | 696 | ### DRY原則 697 | 698 | [Don't repeat yourself-Wikipedia](https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself) 699 | 700 | > すべての知識は、システム内で単一の明確で信頼できる表現を持つ必要があります。 701 | 702 | DRYは、 *Do n't Repeat Yourselfの*頭字語です。この原則は、開発者がコードの繰り返しを減らして情報を1か所に保管できるようにすることを目的としており、1999年にAndrew HuntとDave Thomasが 『 [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) 』で引用しています。 703 | 704 | > DRYの反対は*WET* (すべてを2回書き込むか、タイピングを楽しむ)です。 705 | 706 | 実際には、2つ(またはそれ以上)の異なる場所に同じ情報がある場合、DRYを使用してそれらを1つの場所にマージし、必要な場所で必要に応じて再利用できます。 707 | 708 | 関連項目 709 | 710 | - [実用的な開発者(英語)](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) 711 | 712 | ### KISSの原則 713 | 714 | [KISSの原則-Wikipedia](https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87) 715 | 716 | > 簡潔に単純にしておけ 717 | 718 | KISSの原則は、ほとんどのシステムは複雑にするのではなく、シンプルに保つことが最もよく機能するというもので、シンプルさは設計の重要な目標であり、不必要な複雑さは避けるべきだというものです。 1960年にアメリカ海軍で始まったこのフレーズは、航空機エンジニアのケリー・ジョンソンに関連しています。 719 | 720 | この原則は、ジョンソンが設計エンジニアのチームに一握りの工具を渡し、設計しているジェット機は、現場の平均的な整備士がこれらの工具だけで戦闘状況下で修理可能なものでなければならないという課題を与えたという話に最もよく例示されています。したがって、「バカ」とは、技術者自身の能力ではなく、物の壊れ方と、それを修理するために利用できる道具の巧妙さの関係を指しています。 721 | 722 | 関連項目: 723 | 724 | - [ゴールの法則](#ゴールの法則) 725 | 726 | ### YAGNI 727 | 728 | [YAGNI-Wikipedia](https://ja.wikipedia.org/wiki/YAGNI) 729 | 730 | ***Y**ou **A**in't **G**onna **N**eed **I**t*"縮めて YAGNI 731 | 732 | > 実際にそれらが必要なときに常に実装し、必要があると予測しただけでは決して実装しないでください。 733 | > ( [Ron Jeffries](https://twitter.com/RonJeffries) )(XPの共同創設者であり、「Extreme Programming Installed」という本の著者) 734 | 735 | この*エクストリームプログラミング* (XP)の原則は、開発者は当面の要件に必要な機能のみを実装し、後で必要になる可能性のある機能を実装して将来を予測しようとする試みを避けることを示唆しています。 736 | 737 | この原則を順守することで、コードベース内の未使用のコードの量を減らし、価値のない機能に時間と労力が浪費されるのを防ぐことができます。 738 | 739 | 関連項目 740 | 741 | - [関連書籍:インストールされているExtremeプログラミング](#関連書籍) 742 | 743 | ### 分散コンピューティングの落とし穴 744 | 745 | [分散コンピューティングの落とし穴-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) 746 | 747 | 「*ネットワークコンピューティングの落とし穴*」としても知られているこの落とし穴は、ソフトウェア開発の失敗につながる可能性のある、分散コンピューティングに関する思い込み(または信念)のリストです。仮定は以下の通りです。 748 | 749 | - ネットワークは信頼できる 750 | - 待ち時間はゼロです 751 | - 帯域幅は無限です 752 | - ネットワークは安全です 753 | - トポロジーは変わらない 754 | - 管理者が一人だけいます 755 | - トランスポートコストはゼロ 756 | - ネットワークは均一です 757 | 758 | 最初の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番目の誤りを追加しました。 759 | 760 | このグループは、 [Sun Microsystemsの](https://en.wikipedia.org/wiki/Sun_Microsystems)内部で当時何が起こっていたかに触発されました。 761 | 762 | これらの誤りは、弾力性のあるコードを設計するときに注意深く検討する必要があります。これらの誤りのいずれかが、分散システムの現実と複雑さに対処できない欠陥のあるロジックにつながる可能性があると仮定します。 763 | 764 | 関連項目: 765 | 766 | - [分散コンピューティングの落とし穴の採餌(パート1)-Vaidehi Joshi 767 | 中(英語)](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53) 768 | - [Deutsch's Fallacies、10年後(英語)](http://java.sys-con.com/node/38665) 769 | 770 | ## 関連書籍: 771 | 772 | もっと興味を感じたなら、以下の本を参照してください。 773 | 774 | - [インストールされているエクストリームプログラミング-ロンジェフリーズ、アンアンダーソン、チェットヘンドリクソン](https://www.goodreads.com/en/book/show/67834) -エクストリームプログラミングのコア原則をカバーしています。 775 | - [The Mythical Man Month-フレデリックP.ブルックスJr.-](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month)ソフトウェアエンジニアリングに関する古典的な巻。 [ブルックスの法則](#ブルックスの法則)は本の中心的なテーマです。 776 | - [ゲーデル、エッシャー、バッハ:永遠のゴールデンブレイド-ダグラスR.ホフスタッター。](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) -この本は分類するのが難しいです。 [ホフスタッターの法則](#ホフスタッターの法則)は本からです。 777 | - [ディルバートの原則-スコットアダムス](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - [ディルバートの原則](#ディルバートの原理)を作成した作者によるアメリカの企業の漫画の外観。 778 | - [ピーター原則-ローレンスJ.ピーター](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - [ピーター原則の](#ピーターの原則)出典である、より大きな組織と人々の管理の課題に関する別の漫画の見方。 779 | 780 | ## 翻訳 781 | 782 | 多くの素晴らしい投稿者のおかげで、ハッカーの法則は多くの言語で利用可能です。モデレーターのスポンサーもご検討ください。 783 | 784 | 言語 | モデレータ | ステータス 785 | --- | --- | --- 786 | [🇧🇷 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) 787 | [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partially complete 788 | [🇩🇪 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) 789 | [🇫🇷 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) 790 | [🇬🇷 ελληνικά / 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) 791 | [🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partially complete 792 | [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partially complete 793 | [🇱🇻 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) 794 | [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partially complete 795 | [🇪🇸 Castellano / Spanish](../translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partially complete 796 | [🇹🇷 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) 797 | | [JP 日本語 / Japanese](../translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)|Partially complete | 798 | 799 | 翻訳を更新したい場合は、 [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls)するだけです。新しい言語を追加したい場合は、 [GitLocalize](https://gitlocalize.com/) にログインしてアカウントを作成し、言語の管理を依頼するためのissueを開いてください。また、上の表とファイルの先頭にあるリンクを更新するプルリクエストを開いていただけると、とても助かります。 800 | 801 | ## 関連プロジェクト 802 | 803 | - [今日のヒント(英語)](https://tips.darekkay.com/html/hacker-laws-en.html) -毎日ハッカーの法則/原則の更新を知ることができます。 804 | - [ハッカーの法則コマンド](https://github.com/umutphp/hacker-laws-cli)あなたの端末上でランダムな法則を一覧表示、表示、確認できます。 805 | 806 | ## 貢献方法 807 | 808 | 貢献してください! 追加や変更を提案したい場合は [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new)、変更を提案したい場合は [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) をご利用ください。 809 | 810 | 文章やスタイルなどの要件については、[Contributing Guidelines](./.github/contributing.md) を必ずお読みください。プロジェクトの議論に参加する際には、[Code of Conduct](./.github/CODE_OF_CONDUCT.md)を意識してください。 811 | 812 | ## TODO 813 | 814 | こんにちは!あなたがここに来たということは、私がまだ書き上げていないトピックへのリンクをクリックしたことにですね。 815 | 816 | リクエストしたい場合は [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) をクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。 817 | --------------------------------------------------------------------------------