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

JavaScript/is-promise.md

@@ -0,0 +1,13 @@
+`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.
+- The reason the spec requires that is because it allows interoperability between the many Promise implementations that existed before native promises. Without this, promises would be virtually unusable for years while everyone migrated.
+- This library exists, even though it's only 3 lines because it means you don't have to think about exactly these problems. Lots of people know little enough about Promises that they wouldn't be able to implement this correctly (see all the pull requests & comments offering to "simplify" the logic). That's fine, they shouldn't need to worry about that, they can just import is-promise.

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

@@ -42,32 +42,14 @@ https://github.com/then/is-promise/issues/17#issuecomment-620638655
 >
 > Complaining helps nothing.
 
-그래서 우리는 이러한 사고에도 영향을 덜 받기 위한 노력을 해야한다.
+그래서 우리는 이러한 사고에도 영향을 덜 받기 위한 노력을 해야한다. 위 코멘트를 작성한 `Qix-`는 다음과 같은 방법을 권한다.
+- `.npmrc`에 `save-exact=true`을 주어서 의존하는 패키지들의 버전을 고정한다.
+- `lockfiles` 를 사용하지 않는다. 이는 많은 논쟁의 여지가 있지만, 의존성을 고정시키는데 유용하다.
+- 패키지 저장소의 `mirror`를 구축하여 사용한다.
 
+## 마치며
+그 대상이 두줄이든, 수백줄이든 기능을 모듈화하는건 유용하다. 코드의 재사용성을 높일 수 있으며, 복잡한 내용을 추상화하여 코드를 개발자로 하여금 자세한 구현내용에 신경쓰지 않을 수 있도록 해준다. 즉, 이 코드가 '어떻게'가 아닌 '무엇을' 하는지에 대해서만 집중할 수 있게 한다. 표현력이 높아진다.
 
-- 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.
-
-
-
----
-
-`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.
-- The reason the spec requires that is because it allows interoperability between the many Promise implementations that existed before native promises. Without this, promises would be virtually unusable for years while everyone migrated.
-- This library exists, even though it's only 3 lines because it means you don't have to think about exactly these problems. Lots of people know little enough about Promises that they wouldn't be able to implement this correctly (see all the pull requests & comments offering to "simplify" the logic). That's fine, they shouldn't need to worry about that, they can just import is-promise.
+소프트웨어 개발에 있어, 사고는 언제나 일어날 수 밖에 없는 요소이다. 우리가 해야 할 일은 이 사실을 인정하고, 우리가 할 수 있는 일들을 하는것이다.