원래 매 회고마다 우아한 테크코스에서 해주는 말과 태도, 피드백을 정리했었다. 그렇게 하다보니 태도나 피드백을 보고싶을 때 다 나눠져 있어 찾아보기가 힘들었다. 하나로 합치는 게 더 좋겠다는 생각이 들었다. 코딩에 대한 태도나 방법이 흐릿해질 때마다 이 글을 정독해서 생각을 정립할 생각이다 :) 아무튼, 이 글은 코딩에 대한 사람의 태도, 자세를 정리해놓은 글이다.

의식적인 연습

목적의식있는 연습에 얼마나 많은 시간을 투자했는가?
개인의 컴포트 존을 벗어난 지점에서 진행, 자신의 현재 능력을 살짝 넘어가는 작업을 지속적으로 시도하자
피드백과 피드백에 따른 행동 변경을 수반하자

코딩의 의식적인 연습

한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
- 가능하다면 메서드의 길이는 5줄
- 한 메서드가 하나의 일만 하고 있는지 확인
else 예약어를 쓰지 않는다.
- 다형성을 통해 조건문을 처리하자
- Null Object Pattern을 시도해도 좋다
모든 원시값과 문자열을 포장한다.
- 컴파일러와 프로그래머에게 값의 의도를 나타내자
한 줄에 점을 하나만 찍는다.
- 다른 객체에 깊숙이 관여하면 안 된다
줄여쓰지 않는다(축약 금지).
- 클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하자
모든 엔티티를 작게 유지한다.
- 50줄 이상되는 클래스와 파일이 10개 이상인 패키지는 없어야 한다
2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
일급 콜렉션을 쓴다.
- 콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다.
게터/세터/프로퍼티를 쓰지 않는다.

좋은 객체의 7가지 덕목

객체가 현실 세계에 존재한다
- 컨트롤러, 서비스 로케이터, 싱글턴은 좋은 객체가 아니다. 단지 다른 객체와 함께 사용하기 위해 만들어 낸 것이다
객체가 계약(책임)에 따라 동작한다
- 인터페이스에 선언된 메서드들을 구현해야 한다
- 계약없이 동작하는 객체는 단위 테스트에서 mock하는 것이 불가능하다
- 계약없는 객체는 데코레이터 패턴을 통해 확장하는 것이 불가능하다
객체가 고유하다
- 좋은 객체는 언제나 고유하기 위해 무언가를 캡슐화해야 한다
- 캡슐화할 것이 없다면 객체가 동일한 복제본을 가질 수도 있다
객체가 불변하다
- 불변 객체는 생성, 테스트, 사용하기가 더 간단하다
- 불변 객체는 언제나 스레드 안전하다
- 불변 객체는 캐싱하기 쉽다
- 불변 객체는 NULL 참조를 방지한다
객체의 클래스에 정적(클래스) 멤버가 없다
- 정적 멤버는 클래스의 행위를 구현하지, 객체의 행위를 구현하지 않는다
- 정적 멤버를 사용한다면 Mock하는 것이 불가능하며 스레드 안전하지 않다.
- 정적 멤버를 사용한다면 OOP의 패러다임에 반하는 일이며 이는 다른 객체로부터 완변하게 고립되지 못 한다
객체의 이름이 직명을 나타내지 않는다
- 객체의 이름은 이 객체가 무엇인지 말해야 하고 무슨 일을 하는지 말해서는 안 된다
- 일반적으로 “er”로 끝나는 이름은 피하라
객체의 클래스가 Final이나 Abstract다
- 상속을 통해 확장할 수 없는 클래스이며 확장하기 위해서는 데코레이션 패턴을 통해서 한다
- 인스턴스를 가질 수 없는 클래스로 만들어 abstract로 표시해 로직을 주입하길 바라도록 한다.c
- 이런 방식으로 작성하면 원본 객체의 내부 로직을 건드릴 수 없게 할 수 있다.

소프트웨어 장인이 가져야할 태도

프로그래밍 역량 외에도 테스트, 배포 자동화, 고객/구성원들과의 협업, 문화 만들기 등에도 관심을 가지는 자세
테스트 코드 구현까지 완료해야 기능 구현을 완료하는 것으로 생각하는 자세
레거시 코드를 바라볼 때 재미있고, 도전적인 문제로 바라보는 자세
무리한 일정과 변경 요구에 무조건적으로 ‘예’라고 말하기 보다, ‘아니오’라는 말을 하고 대안을 제시하는 자세
자신의 시간과 돈을 들여 스스로 성장하려는 자세
나 혼자 성장하는 것에만 관심을 가지기 보다, 후배들을 키우고, 커뮤니티를 통해 같이 학습하고, 지식을 공유해 소프트웨어 산업 생태계에도 기여하려는 자세
고객(또는 고용주)을 프로젝트를 성공시킬 생산적인 동반자 관계로 바라보는 자세. 동반자 관계와 거리가 멀고 나의 커리어에 부정적이라고 느낀다면 다른 고객을 찾아라.
소프트웨어 장인에게 가장 필요한 자질은 정직과 용기

우테코의 말말말

슬럼프에 빠지지 않으면서 꾸준히 학습하는 게 가장 좋다.
운동은 필수다. 체력 관리를 하라.
의욕만 넘쳐서 무턱대고 하지말고 효율적으로 공부해라.
상대방의 의견이 좋았어도 바로 콜하지 말고 내 의견을 이야기하자.(매번 Okay만 하지말자) 더불어 상대방이 이해할 수 있도록 명확히 이야기하자
이슈는 먼저 본 사람이 줍는다.
모르면 모른다고 확실히 말하자.
도메인 테스트 커버리지가 80%가 넘도록 하자
모른다면 적어도 검색할 수 있는 키워드를 뽑아낼 수 있는 능력을 키우자
완벽주의적인 성향이면 새로운 도전을 안 할 가능성이 있다. 완벽주의적인 성향을 깨라.
의미있는 커밋 메세지를 남기자
짧은 실패를 자주 해라.
빨리 가려고 하지말고 그냥 매일 매일 일정 시간을 투자하면 된다
책도 그렇고 컴퓨터 용어도 그렇고 처음부터 완벽히 이해하려고 하지 마라. “~일거야”라고 가정을 한 뒤에 반복해서 보면 감이 생긴다.
깨지는 테스트는 필요없다.
프로그래밍을 정말 즐긴다면 시키는 것만 하지 않는다. 스스로 다른 개발을 찾아서 한다.
심리적 안정감이 팀을 효율적으로 만든다.
어떤 의견을 제시해도 벌을 받거나 보복당하지 않을 거라고 믿는 조직 환경을 만들자
가장 만족도가 높은 교육은 문제의 단계를 쪼개고 이빨 빠진 코드를 준 후, 힌트를 통해 문제해결을 하는 것이었다.
심리적 안정감을 만드는 역량을 키우는 좋은 방법은 리더가 되거나 교사가 되면 된다
가장 좋지 않은 팀 분위기는 충돌이 없는 것이다. 충돌을 두려워하지 말자.
발표 잘하는 노하우는 발표를 많이 해보는 것이다. 커뮤니티 스터디와 같이 소그룹에서 발표하는 연습을 해보자. 그리고 나 자신도 발표하는 사람이 실수해도 괜찮다고 응원하는 사람이 되자.

블로그의 말말말

현재를 위해 TC를 작성하되 개발이 진행되면서 미래를 위한 TC들로 바뀌어야 한다.
내부 구현은 공개된 인터페이스를 통해서만 테스트한다
TDD 혹은 테스트 자동화를 프로젝트에 진지하게 도입하고 있는 개발자라면 다른 프로젝트의 커버리지보다는 테스트 가능한 것과 테스트 불가능한 것을 어떻게 분리해냈느냐가 더 궁금할 것이다.

우테코의 페어 프로그래밍 피드백 모음

좋았던 점
- 처음부터 끝까지 TDD로 진행한 것
- 각자 피드백을 받은 후 공유하는 시간
- 개인 컨디션과 상황을 배려한 것
- 협업 규칙을 정한 것. 쉴 때 쉬자고 이야기 한 것
- 자신에게 익숙하지 않은 내용에 대해 스스로 공부하고 온 것
아쉬운 점
- 좀 더 유연하게 생각했으면 좋겠다.
- 이유를 명확히 하는 습관을 들이면 좋을 것 같다.
- 의견 표현을 좀 더 해도 좋을 것 같다.
- 의견 충돌하는 경우가 있었다. 빠르게 제출한 뒤 리펙토링을 하는 경우가 있었고, 처음부터 설계에 힘 주는 걸 좋아하는 경우가 있었다.
- 필요 이상의 완벽주의가 있다. 코드 품질에 대한 스스로의 압박이 있다.
- 생각하는 것에 시간을 많이 소비한다.

출처

https://codingnuri.com/seven-virtues-of-good-object/
https://developerfarm.wordpress.com/2012/01/26/object_calisthenics_1/
https://ui.toast.com/weekly-pick/ko_20200708/