지금 당장 멈춰야 할 15가지 나쁜 프로그래밍 습관 (실제로 더 나은 개발자가 되기 위해)
원본 링크 : [링크]
<간단 요약>
총 15가지 나쁜 프로그래밍 습관을 간략하게 설명하고 핵심 메시지와 실천 방안을 정리하는 내용으로
계속 프로그래밍을 하다보면 좋지 않은 습관이 생기기 마련이다.
더 좋은 개발자가 되기 위해서 간단하게 원본 링크를 타고 보는것을 추천한다.
< 1. 버전 관리를 하지 않거나 쓰레기처럼 사용하지 않습니다 >
Not using version control, or using it like trash
버전 관리를 사용하지 않거나 무질서한 GIt 사용은 협업,히스토리, 관리, 실수 복구를 어렵게 만든다.
대안으로 Git의 필수화, 작은 단위의 커밋, 브런치를 사용하거나 PR 기반 협업, CI 보호 규칙을 적용하는게 좋다.
< 2. 끔찍한 이름 짓기 -한글자 말도 안되는 소리>
Horrible naming -single- lteer nonsense
의미 없는 변수/ 함수명은 유지보수 비용을 급격하게 올린다.
의도를 명확히 드러내는 이름을 사용하고 너무 짦은 축약을 하지 않고 작은 단위로 함수를 유지하려고 노력해야 한다.
< 3. 자동 검사나 취약성 검사는 없습니다 >
No automated tests or fragile tests
테스트가 없거나 쉽게 깨지는 테스트는 리팩토링, 배포를 위험하게 만든다.
핵심 로직 단위 테스트 작성, 통합 테스트로 주요 흐름 보장, CI에서 자동 실행 하도록 한다.
< 4. 코드 리뷰를 건너뛰거나 피드백을 무시하기 >
Skipping code reviews or ignoring feedback
코드 리뷰를 생략하거나 품질 저하와 지식 공유 실패로 이어진다.
작은 단위로 코드 리뷰를 하거나 기록을 해둔다.
결국은 작은 노하우들이 모여서 더 좋은 시스템을 만든다.
< 5.잦은 복사-붙여넣기 중복 >
Frequent Copy & Paste duplication
중복 코드는 수정 누락과 예외 발생을 초라한다.
사이드 이펙트가 발생하기 때문에 중복된 코드를 최소화하고 공통 로직을 결합하고 리팩토링해야한다.
< 6. 조기 최적화 광증 >
Premature optimization mania
측정 없이 최적화하면 복잡성만 증가하고 유지보수가 어려워진다.
실제 문제가되는 영역을 우선적으로 처리하거나 프로파일링한다.
< 7. 기술 부채가 코드베이스를 망치게 내버려 두기 >
Letting technical debt rot your codebase
기술 부채는 시간이 갈수록 개발 속도를 크게 떨어진다.
부채 목록을 명확하게 관리하고 스프린트마다 리팩토링 시간을 확보하거나
구조를 개선하는데 시간을 써야 한다.
< 8. 문서가 전혀 없고, README는 비어 있습니다 >
Zero documentation, README is empty
문서 부재는 온보딩, 협업, 유지보수를 어렵게 만든다.
기본적인 설명 프로젝트 구조, 사용방법 혹은 예외상황은 간단하게라도 문서화를 해야 한다.
< 9. 의미 없는 가비지 커밋 메시지 >
Garbage commit messages that have no meanings
의미 없는 커밋 메시지는 히스토리 분석과 디버깅을 어렵게 한다.
커밋 메시지에도 간단한 의미라도 부여해야 한다. 그래야 나중에 롤백을 하는 과정이나 히스토리 파악에 용이 하다.
< 10. 과거에 머무는 수동 빌드와 배치 >
Manual builds and deployment living in the past
수동 빌드, 배포는 높은 확률로 휴먼이슈나 오류율 , 불안정성을 초래한다.
빌드는 시스템에서 배포를 진행할수 있도록 CI/CD 구축, 매일 자동화 빌드 등을 추천한다.
< 11. 과도한 설계 - 필요할 때보다 너무 많은 것을 하는 것 >
Overengineering - doing too much before it' needed
필요 이상의 과도한 설계는 복잡성과 개발 비용과 시간을 크게 증가시킨다.
코드를 봤을때 가독성이 높아야 분석하고 적용하는데 시간이 단축된다.
YAGNI 원칙 적용, 단순한 MVP 우선 구현
< 12. 삼키는 오류와 끔찍한 기록 >
Swallowing errors and terrible logging
에러 를 무시하거나 로그를 부실하게 작성하면 문제 추적을 더욱 어렵게 만든다.
무결성을 판단해서 에러를 처리하거나 문제를 명확하게 표시하는게 좋다.
< 13. 배우기를 거부하고 정체되어 있다 >
Refusing to learn and staying stagnant
학습 정체는 개발자로서 경쟁력을 급격하게 잃게 한다.
기술에 발전에 관심을 가지고 꾸준히 학습해야 한다.
< 14. 번아웃될 때까지 쉬지 않고 일하는 거야 >
Working nonstop until you burn out
과로는 생산성과 창의성을 동시에 파괴한다.
적당한 휴식과 규칙적으로 작업하는것을 추천한다.
< 15. 보안에 하드코딩된 비밀을 무시하고 검증도 하지 않습니다 >
Ignoring security hardcoded secrets and no validation
보안 미흡은 데이터 유출, 해킹 등 치명적인 사고로 이어질수 있다.
서비스전 보안에 대해서 여러가지 테스트를 진행하고 개발완료에 보안을 포함해야 한다.
'개발 > 읽을거리' 카테고리의 다른 글
| 읽을거리) 착한 매니저들이 팀원의 커리어를 망치는 법(골렘 이펙트) (0) | 2025.12.31 |
|---|---|
| 읽을거리) 운영형 모바일 게임이 살아남기 어려운 구조적 이유와 그 돌파구 (0) | 2025.12.16 |
| 읽을거리) 토스(Toss)의 8가지 라이팅 원칙들 (0) | 2025.11.07 |
| 읽을거리) 게임 재화 분리에 대한 이점 및 인게임 화폐(재화 종류) (0) | 2025.09.25 |
| 읽을거리) 큰 차이를 만드는 10가지 작은 UI 수정 (0) | 2025.09.11 |
댓글