버그를 찾아내는 묘수가 있나요?

주석을 꼼꼼이 다는것도 중요하다고 생각합니다.

가장 중요한건 기획과 사양서겠지만 여건이 그러하지 못하는 경우가 많으니까요..

제 경우에는 리뷰를 통한 소스 프리젠테이션도 상당히 큰 도움이 되었습니다.(하지만 막상 하면 죽을맛이죠.. ㅡㅡ;)

Writing Solid Code 와 The Elements of programming style, 그리고 XP 시리즈를 참고해 보십시오.

참, 버그없는 코딩이 아니라 버그찾기 묘수였던가요? ;)

일본이 괜히 선진국이 아니군요..

제가 가지고 있는 원칙 : 초급수준의 코딩.. 쉽게 남들보기 쉽게 짭니다. 절대 workaround 나 나만의 비법 이런거 안쓰죠. 덕택에 버그가 줄긴 하지만 주위에서 튜닝하라고 난리칠때 문제가 ㅜ.ㅜ

불안정한 OS기반에서 개발된것들이 다 똑같지 뭐..

우리나라 s/w개발업체들 심지어 한컴도 설계가 매끄럽지 못해 항상 잦은 버그를 일으킨다고 하더군요 ㅡㅡ; 우리나라 it업체들 개발자 데려다 놓고 촉박한 시간에 구현위주로 개발방향이나 스케쥴을 맞추다 보니 정착 중요한 버그를 신경도 안쓰는듯합니다. 그리고 윗글에서 일본의 경우를 예로 들으셨는데 저정도의 반, 아니 1/3도 하지 않는 업체들이 태반입니다. s/w개발에 대한 인식도 없는 그런 사장, 팀장, 개발자가 모이면 버그 투성이인 제품만 만들겟죠! 우수운 이야기죠! 분명히 s/w개발을 한다는 업체에서 버그에 대한 인식이 부족하다는건... 그러면 결국 그걸 사용하는 사용자들이 피해를 입게 됩니다. 그렇다면 MS사의 윈도우를 말안할수 없겠네요 윈도우는 상당히 버그가 많습니다. 그 버그가 너무 많아서 사용자들이 많이 싫어했쬬 사실 리눅스가 어느정도 퍼진것도 윈도우의 버그의 영향도 많다고 볼수 있습니다. 그러나 MS사는 윈도우의 버그를 교묘히 이용해서 시장을 지배햇쬬!(-_-+) 프로그램을 만드는 것도 기술이지만 버그를 수정하는 것도 기술입니다. 또한 프로그램을 만드는것보다 버그를 잡는게 더욱 중요합니다. 국내에는 아직 버그잡는 tip/tech 사이트가 없는게 좀 아쉬울 따름입니다. 저도 it업체에 종사하는 사람으로써 저만의 방법을 얘기해보겠습니다.

일단 어떤 프로그램 개발하기 전에 작은 몇개의 모듈로 나눕니다. 그리고 모듈 하나씩 개발하는 거죠! 쉽게 테스트 프로그램이죠! 이미 만들어진 라이브러리 함수를 호출하거나 다ㅡ른 개발자의 소스를 참고하기도 합니다. 알고리즘도 적절히 변경해가면서 테스트 프로그램에서 충분히 테스트 합니다. 디버거를 이용해서 메모리 유출문제가 일어나지 않은가 체크도 하고 변수에 값이 제대로 들어가는지 원하는 결과가 나오는지 기타등등... 그런 모듈이 완성되면 본 프로그램 소스와 통합합니다. 그리고 다시 테스트하죠 -- 모듈 제작시 어느정도 테스트를 맞췄기 때문에 크게 이상이 있지 않는한 잘동작합니다. 그런식으로 작은 모듈 일단 만들고 본 프로그램 소스와 통합하고 계속 그 작업을 반복합니다. 결국 모든 모듈을 완성했으면 통합 테스트하죠 ^^;
어찌보면 구조적 프로그래밍 기법과 비슷한 개발방식입니다.
아무리 복잡하고 큰 프로그램도 결국 하나 이상의 명령어의 집합이므로 작은 모듈이 모여서 하나의 큰 프로그램이 되는거죠! 결론을 말씀드리자면 가장 일반적이고 무식한 방법이 가장 좋은 방식입니다.

테스트하는 사람 따로 없다고 하는데 왠만한 회사에서는
QA, QC라고 불리우는 사람들이 테스트를 하고 타부처나 고객,
타사에 전달하는데 추후 발생하는 문제에 대한 책임이나 처리도
도맡아 합니다.

월급주고 키울만한 가치가 있느냐고 생각하실지 모르지만 제가
다니는 회사의 경우에는 지대한 역할을 합니다. 온갖 버그들을
빠짐없이 정리하고 히스토리를 관리하고 스케줄에 맞춰 해결해
내도록 귀찮게 하는 것이 잔일이면서도 아무나 못합니다. :)

개발자분들이야 누가 그런 일을 하고 싶어하냐라고 생각하실지도
모르지만 의외로 그런 일을 좋아하고 자랑스럽게 생각하는 사람도
많습니다.

모듈별로 테스트가 제대로 이루어 졌는지 냉정하게 생각해 보시길...

또한 모듈별로 테스트를 하면서 작성한다고 해도, 가능하면 자주 통합테스트를 실시해야 합니다. 작성도 다 안된모듈로 어떻게 테스트를 하냐고 물으실 테지만, 가능은 합니다. 그럼 이만.

일본 회사에 취업해 있는 사람으로 결론 부터 내리자면... 애플리케이션이라면 회사가 매뉴얼(이른바 사양서)를 제대로 만들지 않아서 그렇습니다. 일을 하면서 버그 체크는 안됩니다. 10줄을 짜면 평균 1줄은 또 버그가 나옵니다.

네트웍 개발도 해본 얼치기 경험자로서 네트웍은 언제라도 예상외의 동작을 할 수 있으므로 넉넉한 개발 기간과 테스트 기간은 필수입니다. 아니면 섣불리 일을 맡으면 안됩니다. 세팅이 정확하다고 tcp/ip가 언제나 데이터가 제대로 날라가는게 아니란거 아시죠?

한국에서는 버그가 생긱면 개발자의 잘못으로 돌립니다만, 일본에서는 매뉴얼(사양서)에 이런 내용이 있는지 확인해보고 빠져있으면 다시 회의해서 개발스케쥴을 조정해주거나, 아니면 해당부분을 대타 불러서 처리해 줍니다. 일본쪽 회사에서는 당연히 그렇게 일처리를 하리라고 믿고 있을겁니다.

제가 일했던 모 회사는 개발자 200명이 크로스 체크를 했습니다. 저의 경우에 매일 평균 20여건씩 버그가 올라오더군요. 2달을 성능 개선없이 버그만 잡고 테스트 하길 반복했습니다. 버그를 그만큼 잡은 덕분에 나중에 크레임없이 잘 넘어갈 수 있었습니다. 지독하게 깐깐한 것이 결론적으로는 도움이 되죠. 당시 팀장이 핵심 업무중 하나가 버그 관리였습니다.

그리고 <다른 회사에서도 프로그래머가 테스트까지 같이 한다>고 하셨는데 개발자가 몇분이지는 잘 모르겠지만, 테스트 시간과 비용까지 일본회사에서 다 받았을텐데... 일본쪽 사정을 모르니까 하는 얘깁니다. 아니면 회사가 처음부터 덤핑을 친 모양인데 바람직해 보이지 않는군요. SI성 사업은 회사나 사람이나 골병이 드는 사업인데, 기술적인 문제까지 걸려 있다면 정말 어려워 보이는군요.

스케쥴관리는 기본적으로 칼퇴근이 가능한 상태에서 추가로 융통이 가능합니다. 다시말해 매일 야근하기 시작했다 싶으면 개발 스케쥴 관리는 물건너 갔다고 보면 됩니다. 야근을 한다는 것은 팀장이 스케쥴 관리를 잘못하고 있는 겁니다. 최소한 제가 일본에서 배운바에 의하면 그렇습니다.

일본인들 버그 잡아내는 기술은 한국은 아직 못따라갑니다. 일제가 좋다라는 얘기가 성능이 좋은 것도 있지만 오동작을 절대 하기 않기 때문이기도 합니다. 잔고장이 없다는 거지요.
그만큼 깐깐합니다. 현재 작업을 잠시 멈추시고 뭐가 문제인지 전체 버그 리스트를 뽑고 다시 스케줄을 잡아 보시가 바랍니다.