A new year, a new MDN : MDN이 그동안 wiki 기반으로 운영해오다가 GitHub을 이용한 마크다운 기반으로 변경하면서 디자인을 전면 개편했다. 새로운 로고도 공개하면서 조만간 개인화 기능을 추가한 유료 구독 서비스를 공개할 예정이라고 한다.(영어)
Solid.js feels like what I always wanted React to be : React를 오래 사용했지만, Hook을 쓰면서 느끼던 불편함을 Solid.js의 Reactive 특징에서 이유와 해결책을 보게 되었다며 설명하는 글이다. React Hook으로 카운터를 올리는 예시를 통해서 React Hook이 실수로 버그를 만들 여지가 있음을 보여주고 해결책은 있지만 익숙해지기 전에는 헷갈릴 수 있다고 설명한다. Solid.js에서는 Reactive적인 특징이 있어서 DOM에서 사용할 값도 함수로 호출해서 인터벌로 업데이트할 때 사이드 이펙트가 발생하지 않고 컴포넌트 자체는 딱 한 번만 실행되게 된다고 한다. Solid.js에서는 모든 것이 리액티브 시스템에서 동작하고 라이프사이클 훅은 많은 역할을 하고 있지 않다고 한다.(영어)
How to Upgrade to the React 18 Release Candidate : React의 다음 버전인 18의 릴리즈 후보 버전이 나와서 이 릴리스 후보 버전으로 어떻게 업그레이드할 수 있는지를 정리한 글이다. 변경된 API와 지원되는 기능이 잘 정리되어 있어서 정식 18 버전이 나오기 전에 RC 버전으로 마이그레이션 준비를 할 수 있다.(영어)
그 밖의 개발 관련
신입 개발자의 첫 홀로서기 프로젝트 : 29CM에 입사한 신입 개발자가 최대 혜택가 관련 기능을 개발하면서 겪을 경험을 정리한 글이다. 도메인 파악이 어려워서 의사 결정 테이블로 조건을 정리하고 QA까지 통과해서 배포했지만, 성능 문제가 발생해서 Postgresql의 인덱스 개선, 리인덱싱 문제를 해결하고 메모리릭 문제를 힙덤프로 해결한 과정이 나와 있다.(한국어)
코드 리뷰 관련 질문!! : 코드 리뷰 관련 강연을 하면서 받은 질문에 대해 생각을 정리한 글이다. 리뷰하기 좋게 작성자가 노력해야 하고 리뷰는 매일 시간을 정해두고 하기를 권하고 있다. 리뷰하면 품질에 대한 비용을 줄일 수 있고 이를 성과로 인정해야 조직에서도 리뷰를 더 적극적으로 할 수 있으며 지속해서 해야 시간이 지나면서 혜택을 크게 볼 수 있다.(한국어)
인프라 관련
DevOps 안내서 : subicura님이 정리한 DevOps 안내서이다. 스타트업에서 DevOps를 도입한다는 가상의 시나리오에 따라 Node.js 웹 애플리케이션을 만들고 이를 자동화하는 과정이 정리되어 있다. 목차를 보면 AWS와 Kubernetes 배포까지 계획하고 계신 거로 보이지만 현재는 Node.js 웹 애플리케이션의 작성과 GitHub 연동까지 작성되어 있다.(한국어)
Just say no to :latest : Dockerfile에서 latest 태그를 지정하면 지속적 배포의 중요한 요구사항인 재현 가능하고 멱등한 빌드를 깨뜨려서 프로덕션에서 문제를 일으킬 수도 있다고 얘기하고 있다. Python, npm, Terraform 등 다른 생태계에서도 버전을 지정할 것을 권장하고 lock 파일도 꼭 커밋해서 관리할 것을 권장하고 있다.(영어)
[번역]쿠버네티스는 단순히 컨테이너를 관리하는 툴이 아닙니다. : 컨테이너를 관리하기 위해서 만들어졌지만, API를 제공해서 일관적인 사용 방법을 제공할 수 있게 되고 여기에 CRD 등 더 많은 API를 제공하면서 단순히 컨테이너 관리 도구가 아니라 API를 제공하는 것이 핵심이라고 설명하는 글이다.(영어)
볼만한 링크
페이스북 개발자의 성과 만들기 : 페이스북에서 일하는 지인한테 어떻게 일하고 성과평가를 하는지를 듣고 정리한 글이다.(한국어)
업무의 시작
데이터를 기반으로 한 뚜렷하고 심플한 목표가 주기적으로 내려온다.
이 목표를 이루기 위한 아이디어는 모든 작업자가 생각해 내서 프로젝트를 자발적으로 구성한다.
프로젝트 멤버를 구성할 때는 공개적으로 어떤 아이디어이고 어떤 인력이 필요한지를 사내에서 공개적으로 구인한다.
업무의 진행
업무에서 어떤 성과를 냈는지가 제일 중요하므로 성과를 어떻게 측정할지에 대한 문서화를 한다.
모든 작업은 A/B 테스트를 통해 배포하므로 성과가 좋으면 퍼센티지를 늘려가게 되고 문제가 있다면 0%로 바꾼 뒤에 문제를 해결한다.
QA는 따로 없기 때문에 개발하면서 E2E 테스트를 철저히 하고 있다.
VSCode를 커스터마이징해서 클라우드 기반의 1인 개발환경을 쉽게 설정할 수 있는 환경을 제공한다.
업무의 위기
프로젝트에 사람이 더 필요한 경우 직접 구하거나 매니저에게 요청하기도 한다.
매니저와 개발자의 트랙이 명확히 구분되어 있다.
온콜은 당번제로 한 달 단위로 돌아가게 되고 장애를 등록하면 자동으로 담당자에게 전화가 간다.
장애에 도움을 주는 사람들도 있는데 이들은 이 업무가 그들의 성과이다.
장애가 해결되면 장애 리포트를 정리한다.
성과의 기준
성과는 프로젝트 영향력, 엔지니어링/서비스 전반, 피플, 디렉션의 4가지 범주로 평가한다.
프로젝트 영향력은 실제로 프로젝트에 어떤 공헌을 하였는지를 평가한다.
엔지니어링/서비스 전반은 개발자 역량에 대한 평가이다.
피플은 공유나 태도, 커뮤니케이션에 대한 평가이다.
디렉션은 시니어이거나 시니어가 될 주니어에게 필요한 성과로 리더쉽이나 기술 리딩에 대해 평가한다.
성과 평가
평가는 1년에 한 번 하는데 중간에 동료나 매니저에게 지금 잘하고 있는지 확인하는 요청을 할 수 있다.
모든 성과는 측정 가능해야 한다.
평가는 매년 해도 연봉협상도 매년 하는 것은 아니다.
평가는 대상자가 제출하는 성과 보고서를 기준으로 진행된다.
비전공자 프론트엔드 개발자의 취업 후기 : 개발과 관련 없는 전공을 하고 프론트엔드 개발자에 관심을 가지게 되어 공부한 뒤 10개월 정도 만에 취업한 과정을 정리한 글이다. 독학으로 공부하면서 많은 강의를 들었는데 특히 유데미 강의 같은 경우는 3번을 반복해서 봤다는 부분이 인상적이고 강의뿐 아니라 스터디나 모의 면접, 토이 프로젝트도 진행하면서 여러 회사에 지원하면서 도전한 결과 최종 합격을 하게 되었다고 한다.(한국어)
Comments