느낀점10 구글 엔지니어는 이렇게 일한다 #12장 단위테스트를 읽고 #12 단위 테스트| 일부 내용첫째, 버그도 없고 자신의 검증 대상과 관련 없는 변경 때문에 실패하는 '깨지기 쉬운' 테스트들이 도사리고 있었습니다. 둘째, 무엇이 잘못되어 실패했는지, 어떻게 고쳐야 하는지를 파악하기 어려운 '불명확한' 테스트들이었습니다. 애초에 무슨 기능을 어떻게 검사하려고 했는지조차 이해하기 쉽지 않았습니다. 책에서는 '깨지기 쉬운 테스트' 와 '불명확한 테스트' 를 예시로 맹목적인 테스트로 인해 발생 할 수 있는 생산성 저하 케이스에 대해 설명해주고 있다. 실제 개발을 진행하며 이런 상황을 빈번히 마주치게 된다. 그럴때마다 어떤것이 올바른 테스트 작성 방향성인지 헷갈릴 경우가 많다. 지금도 일부분에 대해서는 혼동이 오고는 한다. 이건 좀 더 경험 / 역량이 쌓이면 해결될것이라고 생.. 2024. 11. 25. 구글 엔지니어는 이렇게 일한다 #11장 테스트 개요를 읽고 #11 테스트 개요| 일부 내용최고의 팀은 팀원들의 집단 지성을 팀 전체의 이익을 환원하는 방법을 찾아냅니다. 바로 자동 테스트가 하는일이죠. 어쩌면 단순하다고 볼 수 있는 테스트 케이스 작성을 이런 관점에서 생각해볼 수 있다는것이 놀랍다. | 일부 내용더 나아가 하루에도 몇 번씩 새로운 버전을 릴리스해야 합죠. 일 년에 고작 한두 번만 업데이트되던 과거의 소프트웨어 세상과는 완전 딴판 입니다. 애자일, 스프린트 방식이 전반적으로 도입되기 시작하면서 프로그램의 배포주기는 더욱 더 짧아지기 시작하는것 같다. 그만큼 배포, 롤백, 각종 트러블 슈팅의 빈도 수도 올라갔기 때문에 테스트의 중요성이 더 대두된다. | 일부 내용테스트 문화가 확실하게 뿌리 내린 조직을 경험해보지 못한 개발자는 테스트를 작성하면 .. 2024. 11. 24. 구글 엔지니어는 이렇게 일한다 #10장 문서자료를 읽고 #10 문서자료| 일부 내용대부분의 엔지니어가 코드를 작성하고, 이용하고, 유지보수하며 토로하는 대표적인 불만이 양질의 문서자료가 부족하다는 점 입니다. 지금까지의 경험에 한해서는 어디를 가서도 문서자료의 부족함이 없다는 이야기는 못들어 봤다. 항상 문서 자료가 부족하다는 이야기 뿐이었다. | 일부 내용구글에서 문서자료를 개선하고자 해본 시도 중 가장 성공적이었던 방법은 문서자료를 코드처럼 취급하여 엔지니어링 워크플로에 통합하는 것이었습니다. 그 결과 엔지니어들이 간단한 문서자료를 작성하고 유지보수하는 일이 한결 수월해졌습니다. swagger, jsdoc, postman, redoc 등 이를 활용할 수 있는 도구들이 많이 다양해졌다.대다수의 사람들이 최소한 API 명세에 한해서는 문서화의 중요성을 인.. 2024. 11. 23. 구글 엔지니어는 이렇게 일한다 #9장 코드 리뷰를 읽고 #9 코드 리뷰| 일부 내용지식과 책임을 '소유권' 이라 부르고, 소유권을 행사하는 사람을 소유자 라고 합니다. 단순히 해당 영역의 소스 코드가 소유자의 것이라는 뜻이 아니라 회사가 추구하는 가치가 지켜지도록 관리한다는 의미의 소유 입니다. '회사가 추구하는 가치가 지켜지도록 관리한다'코드 리뷰를 하면서 이런식으로 방향을 정의한적이 있던가. 단순히 팀의 컨벤션, 회사의 컨벤션, 코드의 효율성 및 가독성만을 탐독하지 않았나 반성하게 된다. | 일부 내용구글은 아무리 작더라도 코드베이스를 수정하는 거의 모든 변경에 코드 리뷰를 요구합니다. 이러한 강제적인 규제는 비용을 유발하고 엔지니어링 속도에도 영향을 줍니다. 코드 베이스에 새로운 코드를 추가하는 속도를 늦추고 필요한 변경을 제때 반영하기 어렵게 할 수도.. 2024. 11. 22. 이전 1 2 3 다음 반응형