ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 정의로운 개발자
    카테고리 없음 2015. 11. 22. 18:39

    요즘 송곳이라는 드라마를 재미있게 봅니다. 이수인이라는 푸르미 과장이 등장하는데 불의를 못참고 오지랍 넓게 이를 바로 잡으려 노력합니다. 보통 사람이라면 개인의 이익이 부합되면 정의로움을 포기하는데 그렇지 않고 계속 정의를 추구하는 데서 작가는 이런 사람들을 송곳같은 사람이라고 표현하고 있습니다. 

    개발에서도 정의로움이 있다라는 것을 요즘 깨닫습니다. 보통 개발하면 일정을 준수하면서 설계 당시의 퀄리티를 준수하면 모든 목표가 완료되는 것으로 압니다. 절~대 그렇지 않습니다. 특히 개발자가 아니면 볼 수 없는 그 이면의 퀄리티들이 굉장히 많이 존재하는데 이런 부분들은 정의로운 개발자가 아니라면 무시해 버리기 십상입니다.


    첫째 자동화 알고리즘의 도입입니다. 운영 인력이 들어가는 서비스의 경우 개발자들은 매순간 선택하게 됩니다. 조금만 더 공을 들이면 자동화시켜서 처리가 가능하지만 편하자는 유혹을 이기지 못하면 그냥 수동 운영을 하도록 만들어 버립니다. 자동화 여지는 담당 개발자외에는 판단하기가 어렵기 때문에 보통 관리자나 운영자, product manager들은 잘 모릅니다. 그러나 담당 개발자는 분명 알고 있죠. 내가 쉽게 타협했다는 것을. 해당 서비스가 이런 수동 운영 기능이 계속 누적되어 몇 년 지나면 겉에서 보기에 아주 지저분한 시스템이 되어버리고 맙니다. 이런 시스템들 널려 있죠. 다 순간의 편함들이 누적되어서 그런 겁니다.


    두번째 테스트 코드입니다. 단위 테스트가 불필요하네 통합 테스트가 어쩌네 해도 어떤 식으로의 테스트 코드도 모두 추후의 복잡성이 증가했을 때 아주 큰 역할을 해 주게 됩니다. 즉 아주 조그만 어떤 테스트라도 넣어 두면 도움이 된다는 겁니다. 그러나 테스트 코드는 당장의 소프트웨어 퀄러티와 납기일에 영향을 주지 못합니다. 따라서 단기 성과에 급급한 조직이라면 테스트 코드는 신경쓰지 않게 됩니다.


    세번째 코드 리뷰 입니다.  1년 이상 온라인 상의 리뷰를 했는데 개발자의 수준이 일정이상이 되는 사람이 많으면 꽤 도움이 됩니다. 코드 리뷰가 제대로 되려면 A급 개발자들이 많아야 합니다. 


    위에서 언급한 요소들은 개발자입장에서는 단기간의 성과를 가져다 주지 않기 때문에 크게 신경쓰지 않는 개발자들도 많습니다. 특히 6개월 단위 단기 평가를 하는 조직의 경우는 더 심합니다. 따라서 저는 이런 장기적인 안목의 요소들에 신경쓰는 개발자를 '정의로운 개발자'라고 부르고 싶습니다. 이런 사람들은 그저 제대로된 소프트웨어를 만들고 싶다는 그 일념 하나로 이런 일들을 하기 때문입니다. 6개월 앞이 아닌 2-3년 후의 시스템의 복잡성을 내다 보고 현재의 스트레스를 앉고 알고리즘도 만들어 보고 테스트 코드도 넣고 코드 리뷰도 왕성하게 해 나갑니다. 이런 정의로운 개발자가 많은 조직이 결국 우수한 조직이 됩니다. 




Designed by Tistory.