개발자 대화법

실제 실무에 계신 튜터님과의 수업을 통해서 개발자는 어떤 식으로 대화 해야할까? 우리가 추구 해야할 대화 방법은 무엇일까에 대한 고민과 개념을 한번 더 정립하였습니다

 

대화의  핵심

개발자는 명확한 목적과 의도를 담은 "함수" 로 대화한다.

이게 무슨말일까요?

우리가 대화할때 목적과 의도 없이 대화한다면 그건 건설적인 대화일까요? 실생활에선 입, 문자 라는 수단을 통해서 이런 목적과 의도를 담은 말을합니다.

우리 개발자는 함수라는 수단을 통해서 대화를 하게됩니다.

 

대화의 전달력

개발 언어도 언어입니다. 잘 읽히는 글을 써야 대화 내용이 잘 전달 됩니다.

 

1. 대화가 되는 말 만들기.

BigDecimal calculateDiscount(int price)

Invoic generate(int value)

이런 두가지 함수가 있을때 무엇이 더 좋은 함수명일까요?

당연히 위에 함수가 더 명확해보입니다. 

이를 수업에선 영어의3형식에 빚대어 표현 해주셨습니다.

 

반환형 : 주어 // 무엇에 대해서 이야기하는가?

함수명 : 동사 // 무엇을 하려고 하는가?

파라미터 : 목적어 // 대상은 무엇인가?

꼭 이렇게 영어에 똑같에 만들지 않아도 좋지만, 이런식으로 작성하려 해보면 좋은 의미를가진 함수명이 나올수있다고 생각합니다.

 

2. 무엇을 말 할지 명확하게 표현

bad : dataProcess();
good : calculateTotalCount();

위에 두가지 케이스 처럼, 이 함수에서 내가 무엇을 하고자 하는지 명확하게 작성해야 합니다.

단순 "데이터 처리" 보단 "전체 카운트를 계산한다" 같은 메서드명을 작성하는게 좋습니다.

 

3. 하고자 하는 말을 정확하게 표헌

public boolean check(int num) {
	return num >= 1440;
}

이런 함수에서 여러분들은 1440이 무엇인지,무엇을 위한 체크 인지 알아 볼 수 있나요? 선생님이 의도는 24시간을 분으로 표현했을때 1440분, 그러나 학생들은 해상도인가? 하는 생각을 가지더라구요, 이렇게 말하고자 하는것을 정확하게 표현 해주지 않으면 의사소통과정에서 문제가 발생합니다.

int mintesOfDay = 1440 같은 매직넘버로 표현 해주는것이 좋습니다.

 

4. 어려운 말은 쉽게 표현

if(user.isActive() && ... && ...) {}

여러 조건 이있어서 사람들이 한번에 알아보기 힘든 경우 canAccessPremiumMember() => 같은 표현으로 대체하여 한눈에 알아 볼 수 있게 만들어줍니다.

 

5. 목적과 맥락에 따른 표현

public void sendWelcomeEmail();
반드시 하나의 목적만 얘기하기 위한 대화.
public void sendEmail();
목적어 표현을 통해 다양한 상황에 대응 가능한 대화.

 

매개 변수는 몇개 정도가 좋을까? 

>>>> 현업에선 3개정도, 필요에 따라 객체로 전.

목적어가 많으면 의미 전달이 어렵다.

 

6. 상황에 맞는 표현

stop vs terminate : stop은 일시정지의 느낌이 강하고 프로세스 종료는 terminate 가 적절하다.

find vs order : find는 있을 수도있고 없을 수 있지만 get은 비지니스 유스케이스상 반드시 존재한다는 약속을 담은 표현 (그 값이 null일지라도)

validate vs check : 엄격한 검증 vs 정당한 확인

 

7. 모두가 쉽게 이해되는 단어 선택

어떤 활동의 보상이 사용자엑세 주어지면 사용자 입장에서 Item vs Reward?

item은 물리적이거나 구체적인 객체를 의미

Reward 는 보상의 개념을 조금 더 넓게 아우름 

>> 모호한 상황이라면 포관적이고 의미 전달이 쉬운 단어 선택

 

* 잘못된 상황에서 주는 경고도 reward인가?

XXXX penalty 가 더 적절할 것이다.

 

*유비쿼터스 언어 : 도메인 전문가, 개발자, 등 프로젝트의 다른 이해관계자들이 모두 동일하게 사용하는 공통의 언어 또는 단어.

 

8. 정리된 내용을 전달(Refactoring)

- ealry return처리

- magic number 제거 

- extensions 분리

- 변수, 함수 네이밍

- 기호 작성 순서 변경

- hard coding 제거

등등 다른 사람들이 한눈에 확인 하기 쉽게 리팩토링을 해보는 것이 좋습니다.

 

9. 대화 전달력의 핵심

흔히 말하는 SOLID 원칙에서 S는 Single Responsibility Principle 단일 책임 원칙을 의미합니다.

이는 하나의 클래스 또는 모듈에서 하나의 책임(기능) 을 담당해야 한다는 원칙이고, 

여기서 중요한건 변경되어야 할 이유도 오직 하나 라는 점 입니다.

 

10. 대화의 자세

로마에 가면 로마의 법을 따르라 처럼 각 회사, 팀 마다 거기에 맞는 규칙과 컨밴션이 있을겁니다.

자신의 생각이 옳다고 생각해서 그것을 따르지 않으면 안된다는 것입니다.