우아한형제들 기술이사 / 서버개발그룹 그룹장인 손권남님께서 신입 개발자의 역량과 성장에 대한 강의를 진행해주셨다. 공감가는 내용이 많고 정리해두면 좋겠다고 느껴 작성해보고자 한다.
회사 내 기본 개발 개념은 잡고 가자!
- 코트 읽기 좋게, 주석X
- 위키 등 회사의 문서화 시스템에 잘 문서화, ERD 등도 정리
- 커밋 메세지는 작성한다면 상세히
- TDD 개발
1. 의미에 맞는 용어로 전환하자
회의가 똑같은 말을 반복할 수 있다.
배달비?
- 고객 부담 배달비
- 업주 부담 배달비
- 배달 정산 비용
2. 리팩토링/테스트코드는 사치? → 처음부터 제대로하자.
- SI업체에서 매우 빡빡한 일정, 작동하는 기능만 요구 → 유지보수는 다른회사?
- 옳은 말만 하는 것 같고, 상대가 답답해 보일 수 있음.
- 사무실에서는 이게 맞아보이지만 막상 현장 상황을 살펴보면 다를 수 있다.
3. 해석의 여지를 없애자. (비언어적 언어X, 공격적인 말투X)
- 우리 언제 밥 한 번 먹자
- 언제? 어디서? 먹을 것인가.
- 비언어적, 암묵적 대화를 없애자.
- 정중하게 기술 업계의 독성 말투 문제, 고치자
4. 검색으로 배우자 (사람, 기술)
- 검색키워드
- 개발자의 성장
- 신입 개발자 역량
- 좋은 개발자
- 나쁜 개발자
- 좋은 엔지니어
- 일 잘하는 방법/사람
- 좋은 말고 나쁜도 검색해보기
- 단점
- 주의할 점
- cons, pitfall, gotchas, warns, when not to use
- 구글 사용법 익히기
- 지정검색
- 검색어 제외
- 기간 지정 등
- 오픈소스의 issue tracker, 커뮤니티에 직접 검색
5. 학습 정보 탐색방법
- 튜토리얼 문서
- 레퍼런스 문서
- 강의
- 책
6. 학습을 내것으로 만들자
- 함께 모여 읽은 내용 → 삼색 볼펜 초학습법 공유
- 기록하고 공유
- 발표하고 가르침
- 학습 테스트 작성
- 사이드 프로젝트
- 주체성
7. 기록하자
- 기록은 학습 전략
8. 주석(comment) 달자
- 가독성 높은 코드가 목적이지 주석을 없애는게 목적이 아니다.
- 코드의 목적
- 변칙적인 부분에 대해 왜 그런 처리가 필요한지 이유를 기록
- 문서화 방법 익히기(javadoc)
- 테스트코드 작성하기
- 테스트의 설명, 이유
- Batch job의 경우 시간 의존적인 상황 있다면 이유적기
9. 질문하자!
- 하지만 값을 치루자
- 먼저 일정시간 탐구 → 회사 문서(위키), 검색
- 잘 질문하자
- 무슨일?
- 뭘해봤는지
- 질문에 대한 값 치루기
- 문서에 다시 반영
- 주석으로 적기
- 리팩토링
10. 예외처리를 잘하자
- 충분한 정보를 남기자
- 주문정보가 없습니다 → 주문번호 123번이 없습니다.
- 예외를 절대로 먹지말고 항상 로그로 남기자
- 예외를 먹어야 하는 상황이라면?
- 그 이유를 주석으로 남기자
- 정확히는 모든 변칙적인 상황에 대해 이유를 주석으로 남기자
11. 문서화를 잘하자
- 개발자의 최우선은 코드.
- 코드와 문서의 거리가 가까워야 그나마 즉시 갱신이 가능하다
- 주석을 잘 달고
- 테스트코드로 문서화하고
- ERD보다는 Entity클래스에 주석을 다는게 더 도움된다
- 프로젝트 내의 README 파일 문서화
- API문서는 위키가 아닌 코드를 문서로 자동변환하도록 한다.
12. TDD로 구현하지만 도구로 보자(목적은 작동하는 코드) → 작동하는 코드를 먼저하고 리팩토링하는 방법도 있다.
- 테스트 코드 작성해서 완성하자
- 보통사람은 무에서 완벽한 유를 창조하기 어렵다
13. commit은 대충해도 된다(웹서비스 개발자)
- 깃 로그에 크게 신경쓰지 않는다.
- 커밋 완벽하게는 언제?
- 커밋 하나의 충분한 정보를 담고
- 테스트도 완경성, 문서화도 완결성
- 패키지 소프트웨어나 오픈소스 라이브러리를 만들때.
14. 완벽한 문서/코드/기획서가 있다고 생각하지 말자
- 내가 소통을 통해 완벽함으로 가는 여정의 주체가 되자
- 기록하고 그 기록을 계속 갱신하며 경험을 누적해가자
'활동 > 우아한테크코스' 카테고리의 다른 글
[내 편] 내 마음을 편지로 (2) | 2022.10.29 |
---|
댓글