<규칙>
1) 최적화 & 가독성
- IOT나 소형 하드웨어, 칩을 다루어 resource가 제한된 환경에선 최적화가 필수다.
- 그러나 web 등에선 최적화를 위해 코드를 간결하게 한다고 method를 이어 붙이거나, 타인이 바로 알아보기 어려운 고급 function 등을 쓴다면 legacy code - 작성자만 알아보는 code가 된다.
- 팀으로 활동하거나, 누군가에게 코드를 넘겨야 한다면(유지보수 등) 그들은 code를 이해하기 위해 상당한 시간을 소모한다. github 에서 code 몇 개만 뒤져보면 가독성의 중요도를 알 수 있다.
- Code 가독성을 어렵게 하여 일부러 보안성을 높이는 경우도 있지만 이건 예외적이니 넘기자.
- 최적화가 필요한 code는 module로 제작.
2) Convention
- 가독성과 유사한 이슈다. 서로 간에 code 작성 규칙을 만들어 놓지 않으면 엉망이 된다.
- 띄어쓰기 : 누구는 스페이스 2칸, 누구는 4칸??
- 줄바꿈 이슈 : code 길이가 어느 정도일 때 줄바꿈 할 것인가?
- 변수 Naming 이슈 : Camel 표기법 vs Snake 표기법
- 주석 작성법
- git commit convention rule : 아무렇게나 msg를 작성하여 commit 하는 이가 얼마나 많은가
- slack convention : 중요하지 않은 이슈 등을 왜 전체 공유로 하는가? 꼭 필요한 팀-인원에게만 공유하라고
3) 아키텍처 (설계 기반 code) & 디자인 패턴
- 개발의 목적에 따라 달리 만들면 된다.
- 급히 service 해야하거나, 시안이 필요한 경우, application size가 작다면(미니 프로젝트로 게시판 만들기 정도) 설계를 깊이 생각하지 말고 빨리 만들어 내는게 중요하다.
- 반대로 위의 경우가 아니라면 아키텍처를 꼭 고려해야 한다. application의 규모와 복잡성이 늘어남에 따라 확장하는데 문제가 있고, 장애 발생시 대응 시간 또한 크게 차이난다. 유지보수를 생각한다면 더욱 그렇다.
4) Test Coverage
- Test 는 좋은 일이나 상황-환경에 따라 적합성이 다르다.
- 나쁜 Test code와 함깨 code를 짜는 건 Test가 없는 code보다 위험할 수 있다. (어? build 되던데? Test에선 문제 없던데?)
- [Test가 필요한 경우]
* 최소 1달은 건드리지 않을 Module이나 Micro Service를 개발하는 경우
* Open Source를 작성하는 경우
* 핵심 code 또는 금전과 직접점이 있는 code
* Code를 업데이트하는 것과 동시에, Test를 업데이트 할 수 있는 충분한 비용이 있는 경우
- [Test가 필요 없는 경우]
* 스타트업
* 팀이 작고, code가 빠르게 변하는 경우
* 출력값을 보고 간단하게 수동으로 Test가 가능한 Script를 작성하는 경우
5) 주석
- 주석은 있으면 좋은 것이다. 개발자가 뭘 구현하였는지, 어떤 목적으로 넣었는지 파악하기 어려우면 작업 진척이 늘어진다.
- 물론 최고의 Code는 주석 없이도 이해 가능한 직관적인 code다.
==> 그러나 이는 어려운 일이니 각 method 나 function의 상단에 기능 및 목적을 나타내는 짧은 주석 1줄만 다는 걸 추천.
==> 다른 방법으론 각 method & function에 대한 정의와 사용법을 설명하는 간략한 문서를 작성하는 것.
6) 강한 결합 & 느슨한 결합
- Monolithic 소프트웨어는 Micro-service 소프트웨어 보다 빠르지만, 단일 Server 에서만 그렇다.
- 느슨한 결합은 code의 안정성, 확장성, 장애 대응 가능성, 분산처리 등이 용이하다.
7) 코드 리뷰
- 팀 구성원들이 code의 95% 가량을 이해하고 있고, 시간 낭비없이 모든 업데이트 사항을 모니터링 할 수 있는 개발자가 있다면 코드 리뷰를 도입하는게 좋다.
- 코드 리뷰의 핵심은 Code 품질을 유지하는 것이지 가르치는게 아니다.
- Code의 다른 부분을 이해하고 싶다면 해당 부분의 담당자에게 질문하도록 한다.
8) Refactoring
- 나중에 Refactoring 할 것이니 걱정 없다는건 대부분 기술 부채로 돌아오거나, code를 재작성 해야하는 것으로 돌아오기 마련이다.
9) 피곤하거나 컨디션이 좋지 않으면 coding을 멈춰라
- 개발자가 피곤할 때 평소보다 2-5배 많은 장애와 실수를 남발한다. 차라리 쉬는게 낫다.
==> 최근 본인이 어떤 작업을 마치기 위해 3주간 애쓴게 있었다. 일찍 퇴근하거나 쉴 수 있음에도 하였고 결국 마무리하였다. 문제는 바로 다음 날부터 환절기-감기 를 맞아 3주간 고생했다는 것이다.
==> 아픈 3주간 퇴근 이후 코딩을 할 기력이 없었고, 일상은 2일에 한번씩 연차를 써야할 만큼 여러 합병증이 도졌다...
==> 건강을 도외시 한다면 반드시 더 크게 돌아온다. 여유를 가지자.
10) 반복적 개발
- Code 작성 전, 고객 & client가 원하는 걸 분석 및 예측하여, 짧은 기간 동안 개발 가능한 MVF(Most Valuable Features)를 추려내라.
- 품질 업데이트를 배포하기 위해 이런 반복을 사용하고, 무리한 요구사항이나 품질 희생에 Time과 Resource를 낭비하지 마라.
11) 개발 외의 삶
- 하루의 많은 시간을 할당하여 코딩만 한다면, 당신은 언젠가 coding이 질릴 수 있다.
- Coding을 오래하기 위해서라도, 많은 시간을 가족, 친구, 운동, 게임 등 coding 외의 다른 것들로 채워가라
<출처 2>
'Programing > How to Coding?' 카테고리의 다른 글
| [How to Coding?] Design 작업에 대해 [업데이트 예정] (0) | 2022.08.27 |
|---|---|
| [How to Coding?] 수준과 가성비에 대해 (0) | 2022.01.26 |
댓글