코드를 작성하는 역량과 읽고 분석하는 역량중 더 중요한 것은

현재 노트: KR-410.10 a 우아한테크코스 프리코스 7기 2주차 - 목표 수정과 depth 및 eslint
상위 분류: KR-410.10 우아한테크코스 프리코스 7기 회고록 1개월 기록

#성장경험 #개인학습과회고

코드를 작성하는 역량과 읽고 분석하는 역량중 더 중요한 것은?

어느날 누군가에게 다음과 같은 질문을 들었을 때 해당 질문에 대합 나름의 답을 정리해본 글입니다.
먼저 해당질문에 답변하기전 개발자로서의 코드의 영역과, 코드 에서도 작성의 영역이 얼마나 차지하는 지를 정리해 보았습니다. 현직 개발자 출신의 지인들이 다음과 같은 이야기를 들려 주었습니다.

"하루종일 회의하다가 오후 6시정도 퇴근할 때 되면 그 때 부터 코드를 작성하기 시작한다"

다른 사람의 코드를 보는 시간이 7할, 내가 코드를 작성하는 시간이 3할 인것 같다

그리고 저의 엔지니어 출신의 경험인

변수명 하나 정하는데 2시간 회의를 했지만, 결국 정하지 못한 경우

소통이 약 60%

이런 점들을 종합적으로 고려해봤을 때 먼저 개발에서 소통이 차지하는 부분이 약 60%라고 생각합니다. 같은 팀 뿐만아니라 다른 팀과의 소통, 기획자와 같은 다른 부서의 소통까지 포함하면 어떤 것을 할지, 어떤 것이 가능한지등을명확히 하는 과정이 많은 비중을 차지한다고 생각합니다.

레거시코드 분석 및 레퍼런스 검색등 다른 사람의 경우 30%

그리고 이어서 레거시 코드의 분석 및 탐색이 30%정도라고 생각합니다. 만약 모든 것을 처음부터 나혼자 새로시작하는 환경이 아닌 이상 대부분의 레거시 코드가 있고 레퍼런스를 검색할 수 있는 상황에서 자유분방하게 시작하기는 힘들것 이라 봅니다. 최소한 지금까지 내가 맡은 파트에서는 어떤 식으로 작성하고 있었는지 히스토리를 알고 있어야 기존의 것을 확장하던, 유지보수하던, 또는 연동할 수 있는 무엇인가를 개발할 수 있다고 생각합니다. 그리고 중요한 것이 시간과 노력을 아껴줄 수 있기 때문입니다. 단 몇줄의 코듣도 해당 기능이 동작하기 위해 무수히 많은 프로세스의 고려하에 만들어진 경우가 있을 수 있는데, 이런 점을 쉽게 배우고 활용할 수 있기 때문입니다. 없는 것을 만드는 것도 중요하지만, 이미 있는 것을 잘 활용하는 것도 중요한 역량이라고 생각합니다.

내가 무엇을 할지, 무엇을 해야하는지 확정되면 코드작성 10%

이제 남은 코드 구현이 10% 정도를 차지한다고 봅니다.
순서대로 보자면 60%정도 소통을 통해서 무엇을 할지, 무엇이 가능한지, 무엇이 안되는지, 언제까지 할지 등을 종합적으로 고려해서 그래 이걸로 하자! 가 된 이후에는
먼저 레거시코드나 레퍼런스 검색등을 통해 비슷한 고민에 대해 구현한 경우, 장단점, 등 공유 받을 수 있는 내용을 학습합니다. 그리고 이 모든 것을 통해 부족한 것과 해야할 것이 파악이 된다면
그제서야 코드를 작성하지 않나 싶습니다.

이렇게 생각하는 이유는 생각보다 우리는 요구사항을 고려하지않은 구현을 하는 경우가 많았다고 느꼈기 때문입니다. 정말 구현이 간단한 경우가 아니라면 일단 구현하고 시간과 노력을 들였는데 "그런 코드면 못써요", "그건 요구사항이 아니에요"같은 말을 듣는 경우가 많았다고 생각합니다.

누군가가 말하는 속도의 크기보다 방향성이 중요하다는 말처럼 메타인지적으로 구현하려는 목적을 항상 생각하면 구현해야한다고 생각합니다.
그래서 결론적으로는 코드 작성이라는 행위 자체는 전체 개발자 프로세스에서 10% 코드 및 레퍼런스등을 읽는 행위는 30%이며, 이 두 행위만 놓고 비교했을때는 약 1:3 비율정도로 읽는게 많은 비중을 차지 않나 싶습니다.
그래서 결론은 다른 사람의 코드를 읽고 분석하는 역량이 더 중요하다!
생각해보면 구현하다가도 "어 한국시간으로 바꿔주는 메소드있나?" 하면서 검색하고, "어 이거 에러로그 봐도 이해가 안가는데 다른 사람들은 어떻게 해결했지?"와 같은 경우가 빈번하다고 느낍니다.