좀 두서없긴 한데, 얼마전에 회의시간에 딴짓하며 적어본 내용이 있어, 여기에 올려봅니다.
어떤 내용이냐하면 제목처럼 Code작성시 주의할 사항... 입니다.
사실 주의할 것이 아니라 당연히 생각해야할 것들이지만, 마음 급하게 일하다 보면
별거 아닌 것로 생각하고, 무시하고 진행하다, 오히려 시간만 낭비하는 일이 있기 때문인데...
그런경우의 생산성 손실은 엄청 클 수 있습니다.
그럼 한번 생각나는 대로 적은 것을 말씀드리겠습니다.
1. 함수, 변수 이름 정하기
: 정확하고 읽기 쉬운 이름으로 정해라. 만약 예전 코드의 이름들이 복잡하다면, 틈나는 대로 refactoring하라.
: 다만, 여러명이 같이 개발하는 코드라면, 나혼자 결정할 사항은 아니므로, 협의해서 정해라.
2. 피곤하면 실수한다.
: 피곤하고, 눈꺼풀이 무겁거나, 집중이 안된다면, 지금 키보드 마우스를 손에서 때고... 10~30분이라도 휴식하라.
3. 촌수를 잘 따져라.
: DIL -> HAL -> DDI 등 코드의 계층을 잘 이해해서 다뤄야 함. DIL이 DDI를 직접 호출한다던지 하지 말라.
4. 안 쓰는 함수, 변수는 정리하거나... 버리가 아깝다면 #notused 로 감싸서 코드 맨 아래로 내려라.
: 안쓰는 함수나 변수를 확인하는 자동화 툴을 사용하기도 한다던데... 이건 저도 안 해봤습니만...
5. 빌드시 안 쓰는 함수, 변수는 warming 메시지로 경고를 내주는데, 되도록 이때 미리 정리를 해두는 것이 좋다.
: warming이 무지막지하게 쌓이면, 정작 중요한 warming 메시지는 지나칠 수 있다.
6. 당연한 말이지만... 빌드시 경고 문구의 문장의 의미를 잘 알고 있어야 한다. (영어라고 그냥 지나치지 말자)
: 되도록이면 경고 문구는 excel파일등으로 정리해서, 자주 나오는 경고는 숙지하고 있어야 한다.
7. 조건문 사용시는, Yes, No 그리고..... 알 수 없음 조건을 추가해야한다. 보통 default 또는
if(), else if(), else... 로 처리하는 거나, switch case에서 default를 추가하자.
8. 하나의 SW모듈이 작성되면, 모듈별 test는 하고, 다음 모듈을 작성하거나, 통합 test를 하자.
: 코드가 방대해지면, 어디서 버그(bug)가 발생했는지 찾기 어렵다. 미리 미리 숙제는 조금 있을 때 바로 하는
습관을 들이자.
9. 마음을 다스려라 : 가장 중요한 것은 심리적 안정감이다. 쫒기는 마음으로 코드를 작성하거나, 기존 코드를 보면
주마간산처럼 그냥 시간만 낭비하는 상황이 나올 수 있다.
: 집중이 안된다면, 빈 회의실에서 혼자 다시 코드를 보기를 권장한다.
: SW업종의 사무실이라고 키보드 소리만 들리지는 않는다. 수많은 사람들의 목소리들... 전화통화... 회의 소리... 관리자들의 갖은 참견과 질문이 넘치는 공간에서 집중하기란 쉽지 않다.
10. 좋은 키보드와 마우스를 사라 : 회사에선 만원짜리를 주겠지만, 그런건 그냥 보조용으로 두고, 좋은 키보드와
마우스를 사라... 좋은 만큼 손의 통증을 줄여주고, 오타와 오 클릭을 줄여준다. 프로는 프로의 도구를 사용해야한다.
11. 큰 모니터...를 준비하라... 이왕이면 듀얼 모니터가 좋다. 27인치 2개 또는 23인치 2개정도가 무난하다.
: 요즘 나오는 21:9 모니터라면, 34인치급으로 구매를 해라, 그치만 가격이 비싸므로 23인치 두개를 사는 것이
현실적일 수 도 있다.
12. 코드 컴페어툴을 적극 활용해라... 코드 에디터 툴을 적극 활용해라 : beyond compare, Source Insight등이 좋다. 특히 Source Insight의 함수 관계 도 보기 기능은 너무 좋다.
13. Test 가능한 코드를 염두하고 처음 부터 코딩 계획을 세워야 한다. 어떤 기능을 위해, Hello World부터
찍어보지 말고, 종이에 목적과 예상 결과 How to test, How to update, How to use for another model 등을 고민하라.
14. 위의 내용을 다시 집어 보면,
정확한 요구사항을 정리하고, 요구사항을 SW적인 언어로 정리한다(흐름도), 이렇게 정리된 것을 리뷰하고,
How to test, How to update, How to use for another model.... 등을 고려해야한다.
고려가 되었다면, SW 문서를 작성한다. HLD, LLD등을 작성하고....
그게 끝나야 실제 코딩을 해야한다. 물론 간단한 코드 수정이라면, 기존의 문서를 읽어보고, 바로 작업을 하면 된다.
여기서의 설명은 처음 기능을 구현할 때의 일이다.
그러나 남이 짠 코드를 보다보면, 문서도 없고, 어떻게 동작하는지 알기 어려운 코드들이 있다.
이런건 내것이 아니니, 문제가 없도록, 땜빵코드나 집어 넣고, 마무리를 하자는 마음도 있겠지만, 되도록
간단히라도 문서로 정리를 해두자.
... 2015/6/9 ...
