[Etc] 좋은 코드 유지하기 - 1 (마인드편)
2021-05-10 22:19:36
서론
우선, 이 포스팅은 몇년 간 개발을 진행해오며 느낀 저의 생각과,
여러 책, 여러 좋은 개발자분들의 블로그에서 따 온 내용들이 혼합된 것임을 밝힙니다.
저 또한 이 노트들을 최대한 지키려고 노력하지만, 항상 시간에 급급하고 마음이 조급하여
보이스카우트 규칙을 어긴(도착할 때보다 더 지저분해진) 코드를 작성하는 일이 빈번합니다.
하지만 아예 좋은 코드를 아예 모르는 개발자와 좋은 코드를 지키려고 최소한의 노력을 하는 개발자의 코드는 분명히 다르다고 생각합니다.
무의식적으로라도 좋은 코드를 작성하기 위해서, 의식적으로 더 좋은 코드를 위해서,
그리고 또 잊을 본인을 위해서라도 이 포스팅을 남겨보겠습니다.
이 글을 마인드다잡기와, 코드다잡기로 분류해서 작성해보겠습니다.
좋은 코드 유지를 위한 마인드 다잡기
최적화보단 가독성을 먼저
코드는 항상 읽기 쉽고 개발자들이 쉽게 이해할 수 있게끔 작성해야 합니다. 읽기 어려운 코드를 읽는데 낭비되는 시간과 비용은 최적화로부터 얻을 수 있는 것보다 더욱 큽니다. 예를 들자면, 가독성을 위하여 5분간 적절한 변수명 짓는 고민이 차후에 다른 개발자(자기자신도 포함)가 1시간 고민하는 사태를 방지할 수 있습니다.
코드는 최대한 간단하고 단순하게
복잡한 코드는 개발자의 용맹함을 나타내는 지표가 아닙니다.
간단하게 작성한 코드는 버그를 줄이고 디버깅 시간도 줄일 수 있습니다.
주석은 최대한 적게
주석을 많이 사용한다는 것은 다른 사람이 그만큼 이해하기 어려운 코드라는 걸 나타냅니다.
좋은 코드는 주석 없이도 이해될 수 있어야 합니다.
메소드의 정의와 사용법을 설명하는 한 줄로 된 간단한 주석 정도가 좋습니다.
나중에 리팩토링 할거니깐 지금은 대충 짤거야
나중에 리팩토링할 시간은 열에 아홉은 없을 예정입니다. 처음 코드를 작성할 때 최대한 깔끔하고 단정한 코드를 작성하는 습관을 들여야 합니다. 차 후 다시 볼거란 다짐은 평상시 안좋은 습관을 몸에 지고 있다는 이야기와 같습니다.
컨디션이 좋지 않을땐 억지로 코딩하지 말 것
개발자들은 피곤하거나 컨디션이 좋지 않을때 평소보다 2배 이상의 버그를 만들어내곤 합니다. 회사에서 주어진 WBS 상 어쩔 수 없는 경우가 대부분이겠지만, 좋은 컨디션에 더 좋은 코드가 나올 확률이 높습니다.
DRY
Don’t Repeat Yourself - 똑같은 일은 두번 하지 않는다
당연한 얘기겠지만 같은 코드를 중복해서 작성하지 않습니다.
중복되는 함수나 코드는 하나의 공통 컴포넌트로 처리합니다.
저같은 경우도 회사에서 코드를 작성할 때 다른 팀원의 코드를 아무 생각 없이 Copy & Paste 하여 사용한 적이 많습니다. 이런 경우에도 반드시 코드를 합치거나 하나의 함수만 참조하도록 해야 합니다. 또 다음에는 누군가가 제 코드를 Copy&Paste 할 수 있으니깐요.
이러한 DRY 를 어긴 코드를 WET(We Enjoy Typing 혹은 Write Everything Twice) 라고 합니다.
KISS
Keep it simple, stupid.
알버트 아인슈타인은 “할머니에게 설명할 수 없다면 당신은 제대로 이해한 게 아닙니다.” 라고 말했습니다.
즉, 소프트웨어 디자인을 간단하고 단순하게 하는 것입니다.
프로젝트가 진행되기 전에 최대한 기반 배경과 추진되는 목적자체를 이해하고 어떻게 구현을 단순화하고 알기 쉽게 설계할 수 있을지 회의를 해서 개선해야합니다.
프로젝트를 단순하게 디자인 하지 못하고 복잡하게만 구현을 한다는 것은 프로젝트를 제대로 이해하지 못했다는 증거입니다.
YAGNI
You Ain’t Gonna Need it
정말 필요할 때까지 그 기능을 만들지 말라는 의미입니다.
현재 필요하지 않지만 나중에 필요할지도 모를 코드를 미리 작성하면 코드 자체가 길어지고, 분석도 어려워지며, 버그가 발생할 가능성이 커집니다.
YAGNI(야그니)를 지키지 않으면 야근한다 는 개발자들 사이의 우스갯소리가 괜히 있는 것이 아닙니다.😂
MySql을 연동해야하는 프로젝트이지만 Oracle을 나중에 연동해야 할지도 모르는 상황이더라도, 현재 연동할 DB만 작업해놓는 것이 좋습니다.
미리 구현하는 것이 성실해보이지만, 그만큼 작업시간이 소요되므로 프로젝트의 시간도 늘어나며, 비용적인 부담도 발생합니다.
참고 :
https://mingrammer.com/translation-13-simple-rules-for-good-coding/
https://chodragon9.github.io/blog/easy-code/#%EC%9D%B4%EC%A0%9C-%EB%B3%B8%EB%A1%A0%EC%9C%BC%EB%A1%9C-%EB%93%A4%EC%96%B4%EA%B0%80%EA%B2%A0%EC%8A%B5%EB%8B%88%EB%8B%A4
https://rhange.tistory.com/168
클린코드(로버트 C.마틴)
