그렇다.

내가 자주 하던 말이 '어쩌다 보니..그러다 보니..'였다.

그런데 이 말이 신문에 자주 소개되기 시작했다.

MBC 해직기자였던 분이 수제 스피터 장인이 된 박성제 전 기자님의 책 제목도 '어쩌다보니..그러다보니'이다.


그러나 나에게는 약간 다른 뉘앙스가 있다.

어쩌다 보니 일찍 컴퓨터를 접하게 되어, 그러다 보니 어느새 개발자의 길을 가고 있었고

어쩌다 보니 L1부터 L7레벨까지 다양한 소프트웨어를 개발하게 되었고, 그러다 보니 상대적으로 소프트웨어를 대하는 폭이 넓어졌다.(물론 면적 일정비의 법칙에 따라 깊이는;; )

어쩌다 보니 미국에서 일하게 되어, 그러다 보니 다른 시각을 가지게 되었다.


2011년 7월 처음으로 미국에서 일을 시작하면서 겪었던 낯선 느낌들을 

그동안 내가 겪어온 이야기들을 글로 나누면서 업계 후배들과 이야기를 나누고 싶었다.


미천하지만 한국 IT업계/한국사회에 다른 시각을 줄 수 있었으면 하고 바라지만,

현실은 미천할 뿐.

그래도 느낀 그대로 적어보고자 한다.


이제 시작!




https://flic.kr/p/gPYSu



Image by Riebart via Flickr



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


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

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



유지보수

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

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


+ Recent posts