매력적이지만 버려야 할 10가지 나쁜 프로그래밍 습관

----------------------------------------------------------------------------------

매력적이지만 버려야 할 10가지 나쁜 프로그래밍 습관

https://www.itworld.co.kr/news/337915

----------------------------------------------------------------------------------

1. 주석 없는 코딩: 문서화되지 않은 코드는 이해와 디버깅이 어렵습니다.

2. 느린 코드: 코드를 단순하게 만들어 빠르게 실행되도록 합니다.

3. 장황한 코드: 간결한 코드는 이해하기 쉽지만, 과도한 축약은 오히려 해로울 수 있습니다.

4. 오래된 코드: 불필요한 복잡성을 피하고 필요한 기능만 사용합니다.

5. 나만의 코드 롤링: 검증된 라이브러리를 사용하되, 특수한 경우에는 직접 구현할 수도 있습니다.

6. 너무 이른 최적화: 조기 최적화는 피하고, 필요할 때 최적화합니다.

7. 부주의: 데이터를 처리하기 전에 항상 확인하여 오류를 방지합니다.

8. 불일치: 코드의 일관성을 유지하되, 필요할 때는 새로운 접근을 시도합니다.

9. 종소리와 휘파람을 따라가기: 기존 방식을 고집하기보다 새로운 기능을 도입할 수 있습니다.

10. 규칙 깨기: 때로는 규칙을 어기는 것이 필요하지만, 그에 따른 책임을 인식해야 합니다.

----------------------------------------------------------------------------------

1번 항목에 대해서 짧은 의견을 더해봅니다.

아주 오래전이긴 하지만 저는 코딩할 때 주석을 먼저 쓰고 시작했습니다. 큰 틀의 디자인은 다른 방법을 사용해야 했지만 함수 내 로직 설계는 이만한 방법이 없었던 거 같거든요.

그런데, 얼마전 후배들과 이야기에서 요즘은 "간결한 코딩'을 강조하면서 주석 역시 낡은 습관처럼 이야기 하는 경우가 있더라고요. 글쓴이도 이에 대해서 같은 말을 하네요. (저와 같은 옛날 사람인가 봅니다.)

"코드를 작성하는 것보다 디버깅하는 것이 두 배 더 어렵기 때문에, 처음부터 너무 복잡하게 작성하지 말라"

Phil Karlton, Garbage Collection 창시자

많은 소프트웨어 엔지니어들이 공감하는 것은 코드는 작성하는 것보다, 읽는 것이 더 어렵다는 것입니다.

내 코드가 충분히 간결하다면 문제가 안되겠으나, 스스로 그렇지 못하다고 생각하면 짧게 나마 나의 의도를 담은 주석정도는 달아 두는 것이 리뷰어와 동료에 대한 배려이지 않을까 싶습니다. :)

5번 항목도 잠시 언급하자면,

요즘은 워낙 라이브러리가 많아서 오히려 너무 라이브러리에 의존하는 것 같다는 느낌이 들 때도 있습니다만, 사바사인 경우가 많은데... 어떤 분은 도통 라이브러리를 너무 신뢰하지 않고 직접 만들어야 직성이 풀리는 것 같습니다.

이 역시 주의해야 할 부분이라는 생각입니다. 저는 필요하다면 저렴한 유료 라이브러리의 사용을 적극 권장합니다. 서비스 개발하는 엔지니어가 동적 데이터 바인딩을 지원하는 테이블 라이브러리에 신경을 곤두 세워야 할 필요는 없을 테니까요.

약간의 검색으로 커뮤니티가 풍부한 라이브러리, 조금 돈이 들지만 유명한 라이브러리의 사용을 검토하는 것은 우리 팀의 속도를 x2, x3 빠르게 해줄 것입니다. 라이브러리 사용에 따른 약간의 제약은 사실... 대부분 정책적으로 소화할 수 있는 경우가 많을 것 같습니다.

공유드린 글 길지 않으니 일독을 권장 드립니다.

그리고, 내가 1인 개발자가 아니라면~ "내가 누구와 개발하는가? 무엇을 개발하는가?"에 집중해 보면 좋겠습니다.