‘타입스크립트만으로 문서를 대체할 수 있을까 | 커리어리

‘타입스크립트만으로 문서를 대체할 수 있을까 ?’ 처음 글의 제목을 보고 ‘클린 코드’ 의 한 인용문이 생각났다. ‘문서’는 ‘주석’의 연장선에 있기 때문에 다음 글의 핵심을 메시지를 잘 요약하는 인용문인 것 같다. > Don’t comment bad code - rewrite It > (나쁜 코드에 주석을 달지 마라. 새로 짜라.) > > Brian W. Kernighan and P.J Plaugher 문서는 중요하다. 하지만 코드만큼 중요하지는 않다. 코드만 잘 작성 하더라도 엔지니어의 의도를 충분히 전달할 수 있다. 문서는 의사를 전달하는 이 과정을 대체하는 역할이 아니라 돕는 역할을 해야 한다. 공유하는 글은 이 메시지의 좋은 사례라 생각한다. 글의 핵심 내용을 요약하면, 아마존에서 새로운 라이브러리를 공개했다. 하지만 공식 문서 없이 코드만 공개했다. 코드밖에 없었지만 라이브러리를 학습하는 데 문제는 없었다. 코드를 이용해서 라이브러리를 학습하는 과정에서 <코드를 읽는 과정의 중요성>, <Typescript의 중요성>, 그리고 <Naming의 중요성>을 경험했다. FYI. 현재는 라이브러리를 소개하는 간단한 문서가 Github 에 올라와 있다. 처음부터 코드만으로 문서를 대체할 생각은 아니었을 것 같다. 아마도 원래 의도는 ‘우리는 이거 만드느라 바쁘니까, 일단은 알아서 쓰세요’ 이지 않았을까 싶다.

Do TypeScript Types Provide Enough Documentation On Their Own?

Medium

2021년 3월 28일 오후 4:12

댓글 0

함께 보면 더 좋은

시간 지나면 절대 하지 않는 성격이라 바로 끄적임 [결론 > QnA > 서론] 순으로 내용이 좋았음 ▶️내용 ▪️서론 ▫️상태관리란 무엇인가 ▫️🔥 왜 (어떤 문제를 해결하기 위해) React Query 를 도입하게 되었는가 ▪️본론 ▫️그냥 React Query 설명 ▪️결론 ▫️사용하면서 좋았던 점 ▫️🔥 사용하면서 아쉬웠던 점 ▫️🔥 QnA ▶️끄적인거 ▪️React Query 를 도입하게 된 이유 ▫️(비슷한 고민을 했구나) ▫️API 상태 관리를 Redux 에서 하는게 맞나 ? (보일러 플레이트 코드가 많아짐 > 생산성이 저하됨) ▫️(🤔) 원래는 Redux + Saga (Thunk) 사용하는 게 당연했으나 이제는 그 문제를 위한 더 좋은 방법이 많아서 레거시라고 판단 ? ▪️Query Key 키 관리 어떻게 하고 있나 ? ▫️(이 부분 제대로 못 들음) Domain 별로 관리하고 있음 ▫️Function 이름을 그대로 사용하는 경우도 있음 ▫️Enum 을 사용하는 방법도 고려했었음 ▪️Local State를 React Query 로 한번에 관리하는 것도 고려 했었나 ? ▫️고민 해봤지만 생산성 측면에서 나누는 게 좋다고 판단했음 ▫️mobX 로 간단하게 관리할 수 있기 때문에 (mobX 사용 안해봐서 궁금하네) ▫️(다른 질문 내용) Recoil 도 고려했었음, 하지만 아직 베타라서 mobX 로 감 (같은 훅 방식이라서 잘 어울린다고는 생각함 ?) ▪️React Query 아쉬웠던 점 ▫️Compontent 가 비대해지는 문제 있음, 어떻게 관리할 것인가가 숙제로 남음 ▫️(🤔) 외부에 나눠져있던 API 관련 코드가 component 내부로 들어와서 그런 듯 ▫️(🤔) 그런데 Hook 으로 감싸면 어느 정도 관리가 될 것 같지만 배민에서 어떻게 하는지 코드가 궁금하네 ▫️(🤭 엄청 공감) 맨 처음 데이터를 수신한 상태 값이 있으면 좋음 ▪️(😆)Optimistic Update === 아님말고형 ▪️(😇) useQuery 에서 select 기능 활용 안하고 있었음

[LIVE] React Query와 상태관리 :: 2월 우아한테크세미나

YouTube

추천 프로필

현직자에게 업계 주요 소식을 받아보세요.

현직자들의 '진짜 인사이트'가 담긴 업계 주요 소식을 받아보세요.

커리어리 | 일잘러들의 커리어 SNS