📌 목차
- The Twelve-Factor App (한국어)
- Spotify의 Squad 팀 모델은 실패였다
- Code Review에 대해
- 팀 문화의 탄생
- 당신이 좋은 개발자라는 징표
- 효과적인 코드 리뷰를 위해서
- 기술 업계의 독성 말투 문제, 고칩시다!
- 문서화에 대해 아무도 말해주지 않는 것들
- 빠른 개발을 위한 기술
- 소프트웨어 환멸감 [번역]
- LINE의 장애 보고와 후속 절차 문화
- Conventional Commit
- 유의적 버전(Semantic Versioning)
- 새로 입사한 개발자가 프로젝트에 기여하는 방법 한 가지
- 개발자 Code Review 가이드
- 10년간 슈퍼셀을 경영하며 배운 10가지 교훈
- 구조적 동시성에 대한 소고, 또는 Go 문의 해로움
- 구글 코드 리뷰 가이드
- Shape Up: 스타트업 소프트웨어 제품 개발 및 관리 프로세스
- 페이스북 개발자의 성과 만들기
- There’s No Such Thing as Clean Code
- 개발자 머피의 법칙
- 확장하기 쉬운 코드가 아니라 삭제하기 쉬운 코드를 작성하자
- 소프트웨어 아키텍쳐의 중요성
- 신규 Web 서비스시 고려해 볼 사항
- 변하지 않는 상태를 유지하는 방법, 불변성(Immutable)
- Database Driven Development에서 진짜 DDD로의 선회
- DDD 했더니 비대해지는 엔티티, 좋은 대책은?
- 필요한 내용만 추려서 DDD 당장 써먹기
- DDD Lite@Spring
- Is TDD Dead?
- 실용적인 테스트 피라미드
- 쉬운 테스트 주도 개발과 단위 테스트를 위한 5단계 방법론
- 서버 사이드 테스트 자동화 여정
- 유용한 테스트 케이스를 위한 개발자의 자세
- TDD 라이브 - SpringCamp2013
- 1500개의 테스트를 작성하며 나는 무엇을 얻었나
- OKKYCON: 2018 The Real TDD - TDD 제대로 알기
- 유닛테스트에 대한 생각
- LocalStack을 활용한 Integration Test 환경 만들기
- 테스트 상태인 Private 메소드를 Public메소드로 변환시 Unit Testing은 어떻게 해야하나?
- 개발자를 위한 A/B 테스트 해시 샘플링
- 소프트웨어 테스팅의 False Positive
- 실용적인 프런트엔드 테스트 전략
- JUnit5로 계층 구조의 테스트 코드 작성하기
- xUnit 테스팅 프레임워크를 TDD로 만들어보자
- 테스트 코드 작성에 대한 나름의 고찰
- 단위 테스트, 도대체 어디까지 작성해야 할까?