개발에 있어서...

 개발에 있어서

. 리펙토링의 개념을 제대로 알고 있는가

. 상황에 맞는 적절한 디자인 패턴을 적용할 수 있는가

. 프로그램 버전과 문서화를 얼마나 꼼꼼히 하는가

. 최신 기술에 관심이 있는 사람인가,

. 팀의 업무 문화와 수준을 올려줄 수 있다는 믿음을 주는 사람인가,

. 팀 작업에 중점을 두는가, 본인에게 익숙한 것에 중점을 두는가,

 

개발 전

. 툴 활용 능력이 아예 없는 사람은 아닌가?

. 자기 생각을 먼저 정리하고 문서화 하는가,

. 다른 사람과의 대화를 통해 목적을 뚜렷이 하는가,

 

 

개발 중

. 사용하는 라이브러리나 프레임워크에 대한 지식이 있는가,

. 설계의 간소화를 위해 노력하는가, 그리고 구현하는가,

. 최신 기술을 얼마나 효율적으로 적용해 프로그램의 질을 향상하는가,

. 툴이 알려준 경고들에 대해 얼마나 잘 대처하는가(경고는 경고가 아니다. 잠재적 버그다.)

 

개발 후

. 작성한 코드의 장단점을 파악하고 있는가,

. 마지막으로 자신의 코드에 책임지는 사람인가?

 

 

1. 기술도 물론 중요하지만 ‘경험’이 더 중요하다.

최대한 많은 경험을 쌓는 것이 중요하다. 현업 개발자에게 가장 중요한 역량은 ‘문제 해결 능력’인데, 이는 혼자 하는 공부로 얻을 수 있는 것이 아니다. 경험을 쌓을수록 문제를 미리 예측할 수 있으며 어떠한 상황에도 유연하게 대처할 수 있는 능력을 기를 수 있다.

나도 수많은 경험을 했지만, 개발은 끝이 없는 영역이기에 여전히 예측할 수 없는 문제들이 많다. 끝없이 몸으로 부딪히며 ‘문제 해결력’을 기르는 것이 중요하다. 이제 막 개발 분야에 입문했거나 경력을 쌓고자 하는 주니어 개발자라면, 여러 제품을 개발하며 경험을 쌓는 것을 권한다.

 2. 모르는 것을 부끄러워하지 마라

실력이 부족한 개발자는 나쁜 개발자가 아니다. 나쁜 개발자는 자신의 부족한 점을 드러내지 않는 사람이다. 이런 사람은 협력하는 팀원들을 힘들게 만든다. 모르는 것을 모른다고 해야 모두가 행복해진다. 모르는데 아는 척을 하는 순간 본인 뿐만 아니라 모든 이들의 불행이 시작되는 것이다.

아는 척을 하면 그 순간에는 사람들의 눈총이나 부끄러움을 피해갈 수는 있지만, 결국 전체적인 업무 효율은 떨어지게 된다. 그에 대한 책임은 팀원들이 지게되는 것이다. 그러니 솔직하게 말하며 학습해 나가는 것이 최선의 방법이다. 모름을 인정할 때 업무가 효율적으로 돌아간다.

3. 나를 성장하게 하는 남의 코드

동료의 어떤 코드라도 읽어보고, 분석해보라. 그게 잘 쓴 코드든 못 쓴 코드든 다른 사람의 코딩을 접하는 것은 자신의 실력을 높이기 위한 좋은 방법이다. 또한 이는 갇혀있던 우물에서 벗어날 수 있는 지름길이다.

세상에는 실력이 뛰어난 개발자가 정말 많다. 그만큼 배울 수 있는 기회가 많다는 뜻이다. 어떤 방식이든 괜찮다. 똑같이 배껴 써보는 방법도 좋고, 상대방의 코딩을 리뷰해주는 것도 좋다. 그 과정에서 어느새 개발을 바라보는 시야가 넓고 깊어진 자신을 발견할 것이다.

4. 남을 성장하게 하는 나의 코드

Open Source 활동을 자주 할 것을 권한다. 내 기준으로 짠 코드를 타인의 입장을 고려해 정리정돈할 수 있기 때문이다.

Open Source 활동을 하면 말 그대로 자신의 코드를 공개하는 것이기 때문에 누구든지 부끄러움을 피하고 싶은 생각에 보다 큰 공을 들여 코딩을 하게 된다. Method 이름 한 개조차 가볍게 적을 수 없다.

 

협업에 대해

1. 합리적인 일정 산출

전체 프로젝트 기간에서 기획과 개발 일정을 정해 두었더라도 막상 실제 프로젝트가 시작되면 초반 기획 부분에서 생각보다 많은 시간을 할애하게 되는 경우가 많다. 그런 변수가 생기면 프로젝트 진행 속도가 느려지게 되고, 결국 이는 개발 기간의 단축으로 이어지기에 프로젝트의 전체 완성도가 떨어지게 된다. 따라서 전체 기간 중에 세부 목표를 설정하여 기간을 나눠 합리적인 일정을 짤 수 있어야 한다. 너무 짧지도, 그렇다고 너무 길지도 않아야 한다. 최대한 많은 변수들을 고려해 일정을 짜고, 그 안에 완수하도록 노력해보기를 권한다.

 2. 주석이 필요 없는 코드를 짜라

현업에 들어가면 혼자서 코딩하는 일은 없다. 하나의 프로젝트에 다양한 사람들이 직·간접적으로 참여하기 때문에 여러 이해관계가 얽혀있다.

그렇기 때문에 내가 구현한 결과물을 이해시키고 함께 더 나은 결과물을 만들고자 할 때 함께 일하는 사람들이 알아보도록, 그래서 커뮤니케이션이 원활하게 이뤄지도록 코드를 짜야 한다. 기능을 구현하는 것은 스스로 노력해서 만들어낼 수 있지만, 프로젝트에서 생각보다 많은 시간이 투입되는 부분이 바로 이 커뮤니케이션 부분이다.

사람들이 쉽게 이해할 수 있는 코딩에 대해 로버트 마틴이 저술한 <Clean Code>는 다음과 같이 말하고 있다. ‘코딩을 할 때 코드 앞에 주석을 달지 마라’. 이는 주석이 있는 것 자체로 가독성이 없는 코딩임을 암시하고 있는 것이기 때문이다. 주석이 없어도 남이 보고 이해할 수 있는 코드를 짜야 한다.

 3. 누군가의 이슈는 모두의 이슈다

팀은 하나의 서비스를 위해 달린다. 디자이너도, 기획자도, 개발자도 모두 하나의 서비스를 런칭하고 버전을 업데이트 하며 오롯이 하나의 목표를 위해 최선을 다한다.

그렇기 때문에 한 명의 이슈가 팀원 전체의 이슈라는 생각으로 프로젝트를 진행해야 한다. 만약에 디자이너, 기획자, 개발자가 팀을 이뤄 11월 30일에 서비스를 런칭할 예정인데, 개발자가 발견한 중대한 에러로 인해 계획된 일정보다 3일정도의 시간이 더 걸리게 됐다면 이는 개발자 한 명의 이슈가 아니다.

따라서 팀으로 활동할 이들에게 발생할 이슈는 곧 팀원 모두의 이슈이기 때문에 작은 이슈라도 팀 내에서 공유가 원활해야한다. 자신에게는 작은 일이 팀 전체에게는 큰 여파로 다가올 수 있기 때문이다.