Footnotes

  1. 삼항연산자(ternary)의 어두운면과 우려를 나타내는 글 ↩

  2. forEach 루프 break하는 트릭. 참조하는 배열의 length값을 0으로. ↩

  3. 조건문에서 label을 지정해서 해당 블록으로 break가 가능하다는걸 보여주는 내용. 실제 적용할만한 사례는 거의 없고 글쓴이는 while+switch문에서 break를 좀 더 효율적으로 사용한 예를 보여주고 있다. ↩

  4. optional chaining 문법으로 리팩토링 하면서…변경 가능한 부분(삼항연산자, 배열, 기능탐지)과 주의사항(값 할당, 잘못된 위치에 표기), 조심할 부분(null/undefined, 연산 순서와 순위, return 항상 호출됨)으로 구분해서 정리한 글. 커밋을 보면 실제로 어떻게 작업했는지 확인도 가능하다. ↩

  5. <script /> 태그와 속성값에 대한 정리 ↩

  6. rust로 작성하고 wasm으로 컴파일해서 클라이언트 프로그램을 작성하는 방법을 자세하게 설명하고 있다. rust에 관심이 있거나 하다면 볼만한 글. ↩

  7. 종속성 구조를 파악해서 최적의 병렬화로 빠르게 데이터 가져오기 ↩

  8. structuredClone() ↩

  9. pipe, flow 제안(초안)사항을 검토하는 관점에서 보는 시각 ↩

#javascript#bookmarks
#1

Footnotes

  1. 코드 리뷰는 비동기식 커뮤니케이션의 한 형태이므로 많은 컨텍스트(바디랭귀지 및 주고받을 기회 등)가 손실됩니다. 이것은 대부분의 원격회사인 우리에게 특히 중요하므로 피드백에 약간의 뉘앙스를 추가할 방법을 원했습니다. ↩

  2. Feedback Ladder: ⛰ 산(Mountain) / 차단 및 즉각적인 조치 필요, 🧗‍♀️ 볼더(Boulder) / 블로킹, ⚪️ 자갈(Pebble) / 비차단하지만 향후 조치가 필요함, ⏳ 모래(Sand) / 논블로킹이지만 향후 고려 필요, 🌫 먼지(Dust) / 비차단, “받거나 놔두세요” ↩

  3. 코드 리뷰 없이 신뢰를 기반으로 엔지니어링 문화를 구축한 방법. 다른 사람들의 상황이 자신에게 적용되는지 자문해볼 필요가 있다. ↩

#code_review#bookmarks
#221
- 프로젝트에 새롭고 반짝이는 기술보다는 지루한 기술을 선택하는 것이 좋습니다.
- 흥미로운 기술은 프로젝트에 불필요한 위험을 초래할 수 있습니다.
- 이미 확립되고 입증된 기술이 성공적인 결과로 이어질 가능성이 더 높습니다.
- 신기술을 둘러싼 과대 광고는 오해의 소지가 있습니다.
- 신기술의 수명을 예측하기는 어렵습니다.
- 지루한 기술은 화려하지 않을 수 있지만 안정적이고 신뢰할 수 있으며 예측 가능합니다.
- 최신 기술 유행보다는 비즈니스 문제 해결에 집중하세요.
- 사람과 프로세스에 투자하면 더 나은 결과를 얻을 수 있습니다.
- 지루한 기술을 선택하는 것은 보수적이거나 위험을 피하기 위한 것이 아니라 프로젝트의 장기적인 성공을 우선시하는 정보에 입각한 결정을 내리기 위한 것입니다.

Footnotes

  1. Dan McKinley :: Choose Boring Technology ↩

  2. 항상 최신의 최첨단 솔루션을 쫓기보다는 확립되고 신뢰할 수 있는 기술을 사용하는 것을 지지하는 글. 특히 장기 프로젝트의 경우 기술 선택에서 안정성과 예측 가능성의 중요성을 강조. ↩

#bookmarks
#222