✨ 좋은 소프트웨어 코드의 6가지 공통점
쉽게 읽을 수 있다.
해당 코드 개발자가 아닌 다른 개발자도 최소한의 시간과 노력만 투자해 코드를 쉽게 이해할 수 있어야 최상의 코드라고 할 수 있다.
주석이 잘 작성되어 있다.
코드가 제공하는 기능, 즉 왜 필요한가를 말해주는 주석이 필요하다.
좋은 주석은 코드를 개발한 당사자에게도 도움을 준다.
코드 구조가 간결하다.
아주 간결하거나 단순한 코드가 가장 좋은 코드이다.
변경에 탄력적이다.
현재 필요한 사항과 미래에 필요할 수 있는 사항 모두를 염두에 둔 소프트웨어가 좋은 소프트웨어다.
활용을 위해 관리할 수 있어야 한다.
쉽게 수정할 수 있도록 만들어야 한다.
URL, 엑세스 키 등을 직접 하드 코딩하는 방식으로 소프트웨어를 개발해선 안 된다.
제 기능을 해야 한다.
코드가 본래 기능을 수행해야 한다.
🛠️ 좋은 코드 작성을 위한 규칙
최적화보다는 가독성이 우선이다.
최적화에 위배되더라도 가독성 있는 코드를 작성하는 것이 소프트웨어의 전체 수명주기를 고려할 때 비용 효과적이다.
아키텍처를 우선 개발하라.
코드를 작성하기 전에 선행해야 할 작업, 코드 사용 방법, 모듈화 방법, 서비스 동작 방법, 구조, 테스트 및 디버깅 방법, 업데이트 방법들을 먼저 생각하고 이해해야 한다.
테스트 커버리지를 고려하라.
아래 상황에서는 터스트가 필요하다.
- 최소 한 달은 변경하지 않을 모듈이나 마이크로서비스를 개발
- 오픈 소스 코드를 작성
- 핵심 코드 또는 금전적인 부분과 맞닿는 코드를 작성
- 코드 업데이트와 동시에 테스트 업데이트를 할 수 있는 충분한 비용이 있음
간단하고 단순하게 코딩하라.
KISS(Keep It Simple and Stupid) 원리를 지킨다.
수학을 공부할 때도 느끼지만 문제를 간단하게 푸는 게 진정한 고수다
주석을 작성하되 보조적으로 사용하라.
좋은 코드는 주석이 없어도 이해가 되지만 다른 개발자들이 해당 코드를 다루는 과정에서 시간을 절약할 수 있도록 메서드의 정의와 사용법을 설명하는 한 줄짜리 간단한 주석을 작성하자
강한 결합과 느슨한 결합을 추구하라.
마이크로서비스는 구성 모듈 간에 강하게 결합해야 하고, 서비스 간에는 느슨하게 결합해야 한다.
구성 모듈 간에 강하게?? 서비스 간에 느슨하게???
코드 리뷰가 항상 좋은 것은 아니다.
코드 리뷰는 코드에 내재된 오류를 찾는 것이 목적이다.
시스템을 이해하는 수단이나 다른 팀원을 가르치려는 목적으로 코드 리뷰를 하는 것은 의미가 없다.
시스템을 이해하는 수단이나 다른 팀원을 가르치려는 목적으로는 왜???
리팩토링은 작동하지 않는다.
기능 실행에 초점을 맞추어 개발하면 나중에 큰 기술적 부담으로 돌아오거나 모든 코드를 다 삭제한 후 처음부터 다시 작성하게 되는 상황이 종종 발생한다.
피곤하거나 컨디션이 좋지 않을 때는 코딩하지 마라.
개발자들이 피곤할 때는 평소보다 2 ~ 5배 더 많은 버그와 실수를 만들어낸다는 보고가 있다.
모든 것을 한 번에 작성하지 마라. 반복적으로 개발하라.
코드를 작성하기 전에 사용자 혹은 클라이언트가 정말로 필요로 하는 것이 무엇인지 분석하고 예측한 후에, 짧은 기간 동안 개발할 수 있는 MVF를 선택한다.
가능하면 자동화 도구를 사용하라.
소픝트웨어 개발을 장기적인 관점으로 볼 때 자동화는 100% 효과를 거둘 수 있는 좋은 수단이다.
취미를 가져라.
소프트웨어 개발 업무에서 벗어나 잠시 다른 일을 하면 정서적 안정감을 얻는 데도 좋고 새로운 아이디어를 개발할 기회가 되기도 한다.
여유 시간에 새로운 것을 배워라.
iT 분야의 기술은 매우 빠르게 변하고 있다. 따라서 코드를 개발하는 과정에서 새로운 기술을 적용한다거나 새로운 환경에서 개발을 수행함으로써 새로운 스타일의 코드와 기술 변화에 대응해야 한다.
