어떻게하면 시간이 부족해도 코드를 잘 작성할 수 있을까?

이번 프로젝트를 진행하며 고민이 많다.
어떻게해야 코드를 더 잘 작성할 수 있을지 사실 나는 고민을 잘 해보지 않았는데 이번 함께 팀이 된 사람들의 스타일이 나와는 다르게 고민을 많이 하는 스타일이라 어떻게 해야할지 계속 생각을 하게된다.
원래 당연하게 생각했던 부분을 왜 이렇게 해야하지? 라는 생각도 좀 해보고 코드를 작성하고 PR을 날렸을 때 코드 리뷰를 하게되며 이게 맞는지 저게 맞는지 이야기도 해보고..
멘토님과도 이야기를 해보며 생각 정리를 좀 해봤을 때 내가 이번 프로젝트에서는 다음과 같이 진행하기로 마음먹었다.

1. 잘 모르겠을 때 최대한 반복을 줄이는 방식으로 코드를 작성하자.

사실 너무 당연한것 같지만 이 부분을 놓쳐 내가 코드를 마구잡이로 작성하고 있는 느낌을 받았다. 너무 당연하게 다른 방식으로 코딩했지만 결국 불필요한 반복이 계속 되는 부분이 있었다. 왜 그때는 생각 못했을까 하지만 지금이라도 알아서 너무 다행이다.

2. 처음부터 완벽을 추구하는것이 아닌 오답만이라도 거르자

코드를 처음부터 완벽하게 짜려고 하지말자

자신의 코드에 대한 확신도 없고 그렇다고 남의 방법이 완전히 납득이 가서 그렇게 하는것도 아닌 우리의 상황.. 코드를 완벽하게 짜려고 하는 욕심이 있었기 때문에 이도저도 못하는 상황이었던 것 같다. 이때는 일단 오답만 피해가고 나중의 내가 잘 처리하도록 넘기도록하자. 이 결정은(리팩토링지옥) 조삼모사의 상황이 될 수도 있다. 하지만 이게 결국 나의 귀중한 경험이 될것이며 빠르게 개발을 끝냈을 때 리팩토링을 하는 방식이나 추가 기능을 더하는, 내가 볼 수있는 엔딩의 개수가 많아지는 방법으로 가도록하자.
같은 시간에 한번 경험을 하는것보다 두세번 경험하는게 더 효율적이지않을까.
그렇기때문에 프로젝트를 마쳐야하는 상황에서 코드 작성 방식에 대한 견해가 다를때는 망나니를 정하자라는 룰을 추가해보면 어떨까한다.

사실 코딩 방식이 달랐을때도 단지 한쪽은 돌아가는 느낌이었지 둘다 맞는 방법이긴했다. 오답이 아니었다. 어떤 방식으로해도 조금 비효율의 문제지 기능에는 문제는 없으므로 그 방식을 적용하기로 결정해보고자한다.

마무리

결국 이 과정도 내가 코드를 좀 더 효율적으로 짤 수 있는 밑거름이 될 수 있는 귀중한 자신이 될 것이다. 예전의 팀에선 잘하는 사람을 따라가기 급급해서 이런 생각을 하지 못했는데 이번에 이렇게 생각할 수 있는 기회가 있어 좋은것같다.
(하지만 시간은 부족하다..ㅜ)