[2020/04/01] 오늘의 개발하면서 느낀것

신입개발자로 입사해서 현업으로 개발하다보면, 여러가지 문제에 직면하게 된다.

오늘은 만났던 문제들 중에 꼭 고쳐야겠다는 생각이 들었던 점들을 나열해 보려고 한다.

 

1. 시나리오 이해

코딩을 어느정도 하면서부터 시나리오 이해의 중요성에 대해 생각해보게 됬다.

팀단위로 보통 개발을 하게 되면 다른 곳은 잘 모르겠지만, 보통 역할이 나누어져 있고, 업무를 분할하여 진행한다.

 

물론 기업 규모나 조직 특성 및 개인 기량에 따라, 감당하는 수준이 다를 수 있다고 생각한다.

 

처음 프로젝트를 시작하면 필요성에 따라 시나리오를 구성하기 마련이다.

모든 팀원이 시나리오 구성을 함께 한다면 문제가 없겠지만, 시나리오를 전달 받는 개발자가 시나리오의 목적과 내용을

컴팩트하게 이해하지 못하는 경우 문제가 발생한다.

 

본인은 이해했다고 생각하더라도 어떤 이유로 잘못 전달된 내용이 있다면 조금씩 개발이 산으로 갈 수 있다.

 

2. 초기 프로젝트 구성

초기 프로젝트 구성을 가볍게 생각했다가 큰 낭패를 본적이 있었다.

일회용 개발로 생각하고 가볍게 개발하다가, 목적성과 시나리오에 맞지 않게 개발이 되었고

처음 구성을 쉽고 편하게 짜면서, 점점 수정을 하다가, 밑도 끝도 없이 산으로 가버린 적이 있다.

 

이 때 날린 기회비용은 많은 시간과, 스트레스, 신뢰성등으로 후회가 많이 남았었다.

다시는 이런일을 겪지 않기 위해 중요하다고 생가가하게 된것이 바로, 초기 프로젝트 구성을 잘하고

프레임에 벗어나지 않도록 규격에 맞게 개발해야 보다 관리하기 좋은 프로젝트가 될것임을 알게 되었다.

ps. 디자인패턴, 자료구조, 알고리즘을 적절히 활용할 줄 알아야 한다.

 

3. 리팩토링

회사에서 추진하는 프로젝트란 혼자 개발하고, 혼자만 쓰는 코드가 아니다.

예를들어 서버와 클라이언트로만 개발을 하게 되더라도, 기본적인 데이터 규격 및 사양을 정하기 마련이며

서버에서 개발을 할땐, 기능별로 파트를 나누기 마련이다.

 

어떤 기능개발을 하게 된다면 기본적인 라이브러리를 활용하여 개발하는 경우가 대부분이며, 다른사람이 짰던 코드를

보게 될 일이 많고, 같이 개발을 하게되는 경우에도 마찬가지로 남이짠 코드를 봐야할 일이 많다.

 

따라서, 다른 팀원이나 누가보더라도 보기 좋은 코드, 즉, camel_case든 snake_case든 명칭 규격과 네이밍에 대해서도

깔맞춤을 하고 개발을 해야 일의 능률이 올라가며, 이는 신이이 갖춰야할 기본 소양이라고 생각한다.

함수간의 간격, 줄바꿈, 띄어쓰기 등등의 규정을 맞춰야 한다.

 

이러한 규정을 맞추지 않고 개발했을 때 함수인지 변수인지 헷갈리는 상황이 발생할 수 있으며, 헷갈리는 부분을 설명해야

하는데 시간을 할애해야 하는 경우도 생긴다.

 

규격이 맞춰진 다음에는 단위테스트 (TDD)와 같은 테스트를 통해 기본 프레임에 덧붙여지는 피와 살 같은 코드들을 컴팩트하게

짜야 추후 완전한 서비스로 거듭나게 되며, 리팩토링을 통해 보다 좋은 방법으로 고도화, 최적화가 된 코드가 될것이다.

 

4. 커뮤니케이션

입사전 자격요건과 같은 항목들을 보다보면 흔히 볼 수 있는 멘트이다. 커뮤니케이션이란 뭘까? 아직도 명확히 이야기할 수 없을것

같은 질문이지만, 실무를 하면서 몸으로 느낀바가 있다.

 

팀단위 개발에 있어서 커뮤니케이션이 안된다면? 한가지 예를 들어보자

일을 주는사람 또는 일을 전달해주는 사람은 반응형 동영상 플레이어를 만들고자한다. 반면에 일을 받아 개발하는 사람과

용어 또는 의사전달이 제대로 되지 않을시 일을 전달 받고 난 후, 알겠다 하고 막상 개발을 했지만 나는 비반응형 동영상 플레이어를

만들어야 한다고 들었다. 하여 의도한바와 다르게 일을 한 경우가 가끔있다.

 

이런 경우 정말 끔찍한 결과를 초례하게 된다. 시간이면 시간, 서비스 스케줄에 차질, 다른 팀원과 빚어진 마찰, 금전적인 손해등

어머어마한 여파가 생길 수 있다.

 

이러한 문제가 발생하지 않으려면, 적어도 업무가 생겼을 때, 제대로 알아들었다고 생각하더라도, 잔소리를 듣던 꾸중을 듣던

제차 확인을 하는것이 낫다, 나중에 불거질 수 있는 문제를 생각한다면, 당연한 방향성이다.

 

또한, 신입 떄는 커뮤니케이션이 원활하지 않은게 당연할 수도 있다, 그저 당연하다고만 생각하지 말고, 내가 잘못들었을 수도 있다라는

생각을 가지고, 확실히 확인하면서 또는 중간중간 확인을 받도록하여 문제가 생기지 않도록 하자.

 

이럭식으로 공부하고 경험하다 보면, 나는 자연스럽게 원활한 커뮤니케이션이 가능한 사람이 될 수 있을 것이다.

5. 컴퓨터사이언스 지식 

생각한 프로젝트를 실제로 구현할 때, 급하면 항상 자주쓰던 자료구조, 자주쓰던 알고리즘을 기반으로 코드를 짜기 마련이다.

그러다 보면 어떤 상황에서는 보다 유용한 자원활용과 빠른 처리가 가능한 알고리즘이 있음에도 불구하고 활용하기 어려운 경우가

많다.

 

이를 해결하기 위한 대책은 아직 구체적으로는 모르겠다.

그래서 틈틈히 자료구조에 대해 공부하고, 가끔이지만 알고리즘 문제를 풀어보는 것이 지금 할 수 있는 준비라고 생각한다.

가끔 토이프로젝트를 하거나 오픈소스에 기여하는것도 좋다.

또한 부족한 지식을 채우기 위해, 좋은 멘토님이 어떤걸 공부해야할지 모를때 보고 공부하라고 하셨던 링크를 남겨두려고 한다.

갑자기 막다른 골목에 들어섰을 때, 아래 링크를 보면서 정리하고, 해야할 일을 찾아보자.

 

https://sites.google.com/view/dudaji

Learn more, share more