Image by Riebart via Flickr



MSDN 2014년 10월호에 실린 기사.


원문: http://msdn.microsoft.com/en-us/magazine/dn802600.aspx

요약: 쉽게 읽히는 코드를 작성하자. - 주석, 일관성, 명료성.



유지보수

  • 읽기 좋은 코드가 이해하기도 쉽다.
  • 자신이 완벽하게 이해하지 못한 상태에서 코드를 작성하면 읽기 어려울 뿐만 아니라 나쁜 코드가 된다.
  • 불행히도 가독성은 지극히 주관적인 문제이다.
  • 그러나 동료를 위해서, 읽기 좋은 코드를 작성하는 것은 책임감있는 개인개발자의 자질이다.
  • 가독성 좋은 코드를 작성하는 것은 전문가의 몫이 아니며, 초보때부터 노력해서 점차 개선해 나가야 하는 것이다.
문제가 있는 코드들은...
  • 명확한 목적 없이 사용된 자료구조나 알고리즘.
  • 판단하기 어려운 명쾌하지 않은 전략
  • 적절한 주석이 없는 코드.
  • 의도가 명쾌하지 않아 읽는 사람의 시간을 낭비하게 만들지 말자.
==> 코드의 작성 의도를 읽어버리지 않도록 코드 가독성을 고려하자.

가독성 좋은 코드
  • 주석, 일관성, 명료성의 환상적인 배합.
  • 주석
    • 뻔한 주석은 달지 말자. 관련 정보도 주지 않고, 그냥 잡음에 불과하다.
    • 주석은 코드를 척 봤을 때 명확하지 않은 부분을 설명해 주는 문장이어야 한다.
  • 일관성
    • 코드 작성 가이드라인을 따르자. 전사 차원의 가이드라인이 있다면 더 좋다.
    • 처음 작성할 때부터 깔끔한 코드를 작성하자. 나중에 따로 깨끗한 코드를 작성하기 위한 시간을 두지 말자.
    • 팀 리더라면 소스코드를 체크인할 때 코드 일관성 가이드라인을 강제해야 한다.
  • 명료성
    • 보통 잘 읽혀지고 쉽게 이해되는 코드는 명료한 코드이다.
    • 적절한 그룹핑과 네스팅.
  • 기타
    • 코드가 길면 사람이 읽기 어렵다. 보통 30줄 이상 넘어가면 리팩토링해달라는 신호로 받아들이자.
    • 중복된 코드나 사용되지 않는 코드를 확인하자. 필요하다면 도구도 사용하자. 닷넷은 reSharpener의 명령행 도구를 CI와 연동하는 것도 좋다. 코드 보조 도구를 사용하는 것은 좋다. 다만 한개만 사용하자. 
    • 나쁜 패턴이 사용되었는지 확인하자.


+ Recent posts