├── .github ├── CODE_OF_CONDUCT.md ├── contributing.md └── pull_request_template.md ├── .gitignore ├── CONTRIBUTORS.md ├── LICENSE ├── README.md ├── assets ├── banner.png ├── banner.psd ├── diagrams.bmpr └── repository-open-graph-template.png └── images ├── amdahls_law.png ├── gartner_hype_cycle.png └── spotify_model.jpg /.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/contributing.md: -------------------------------------------------------------------------------- 1 | # Contributing Guidelines 2 | 3 | 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: 4 | 5 | 1. Short - one or two paragraphs. 6 | 2. Include the original source. 7 | 3. Quote the law if possible, with the author's name. 8 | 4. Link to related laws in the 'See also' section. 9 | 5. Include real-world examples if possible in the 'Real-world examples' section. 10 | 11 | Some other tips: 12 | 13 | - It is fine to include laws which are humorous or not serious. 14 | - If a law does not obviously apply to development or coding, include a paragraph explaining the relevance to technologists. 15 | - Don't worry about managing the table of contents, I can generate it. 16 | - Feel free to include images, but aim to keep it down to one image per law. 17 | - Be careful not to copy-and-paste content (unless it is explicitly quoted), as it might violate copyright. 18 | - Include hyperlinks to referenced material. 19 | - 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. 20 | 21 | An example law is shown below, which covers most of the key points: 22 | 23 | --- 24 | 25 | ### The Law of Leaky Abstractions 26 | 27 | [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 28 | 29 | > All non-trivial abstractions, to some degree, are leaky. 30 | > 31 | > (Joel Spolsky) 32 | 33 | 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. 34 | 35 | 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. 36 | 37 | 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. 38 | 39 | 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. 40 | 41 | See also: 42 | 43 | - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces) 44 | 45 | Real-world examples: 46 | 47 | - [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. 48 | -------------------------------------------------------------------------------- /.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](./.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 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /CONTRIBUTORS.md: -------------------------------------------------------------------------------- 1 | - [rheh](https://github.com/rheh) - Suggestion - Brooks's Law 2 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018 Dave Kerr 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 💻📖 hacker-laws 2 | 3 | **개발자에게 유용한 법칙, 이론, 원칙, 그리고 패턴들** 4 | 5 |
6 | 7 | 8 | 9 | * [서론](#서론) 10 | 11 | * [법칙](#법칙) 12 | * [암달의 법칙](#암달의-법칙) 13 | * [깨진 유리창 이론](#깨진-유리창-이론) 14 | * [브룩스의 법칙](#브룩스의-법칙) 15 | * [콘웨이의 법칙](#콘웨이의-법칙) 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 | * [원칙](#원칙) 43 | * [딜버트의 법칙](#딜버트의-법칙) 44 | * [파레토의 원리 (80 : 20의 법칙)](#파레토의-원리-80--20의-법칙) 45 | * [피터의 원리](#피터의-원리) 46 | * [견고함의 원칙 (포스텔의 법칙)](#견고함의-원칙-포스텔의-법칙) 47 | * [솔리드](#솔리드) 48 | * [단일 책임 원칙](#단일-책임-원칙) 49 | * [개방-폐쇄 원칙](#개방-폐쇄-원칙) 50 | * [리스코프 치환 원칙](#리스코프-치환-원칙) 51 | * [인터페이스 분리 원칙](#인터페이스-분리-원칙) 52 | * [의존 관계 역전 원칙](#의존-관계-역전-원칙) 53 | * [DRY 원칙](#dry-원칙) 54 | * [KISS 원칙](#kiss-원칙) 55 | * [YAGNI](#yagni) 56 | * [분산 컴퓨팅의 오류](#분산-컴퓨팅의-오류) 57 | 58 | * [추천 도서](#추천-도서) 59 | 60 | * [TODO](#todo) 61 | 62 | 63 | 64 |
65 | 66 | ## 서론 67 | 68 | 개발을 이야기할 때 흔히 논하는 법칙들이 있습니다. 이 저장소는 그 중 가장 보편적인 것들에 대한 참조와 개요입니다. 공유와 PR 제출 부탁드려요! 69 | 70 | ❗: 이 저장소는 여러 법칙, 원칙, 그리고 패턴에 관한 설명을 포함하고 있지만, 그 중 어떤 것도 _지지_ 하고 있지 않습니다. 그것들을 적용하여야 할지에 말지에 대해서는 언제나 논의의 여지가 있으며, 또한 당신이 어떤 작업을 하느냐에 따라서도 크게 달라집니다. 71 | 72 |
73 | 74 | _(이 글은 https://github.com/dwmkerr/hacker-laws 의 번역입니다.)_ 75 | 76 |
77 | 78 | ## 법칙 79 | 80 | ### 암달의 법칙 81 | 82 | [위키피디아의 암달의 법칙](https://ko.wikipedia.org/wiki/암달의_법칙) 83 | 84 | > 암달의 법칙은 시스템에 리소스를 추가함으로써 얻을 수 있는 컴퓨터 작업 성능 향상의 최대 폭을 나타내주는 공식이다. 일반적으로 병렬 컴퓨팅에서 이를 이용하여, 프로세서 개수의 증가가 프로그램 자체의 구조적인 병렬화 제한에 맞서 실제적으로 가져다주는 이득을 예측할 수 있다. 85 | 86 | 예시를 살펴보자. 어떠한 프로그램이 단일 프로세서로 구동되어야 하는 부분 A와 병렬화될 수 있는 부분 B로 이루어져있다고 할 때, 우리는 프로세서의 추가적인 투입이 제한된 이득만을 가져다줌을 알 수 있다. B 부분의 성능을 크게 향상시킬 수 있지만, A 부분의 속도는 그대로 남을 것이기 때문이다. 87 | 88 | 아래의 그래프는 성능 향상 가능성의 예시를 보여준다. 89 | 90 | ![Diagram: Amdahl's Law](./images/amdahls_law.png) 91 | 92 | *(이미지 출처: Daniels220 @영어 Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* 93 | 94 |
95 | 96 | 보다시피 50%나 병렬화 가능한 프로그램임에도 10개 프로세서 이후에는 거의 이득이 없는 반면, 95% 병렬화 가능한 프로그램은 수천 개가 추가될 때까지도 유의미한 성능 향상을 보여주고 있다. 97 | 98 | [무어의 법칙](#무어의-법칙)과 개별 프로세서의 성능 증가 속도가 완화되면서, 병렬화는 최적화의 핵심이 되었다. 그래픽스 프로그래밍이 이에 대한 가장 알맞은 예시이다. 셰이더 기반의 최신 컴퓨팅에서는 개별 픽셀 혹은 프래그먼트를 병렬로 렌더링할 수 있는데, 이것이 최신 그래픽 카드들이 대개 수천 개의 코어(GPU 또는 셰이더 유닛)로 구성된 이유이다. 99 | 100 |
101 | 102 | 참고 : 103 | 104 | - [브룩스의 법칙](#브룩스의-법칙) 105 | - [무어의 법칙](#무어의-법칙) 106 | 107 |
108 | 109 | ### 깨진 유리창 이론 110 | 111 | [위키피디아의 깨진 유리창 이론](https://ko.wikipedia.org/wiki/깨진_유리창_이론) 112 | 113 | 깨진 유리창 이론에 따르면, 눈에 띠는 범죄의 흔적 혹은 환경에 대한 소홀함은 더욱 심각한 범죄와 시설의 감가로 이어진다. 114 | 115 | 이 이론을 소프트웨어 개발에 적용해보면, 질 낮은 코드(혹은 [기술 부채](#TODO))는 품질을 향상하려는 노력이 무시되거나 평가절하된다는 인식을 줄 수 있게 되고, 결국 더욱 조악한 품질의 코드를 낳게 된다. 이 효과가 퍼지며 시간이 지남에 따라 더욱 큰 질적 저하가 나타나게 된다. 116 | 117 |
118 | 119 | 참고 : 120 | 121 | - [기술 부채](#TODO) 122 | 123 |
124 | 125 | 예시 : 126 | 127 | - [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy) 128 | - [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/) 129 | - [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/) 130 | 131 |
132 | 133 | ### 브룩스의 법칙 134 | 135 | [위키피디아의 브룩스의 법칙](https://ko.wikipedia.org/wiki/브룩스의_법칙) 136 | 137 | > 지체되는 소프트웨어 개발 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다. 138 | 139 | 이 법칙은 이미 늦어지고 있는 소프트웨어 개발을 빨리하기 위해 사람을 더 투입하는 것은 도리어 완성을 늦출 뿐이라고 말한다. 브룩스는 이것은 비록 극도로 단순화한 이야기임을 분명히 했으나, 다만 일반적으로 보았을 때 자원 투입 시간과 의사소통 비용으로 인해 단기적으로 속도가 줄어들 수 있다고 하였다. 또한 많은 작업들은 분할할 수 없기 때문에, 즉 인력이 늘어난다고 하여 쉽게 분배할 수 없기 때문에, 기대할 수 있는 속도 증가 역시 낮다. 140 | 141 | 흔히 말하는 "임산부 9명이 모여도 아기를 한 달만에 낳을 수는 없다"는 구절은 브룩스의 법칙 중에서도, 특정 작업은 나누거나 병렬화할 수 없음을 비유적으로 뜻한다. 142 | 143 | 이것은 그의 저서 '[맨먼스 미신](#추천-도서)'의 주요한 주제이다. 144 | 145 |
146 | 147 | 참고 : 148 | 149 | - [Death March](#todo) 150 | - [추천 도서 : 맨먼스 미신](#추천-도서) 151 | 152 |
153 | 154 | ### 콘웨이의 법칙 155 | 156 | [Conway's Law on Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law) 157 | 158 | 이 법칙에 따르면 시스템의 구조는 설계하는 조직의 구조를 반영한다. 이것은 조직 개선을 시도할 때 종종 인용되고는 하는데, 가령 조직이 여러 개의 작고 끊어진 단위로 구성되어 있다면 거기에서 나온 소프트웨어 또한 그 모습을 닮는다고 한다. 또한 만약 조직이 기능과 서비스를 중심으로 수직적으로 짜여 있다면, 이 역시 소프트웨어가 이러한 모습을 반영할 것이란 것이다. 159 | 160 |
참고 : 161 | 162 | - [스포티파이 모델](#스포티파이-모델) 163 | 164 |
165 | 166 | ### 커닝햄의 법칙 167 | 168 | [Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law) 169 | 170 | > 인터넷에서 올바른 답을 얻기 위한 가장 좋은 방법은 질문을 하는 것이 아니라, 잘못된 답변을 올리는 것이다. 171 | 172 | 스티븐 맥기디에 따르면, 와드 커닝햄은 1980년대 초에 그에게 이런 조언을 해주었다 : '인터넷에서 올바른 답을 얻기 위한 가장 좋은 방법은 질문을 하는 것이 아니라, 잘못된 답변을 올리는 것이다'. 맥기디는 이것을 커닝햄의 법칙이라 이름 붙였지만, 정작 본인은 이를 잘못된 인용이라며 부정하였다. 원래는 유즈넷에 관한 이야기였지만 이 법칙은 다른 온라인 커뮤니티들이 어떻게 작용하는지를 설명하는 데에도 쓰이게 되었다(예시 : 위키피디아, 레딧, 트위터, 페이스북). 173 | 174 |
175 | 176 | 참고 : 177 | 178 | - [XKCD 386: "Duty Calls"](https://xkcd.com/386/) 179 | 180 |
181 | 182 | ### 던바의 숫자 183 | 184 | [위키피디아의 던바의 숫자](https://ko.wikipedia.org/wiki/던바의_숫자) 185 | 186 | "던바의 숫자는 한 사람이 안정적인 사회적 관계(한 개인이 다른 이들에 대하여 누가 누군지 잘 알며 그들 사이의 관계도 파악할 수 있는 관계)를 유지할 수 있는 인지적 최대치로서 제시된 수이다." 정확한 수치에 대해서는 의견이 분분하다. "…(던바는) 인간은 오직 150명까지의 안정적인 관계만을 편안히 유지할 수 있다"고 주장하였다. 그는 좀 더 사회적인 맥락에서 말하길, "바에서 우연히 만났을 때 어색하지 않게 같이 술을 마실 수 있는 사람의 수"라고 하였다. 일반적으로 100에서 250 사이라고 추정한다. 187 | 188 | 개개인 간의 안정적인 관계처럼, 개발자와 코드베이스의 관계도 유지하려면 노력이 든다. 크고 복잡한 프로젝트 혹은 여러 프로젝트를 마주할 때, 우리는 규모를 확장하기 위해 관례, 정책, 그리고 만들어진 절차를 따른다. 던바의 숫자는 사무실이 커질 때만 염두해둘 것이 아니라 팀이 들일 노력의 범위를 얼마나로 할지, 언제 모델링과 계획 자동화 툴에 투자할지 등을 정하는 데에도 중요하다. 엔지니어링 측면에서 보면, 이 숫자는 당직(On-call : 시스템 장애 발생을 대비하여 대기함)으로 설 수 있는 프로젝트의 수이다. 189 | 190 |
191 | 192 | 참고 : 193 | 194 | - [콘웨이의 법칙](#콘웨이의-법칙) 195 | 196 |
197 | 198 | ### 갈의 법칙 199 | 200 | [Gall's Law on Wikipedia](https://en.m.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) 201 | 202 | > 잘 작동하는 복잡한 체계는 항상 잘 작동하던 간단한 체계에서 발전한다. 처음부터 복잡하게 설계된 체계는 절대로 작동하지 않으며 잘 돌아가도록 만들 수도 없다. 언제나 작동하는 간단한 시스템에서 출발해야 한다. 203 | > 204 | > ([존 갈](https://en.m.wikipedia.org/wiki/John_Gall_(author))) 205 | 206 | 갈의 법칙은 고도로 복잡한 시스템을 _설계_ 하려는 시도는 대개 실패함 암시한다. 고도로 복잡한 체계는 하루아침에 이루어진 것이 아니라, 더 간단한 체계로부터 진화한 것이다. 207 | 208 | 고전적인 예시는 월드 와이드 웹이다. 현재의 웹의 상태는 굉장히 복잡하다. 그러나 처음에는 그저 학술 기관 간의 간편한 컨텐트 공유 시스템으로서 시작했을 뿐이다. 이러한 목적을 성공적으로 달성하였기 때문에 시간이 지남에 따라 복잡한 시스템으로 진화할 수 있었다. 209 | 210 |
211 | 212 | 참고 : 213 | 214 | - [KISS 원칙](#kiss-원칙) 215 | 216 |
217 | 218 | ### 굿하트의 법칙 219 | 220 | [The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law) 221 | 222 | > 관측된 통계적 규칙성은 그것을 조종할 목적으로 개입할 경우 사라져버리는 경향이 있다. 223 | > 224 | > 찰스 굿하트 225 | 226 | 종종 이렇게도 인용되고는 한다 : 227 | 228 | > 지표가 목표가 되면, 더 이상 좋은 지표가 아니게 된다. 229 | > 230 | > _마릴린 스트래던_ 231 | 232 | 이 법칙에 따르면 지표를 기반으로 한 최적화는 측정된 결과 자체의 평가 절하로 이어진다. 과도하게 선정된 표본 지표([핵심 성과 지표](https://en.wikipedia.org/wiki/Performance_indicator))를 무작정 처리 결과에 적용하는 것은 왜곡된 효과를 낳는다. 사람들은 행위로 인한 전체적인 결과에 주목하는 대신, 특정 수치를 만족시키기 위해 시스템을 "게임화"함으로써 국소적으로만 최적화하는 경향이 있다. 233 | 234 |
235 | 236 | 실제 사례 : 237 | - Assert가 없는 테스트는 코드 커버리지는 높지만, 잘 테스트된 소프트웨어의 작성이라는 목적을 벗어난다. 238 | 239 | - 작성한 라인 수로 개발자 퍼포먼스를 측정할 경우, 코드베이스는 받아들일 수 없는 수준으로 불어난다. 240 | 241 |
242 | 243 | 참고 : 244 | - [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/) 245 | 246 | - [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13) 247 | 248 |
249 | 250 | ### 핸런의 면도날 251 | 252 | [위키피디아의 핸런의 면도날](https://ko.wikipedia.org/wiki/핸런의_면도날) 253 | 254 | > 어리석음으로 충분히 설명이 되는 일을 악의의 탓으로 돌리지 말라. 255 | > 256 | > — 로버트 J. 핸런 257 | 258 | 이 법칙에 따르면 부정적인 결과를 낳는 행동은 악의로부터 비롯된 것이라기보다는, 행동과 그것이 불러올 파장에 대한 몰이해 때문이다. 259 | 260 |
261 | 262 | ### 호프스태터의 법칙 263 | 264 | [Hofstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law) 265 | 266 | > 설령 호프스태터의 법칙을 고려하더라도, 일은 마치는 건 언제나 예상보다 오래 걸린다. 267 | > 268 | > — 더글라스 호프스태터 269 | 270 | 무언가가 얼마나 걸릴지 짐작할 때 이 법칙을 인용하는 것을 들을 수 있을지 모른다. 뻔한 말 같지만, 우리는 소프트웨어를 개발함에 있어 결과를 내놓기까지의 기간을 예상하는 것에 그다지 능하지 않다. 271 | 272 | 이는 '[괴델, 에셔, 바흐 : 영원한 황금 노끈](#추천-도서)'에서 나온 말이다. 273 | 274 |
275 | 276 | 참고 : 277 | 278 | - [추천 도서 : 괴델, 에셔, 바흐 : 영원한 황금 노끈](#추천-도서) 279 | 280 |
281 | 282 | ### 허트버의 법칙 283 | 284 | [Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) 285 | 286 | > 개선은 악화를 의미한다. 287 | > 288 | > ([패트릭 허트버](https://en.wikipedia.org/wiki/Patrick_Hutber)) 289 | 290 | 이 법칙의 주장에 따르면 시스템의 개선은 다른 부분의 악화로 이어지거나 다른 악화를 숨겨, 현 상태로부터 전체적인 질적 저하를 불러오게 된다. 291 | 292 | 예를 들어 특정 엔드 포인트의 응답 시간 감소로 인해 요청 흐름에 있어서 스루풋과 용량 이슈가 늘어날 수 있고, 이는 전혀 다른 부분에 영향을 끼칠 수 있다. 293 | 294 |
295 | 296 | ### 하이프 사이클 & 아마라의 법칙 297 | 298 | [위키피디아의 하이프 사이클](https://ko.wikipedia.org/wiki/하이프_사이클) 299 | 300 | > 우리는 새로운 기술의 효과를 단기적으로는 과대평가하고, 장기적으로는 과소평가하는 경향이 있다. 301 | > 302 | > — 로이 아마라 303 | 304 | 하이프 사이클은 미국의 정보 기술 연구 및 자문 회사인 가트너에서 시간의 흐름에 따른 기술에 대한 기대와 성숙도를 시각적으로 나타낸 것이다. 305 | 306 |
307 | 308 | ![The Hype Cycle](./images/gartner_hype_cycle.png) 309 | 310 | *(이미치 출처: Jeremykemp @영어 Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* 311 | 312 |
313 | 314 | 즉, 이 사이클에 따르면 대개 신기술과 그 전망에 대하여 거품이 촉발된다. 이때 많은 팀들은 너무 빠르게 뛰어들었다가 결과물에 종종 실망하고는 한다. 이것은 어쩌면 기술이 아직 덜 성숙하기 때문이거나, 혹은 실제 세계에의 적용이 덜 이루어졌기 때문일 것이다. 315 | 316 | 특정 시점이 지나고 나면 기술 자체의 역량과 실제적인 적용의 기회가 늘어나고, 마침내 생산성을 얻을 수 있게 된다. 로이 아마라는 이를 가장 간결한 문장으로 정리하였다. "우리는 새로운 기술의 효과를 단기적으로는 과대평가하고, 장기적으로는 과소평가하는 경향이 있다". 317 | 318 |
319 | 320 | ### 하이럼의 법칙 (암시적 인터페이스의 법칙) 321 | 322 | [Hyrum's Law Online](http://www.hyrumslaw.com/) 323 | 324 | > API에 충분한 수의 유저가 있다면, 325 | > 326 | > 명세에서 지정된 것은 아무런 상관이 없다: 327 | > 328 | > 시스템에서 관측될 수 있는 모든 행동 양식은 329 | > 330 | > 다른 이들에게 달려있을 것이다. 331 | > 332 | > — 하이럼 라이트 333 | 334 | 하이럼의 법칙에 따르면 API에 충분히 많은 수의 소비자가 있을 때, API의 모든 행동 양식은 궁극적으로 명세에 있는 정의가 아닌 아닌 다른 누군가에게 달려있게 된다. 간단한 예시를 들자면 가령 API의 응답 시간과도 같은 비함수적 요소들이다. 좀 더 구체적인 예시는 에러 메세지에 정규 표현식을 이용하여 API의 에러의 *타입* 을 알아내는 소비자들을 들 수 있다. API의 공개 명세에서는 메세지의 내용에 관하여서 아무 것도 알려주지 않으며 대신 에러 코드를 사용해야 한다고 하고 있더라도, 어떤 유저들은 메세지를 사용하거나 메세지의 내용을 변경하여 API를 사실상 붕괴시킬 수 있다. 335 | 336 |
337 | 338 | 참고 : 339 | 340 | - [허술한 추상화의 법칙](#허술한-추상화의-법칙) 341 | - [XKCD 1172](https://xkcd.com/1172/) 342 | 343 |
344 | 345 | ### 커니핸의 법칙 346 | 347 | > 애초에 디버깅이란 코드 작성보다 두 배는 더 어렵다. 그러므로 만약 코드를 가능한한 영리하게 작성한다면, 당신은 디버그를 하기에는 역부족이다. 348 | > 349 | > (브라이언 커니핸) 350 | 351 | 커니핸의 법칙은 [브라이언 커니핸](https://ko.wikipedia.org/wiki/브라이언_커니핸)의 이름을 따라 지었으며, 그와 플라우거의 저서 [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style)에서 유래하였다 : 352 | 353 | > 디버깅이 프로그램 작성보다 두 배는 어렵다는 것을 모두들 안다. 따라서 만약 당신이 최대한 영리하게 코드를 쓴다면 디버그는 어떻게 할 것인가? 354 | 355 | 과장되긴 하지만, 커니핸의 법칙의 주장은 복잡한 코드에서 일어나는 문제들은 고치기 매우 어렵거나 심지어 불가능하므로 단순한 코드가 낫다는 것이다. 356 | 357 |
358 | 359 | 참고 : 360 | 361 | - [KISS 원칙](#kiss-원칙) 362 | - [유닉스 철학](#유닉스-철학) 363 | - [오컴의 면도날](#오컴의-면도날) 364 | 365 |
366 | 367 | ### 메칼프의 법칙 368 | 369 | [위키피디아의 메칼프의 법칙](https://ko.wikipedia.org/wiki/메칼프의_법칙) 370 | 371 | > 네트워크 이론에서, 망의 가치는 대략 사용자 수의 제곱에 비례한다. 372 | 373 | 이 법칙은 시스템 안의 가능한 연결쌍의 수를 기반으로 하고 있으며 [리드의 법칙](#리드의 법칙)과 많은 관련이 있다. 그러나 오들리즈코를 비롯한 다른 이들은, [리드의 법칙](#리드의 법칙)과 메칼프의 법칙 둘 모두 네트워크 효과에 있어 인간의 인지를 고려하지 않음으로써 가치를 너무 높게 잡았다고 반박하였다. [던바의-숫자](#던바의-숫자) 참고. 374 | 375 |
참고 : 376 | 377 | - [리드의 법칙](#리드의-법칙) 378 | - [던바의 숫자](#던바의-숫자) 379 | 380 |
381 | 382 | ### 무어의 법칙 383 | 384 | [위키피디아의 무어의 법칙](https://ko.wikipedia.org/wiki/무어의_법칙) 385 | 386 | > 집적 회로의 트랜지스터 수는 대략 2년마다 2배가 된다. 387 | 388 | 반도체와 기판 기술의 가파른 성장 속도를 설명하기 위한 무어의 예측은 1970년대부터 2000년대 후반까지 굉장히 정확한 것으로 드러났다. 최근에는 [부품 소형화의 물리적 한계](https://ko.wikipedia.org/wiki/터널_효과)로 인하여 약간 둔화되긴 하였지만 말이다. 하지만 병렬화와 반도체 기술의 혁신적 변화에 대한 가능성, 그리고 양자 컴퓨팅은 무어의 법칙이 향후 몇 십 년간에도 들어맞을 수 있음을 의미할 수도 있다. 389 | 390 |
391 | 392 | ### 머피의 법칙 / 소드의 법칙 393 | 394 | [위키피디아의 머피의 법칙](https://ko.wikipedia.org/wiki/머피의_법칙) 395 | 396 | > 잘못될 수 있는 일은 잘못될 것이다. 397 | 398 | [에드워드 A. 머피, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.)의 _머피의 법칙_ 에 따르면 무언가가 잘못될 수 있다면, 그것은 잘못될 것이다. 399 | 400 | 이는 개발자들 사이에서 흔한 격언이다. 때로는 개발 시, 테스팅 때, 심지어 프로덕션 단계에서 예상치 못한 일이 발생한다. 이는 (영국에서는 더 흔한) _소드의 법칙_ 과 관련이 있다: 401 | 402 | > 만약 무언가가 잘못될 수 있다면, 그것은 가장 안 좋은 때에, 잘못될 것이다. 403 | 404 | 이 '법칙'들은 대개 농담처럼 이야기된다. 그러나, [_확증편향_](#TODO) 이나 [_선택편향_](#TODO) 과도 같은 현상들은 이 법칙들을 과도하게 믿게 만들 수 있다(잘 되는 대부분의 경우는 인지하지 못하나 실패는 알기 쉽고 더욱 눈에 띠기 때문에). 405 | 406 |
407 | 408 | 참고 : 409 | 410 | - [확증편향](#TODO) 411 | - [선택편향](#TODO) 412 | 413 |
414 | 415 | ### 오컴의 면도날 416 | 417 | [위키피디아의 오컴의 면도날](https://ko.wikipedia.org/wiki/오컴의_면도날) 418 | 419 | > 실체가 필요 이상으로 늘어나면 안 된다. 420 | > 421 | > 오컴의 윌리엄 422 | 423 | 오컴의 면도날은 여러 가능한 해결책 중에서, 가장 그럴 듯한 것은 가장 적은 개념과 가정이 필요한 것이라고 말한다. 그 해결책이 가장 단순하며 오직 주어진 문제만을 해결하고, 복잡성을 야기하거나 부정적인 결과를 초래하지 않는다. 424 | 425 |
426 | 427 | 참고 : 428 | 429 | - [YAGNI](#yagni) 430 | - [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet) 431 | 432 |
433 | 434 | 예시 : 435 | 436 | - [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste) 437 | 438 |
439 | 440 | ### 파킨슨의 법칙 441 | 442 | [Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law) 443 | 444 | > 작업은 남은 기한을 채울 때까지 늘어난다. 445 | 446 | 원래 맥락에서 이 법칙은 관료제에 대한 연구를 기반으로 하고 있다. 소프트웨어 개발 계획에서도 비관적으로 적용될 수 있는데, 개발자들은 기한이 다가오기 전에는 효율적이지 못하다가 기한이 가까워지면 급하게 일을 하게 되므로 결국 실제적인 데드라인을 흐릿하게 한다. 447 | 448 | 만일 이 법칙이 [호프스태터의 법칙](#호프스태터의-법칙)과 결합된다면, 더욱 비관적인 관점에 도달할 수 있다. 작업은 남은 시간을 채우기 위해 늘어나면서도 *예정된 시간보다 길어지기까지 할 것이다.* 449 | 450 |
참고 : 451 | 452 | - [호프스태터의 법칙](#호프스태터의-법칙) 453 | 454 |
455 | 456 | ### 성급한 최적화의 법칙 457 | 458 | [Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) 459 | 460 | > 성급한 최적화는 모든 악의 근원이다. 461 | > 462 | > [(도널드 커누스)](https://ko.wikipedia.org/wiki/도널드_커누스) 463 | 464 | 도널드 커누스의 논문 [Goto문을 이용한 구조적 프로그래밍](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements)에 따르면, "프로그래머들은 프로그램에서 중요하지 않은 부분을 최적화하는 것을 생각하고 또 걱정함으로써 어마어마한 시간을 낭비하는데, 이런 시도는 디버깅이나 유지보수를 고려하면 오히려 효율성에 막대하게 부정적인 영향을 끼친다. 우리는 가령 97% 정도의 경우에, 작은 부분의 효율성에 관하여 생각하지 않아야 한다 : **성급한 최적화는 모든 악의 근원이다.** 그러나 나머지 결정적인 3%의 경우에까지 기회를 저버리면 안 된다." 465 | 466 | _성급한 최적화_ 란 (좁은 의미로) 그것이 꼭 필요한지 알기 전에 행해지는 최적화라고 할 수 있다. 467 | 468 |
469 | 470 | ### 푸트의 법칙 471 | 472 | [Putt's Law on Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) 473 | 474 | > 기술은, 자신이 관리하지 않는 것들을 이해하는 자들과, 자신이 관리하는 것들을 이해하지 못하는 자들 두 가지 분류의 사람들에 의해 지배된다. 475 | 476 | 푸트의 법칙에는 종종 다음 푸트의 귀결이 따라붙는다: 477 | 478 | > 모든 기술 조직의 계급에서는 시간이 흐르면서 역량의 역전이 일어난다. 479 | 480 | 이 문구에 따르면 조직 구성론에 대한 여러 가지 선택 기준과 유행 변화에 따라서, 조직에는 여러 명의 숙련된 노동 계층과 자신들이 관리하는 일의 복잡도와 어려움을 모르는 여러 명의 관리직이 생기게 된다. 이것은 [피터의 원리](#피터의-원리) 혹은 [딜버트의 법칙](#딜버트의-법칙)과도 같은 현상 때문이다. 481 | 482 | 다만 이런 류의 법칙에서 잊지 말아야 할 점은 이러한 모호한 일반화는 _일부_ 조직에는 적용될 수도 있으나, 나머지에는 아니라는 점이다. 483 | 484 |
485 | 486 | 참고 : 487 | 488 | - [피터의 원리](#피터의-원리) 489 | - [딜버트의 법칙](#딜버트의-법칙) 490 | 491 |
492 | 493 | ### 리드의 법칙 494 | 495 | [Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law) 496 | 497 | > 거대한 네트워크, 특히 소셜 네트워크의 효용은 망의 크기에 대해 지수적으로 증가한다. 498 | 499 | 이 법칙은 그래프 이론에 기반하는데, 이에 따르면 망의 효용은 참여자 군의 부분집합의 수에 비례한다. 이것은 망의 참여자의 수 혹은 가능한 연결쌍의 수보다 매우 빠른 속도로 증가하는 것이다. 그러나 오들리즈코를 비롯한 다른 이들은 이 법칙이 네트워크 효과에 있어 인간의 인지를 고려하지 않음으로써 가치를 너무 높게 잡았다고 반박하였다. [던바의-숫자](#던바의-숫자) 참고. 500 | 501 |
502 | 503 | 참고 : 504 | - [메칼프의 법칙](#메칼프의-법칙) 505 | - [던바의 숫자](#던바의-숫자) 506 | 507 |
508 | 509 | ### 복잡성 보존의 법칙 (테슬러의 법칙) 510 | 511 | [The Law of Conservation of Complexity on Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) 512 | 513 | 이 법칙에 따르면 시스템에는 더 이상 줄일 수 없는 특정한 정도의 복잡성이 존재한다. 514 | 515 | 시스템에 있어 어떤 종류의 복잡성은 '의도되지 않은 것'이다. 그것은 빈약한 구조, 실수, 혹은 문제에 대한 그릇된 모델링의 대가이다. 이러한 의도되지 않은 복잡성은 줄이거나 없앨 수 있다. 반면에, 풀어야 할 문제에 대하여 '내재적'으로 자리하는 복잡성이 있다. 이러한 복잡성은 옮겨질 수는 있으나 없앨 수는 없다. 516 | 517 | 이 법칙이 시사하는 흥미로는 점은, 설령 전체 시스템을 단순화하더라도 내재적인 복잡성은 줄어드는 것이 아니라 _사용자에게 전이되어서_, 이용을 더욱 복잡하게 만든다. 518 | 519 |
520 | 521 | ### 허술한 추상화의 법칙 522 | 523 | [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 524 | 525 | > 모든 사소하지 않은 추상화는, 어느 정도, 허술하다. 526 | > 527 | > —조엘 스폴스키 528 | 529 | 이 법칙에 따르면 컴퓨팅에서 복잡한 시스템과 작업하기 위해 일반적으로 사용되는 추상화에서는 때에 따라 하단 요소의 '누수'가 일어날 수 있고, 이는 추상화가 예상치 못한 방향으로 전개되게 한다. 530 | 531 | 파일을 불러와 내용을 읽는 상황을 살펴보자. 파일 시스템 API는 로우 레벨 커널 시스템의 _추상화_ 인데, 이 시스템 또한 자기 플래터(혹은 플래시 메모리나 SSD)의 데이터를 물리적으로 변경하는 것의 추상화이다. 대부분의 경우 파일을 이진 데이터의 스트림으로서 추상화하는 것은 문제가 없을 것이다. 그러나 자기 디스크에서는 데이터를 순서대로 읽는 것이 임의 접근보다 *비교할 수 없을 만큼* 빠른 반면에(페이지 폴트 비용 때문에), SSD에서는 전혀 상관이 없다. 내부 구현을 상세히 이해하여야 이런 경우에 대처할 수 있는데(가령, 데이터베이스 인덱스 파일은 임의 접근의 비용을 줄이도록 구조가 짜여져 있다), 이렇듯 추상화는 개발자가 모르면 곤란하도록 내부 구현 상세를 '누출'한다. 532 | 533 | 위의 예시는 _더 많은_ 추상화가 도입되면 더욱 복잡해질 수 있다. 리눅스 운영체제는 네트워크를 경유하여 파일에 접근할 수 있도록 하면서도 로컬에서는 '일반' 파일로 취급한다. 이런 추상화는 네트워크 오류가 발생하면 '허술해질' 것이다. 만약 개발자가 이런 파일들을 네트워크 지연이나 오류에 대한 고려 없이 '일반' 파일로 취급한다면, 버그가 생길 것이다. 534 | 535 | 이 법칙을 설명하는 글에 따르면 하부 구동 원리를 모른 채로 추상화에 과도하게 의존할 경우, 도리어 문제 해결을 복잡하게 만들 수 있다고 하고 있다. 536 | 537 |
538 | 539 | 참고 : 540 | 541 | - [하이럼의 법칙](#하이럼의-법칙-암시적-인터페이스의-법칙) 542 | 543 |
실제 사례 : 544 | 545 | - [포토샵의 느린 초기 로딩](https://forums.adobe.com/thread/376152) - 과거에 마주한 문제이다. 포토샵은 종종 켜는 데에 몇 분씩이나 걸리기도 하는데, 이 문제는 구동 시작시에 현재 기본으로 설정된 프린터의 정보를 읽어오는 것에서 발생하였다. 만약 그 프린터가 네트워크 프린터라면 극도로 오랜 시간이 걸리게 되는 것이다. 시스템에 네트워크 프린터의 _추상화_ 가 로컬 프린터와 유사하게 제공된 점은 연결 상태가 좋지 못한 상황의 사용자에게 문제를 일으켰다. 546 | 547 |
548 | 549 | ### 사소함의 법칙 550 | 551 | [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) 552 | 553 | 이 법칙은 정작 심각한 혹은 중요한 것들보다 사소한 이슈들 혹은 외양에 훨씬 더 많은 시간을 쏟게 됨을 시사한다. 554 | 555 | 가상의 예시로서, 위원회가 원자력 발전소에 건설 계획을 허가하는 과정에서 훨씬 중요한 발전소 자체의 설계는 놔두고 자전거 보관소 얘기나 하는 데에 시간을 쏟는 것을 들 수 있다. 거대하고 복잡한 주제의 논의에서 그 분야의 전문 지식이나 사전 준비 없이 뭔가 유용한 이야기를 할 수는 없을 것이다. 그러나 사람들은 자신이 기여하는 것처럼 보여지고 싶어하고, 따라서 쉽게 해결될 수 있으며 그다지 중요한 것은 아닌 작은 디테일에 너무 많은 시간을 쏟는 경향이 생겨난다. 556 | 557 | 이 가상의 일화는 사소한 디테일에 시간 버리는 것을 '자전거보관소한다'고 표현하도록 만들었다. 558 | 559 |
560 | 561 | ### 유닉스 철학 562 | 563 | [위키피디아의 유닉스 철학](https://ko.wikipedia.org/wiki/유닉스_철학) 564 | 565 | 유닉스 철학은 소프트웨어의 구성 요소는 작아야 하며, 하나의 특정한 작업을 잘하도록 해야 한다는 것이다. 작고 단순하며 잘 정의된 단위들을 조합함으로써, 거대하고 복잡하며 다목적인 프로그램을 이용하는 것보다 쉽게 시스템을 설계할 수 있다. 566 | 567 | 서비스가 작고, 하나의 특정한 작업을 맡으며, 복잡한 행동은 단순한 블록의 조합으로 구성할 수 있는 '마이크로서비스 아키텍쳐' 같은 근래의 관행 또한 이 법칙의 적용으로 생각할 수 있다. 568 | 569 |
570 | 571 | ### 스포티파이 모델 572 | 573 | [The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) 574 | 575 | 스포티파이 모델은 '스포티파이'에 의해 유명해진 팀과 조직 구조에 대한 접근법이다. 이 모델에서 팀은 기술보단 기능을 중심으로 구성된다. 576 | 577 | 스포티파이 모델은 부족, 길드, 지부와 같은 그들 조직 구조의 요소 또한 유명하게 만들었다. 578 | 579 |
580 | 581 | ![Spotify Tribe Engineering Model](./images/spotify_model.jpg) 582 | 583 | *(이미지 출처: https://medium.com/@media_75624/exploring-key-elements-of-spotifys-agile-scaling-model-471d2a23d7ea)* 584 | 585 |
586 | 587 | ### 와들러의 법칙 588 | 589 | [Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) 590 | 591 | > 프로그래밍 언어를 설계할 때, 이 기능 목록에 나온 항목들을 논의하는 데 걸리는 총 시간은 2의 항목의 번호 제곱에 비례한다. 592 | > 593 | > 0. 의미론 594 | > 1. 구문론 595 | > 2. 어휘 596 | > 3. 주석다는 법 597 | > 598 | > (즉, 의미론에 1시간을 쓸 때마다 주석다는 법에 1 곱하기 2의 세제곱인 8시간을 쓴다는 뜻이다.) 599 | 600 | [사소함의 법칙](#사소함의-법칙)처럼, 와들러의 법칙에 따르면 언어 구조를 설계할 때 쓰이는 시간은 각 기능의 중요도에 반비례한다. 601 | 602 |
603 | 604 | 참고 : 605 | 606 | - [사소함의 법칙](#사소함의-법칙) 607 | 608 |
609 | 610 | ### 휘턴의 법칙 611 | 612 | [링크](http://www.wheatonslaw.com/) 613 | 614 | [공식 기념일](https://dontbeadickday.com/) 615 | 616 | > 좆같이 굴지 마라. 617 | > 618 | > _윌 휘턴_ 619 | 620 | 윌 휘턴(스타 트렉 : 더 넥스트 제너레이션, 빅뱅 이론 등에 출연한 배우)이 만든 이 단순명료하고 강력한 법칙은 전문적인 조직에서의 조화와 존중의 증대를 지향한다. 이것은 동료들과 이야기할 때, 코드 리뷰를 할 때, 다른 관점에 직면했을 때, 비평할 때, 그리고 일반적인 대부분의 사람들 간의 직업적인 상호 작용에 적용할 수 있다. 621 | 622 |
623 | 624 | ## 원칙 625 | 626 | 원칙들은 일반적으로 설계의 가이드라인과도 같다. 627 | 628 |
629 | 630 | ### 딜버트의 법칙 631 | 632 | [The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle) 633 | 634 | > 기업들은 시스템적으로 무능력한 직원들을 관리직으로 승진시켜 업무 흐름에서 배제하는 경향이 있다. 635 | > 636 | > _스캇 아담스_ 637 | 638 | 스캇 아담스(딜버트 만화의 작가)에 의해 만들어진 경영 개념인 딜버트의 법칙은 [피터의 원리](#피터의-원리)로부터 영향을 받았다. 딜버트의 법칙에 따르면, 무능한 직원들은 그들이 입힐 수 있는 피해를 최소화하기 위해 관리직으로 승진된다. 아담스는 1995년 월 스트리트 저널의 기사에서 이를 처음 설명했고, 이를 1996년 그의 경영학 서적 [딜버트의 법칙](#추천-도서)에서 확장하였다. 639 | 640 |
641 | 642 | 참고 : 643 | 644 | - [피터의 원리](#피터의-원리) 645 | - [푸트의 법칙](#푸트의-법칙) 646 | 647 |
648 | 649 | ### 파레토의 원리 (80 : 20의 법칙) 650 | 651 | [위키피디아의 파레토 법칙](https://ko.wikipedia.org/wiki/파레토_법칙) 652 | 653 | > 세상 대부분의 것들은 균등하게 분배되지 않았다. 654 | 655 | 파레토의 원리에 의하면, 경우에 따라 대부분의 결과는 소수로부터 비롯된다: 656 | 657 | - 어떤 소프트웨어의 80%는 총 시간 중 20%만에 쓰일 수 있다(반대로, 가장 어려운 20%를 만드는 것에 80%의 시간이 든다). 658 | - 20%의 노력이 80%의 결과를 만들어낸다. 659 | - 20%의 일이 80%의 수입을 창출한다. 660 | - 20%의 버그가 80%의 크래쉬를 일으킨다. 661 | - 20%의 기능이 사용량 중 80%를 차지한다. 662 | 663 | 1940년대에 품질 관리의 아버지로 널리 알려진 미국계 루마니아인 공학자 조셉 주란 박사는, [품질 문제에 파레토의 원리를 적용하기 시작했다](https://en.wikipedia.org/wiki/Joseph_M._Juran). 664 | 665 | 이 원리는 또한 80 : 20의 법칙, 중요한 소수의 법칙, 혹은 희소 인자의 원리라고도 불리운다. 666 | 667 |
668 | 669 | 실제 사례: 670 | 671 | - 2002년 당시 마이크로소프트는 20%의 가장 많이 보고된 버그를 고침으로써, 윈도우즈와 오피스에서 80%의 관련 에러와 크래쉬가 사라졌다고 하였다([출처](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). 672 | 673 |
674 | 675 | ### 피터의 원리 676 | 677 | [The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle) 678 | 679 | > 사람들은 조직 내에서 자신이 "무능력해지는 계층"까지 올라가려는 경향이 있다. 680 | > 681 | > _로렌스 J. 피터_ 682 | 683 | 로렌스 J. 피터에 의해 고안된 경영 개념인 피터의 원리에서, 일을 잘하는 사람들은 그들이 더 이상 성공적이지 못한 수준("무능력한 정도")까지 승진한다. 이 지점에서 그들은 심각할 정도로 성과가 없지 않는 이상 상급자가 될 수록 조직에서 쫓겨날 가능성이 더욱 낮아지며, 자신과 별로 관련된 능력이 없는 역할에 계속 남게 될 것이다. 그들을 성공적으로 이끌었던 원래 가진 능력은 새로운 일에 그다지 필요하지 않기 때문이다. 684 | 685 | 이것은 특히 엔지니어에게 있어 흥미로운데, 처음엔 기술력이 깊이 요구되는 분야에서 시작하나 대개 경력이 근본적으로 다른 능력이 필요한 _관리직_ 으로 이어지기 때문이다. 686 | 687 |
688 | 689 | 참고 : 690 | 691 | - [딜버트의-법칙](#딜버트의-법칙) 692 | - [푸트의-법칙](#푸트의-법칙) 693 | 694 |
695 | 696 | ### 견고함의 원칙 (포스텔의 법칙) 697 | 698 | [위키피디아의 견고함의 원칙](https://ko.wikipedia.org/wiki/견고함의_원칙) 699 | 700 | > 당신이 하는 일은 엄하게, 남의 것을 받아들일 때는 너그럽게. 701 | 702 | 종종 서버 어플리케이션 개발에 있어, 이 원칙에 따르면 보내는 것은 최대한 간략하면서도 명세를 철저히 따르도록 하되, 받는 것은 설령 명세를 따르지 않더라도 처리할 수 있는 한 받아들이는 것을 지향해야 한다고 한다. 703 | 704 | 이 원칙의 목적은 의미가 분명한 입력의 경우 비록 형식적으로는 빈약하더라도 이해는 할 수 있으므로 이를 수용함으로써 견고한 시스템을 설계하는 것이다. 다만 그러한 기형의 입력을 받아들임에 있어 특히 입력을 제대로 테스트하지 않을 경우, 보안 위협의 가능성이 생길 수 있다. 705 | 706 |
707 | 708 | ### 솔리드 709 | 710 | 이는 다음에 대한 약자이다: 711 | 712 | * S: [The Single Responsibility Principle (단일 책임 원칙)](#단일-책임-원칙) 713 | * O: [The Open/Closed Principle (개방-폐쇄 원칙)](#개방-폐쇄-원칙) 714 | * L: [The Liskov Substitution Principle (리스코프 치환 원칙)](#리스코프-치환-원칙) 715 | * I: [The Interface Segregation Principle (인터페이스 분리 원칙)](#인터페이스-분리-원칙) 716 | * D: [The Dependency Inversion Principle (의존 관계 역전 원칙)](#의존-관계-역전-원칙) 717 | 718 | 이것은 [객체지향 프로그래밍](#todo)의 핵심 원칙이다. 이러한 설계 원칙들은 개발자들이 유지보수 가능한 시스템을 짓는 것을 도울 수 있다. 719 | 720 |
721 | 722 | ### 단일 책임 원칙 723 | 724 | [위키피디아의 단일 책임 원칙](https://ko.wikipedia.org/wiki/단일_책임_원칙) 725 | 726 | > 모든 모듈과 클래스는 단일한 책임만을 지녀야 한다. 727 | 728 | '[솔리드](#솔리드)' 원칙의 첫 번째이다. 이 원칙에 따르면 모듈이나 클래스는 반드시 오직 하나의 일만을 해야 한다. 좀 더 실용적으로 말하자면, 프로그램 기능에 있어서 하나의 작은 변화는 오로지 한 구성 요소만을 바꿔야 함을 뜻한다. 가령, 패스워드 복잡도 검증을 어떻게 처리할지 변경하는 것은 오직 프로그램의 한 곳만을 바꿔야 한다. 729 | 730 | 이론적으로 이것은 코드를 더욱 견고하게 만들고 수정을 용이하게 한다. 바뀔 구성 요소가 단일 책임만을 지고 있다는 것을 안다면 그 변화에 대한 _테스팅_ 또한 더욱 쉽기 때문이다. 앞서 말한 예시에서, 패스워드 복잡도 관련 구성 요소를 변경하는 것은 오직 패스워드 복잡도 관련 기능에만 영향을 끼친다. 여러 책임을 지고 있는 구성 요소를 바꿀 때에 어떠한 일이 일어날지 예측하는 것은 훨씬 더 어렵다. 731 | 732 |
733 | 734 | 참고 : 735 | 736 | - [객체지향 프로그래밍](#todo) 737 | - [솔리드](#솔리드) 738 | 739 |
740 | 741 | ### 개방-폐쇄 원칙 742 | 743 | [위키피디아의 개방-폐쇄 원칙](https://ko.wikipedia.org/wiki/개방-폐쇄_원칙) 744 | 745 | > 개체는 확장에 대해서는 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 746 | 747 | '[솔리드](#솔리드)' 원칙의 두 번째이다. 이 원칙에 따르면 개체(클래스, 모듈, 함수 등)는 행동을 _확장_ 할 수 있어야 하지만, _기존의_ 행동은 고칠 수 없어야 한다. 748 | 749 | 가상의 예시로서 마크다운 문서를 HTML로 변환할 수 있는 모듈을 상상해보자. 모듈이 내부적인 변경 없이도 새로이 제안된 마크다운 기능을 다룰 수 있도록 확장 가능하다면, 확장에 대해 열려 있는 것이다. 만약 모듈이 소비자에 의해서 기존의 마크다운 기능 처리를 변경할 수 있도록 수정될 수 _없다면_, 수정에 대해 닫혀 있는 것이다. 750 | 751 | 이 원칙은 특히 [객체지향 프로그래밍](#todo)과 관련이 있는데, 우리는 객체를 쉽게 확장하고 싶은 반면 예상치 못한 방향으로 수정되는 것은 피하고 싶기 때문이다. 752 | 753 |
754 | 755 | 참고 : 756 | 757 | - [객체지향 프로그래밍](#todo) 758 | - [솔리드](#솔리드) 759 | 760 |
761 | 762 | ### 리스코프 치환 원칙 763 | 764 | [리스코프 치환 원칙 ](https://ko.wikipedia.org/wiki/리스코프_치환_원칙) 765 | 766 | > 시스템을 파괴하지 않으면서도 자료형을 하위 자료형으로 대체할 수 있어야 한다. 767 | 768 | '[솔리드](#솔리드)' 원칙의 세 번째이다. 이 원칙은 만일 어떠한 구성 요소가 자료형에 의존한다면, 시스템 실패나 하위 자료형이 무엇인지에 대한 정보 없이도 하위형을 대신 사용할 수 있어야 한다고 말한다. 769 | 770 | 가령, 파일을 나타내는 구조로부터 XML 문서를 읽어들이는 메소드가 있다고 하자. 만약 메소드가 '파일' 기반형을 사용하고 있다면, '파일'에서 파생된 모든 것은 해당 함수에서 쓰일 수 있다. '파일'이 역방향 탐색을 지원하고 XML 파서가 그 기능을 이용한다고 할 때 만약 하위 자료형인 '네트워크 파일'에 대한 역방향 탐색 시도 시 실패한다면, '네트워크 파일'은 규율을 위반하고 있는 것이다. 771 | 772 | 이 원칙은 특히 [객체지향 프로그래밍](#todo)과 관련이 있는데, 자료형의 계층 관계를 세심히 모델링해야 시스템 사용자들의 혼란을 막을 수 있기 때문이다. 773 | 774 |
775 | 776 | 참고 : 777 | 778 | - [객체지향 프로그래밍](#todo) 779 | - [솔리드](#solid) 780 | 781 |
782 | 783 | ### 인터페이스 분리 원칙 784 | 785 | [위키피디아의 인터페이스 분리 원칙](https://ko.wikipedia.org/wiki/인터페이스_분리_원칙) 786 | 787 | > 어떠한 클라이언트도 자신이 사용하지 않는 메소드에 의존하도록 강요당하면 안 된다. 788 | 789 | '[솔리드](#솔리드)' 원칙의 네 번째이다. 이 원칙에 따르면 구성 요소의 소비자는 구성 요소가 가진 함수들 중에서 실제로 사용하지 않는 것들에 의존하면 안 된다. 790 | 791 | 예를 들면, 파일을 나타내는 구조로부터 XML 문서를 읽어들이는 메소드가 있다고 하자. 그 메소드는 오직 파일에서의 바이트 읽기, 전진, 그리고 후진 기능만이 필요하다. 만약 이 메소드가 파일 구조의 연관 없는 기능(파일 보안을 위한 권한 업데이트와도 같은)이 변하였다고 해서 업데이트가 필요하다면, 이 원칙은 무효가 된 것이다. 파일이 '탐색 가능 스트림' 인터페이스를 구현하고, XML 리더기가 사용하도록 하는 편이 나을 것이다. 792 | 793 | 이 원칙은 특히 [객체지향 프로그래밍](#todo)에서 적용되어, 인터페이스, 계층 구조, 그리고 추상 자료형을 통해 구성 요소 간의 [결합도의 최소화](#todo)를 이루려고 한다. [덕 타이핑](#todo)은 명시적 인터페이스를 제거함으로써 이 원칙을 강제한다. 794 | 795 |
796 | 797 | 참고 : 798 | 799 | - [객체지향 프로그래밍](#todo) 800 | - [솔리드](#solid) 801 | 802 | - [덕 타이핑](#todo) 803 | - [디커플링](#todo) 804 | 805 |
806 | 807 | ### 의존 관계 역전 원칙 808 | 809 | [위키피디아의 의존 관계 역전 원칙](https://ko.wikipedia.org/wiki/의존관계_역전_원칙) 810 | 811 | > 고수준 모듈은 저수준 구현에 의존해서는 안 된다. 812 | 813 | '[솔리드](#솔리드)' 원칙의 다섯 번째이다. 고수준에서 지휘하는 구성 요소는 의존 관계를 알 필요가 없다는 원칙이다. 814 | 815 | 예시로서, 웹사이트의 메타데이터를 읽는 프로그램이 있다고 하자. 우리는 중심 구성 요소가 웹페이지 내용을 다운로드하는 구성 요소와 메타데이터를 읽을 수 있는 구성 요소를 알아야만 한다고 생각할 수 있다. 만약 의존 관계 역전 원칙을 고려한다면, 중심 구성 요소는 오로지 바이트 데이터를 가져올 수 있는 추상 구성 요소와 바이트 스트림에서 메타데이터를 읽을 수 있는 추상 구성 요소에만 의존하면 된다. TCP/IP, HTTP, HTML 등에 대해서는 알 필요가 없다. 816 | 817 | 이 원칙은 마치 예상되는 의존 관계를 '역전'하는 것처럼 보일 수 있기 때문에 복잡하다(그래서 이러한 이름이 붙었다). 실제로는, 개별 지휘체가 올바른 구현의 추상 자료형이 사용되었는지도 확실시 해야 함을 뜻한다(위의 예시에서 _무언가_ 가 여전히 메타데이터를 읽는 추상 구성 요소에 HTTP 파일 다운로더와 HTML 메타 태그 리더기를 제공해야 한다). 이것은 [제어 반전](#todo)이나 [의존성 주입](#todo)과 같은 패턴으로 이어진다. 818 | 819 |
820 | 821 | 참고 : 822 | 823 | - [객체지향 프로그래밍](#todo) 824 | - [솔리드](#solid) 825 | 826 | - [제어 반전](#todo) 827 | - [의존성 주입](#todo) 828 | 829 |
830 | 831 | ### DRY 원칙 832 | 833 | [The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) 834 | 835 | > 모든 지식은 시스템 내에서 반드시 단일하고, 모호하지 않으며, 권위적인 표현으로 나타나야 한다. 836 | 837 | DRY는 _Don't Repeat Yourself반복하지 마라_ 의 약자이다. 이 원칙은 개발자들에게 있어 코드의 반복을 줄이고 정보를 한 곳에 모을 수 있도록 돕기 위해 고안되었으며, 1999년 앤드류 헌트와 데이브 토마스의 저서 [실용주의 프로그래머](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)에 나와 있다. 838 | 839 | > DRY의 반대는 _WET_ (Write Everything Twice모든 것을 두 번 써라, 혹은 We Enjoy Typing저희는 타자치는 게 좋아요)이라 할 수 있겠다. 840 | 841 | 만일 같은 정보가 둘 혹은 그 이상 곳에 흩어져 있다면, DRY 원칙을 적용하여 하나로 합친 후 원하는/필요한 곳에서 재사용할 수 있다. 842 | 843 |
844 | 845 | 참고 : 846 | 847 | - [실용주의 프로그래머](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) 848 | 849 |
850 | 851 | ### KISS 원칙 852 | 853 | [위키피디아의 KISS 원칙](https://ko.wikipedia.org/wiki/KISS_원칙) 854 | 855 | > Keep it simple, stupid 856 | > 857 | > 간단하게 놔둬, 바보야 858 | 859 | 키스 원칙에 따르면 대부분의 시스템은 복잡하기보다는 단순할 때 가장 잘 작동한다고 한다. 즉, 간단함은 설계의 핵심 목표여야 하며 불필요한 복잡성은 피해야하는 것이다. 1960년대 미 해군에서 유래한 이 어구는 항공 기술자 켈리 존슨과 관련 있다. 860 | 861 | 이 원칙을 설명하기 좋은 예시로 존슨의 이야기가 있다. 존슨은 제트기 기술자들에게 몇 가지의 장비를 나누어주었는데, 교전 중에도 평균적인 수준의 정비공들이 오직 이 장비만을 사용해서 수리할 수 있도록 하는 제약을 지키면서 항공기를 설계했다. 즉, '바보'라는 것은 엔지니어들의 수준을 말하는 것이 아닌, 어떻게 기체를 분해할 것인가와 수리를 위해 가용한 도구들 간의 관계를 뜻하는 것이다. 862 | 863 |
864 | 865 | 참고 : 866 | 867 | - [갈의 법칙](#갈의-법칙) 868 | 869 |
870 | 871 | ### YAGNI 872 | 873 | [위키피디아의 YAGNI](https://ko.wikipedia.org/wiki/YAGNI) 874 | 875 | 이것은 _**Y**ou **A**ren't **G**onna **N**eed **I**t넌 필요 없을 거다_ 의 약어이다. 876 | 877 | > 언제나 실제로 필요할 때만 구현하고, 절대 혹시 나중에 쓸지도 모르니 만들지 말아라. 878 | > 879 | > ([론 제프리즈](https://twitter.com/RonJeffries)) (XP의 공동 설립자이자 "Extreme Programming Installed : XP 도입을 위한 실전 입문"의 저자) 880 | 881 | 이 _익스트림 프로그래밍_ (XP) 원칙은 개발자들이 오직 당장 요구될 때에만 기능을 개발하고, 미래를 예측하여 혹시 추후에 필요할지 모르는 기능을 구현하려는 시도를 피하라고 말한다. 882 | 883 | 이 원칙을 고수한다면 코드베이스에서 사용되지 않는 코드의 양을 줄일 수 있을 것이고, 의미 없는 기능 구현에 시간과 노력을 쏟지 않아도 될 것이다. 884 | 885 |
886 | 887 | 참고 : 888 | 889 | - [추천 도서 : Extreme Programming Installed : XP 도입을 위한 실전 입문](#추천-도서) 890 | 891 |
892 | 893 | ### 분산 컴퓨팅의 오류 894 | 895 | [The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) 896 | 897 | 네트워크 컴퓨팅의 오류라고도 알려진 이것은, 소프트웨어 개발에 있어 실패로 이어질 수 있는 분산 컴퓨팅 관련 가설의 목록이다. 898 | 899 |
900 | 901 | 이는 다음과 같다 : 902 | 903 | - 네트워크는 신뢰할 수 있다. 904 | 905 | - 지연은 0이다. 906 | 907 | - 대역폭은 무한하다. 908 | 909 | - 네트워크는 안전하다. 910 | 911 | - 위상은 변화하지 않는다. 912 | 913 | - 오직 하나의 관리자만이 존재한다. 914 | 915 | - 전송 비용은 없다. 916 | 917 | - 네트워크는 모두 균일하다. 918 | 919 |
920 | 921 | 첫 네 가지는 [빌 조이](https://ko.wikipedia.org/wiki/빌_조이)와 [톰 리온](https://twitter.com/aka_pugs)에 의해 1991년경 제기되었으며 [제임스 고슬링](https://ko.wikipedia.org/wiki/제임스_고슬링)에 의해 처음으로 '분산 컴퓨팅의 오류'로서 분류되었다. [L. 피터 도이치](https://en.wikipedia.org/wiki/L._Peter_Deutsch)가 5 ~ 7번째 오류를 추가하였고 90년대 말 고슬링은 8번째 오류를 추가하였다. 922 | 923 | 그들은 당시 [썬 마이크로시스템즈](https://ko.wikipedia.org/wiki/썬_마이크로시스템즈)내에서 일어나던 일로부터 영향을 받았다. 924 | 925 | 회복성이 높은 코드를 설계할 때, 이 오류들에 의해 잘못된 로직을 작성하여 실제 세계와 분산 컴퓨팅의 복잡성을 다루는 데에 실패할 수 있으므로 유의해야한다. 926 | 927 |
928 | 929 | 참고 : 930 | 931 | - [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi 932 | on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53) 933 | - [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665) 934 | 935 |
936 | 937 | ## 추천 도서 938 | 939 | 이 개념들이 흥미롭다면, 다음 책들도 즐길 수 있을 것입니다. 940 | 941 | - [Extreme Programming Installed : XP 도입을 위한 실전 입문 - 론 제프리즈, 앤 앤더슨, 체트 핸드릭슨](https://www.goodreads.com/en/book/show/67834) - 익스트림 프로그래밍의 핵심 원리를 다룬다. 942 | - [맨먼스 미신 - 프레드릭 P. 브룩스 Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - 소프트웨어 공학의 고전. [브룩스의 법칙](#브룩스의-법칙)은 이 책의 주요한 주제이다. 943 | - [괴델, 에셔, 바흐 : 영원한 황금 노끈 - 더글라스 R. 호프스태터](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - 이 책은 분류하기 어렵다. [호프스태터의 법칙](#호프스태터의-법칙)은 이 책으로부터 비롯되었다. 944 | - [딜버트의 법칙 - 스캇 아담스](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - [딜버트의 법칙](#딜버트의-법칙)을 만든 저자의 미국 업계에 대한 풍자적인 만화. 945 | - [피터의 원리 - 로렌스 J. 피터](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - 거대 조직과 인적 경영에 있어서의 난점에 관한 또 다른 해학적 관점을 보여주는, [피터의 원리](#피터의-원리)의 출처. 946 | 947 |
948 | 949 | ## TODO 950 | 951 | Hi! If you land here, you've clicked on a link to a topic I've not written up yet, sorry about this - this is work in progress! 952 | 953 | Feel free to [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) requesting more details, or [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) to submit your proposed definition of the topic. 954 | -------------------------------------------------------------------------------- /assets/banner.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/codeanddonuts/hacker-laws-kr/1b83a6641b9fad98b6e58a557e774d82721ef3b6/assets/banner.png -------------------------------------------------------------------------------- /assets/banner.psd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/codeanddonuts/hacker-laws-kr/1b83a6641b9fad98b6e58a557e774d82721ef3b6/assets/banner.psd -------------------------------------------------------------------------------- /assets/diagrams.bmpr: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/codeanddonuts/hacker-laws-kr/1b83a6641b9fad98b6e58a557e774d82721ef3b6/assets/diagrams.bmpr -------------------------------------------------------------------------------- /assets/repository-open-graph-template.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/codeanddonuts/hacker-laws-kr/1b83a6641b9fad98b6e58a557e774d82721ef3b6/assets/repository-open-graph-template.png -------------------------------------------------------------------------------- /images/amdahls_law.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/codeanddonuts/hacker-laws-kr/1b83a6641b9fad98b6e58a557e774d82721ef3b6/images/amdahls_law.png -------------------------------------------------------------------------------- /images/gartner_hype_cycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/codeanddonuts/hacker-laws-kr/1b83a6641b9fad98b6e58a557e774d82721ef3b6/images/gartner_hype_cycle.png -------------------------------------------------------------------------------- /images/spotify_model.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/codeanddonuts/hacker-laws-kr/1b83a6641b9fad98b6e58a557e774d82721ef3b6/images/spotify_model.jpg --------------------------------------------------------------------------------