[나는 인턴 6] 우리끼리 개발 ≠ 같이 개발

(사진은... 나두 SLASH21 참여했다...구ㅎ 아니 들었다구,,,ㅎ)

지키는게 좋다고 배웠지만 우리끼리 개발할 때는 크게 신경쓰지 않은 것들이 조직에서 함께 개발할 때는 중요한 것들이 있더라.

 

1.  PR과 commit 단위는 완성 된 코드를 올려야 함

옛날에는 자잘한 버그가 있더라도 일단 커밋 날리는 것에 의의를 뒀던 것 같다. 지금 생각하면 왜 그랬는지 모르겠지만.

하지만 언제든지 제 3자가 특정 PR 또는 특정 commit의 코드를 받아 볼 수 있음을 염두해야 한다.

당장 나 같은 경우에도 어떤 기능의 변화를 보기 위해 총 3개 버전의 코드를 다운 받아 보았고 실행시켰다.

만약 미완성 된 코드를 올려놨다면 더 많은 설명을 필요로 했겠지.

 

2. 알아서 잘 해줬겠지 라고 생각하지 말기

여태까지는 앞으로 개발할 것들이나, 그라운드 룰 같은 것들을 참여하는 인원 모두가 0부터 함께 말을 맞춰 나갔지만

큰 조직은 그렇지 않으므로 이해가 되지 않는 부분이나 추가 설명이 필요한 부분은 반드시 설명을 요청해야한다.

오해는 눈덩이를 불러일으키니까.

 

3. 주석은 정말 도움이 된다

같은 분야의 개발을 하면(iOS, AOS, Flutter 등) 코드 리터러시가 있어서 매우 짜임새가 좋은 코드가 아니더라도(예를 들면 내 코드라던지 내 코드라던지 내 코드) 어느정도 파악이 가능하다. 하다 못해 파일명이나 함수명 등도 유추로 찾아낼 수 있다.

그런데 분야가 바뀌면 다른 얘기다.

예를 들어 "흠.. 이 기능을 안드로이드에서는 어떻게 짰지?"가 궁금하다면 자바나 코틀린 코드를  볼 수도 있는데,

일단 열고나서부터가 막막하다.

그런데 주석이 잘 되어 있으면 검색도 용이하고 코드 흐름 자체도 파악하기 좋다.

 raywenderlich.com 정도로 자세할 필요는 없지만

함수 역할, 분기처리, 실제 앱에서의 동작방식 등

 

4. (또 뭐가 있을까... 생기면 채워 넣어야지)