두줄짜리 라이브러리는 필요한가

잡생각/두줄짜리_라이브러리는_필요한가.md

@@ -8,52 +8,64 @@
 거의 5년만에 이루어진 업데이트에서 의존하고 있던 프로젝트들이 빌드가 실패한다는 레포팅을 받자 패치를 내놓지만 수정에 실패하고, 결국 `Breaking Changes`를 알리며 메이저 버전을 업데이트 한다.
 
 이 사건은 사람들로 하여금, 두 줄의 라이브러리를 위해 디펜던시 그래프를 만드는게 맞는가? 하는 성토의 장을 열게 된다.
+그중 몇가지 인상깊었던 코멘트들과 개인적인 생각을 남겨두려 한다.
 
-The issue here is not the development and use of tiny libraries, both sides of that coin have pros and cons, the issue is the lack of testing before publishing. There really is no excuse for the latter, especially when a tiny library has so many dependents.
-
-Unfortunately the JavaScript ecosystem's dependency tree is now so vast it is easily broken; as a lot of us have experienced over the last few days.
+## 이번 일은 두줄짜리 라이브러리를 사용해서 생긴 일이 아니다.
+두줄짜리 라이브러리를 사용해서 생긴 일이 아닌, 라이브러리를 배포함에 있어 충분한 테스트를 거치지 않은것이 문제이고 이로 인해 쉽게 깨져버린 자바스크립트 패키지 에코시스템의 문제라고 얘기한다.
 
 https://github.com/then/is-promise/issues/17#issuecomment-620600431
 
-I've been meaning to write a blog post about this, but unfortunately I'm not as productive when it comes to writing non-code.
+만약 이 라이브리러리의 메인테이너가 더 큰 규모의 라이브러리의 메인테이너였다면, 동일한 패키징 에러를 일으켰을 것이다.
 
-tl;dr You make small focused modules for reusability and to make it possible to build larger more advanced things that are easier to reason about.
+https://github.com/then/is-promise/issues/17#issuecomment-620638655
 
-People get way too easily caught up in the LOC (Lines Of Code). LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works. Our short term memory is finite. In addition, by having these modules as modules other people can reuse them and when a module is improved or a bug is fixed, every consumer benefits.
+> 어느정도 동의한다. 작은 규모의 라이브러리를 사용하지 않고, 큰 규모의 라이브러리를 사용한다고 하더라도 그러한 큰 규모의 라이브버리에서 똑같은 일이 발생하지 않을 것이라는 보장은 없다.
+> 다만, 작은 기능을 위해 더 많은 라이브러리의 의존할수록 확률은 높아지고 이러한 경우에 취약해진다 생각한다.
 
-Imagine if PC manufacturers all made their own CPUs. Most would do it badly. The computer would be more expensive and we would have slower innovation. Instead most use Intel, ARM, etc.
+## 결국은 트레이드오프
+작은 기능을 위한 의존하는 라이브러리가 많아질수록, 이런 리스크를 앉고 가야하는건 자명하다. 하지만 개인적으로는 이러한 리스크를 감당하더라도 그리고 고작 두줄이더라도 라이브러리를 사용하는 편이 가져다 주는 이점이 더 많다고 생각한다.
 
-This would not be possible if it weren't for how npm works. The beauty of being able to use nested dependencies means I don't have to care what dependencies a dependency I use have. That's powerful.
+[이 의견](https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328)에 전적으로 동감하는데, 요약하자면 다음과 같다.
 
-Some years ago. Before Node.js and npm. I had a large database of code snippets I used to copy-paste into projects when I needed it. They were small utilities that sometimes came in handy. npm is now my snippet database. Why copy-paste when you can require it and with the benefit of having a clear intent. Fixing a bug in a snippet means updating one module instead of manually fixing all the instances where the snippet is used.
+- 모듈이 한줄이든, 수백줄이든 상관없다. 복잡성을 숨기고 추상화하는데 의미가 있다. 개발자는 해당 구현에 자세한 내용을 알 필요가 없어진다.
+- `is-promise`는 주어진 객체나 함수가 `promise`처럼 다루어질 수 있는지 체크한다. "`promise`처럼 다루어질 수 있는지" 에 대한 스펙은 예상과는 조금 다르게 되어 있다. 표준에 `promise`가 추가되기전 `promise` 구현체들에 대한 호환성을 유지하기 위해서 그렇단다.
+- 하지만 이 두줄의 라이브러리를 사용함으로써, 우리는 "그래서 스펙에서 요구하는 `promise`로 다루어 질 수 있는지가 뭔데?"에 대해서 신경쓰지 않아도, 자세히 알지 못해도 된다.
+- 또한 공유의 가치를 믿는다. 공개되고 많은 사람들이 사용하고, 기여하며 다양한 케이스에 대응할 수 있는 견고한 코드가 된다고 믿는다.
 
-For example. I have this module negative-zero. Its job is to tell me if a number is -0. Normally you wouldn't have to care about this, but it could happen. How do you figure out if a number is -0. Well easy x === 0 && 1 / x === -Infinity. Or is it? Do you really want to have to know how and why this works? I would rather require negative-zero and be productive on other things.
+결국 장점과 단점을 잘 저울질해서 결정하면 되는 문제이다. 정답은 없다.
 
-Another example. Chalk is one of the most popular modules on npm. What you might not realize is that it's actually a collection of modules. It depends on a module for detecting if the terminal supports color, for getting the ansi escape codes, etc. All of this could have been just embedded in the main module, and it probably is in many cases. But that would mean anyone else wanting to create an alternative terminal string styling module would have to reinvent the wheel on everything. By having these supporting modules, people can easily benefit from our work in Chalk and maybe even help improve Chalk indirectly by improving one of the dependencies.
+## 이러한 사고는 일어날 수 밖에 없다.
 
-Yet another example. I have this module user-home which get's the user's home directory. You might think it would be simpler to just do process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME. And most do this. But first, why require everyone to know how to get the home directory? Why not use a "lego block"? What you also might not realize is that this check is incomplete. On Windows you should also check process.env.HOMEDRIVE + process.env.HOMEPATH and you might also want to do additional checks. Lego blocks.
+[위의 코멘트](https://github.com/then/is-promise/issues/41#issuecomment-620483439)에서 이 부분이 제일 인상깊었다.
 
-Do you make your own shoes? No, you buy them in a store. Most don't care how the shoe is made. Just how good it fits.
+>Accidents happen. It happens [quite](https://github.com/chalk/ansi-styles/issues/15#issuecomment-202589714)<sup>1</sup> [often](https://github.com/visionmedia/debug/issues/603#issuecomment-420176933)<sup>2</sup?. It's a part of software development. It's a part of any engineering field.
+>
+> Complaining helps nothing.
 
-I want programming to be easier. Making it easier to build durable systems. And the way forward in my point of view is definitely not reinventing everything and everyone making the same stupid mistakes over and over.
+그래서 우리는 이러한 사고에도 영향을 덜 받기 위한 노력을 해야한다.
 
-https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328
 
+- Pin your dependencies. Add save-exact=true on its own line in a file called .npmrc in the root of your repository. This tells npm/yarn to omit the range prefix on packages installed with npm install/yarn install, pinning the package. Further, remove any range prefixes from your dependencies/devDependencies/etc. that might already exist in your package.json.
+
+- Don't use lockfiles. This is a highly controversial point, but the security tradeoffs are very debatable and by pinning dependencies you help mitigate this. There's a larger discussion to be had here, but in my own experience they have only caused issues both in development and production (including deployment pipelines), many of which are delayed/subtle.
+
+- Use a mirror. Setting up a CouchDB mirror is trivial and will mitigate any outages, etc. you might face.
+Accidents happen. It happens quite1 often2. It's a part of software development. It's a part of any engineering field.
+
+Complaining helps nothing.
 
-천천히 더 읽어봐야할 것 **여기 보는중**
-https://github.com/then/is-promise/issues/6
 
-이것도 좋은글
-https://github.com/then/is-promise/issues/41#issuecomment-620483439
 
 ---
 
 `is-promise` 는 또 따로 정리해야할것 같은데?
 단순히 `typeof a === "promise"` 가 아닌 이걸 써야 하는 이유?
 
 `is-promise`는 이 객체가 `promise` 타입인지 아닌지가 아니라, `promise`로써 다루어 질 수 있는지를 체크한다.
+https://github.com/then/is-promise/issues/6
 https://promisesaplus.com/#the-promise-resolution-procedure
 https://www.stefanjudis.com/today-i-learned/promise-resolution-with-objects-including-a-then-property/
+https://github.com/then/is-promise/issues/38#issuecomment-619929999
 이걸 읽어봐야할 듯
 
 - The reason this library treats your example as a Promise is that the Promises spec requires any object or function with a .then method to be treated as a Promise.