좋은 코드를 작성하기 위해 노력해야 한다.
나쁜 코드는 유지보수의 노력이 어마어마하게 들어갈 수 있다.
"Design Principles, SOLID, GRASP, Code smell" 로 검색하면
코딩 작성에 필요한 유용한 정보가 많다.
현업에서 많이 보았던 나쁜 코드 경우의 예이다.
클래스는 하나의 책임만 가져야 한다.
하나의 클래스나 함수 안에서 너무 많은 일을 한다.
함수 한 개의 라인 수가 크면 이러할 확률이 높다.
함수가 너무 길면 기능 단위로 쪼갤 수 있는지 다시보자.
기능 수정, 추가 때 영향이 최소화되도록 고려해야 한다.
기능을 수정하거나 추가하기 어렵다.
예를 들어 단순히 state 하나를 추가했는데
너무 커플링이 심해 불량이 나는 경우이다.
기존 함수가 있다고 너무 쉽게 호출해서 문제가 생긴 적도 있는데
인터페이스화 해서 간접 호출을 했어야 했다.
코드의 레벨을 맞추면 코드가 깔끔해진다.
예를 들어, 함수 내에서 비슷한 내용인데
일부는 풀어쓰고 일부는 매크로를 쓰고
통일성이 없으면 가독성이 떨어진다.
중복 코드는 제거해야 한다.
중복 코드를 놔두면, 다른 사람이 하나만 고쳐 문제가 된 적이 많다.
마지막으로, 가장 중요한 배려의 자세이다.
내가 작성한 코드를 단종이 될 때까지 유지보수한 적은 매우 드물다.
누군가가 대신 이어받는 경우가 많다.
처음부터 작성한 경우보다 남이 작성한 코드를 이어받아 한 경우가 더 많다.
급하다고 또는 자신만의 생각에 빠져
다른 사람이 파악하기 어렵게 코딩하면, 결국 유지보수의 노력이 배로 들어간다.
상식적으로 파악하기 어려운 부분이나
history가 필요한 부분은 문서나 주석을 반드시 남겨야 한다.
작성한 코드도 여러 번 다시 보자.
분명 기존 코드보다 더 나은 코드를 작성하게 될 것이다.
'임베디드 개발 > 프로그래밍' 카테고리의 다른 글
| 현업에서 자주 겪었던 코딩 실수 - 배열 인덱스 관리 오류 (0) | 2020.04.18 |
|---|