간단한 로직 같은 경우는 슈도코드로 커버가 가능하지만
복잡한 비즈니스 로직이나 트랜젝션을 고려하여 프로그래밍을 하다 보면 버그가 생기기 마련인데
원인은 미처 고려하지 못한 부분이 있거나 처음부터 로직을 잘못 이해하여 작성한 경우가 대부분이다.
여렵고 복잡한 로직을 알기 쉽게 작성하려면 로직을 본인이 잘 이해해야 한다. ㅋㅋ
너무 당연한 말이지만 일정에 쫒기면서도 모든 것을 이해하면서 프로그래밍 하고 계신지 의문이다….
PM이 데드라인 압박과 결과물 독촉을 재촉하여도 일은 똑바로 해야 하지 않겠는가?
정신을 가다듬고 짧은 시간 안에 가장 효과적으로 퍼포먼스를 낼 수 있는 방법을 생각해보자. 마음을 가다듬고 집중! 집중하자!
첫번째, flow chart를 이용하여 로직이 어떤 순서로 이동하는지 정리할 필요가 있다.
물론 머리가 좋아 정리할 필요가 없다면 좋겠지만 그런 사람은 흔치 않다. 심지어 문서화까지 생각하면 일단 정리해놓는 것이 안전하다.
두번째, 가장 기초적인 것이지만 개발자 대부분이 망각하는 것이다.
바로 진리표(true table)를 작성하는 것이다.
excel이나 종이나 notepad나 word나 어디든 상관 없이
각 플로우마다 변수가 어떻게 변하는지 테이블로 작성한 경우 로직 이해, 작성이 용이하다.
마지막으로 테스트 코드를 작성하는 것이다.
일단 작성해 보았으면 로직이 정상적으로 잘 도는지 테스트 코드를 작성하고
예외 케이스가 있는지 고려해 보아야 할 것이다.
테스트 코드를 작성 하다 보면 로직에 대한 이해도 올라갈 뿐만 아니라 테스트가 용이한 코드…유지보수성이 높은 코드에 대해 고려하게 된다.
예외 케이스는 멀티스레드, 멀티 인스턴스, 분산처리, 동시처리, 트랜젝션, 롤백, 물리적 단선, 등등 너무나 고려해야 할 케이스가 많기 때문에~~~~~~
개발자의 경험과 역량에 크게 좌우된다.
일단 내가 만든 것에 확신이 없거나 확신이 있더라도 중요한 시점에 대한 정보는 미리 로그를 잘 남겨 놓는다면 해결하기 어려운 문제에 봉착할 확률이나 리스크를 줄여줄 것이다.
그리고 팀프로젝트를 하게 되면 CI 서버는 반드시 구축하고 테스트 코드 작성이 필요하다.미리 CI에서 걸러진 테스트 코드들이 QA -통합테스트 비용을 줄여줄 것이다.
프로그램을 잘 만들기 위해서는….적어도 아래 정도는 필요하지 않을까…
1. 집중!!!
2. 플로우차드(flow chart)
3. 진리표(true table)
4. Test code
5. CI 서버
6. 로그
hothead 