마틴 파울러 "컴퓨터가 이해할 수 있는 코드는 바보라도 작성할 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 작성한다."
나쁜 코드로 치르는 대가
나쁜 코드가 쌓일수록 팀 생산성이 점점 떨어진다.
- 여기서는 코드 품질이 낮거나 유지보수하기 어려운 코드를 "나쁜 코드"라고 지칭한다. 이런 나쁜 코드가 더 많이 쌓이면 팀의 작업 효율이 감소한다.
재설계로 들어간 거대한 비용이 레거시를 운영하는 것 보다 더 비용이 절감된다.
- 나쁜 코드로 인해 생긴 문제를 해결하려면 초기에 큰 비용이 들 수 있지만, 장기적으로는 더 절감된다. 왜냐하면 나쁜 코드를 계속 유지하면서 생기는 유지보수 비용과 문제 해결 비용이 더 크기 때문이다.
💡 레거시
과거에 개발되었으나 현재까지 사용되고 있는 코드나 시스템
클린한 코드란?
의존성이 적은 코드
독립성: 다른 모듈이나 라이브러리에 대한 의존성이 낮아야 한다. 이렇게 하면 코드를 변경할 때 다른 부분에 영향을 덜 미치고 오류가 발생할 가능성이 줄어든다.모듈화: 코드를 작은 모듈 또는 컴포넌트로 분할하고, 각 모듈은 자체적인 역할과 책임을 가져야 한다. 이렇게 하면 코드의 유지보수와 테스트가 쉬워지며, 코드를 재사용하기도 편리해진다.외부 의존성 관리: 외부 라이브러리, 서비스 또는 데이터베이스와의 의존성을 관리할 때 주의해야 한다. 이러한 의존성은 변경될 수 있으므로 코드 내에서 이러한 의존성을 추상화하고, 변경에 유연하게 대처할 수 있는 방법을 고려해야 한다.
💡 의존성의 추상화
의존성을 추상화하는 것은 코드에서 다른 부분에 어떻게 연결되는지를 감추는 것!
이렇게 하면 코드를 더 유연하게 만들어서 변경이 필요할 때 더 쉽게 대처할 수 있고, 코드를 테스트하고 이해하기가 더 쉬워진다.간단한 예를 들어보면, 만약 소프트웨어에서 데이터베이스를 사용한다면, 데이터베이스와의 연결을 코드 한 곳에 넣어두고, 다른 부분은 그 연결을 직접 다루지 않고 추상적으로 사용한다. 이렇게 하면 나중에 데이터베이스를 바꿔야 할 때 연결 부분만 바꾸면 되고, 다른 부분은 건드리지 않아도 되니까 편하다.
가독성이 좋은 코드
- 명확한 변수와 함수 이름
- 적절한 주석
- 들여쓰기와 포맷팅
- 불필요한 복잡성 제거
단일 책임 원칙 (Single Responsibility Principle, SRP)
각 클래스나 함수는 하나의 단일 책임만 가져야 합니다. 이를 통해 클래스나 함수가 수정되어야 할 이유가 단 하나라는 것을 보장하며, 코드의 모듈화를 촉진합니다.
- 이처럼 클래스에 많은 책임이 있는 경우 책임 중 하나를 변경하면 사용자가 모르는 사이에 다른 책임에 영향을 줄 수 있으므로 버그가 발생할 가능성이 높아진다.
- 이렇게 하면 변경이 발생하더라도 다른 관련 없는 동작에 영향을 미치지 않게 된다.
테스트 가능성
클린한 코드는 테스트하기 쉬워야 한다. 모듈이나 함수는 독립적으로 테스트 가능해야 하며, 자동화된 단위 테스트가 가능해야 한다.
참고
3년차 개발자