[번역] 나쁜 코딩 습관 35가지

원문: https://techbeacon.com/app-dev-testing/35-programming-habits-make-your-code-smell

당신의 코드를 구리게 만드는 35가지 "나쁜 버릇"

나쁜 버릇은 고치기 힘들다. 그게 나쁜 버릇임을 알지 못하면 더욱 고치기 힘들다. 나쁜 버릇임을 알면서도 고치지 않는 것이 최악이다. 하지만 적어도 고칠 마음은 있으니 이걸 읽고 있을 것이다. 프로그래머로 일하면서 나쁜 습관들을 봐왔다. 코딩 문제도 있었지만 팀워크 문제도 있었다. 나 또한 나쁜 습관이 있었고 이에 대한 책임이 있다. 나쁜 프로그래밍 습관 35가지를 아래와 같이 4개의 카테고리로 – 코드 관리, 팀워크, 코드 작성, 테스트 및 유지관리 - 나누어 보았다.

 

코드 관리

1. “나중에 고칠게요.”
   사소한 버그라고 디버깅을 미루면 안된다. 사소한 버그도 놓치지 않도록 "할일 목록"을 적극 활용하자.

2. 짧은 코드 만들기에 집착하기
   20줄짜리 코드를 2-3줄로 줄이는 게 재밌을지는 몰라도 가독성은 떨어질 수 있다. 일반적으로 코드의 간결함보다 높은 가독성이 훨씬 중요하다. 코드의 접근성을 먼저 생각하고, “똑똑해 보이는” 코드는 그 다음에 생각하자.

3. 의미없는 최적화
   종종 쓸데없이 최적화에 노력을 쏟을 때가 있다. 웹사이트 크기를 수 바이트 줄이는 게 그렇게 중요한가? 그냥 gzip 쓰면 그만 아닌가? 더 중요한 요구사항들도 있지 않은가? 최적화는 프로젝트의 가장 마지막에 두자. 요구사항이 바뀌면 그 앞에 해왔던 최적화들은 쓰레기가 된다.

   『너무 이른 최적화는 만악의 근원이다.』 – 도날드 커누스 Donald Knuth

4. 코딩 스타일을 무시하는 것 (참고: https://namu.wiki/w/코딩 스타일)
   개발자들은 코딩 스타일 이슈를 등한시하기 쉽다. 초보에겐 이게 중요해 보이지 않겠지만, 이를 지키지 않으면 결국 진행하기 어려운 프로젝트가 된다. 작은 부분이라도 스타일을 꼭 지키자. Code checking system과 linting tool을 이용하자. (참고: https://subicura.com/2016/07/11/coding-convention.html)

5. 오류 숨기기
   예외를 무시하든 에러를 보고하지 않는 라이브러리를 쓰든 오류 가능성을 숨기는 방법은 여러가지가 있다. 하지만 이 중 하나라도 주요 이슈로 터지면 그걸 고치는 데에는 몇 배의 시간이 든다. 어디서부터 시작해야 할지도 모를 테니까. 오류에 대한 로그를 잘 남기자. 그래야 다른 사람들이 오류를 조사하기 편해진다.

6. 변수의 정보가 담겨있지 않은 변수명 짓기
   이름짓기는 항상 어렵다. 하지만 좋은 변수명/함수명을 만드는 간단한 방법이 있다. 코드 내의 다른 변수/함수와 분명히 구별되는 정보를 이름에 간단히 담기만 해도 가독성은 확실히 올라간다. 이름만 잘 지어도 코드를 알아보는 데에 걸리는 시간을 한시간에서 10초로 줄일 수 있다.

7. 개발에 도움되는 도구들을 무시하기
   Code review, test-driven development, quality assurance, deployment automation 등 세상엔 프로젝트 성능 향상을 위한 많은 방법들이 있다. 개발자들이 괜히 블로깅에 열을 올리는 게 아니다.

 

팀워크

8. 계획을 자꾸 바꾸는 것
   프로젝트를 망하게 만드는 가장 쉬운 방법은? 계획 없이 일하면 된다. 누가 당신 코드에 딴지를 건다면 언제든지 “아직 미완성입니다.”라고 말할 수 있다. 하지만 미완의 코드를 다른 코드와 합치는 순간 “강하게 결합된 코드 tightly coupled code”가 된다. (참고: https://hongjinhyeon.tistory.com/141)

9. 실현 가능성이 낮은 계획을 고집하기
   계획을 바꾸는 것도 나쁘지만, 실현 불가능한 계획을 고집하는 것도 나쁘다. 항상 아이디어를 팀과 공유하고 피드백을 받고 막혔을 땐 조언을 받자. 관점의 차이가 모여 결과의 차이를 만든다.

10. 혼자 일하기
    프로젝트 진행현황, 아이디어 등은 팀과 항상 공유해야 한다. 당신이 하는 방식이 옳다고 굳게 믿는가? 아니다. 틀렸다. 더 나은 아이디어를 팀원들이 가지고 있을거니까. 팀원들과의 지속적인 대화는 당신뿐만 아니라 팀원들에게도 도움이 된다. 특히 갓 들어온 신입에게는 더더욱.

11. 나쁜 코드 짜기를 거부하기
    마감일에 쫓겨 개판인 코드를 짜서 넘겨야 하는 일, 치명적인 버그가 발견됐는데 완벽한 해결법을 찾기에 시간이 부족한 일. 이런 일은 언젠가 반드시 생긴다. 고객이나 관리자에게 “이거 이대로 가면 분명히 나중에 문제 생깁니다.”라고 말하면 “네, 알겠고요. (=아, 모르겠고!) 일단 마감일만 지켜주세요.”라고 대답이 돌아온다. 괜찮다. 그게 개발자의 숙명이다. 이럴 때를 대비해서 나쁜 코드라도 빠르게 짤 수 있는 능력이 필요하다. 하지만 너무 걱정하지 않아도 된다. 일단 작성하고 보내자. “기술적인 빚 technical debt”을 졌다고 생각하고 나중에 갚으면 된다. (참고: https://bcho.tistory.com/811)

12. 다른 사람을 비난하기
    전문가는 자기 분야에 대해 거만해지기 마련이다. 이건 만국공통이다. 개발자도 다르지 않다. 자만심에 눌려, 또는 쌓아온 신뢰를 깎아먹는 게 두려워 자신의 실수를 인정하지 않는 진짜 실수를 저지르지는 말자. 실수를 인정할 줄 알아야 더욱 빛나는 법이다. 그리고 나서 왜 실수를 저질렀는지, 다음엔 어떻게 피할 수 있는지를 배우는 데에 집중하자.

13. 당신이 배운 것을 팀원과 공유하지 않기
    개발자로서 당신의 가치는 당신이 짠 코드로만 보여지는게 아니다. 코드를 짜면서 당신이 무얼 배웠는가로도 보여진다. 경험을 공유하고, 코멘트를 달고, 왜 그렇게 짰는지를 설명하고, 프로젝트의 새로운 사항들과 디테일을 팀원들이 배우게 해라.

14. 피드백을 너무 늦게 주기
    팀원 모두가 동일한 정보를 공유하고 있는 상태(on the same page)로 만들어야 한다. 어찌보면 개발자의 가장 큰 덕목 중 하나일지도 모른다.

15. 구글 검색 안 하기
    복잡한 문제를 빨리 푸는 가장 좋은 방법은 문제를 풀지 않는 것이다. 그냥 구글 검색 해라. 옆 자리 동료보다 Stack Overflow가 더 좋은 reference가 된다. 괜히 옆 사람 시간 뺏지 말고. 당신의 고민은 분명히 지구 상 누군가가 이미 했던 고민이고 해결도 해놓았다.

16. 자기 스타일 고집하기
    팀원 전체가 동의하고 공유할 수 있는 스타일과 작업환경을 세팅해라. 본인 스타일만 고집하면 팀원들도 힘들고 인수인계도 어렵다.

17. 자기 코드에 애착 갖기
    누가 당신 코드에 딴지를 건다고 기분 나빠하지 마라. 당신 코드에 딴지를 거는거지 당신한테 거는 건 아니니까. 왜 그렇게 짰는지 잘 설명하고, 더 나은 방법이 있으면 받아들이면 그만이다.

 

코드 작성

18. 어떻게 최적화할지 모르기
    최적화는 그렇게 간단히 되는 게 아니다. 프로젝트의 디테일을 조사하고, 분석하고, 관련된 시스템 하나하나를 이해하고, 알고리즘 복잡도와 database query evaluation과 프로토콜과 성능평가 방법 등등… 모든 것이 고려되어야 좋은 최적화가 이루어진다.

19. 적합하지 않은 툴 사용
    당신이 이미 충분히 많이 안다고 생각하는가? 천만에. 새로운 문제들은 항상 새로운 context를 수반하고 새로운 툴을 필요로 한다. 새로운 라이브러리와 언어에 항상 관심을 가져라. 원래 알고 있던 것에만 의존하지 마라.

20. 개발자 툴과 IDE 사용법을 충분히 익히지 않기
    핫키, 단축키, 환경 세팅은 당신 생각보다 더 중요하다. 단축키 써서 몇 초 아끼는 게 중요한 게 아니다. 이것들을 익힘으로써 코딩의 context를 바꾸는 게 중요하다. 툴과 IDE 사용에 익숙해져야 비로소 당신의 코드 그 자체에 집중할 수 있게 된다.

21. 에러 메시지 무시
    에러 메시지를 제대로 읽지도 않고 에러의 원인을 다 이해했다고 착각하지 마라. 에러 메시지 분석에 시간을 들이는 것이 길게 보면 오히려 시간을 단축하는 길이다.

22. 하나의 개발자 툴킷만 사용하기
    개발 언어에 따라 좋은 개발환경이 다르다. Visual Studio는 IDE로서 좋은 툴이다. Sublime은 동적 프로그래밍 언어 개발에 좋다. Eclipse는 Java 개발에 좋다. 이 외에도 다양한 언어와 그에 맞는 개발환경이 있다. vim과 emacs를 선호하는가? 그게 모든 경우에 최고의 툴은 아니다.

23. 파라미터 값을 hardcoding 하기
    바뀔 수 있는 파라미터들은 따로 관리해야 한다. 이것들을 hardcoding 했다간 technical debt이 당신을 잡아먹을 것이다.

24. 매번 바퀴를 발명하기
    모든 걸 새로 짜지 마라. 당신이 풀어야 할 그 문제는 이미 누군가가 공들여서 빠르고 안정한 solution을 만들어 놓았을지도 모르니까.

25. 눈 감고 복붙
    코드 재사용 전에는 꼭 한번은 꼼꼼히 읽어봐라. 안 읽고 복붙 했다가 사고치지 말고. 대충 읽어도 안된다. 꼼꼼히 읽어서 완벽히 이해해야 한다. 이게 가끔은 문제 이해에 도움이 되기도 한다.

26. 코드 동작 방식을 이해하지 않고 코딩하기
    단순히 코딩만 하지 말고 실제로 코드가 동작하는 방식을 같이 이해하자. 당장은 시간이 걸릴지 모르겠지만, 길게 보면 그게 더 중요할지도 모른다.

27. 예전에 짠 코드에 과한 자신감을 갖는 것
    당신은 당신도 모르게 계속 발전하고 있다. 예전에 짠 코드가 지금처럼 훌륭할 것이라고 믿지 마라.

28. 완벽한 라이브러리를 찾았다고 오해하기
    예제 몇 개 봤다고 새 라이브러리를 마스터할 수는 없다. 직접 써보고 분석하면서 익히는 것들이 분명히 있다. 어쩌면 이 라이브러리가 현재 프로젝트에 딱 맞는 조각이 아닐지도 모른다. 항상 의심하며 작업해라.

29. 막혔는데 도움을 청하지 않는 것
    도움을 청하고 받는다고 해서 당신이 무능해보이는 게 아니다. 막히면 도움을 받아라. 혼자 꽁꽁 싸매고 있는게 결과적으로 당신에게 더 괴로울 것이다.

 

테스트 및 유지보수

30. 통과할 테스트만 만드는 것
    통과할 테스트를 만드는 것도 물론 중요하다. 그게 코드 refactor와 reorganize를 안전하게 만든다. 하지만 통과하지 못할 테스트도 만들어야 한다. 그래야 프로젝트가 진행되고 이슈 tracking이 가능해진다.

31. 극단적 케이스에 대한 테스트를 고려하지 않는 것
    프로젝트 일정 중간쯤에 성능평가 자동화 툴을 미리 만들어라. 그래야 더 심각해질 수 있는 문제를 방지할 수 있다.

32. 빌드만 확인하고 동작 확인 안하기
    빌드는 되지만 동작하지 않는 경우도 간혹 발생할 수 있다. 디버깅이 생각보다 골치아프고 오래 걸릴 수 있다. 빌드할 때마다 간단한 테스트를 하는 습관을 갖자.

33. 큰 업데이트를 미루기
    근자감에 취해 있다가 망하기 딱 좋은 케이스이다. 보통은 이걸로 여러 번 망해본 다음에야 정신을 차린다.

34. 예전에 짠 코드를 더 이상 관리하지 않는 것
    당신이 짠 코드를 당신보다 더 잘 아는 사람은 없다. 다른 사람이 당신 코드를 쓴다면 더 잘 이해할 수 있게 도와줘라. 가독성을 올릴 방법이 있다면 올려줘라.

35. 기능 구현 이외의 사항을 무시하는 것
    기능 구현에만 몰두하다 보면 성능, 보안 등의 문제를 소홀히 하기 쉽다. 이것들도 checklist에 적어두고 관리해야 한다. 이것들이 당신 작품의 가치를 떨어트릴지도 모를 일이다.

 

우리 모두는 습관의 동물이다. 좋은 방법이 “습관”이 되면 매 상황마다 좋은 방법을 고민할 필요가 없다.

 

원문: https://techbeacon.com/app-dev-testing/35-programming-habits-make-your-code-smell

 

35 programming habits that make your code smell | TechBeacon

 

---

 

마치며

 

초심자들이 많이 하는 실수 중 hardcoding과 유저입력을 여기저기 흩뿌려놓는 것이 있습니다. 이에 대해 검색해보다가 재밌는 글을 찾아서 번역해봤습니다. (중간 몇몇 링크는 원문에는 없으나 제가 마음대로 추가했습니다.) 원문은 이것보다 훨씬 깁니다만, 군더더기도 많고 (사실 무슨 말인지 모르겠는 부분도 많아서… 영어가 짧…) 해서 제 맘대로 의역을 끼얹었습니다. 많은 분들께 도움되길 바랍니다.

 

- 게으른 맽랩

나쁜 코딩 습관 35가지-1.pdf

0.16MB