2번째 스타트업.

Xonic·2022년 10월 16일

글을 세세하게 적는 스타일이 아니라 글이 두서가 없더라도 이해해주길 바랍니다.

좋은 코드를 작성하는 것이 목적인가?
- 근데 또 비즈니스가 안되면 아무리 좋은 코드를 작성해도 무용지물이 되는 거니까 trade off 에 대해서 또 생각하게 되는 것 같다
비즈니스를 성공 시키고 싶은게 목적인가?
아니면 좋은 개발자가 되는게 목적인가..
답을 아직은 찾지 못하겠다.
다만 지금 회사에선 뭐든 다 잘하고 싶은 마음이 큰 것 같다.

지금 만 11개월 가량 경력이 쌓였는데 과연 뭐가 나아졌을까..?
모르겠다.. 음 대충 생각 나는 건 코드 읽는 능력, Layered Architecture에서 Layer 별 의존성 관리 및 유지보수에 유리한 코드를 작성하려는 마음가짐?..
- Java -> Golang으로 기술 스택을 변경하기도 했구나..
요즘엔 유지보수에 유리한 코드, 테스트 코드를 작성하고 이런 것들은 너무 당연하게만 느껴져서 그건 다행인 점 인 것 같다
- 이전 회사에서는 시간에 쫓겨 테스트 코드는 개뿔.. 결합도 무쟈게 높고, A 기술 이해도가 부족한 사람이 A 기술을 사용하여 똥을 뿌린 코드를 땜빵질한다고 고생했었지 나...

최근 팀원과 커뮤니케이션을 하는 과정에서, 용어가 통일되어 있지 않고 대화가 원활하지 못하다는 느낌을 받았다.
커뮤니케이션 또한 업무에서 중요한 요소인만큼 막힘없이 술술 진행되기만을 바라는 것은 아니었지만, 적어도 우리의 원활한 커뮤니케이션을 방해하는 것이 무엇인지는 알고 있어야 할 것 같았다.
이 고민이 시작된 출발점으로 돌아가보면, 팀에 새로운 개념을 도입하던 때 우리는 몇가지 중요한 부분을 간과했다.

우리가 DDD 로 설계를 하든 TDD로 개발을 하든, 우리의 Architecture가 Layered 이든 Haxagonal 이든, 결국 목적이 변화에 빠르게 대응 할 수 있는 코드를 작성함이 아닌가?
중요한 점은 그 개념에 대해 팀원이 "모두" 다 잘 이해하고 있어야 하는 것이다.
하나의 개념이 나오면 나온 이유가 있을 것이고, 거기에서 나온 표현에 대해서 정확히 이해하고 팀에 도입하는게 중요하지 않을까?
그러므로 우리는 Comm에 유리한 고지에 오를 수 있는 것이라 생각한다.

예를 들어 DDD가 무엇인지 모르는 사람에게 Repository가 뭔지 장황하게 설명해봤자 DDD를 모르면 Repository라는 표현을 정확하게 이해하지 못할 것이다.

내가 궁극적으로 하고 싶은 말은, 어떤 새로운 개념을 팀에 도입하고, 적용하며 스터디를 하는 행위 자체가 우리 팀의 표현을 align 시키는 과정이며 커뮤니케이션을 원활하게 만드는 매개체가 된다.

자신이 팀에 어떤 불합리와 불편함을 개선하고자 새로운 개념을 도입할 때 이 과정에 도움을 주지 않거나, 거부만 하는 팀이라면 주저없이 나와라.
거긴 그대로일 것이다.

이 주제에 대해선 굉장히 생각 해야할 점도 많고, 의도적 연습이 필요한 부분인 거 같은데, 내가 작성한 코드가 나에게도 당연히 잘 읽혀야하지만 더 중요한 건 다른 사람이 봤을 때 잘 읽혀야 하는 것이다.
잘 읽히려면 어떻게 해야할까?
- 표준을 적용하는 것이다. ( ex. Golang Standard Project Layout, Web Standards etc..
- 익히 알고 있는 표현을 이용한다.
  - 디자인 패턴( ex. GOF Singleton, abstract Factory etc..), CS 기반 용어 ( ex. Merge Sort, Bubble Sort, Heap, Stack etc..)
- 당연히 코드를 적는 "나" 자신 말고 신입이던 경력이던 내가 적은 코드를 볼 다른 사람을 생각하며 작성해야한다.
이 부분에 관해선 요즘 프로그래머의 뇌라는 책을 읽고 있는데, 좋은 길라잡이인 것 같다.

공부 한 것을 공유하는 블로그입니다.