426 lines
28 KiB
Plaintext
426 lines
28 KiB
Plaintext
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
|
|
//
|
|
// Server Bug History
|
|
//
|
|
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
|
|
|
|
//---------------------------------------------------------------------------------------------------------------
|
|
<목적>
|
|
1. 본인이 실수한 것을 비롯한 각종 버그 사항들을 기록한다.
|
|
2. 같은 실수를 반복하지 않기 위함이며 내용을 공유하여 다른 작업자들도 동일한 실수를 범하지 않게 한다.
|
|
3. 기록된 문제점들을 검토하여 프로세스, 시스템을 개선할 수 있는 기회로 활용한다.
|
|
|
|
<작성방법>
|
|
1. [제목] 내용설명
|
|
=> [원인] ...
|
|
=> [개선점] 본인이 생각하는 개선점 : 딱히 없거나 뻔한 내용이면 안 적어도 됨
|
|
=> [개선점] 다른 작업자들의 코멘트
|
|
//---------------------------------------------------------------------------------------------------------------
|
|
|
|
=============================== 2009년 06월 ========================================
|
|
[이은파]
|
|
1. 나는 '경험론자'이다... 그런가?
|
|
|
|
=============================== 2009년 02월 ========================================
|
|
[이은파]
|
|
1. 부정 의미의 변수에 부정 연산을 하면 혼란을 초래할 수 있다. (자초했음)
|
|
BOOLEAN bInvalid = ~~
|
|
if(!bInvalid) // <-- 보기에는 문제 없어 보이나 이런 저런 조건이 붙게 되면 혼란스럽다.
|
|
|
|
다음은 위의 반례들을 열거해 본다.
|
|
BOOLEAN bValid = ~~
|
|
if(bValid) // OK
|
|
if(bValid == FALSE) // OK
|
|
if(bValid != FALSE) // OK
|
|
if(!bValid) // OK ...이렇게 관례상 많이 사용하고 있으니까...
|
|
if(bValid == TRUE) // <-- 재고의 여지 있음. 컴퓨터 논리 구조상 0이냐 아니냐로 TRUE|FALSE가
|
|
//결정나기 때문에 잘못된 평가가 내려질 수 있다.
|
|
// if(bValid != FALSE)가 더 바람직하다고 생각된다.
|
|
|
|
[이은파]
|
|
1. 지난 3년을 회고하며...
|
|
- 입사한지 3년이 넘었다. 기억에 남는 부분 회고해 본다.
|
|
- 입사 이래 최대의 굴욕 :
|
|
SolarAuth 네트워크 데이터 스트림 압축해서 처리하는 작업 적용이 해외 각국의
|
|
동의하 일정까지 정해졌는데, 특정 문제가 발생해서 (개인 테스트 미스로) 일정이
|
|
지연되던 시점
|
|
- 입사 이래 두 번째 맹점 :
|
|
내가 할 줄 아는 것 다른 사람도 할 줄 아는 줄 알았다.
|
|
생각해 보면, 세상에는 모르는 것, 또는 익숙치 않은 것 천지, 특정 사례로 따져도 다
|
|
른 사람이 아는 것을 내가 모르는 경우는 얼마든지 있어왔다. 이러한 사실을 알고 있
|
|
으면서 간과된 것은 명백한 미스다.
|
|
- 입사 이래 최대는 아니지만 무안한 사례 :
|
|
누군가 왈 : '나를 따르라' 식의 코딩 좋지 않다 말씀하신다.
|
|
그럴 의도 아니었는데... 입장 바꿔 생각해보면 그럴 수 있다. 반성하자.
|
|
- 입사 이래 가장 불안했던 시절 :
|
|
게임 로직에 대한 이해가 도무지 되지 않던 입사 후 5개월 되던 시점. 이때 Zone관련
|
|
처리에 속으로 이를 갈았음.
|
|
- 입사 이래 가장 힘들었던 시점 :
|
|
입사 후 10여개월 되던 시점. 약 2개월동안 갑자기 두 사람 업무를 담당할 수밖에
|
|
없었던 시점. 개인적인 문제보다는 항상 다른 사람과 연결되어 작업할 경우의 시간
|
|
지연 문제...
|
|
- 입사 이래 자신의 처지가 가장 씁쓸했던 시점 :
|
|
이미 누군가가 작업해 둔 것이 지속적으로 크리티컬 문제를 야기해 문제점을 파악하고
|
|
해결해야 하던 2007년 중반 시점. 아이러니 하게도 그것때문에 그 당시의 평가를 나쁘
|
|
게 받지 못하는 입장이 되긴 했지만, 그때 이후로 문제없는 프로그래밍 방법을 고민
|
|
하던 것이 지금에 이르고 있고 그것이 '최대는 아니지만 무안한 사례'로 변질됨.
|
|
- 입사 이래 세 번째 맹점
|
|
[묻어 가기] 잘 하면서 그것이 먹는 문제 등등에만 국한된 문제. 적절히 맞추는 방법
|
|
의 필요성을 별로 못 느낀 것.
|
|
- 입사 이래 최대 맹점
|
|
난 이제 학생이 아니다. 연구원도 아니고 그냥 회사원이다. 이걸 자꾸 잊어버리는
|
|
것은 정말 병적이다.
|
|
|
|
=============================== 2008년 09월 ========================================
|
|
[이은파]
|
|
1. 최근 관심을 가지고 있는 부분
|
|
- 보수주의와 진보주의 (심리적인 관점)
|
|
- 흔히 듣는 용어이며, 어느 정도는 누구나 이해하고 있다. 또한 누구나 이 두가지 성향을 가지고 있다. (좀더 구분되지만 여기까지)
|
|
단지 전체적인 성향, 특정 부분에 대한 성향에 차이를 보일 수 있다.
|
|
- 보수주의의 사전적 의미 "미지의 것을 두려워하고 변화를 싫어하여 자기가 익숙한 것에 집착하는 성향"
|
|
- 진보주의의 사전적 의미 "변화를 좋아하고 낡은 것을 버리고 싶어하는 성향"
|
|
- 심리적이 관점에서 이것은 기계적인 반응을 보인다고 한다.
|
|
- 개인적인 입장에서 이 둘을 구분할 때, 대학교 교양수업으로 들었던 세계사 교수님의 영향을 많이 받았다고 생각한다. (교수님은 굳이
|
|
구분하면 보수주의 성향이 강했다.)
|
|
- 이 두가지 사상은 각기 장단점이 있다.
|
|
- 다음은 사회라는 관점에서 봤을 때의 개인적인 생각이다.
|
|
- 사회의 안정을 위해서는 보수주의가 상대적으로 강한 것이 좋다.
|
|
단지 그런 성향이 더욱 두드러지는 쪽이 기득권을 가진 자 쪽이라는 점에서 그렇지 못한 쪽에서 자연스럽게 진보주의 성향이 강해지게 된다.
|
|
본인의 경우는 관심의 유무에 따라서 극단적으로 달라지는 경향이 있다. 사회적인 관점에서 관심이 없기 때문에 보수주의 성향을
|
|
보인다. (무관심의 경우도 포함시킨다면.)
|
|
- 진보주의가 상대적으로 강해지면, 사회는 불안정해진다. 이른 바 '격동'이라는 표현을 즐겨 사용하게 되며, 역사적으로는 '혁명'
|
|
이라는 용어로 일종의 과도기적 성격을 지니게 된다. 성공하면 더 나은 사회가 될 수도 있다.
|
|
문제는 그 변화되는 방향이 반드시 좋은 방향이라 볼 수 없다는 것.
|
|
- 정치적인 부분은 함부로 언급하면 바로 짱돌이 날아올지도 모르겠지만... 신보수주의를 표방하는 뉴라이트같은 단체에서는 촛불집회
|
|
같은 것에 대해 '반동주의(진보주의의 나쁜 방향으로의 과격한 변화)'로 평가하는 것은 앞에서 언급한 이유를 들 수 있을 것이다.
|
|
- 다음은 회사라는 관점에서 봤을 때의 개인적인 생각이다.
|
|
- '이윤추구'라는 회사의 기본적인, 그리고 최대의 명제 앞에서 보수주의와 진보주의를 가리지 않는다.
|
|
- 게임업계는 크게 두가지 부분에서 진보주의 성향이 강한 부분을 보인다.
|
|
- 첫째, 경쟁대상이 많다. 이는 생존하기 위한 몸부림을 요구하게 되며, 따라서 확보한 것에 대한 기득권을 유지하기 위해 보수
|
|
주의 성향을 보이게 된다. 확보하지 못한 것에 대해서는 진보성향을 보이게 된다.
|
|
- 둘째, 역사가 짧다. 이는 회사로서의 체계, 수익구조의 불완전성 등을 보이면서 안정되지 못한다.
|
|
- 보수성향을 보이는 시점은 '라이브'라 표현되는 수익구조가 생겨났을 때 두드러지게 된다.
|
|
- 그리고 최근 우리를 본다면, 새로운 프로젝트의 유무에 대해 보수주의와 진보주의가 미묘한 대립을 하기도 했었다.
|
|
- 회사원...이라는 입장에서 봤을 때 개인적인 생각이다.
|
|
- 회사에서 일하는 목적이 무엇인가? 인적 노동을 지불함으로써 밥그릇 챙기기 위한 동물적 본능을 충족시키려는 행위이다.
|
|
- 따라서 보수성향을 보이게 된다. 밥그릇 빼앗으려고 하면, 누가 가만히 있겠는가? 또한 밥그릇을 더 챙기기 위해 회사를 옮
|
|
기기도 한다.(단면만을 표현한 것이므로 오해는 말 것) 이는 평생 직장의 개념이 사라진 지금 더 극명하게 드러나고 있다고 생각된다.
|
|
- 최근 3명이 퇴사했다. 이유야 어찌되었던 그들은 그들이 더 좋다고 생각되는 방향으로 나간 것이며, 우리가 뭐라 탓할 수 없
|
|
는 영역이라 생각된다.
|
|
- 프로그래머...라는 입장에서 봤을 때 개인적인 생각이다.
|
|
- 최근 다른 IT업계의 지인들을 만나는 자리가 있었다. 그들의 불만은 사수는 물론 그들의 선임들이 자신의 기술을 제대로 알려
|
|
주지 않는다는 것이다. 그리고 그것만 계속하고 있다고 한다. 별것도 아니면서!...라고 불만을 토로했다. 개인적으로는 '그 별
|
|
것도 아닌 것 직접 익히지 왜 기다려?'라고 말하고 싶었지만 참았다.
|
|
- 회사원...이라는 입장에서 봤을 때, 그들은 보수주의 성향을 보였다고 생각된다... 탓할 수 있는 일인지 없는 일인지 판단하
|
|
기 힘들다. 물론 회사의 입장에서는 탓해야 하는 일이지만, 그들의 파워에 밀려 탓하지 못하는 것도 문제긴 문제다. 또한 지인
|
|
들의 불만 역시 보수주의에 입각한 불만이었다.
|
|
- 전체적으로 봤을 때, 현 시점 프로그래머는 3D업종에 버금가는 기피대상이다. 그 중에서도 게임 프로그래머는 수위를 꼽을 수
|
|
있다고 보인다. '힘드니까...'라고 표현되며, '밥그릇 챙기기 힘드니까...'라고 표현될 수도 있다. 더 나아가 '계속 변화해야
|
|
하니까...'라고 표현할 수도 있다고 생각된다.
|
|
- 어찌되었던 현 시점 프로그래머라는 군집은 보수주의 성향이 더 강한 시점으로 보이며, 전체적으로는 안정되어 간다고 보인다.
|
|
- 개인적으로는 관심분야인 프로그래밍쪽에는 보수주의와 진보주의 성향이 극과 극으로 나뉘어 있다고 생각된다.
|
|
관심이 없으면 보수주의를, 관심이 있는 경우 진보주의를 택한다. (여기서의 관심은 작업의 유무도 무시할 수는 없을 터지만...)
|
|
따라서 게임업계에 들어온 것이 다행이 아닐까 생각된다. 변화가 없는(그 변화가 미미한 또는 그 변화를 허용하지 않는) 쪽에서
|
|
내가 견딜 수 있을 까? 자문해 보면 대답은 '아니요'다.
|
|
- 물론 나중에 가정을 가지거나 하는 외부의 요인으로 인해 '밥그릇'쪽에 좀 더 관심을 가져야 하는 상황이 되면 지금의 성향은
|
|
크게 꺾이긴 할 거다. 물론 내부의 요인도 있지만... 뭐, 이걸 논할려고 한 것은 아니니 넘어간다.
|
|
- 개발프로세스 관점에서 본 XP (eXtream Programming)
|
|
- 기본 보수주의, 요구사항 진보주의가 아닐까 생각된다. 우리식으로 표현하면 0813, 0814, ~ 식의 방법도 유사한 면이 있다.
|
|
- 최근 코드기어스 R2를 보고 개인적인 생각이다.
|
|
- 일단 등장 인물 대부분이 콩가루들이다. 정상적인 인간 찾기가 힘들다. (여기서의 정상적인 인간은 앞에서 언급한 보수주의와 진보
|
|
주의가 적절한 균형을 유지하는 경우로 본다면...) 주인공의 부모들은 급진주의를 통한 복고주의(보수주의의 과격정도?)를 만드려고
|
|
한다. 모든 인격들의 연결? 전쟁이 없는 세계? 개소리. 보수주의와 진보주의가 빛과 어둠이라고 했을 때, 둘 모두 하나가 없으면
|
|
존재하지 못하는 것들이다. 현 시점의 보수주의가 없어지면, 남은 진보주의에서 다시 보수주의와 진보주의로 나뉠 것이다. (물론
|
|
균형점 이동은 존재할 수 있지만...) 이것이 인간이며, 인간 사회다.
|
|
- 결론
|
|
- 개개인 모두 두 가지 성향을 가지고 있으며, 팀, 회사, 더 나아가 사회 모두 이러한 성향들을 복합적으로 가지고 있다. 그것이
|
|
인간 사회라 불리는 것이다. 한쪽으로 많이 치우칠 경우 어떤 형태로든 진통이 생기기 마련이다. 결국 이 두 성향을 어떻게 잘 받
|
|
아들여 잘 조율할 것인가가 개인은 물론 군집의 더 나은 이상향으로 향할 수 있을 거라 생각된다.
|
|
- 한 마디로... 표현은 힘들지만...
|
|
- 이 파일에 기록한 이유...?
|
|
- 나 자신이 스스로 이상하다고 생각될 때가 있다고 한다면, 세상이 돌아가는 모습을 관조하고 있다는 느낌을 받을 때이다. 주변의
|
|
관찰, 데이터를 통한 관찰, 팀 또는 사회의 분위기를 그저 바라만 보고 있으면, 또는 아, 이 사람이 지금 무슨 생각을 하고 있는지
|
|
알겠다...라는 생각을 강하게 받을 때면, 그것이 관심을 유발하게 된다. 그리고 그 잣대로 최근에 사용하는 것이 fussy논리와 함께
|
|
'진보주의'와 '보수주의' 평가다.
|
|
- 물론 세상은 true|false로 나눌 수는 없다. 하지만 제약을 가한 system에서는 어느정도 가능하다.
|
|
프로그래밍이라는 것도 마찬가지다. 각자의 성향이 어울려 나타나는 파워다. 배척, 적극 수용과 같은 양 극단 만을 제어한다면,
|
|
호감, 비호감 정도로 구분하면서 조율할 수 있으면 하는 생각이다. 좋은 구조란 그 시점에 과거보다 좋은 구조일 뿐, 미래에는 다시
|
|
이전이 더 좋은 구조일 수도 있다.
|
|
- 불평이란 더 나은 방법을 제시하는 진보주의로 나갔으면 하고, 잘못된 부분에 대해서는 선례를 따르는 보수주의로 나갔으면 한다.
|
|
(굳이 현 시점을 부정적으로 표현하면, 더 나은 방법 제시가 없는 불평과, 잘못된 부분은 땜빵이라는 방법_이게 선례라면 슬프다_
|
|
을 선택한다고 보인다)
|
|
- 나 자신에 대한 반성
|
|
- 프로그래밍을 좋아하는 이유는 내 사고 자체가 이진 트리형태를 이루고 있기 때문이다. 시작이 true|false로 나뉘더라도 그 하단
|
|
분기를 통해 다시 true|false로 나뉘면서 평가할 수 있다. 하지만 인간의 오욕칠정은 이진트리로 나누기에는 너무나 변수가 많다.
|
|
경험하지 못한 부분, 또는 생각의 영역이 미치지 못하는 부분에 대해서 하단 이진 분기를 할수는 없지 않는가?
|
|
실례로 음... 변수명과 같은 예를 들어보자. 대문자로 시작하는 사례를 본 적이 없었던 시점, 생각의 한계는 여기까지. 대문자로 시
|
|
작하면 안된다라고 결정되어 있다가 실제 외부 사용 사례를 보고 아, 이런 경우도 있구나...하고 생각의 트리는 확장되었다.
|
|
감정적인 부분에 의한 결론은 대부분 무시하는 편이다. 왜 그래야 하는지 생각의 이진트리가 거기까지 확장되지 못하고 있기 때문이다.
|
|
이래서 인간 관계가 어렵다고 느끼는 것 같다. 이성과의 만남... 왜 그래야 하는지 이해하지 못하고 있으니 그것에 대한 이진트리의
|
|
결론은 항상 false를 가리키고 있다. 가끔 순수한(여러가지 이해관계가 얽혀있기야 하겠지만... 아, 안돼. 이것도 이진트리 분기다!)
|
|
감정의 표출을 보이는 사람들이 부러울 때가 있다. 현 시점에서의 평가는 이성적으로 아직 경험해보지 못한 영역을 그는 알고 있기
|
|
때문이지만... 난 아직도 덜 된 인간이다.
|
|
|
|
|
|
=============================== 2008년 08월 ========================================
|
|
[김창현]
|
|
1. 아이템 스크립트 읽다가 오류시 continue 처리 해서 버그 발생.
|
|
- 현재 0816에서 작업하다가 기존 버전과의 호환성을 생각지도 않고 복사하여 문제 발생.
|
|
0816버전은 continue해도 무관하지만 기존의 파서들은 안된다. 물론 스크립트의 버그가 원인이지만 대처하지 못한 내 잘못이 더 크다.
|
|
앞으로 관리 시 기존 버전의 동작에 대해서도 꼼꼼히 생각해 봐야겠다.
|
|
=============================== 2008년 08월 ========================================
|
|
[김창현]
|
|
1. 저탑 입장 시간 스크립트가 비었을 시 버그 발생.
|
|
- NULL체크 안한것도 안한거지만 너무 하드코딩으로 해놨었다. 잘 하지 않는 부분인데 그렇게 해서 자신에게 매우 유감스럽다
|
|
오래 된 작업이긴 하지만, 앞으로는 신경을 좀 써야겠다.
|
|
|
|
=============================== 2008년 06월 ========================================
|
|
[김창현]
|
|
1. 소스를 수정했는데 기존의 구문이 당연하다고 여겼던 부분이 내 생각과 틀려 버그를 유발.
|
|
- 남의 소스를 수정시에는 좀더 신중하게 해야겠다는 생각이 든다.
|
|
|
|
=============================== 2008년 03월 ========================================
|
|
[이은파]
|
|
1. 내가 버그다. (080312)
|
|
- 많은 불만을 듣는다. 아무리 생각해도 이해하지 못하는 부분들이 있다.
|
|
곰곰히 생각한 결과 다음과 같은 부분에서 관점을 바꾸고 행동을 바꿀 필요점을 깨닳았으며,
|
|
해당 패턴에 대한 실천 및 테스트를 진행하기로 한다.
|
|
|
|
---- 행동 강령 ----
|
|
1) 프로그래밍을 취미로 생각하는 것은 그만 두자. 일로 생각하자. 적어도 나에겐 필요하다.
|
|
당장 어렵다면 최소한 일과 취미의 프로그래밍을 구분하자.
|
|
2) 생각을 정리한다는 취지에서 단위 코드 재정리를 수행하지 말자. 지금까지로 봐서는 90%이상 욕먹었다.
|
|
=> 코드 재정리가 문제가 되는 것이 아니라 리펑토링이 문제라고 생각합니다. 모두가 공감할 수 있는 구조로 리팩토링을 해야하지 않을까요?
|
|
3) 리팩토링을 가장한 리펑토링은 그만두자. 이것 저것 시도해 본것까지는 좋았지만 2)번의 결과를 낳는다.
|
|
또한 스스로 생각해도 반드시 성공 사례가 나오는 것은 아니다.
|
|
4) 타성에 물들자. 관심 없는 부분에 대해서는 묻어가는 성격이 대단히 강한데... 이것만 예외였던 것도
|
|
오버페이스를 야기한다.
|
|
=> 이런 일들로 인해 굳이 본인의 장점(끊임없는 리팩토링과 새로운 시도 정신?)을 죽일 필요는 없겠죠?
|
|
5) 타성에 물들자. 누가 해주겠지나, 알아서 잘 하겠지...라고 되뇌이자. 적어도 나에겐 필요하다.
|
|
6) 어느정도의 불평은 과도기로 생각하고 각오한 바 있었지만, 이쯤되면 문제가 크다. 무리하지 말자.
|
|
7) 주말근무 그만두자. 이것저것 고민하고 살펴보는 시간이 생김으로써 남들 이상으로 생각이 많아진다.
|
|
8) 주말근무 그만두자. 이것저것 개선하고자 쓸데없는 작업(그것도 욕먹는)을 하게된다.
|
|
9) 리듬이 깨지면 아픈 경향이 있다. 1,7,8)에 연관되어 일 외에는 철저하게 놀 수 있는 방법을 강구하자
|
|
당장은 컴퓨터를 벗어날 수는 없겠지만...
|
|
10) 무리하지 말자. 무리하면 할 수록 욕먹는다. 결과적으로 나 역시 심신이 지친다.
|
|
4,5,6)에 연관되어 내가 왜 해야하지라고 생각하자. 최소한 나에겐 필요하다.
|
|
11) 절대 2번 이상 생각하지 말자. 1번만 생각하면 최소한 다른 사람과 코드가 비슷해진다.
|
|
괜히 이산, 집산, 재구성 등을 고민하면서 절대 욕먹는 형태가 나온다. 적어도 나의 경우에는 필요하다.
|
|
12) 11)에 연관되어 즉흥적으로 작업하자. 적어도 나의 경우엔 필요하다.
|
|
=> 너무 오버를 하네요^^ 제가 직설적으로 얘기하자면 열심히 일을해서 문제가 되는 것이 아니라 잘못된 방향으로 일을 하기 때문에 문제가 되는 것입니다.
|
|
이번과 같은 일들을 통해 본인이 성장할 수 있는 계기가 되는 것이 중요하다고 봅니다.
|
|
=>=> [은파] 어... 될대로 되라...라는 의미는 아닙니다. 한번 구현된 것 (이건 체크인 이전이 될 수도 있습니다)에
|
|
아, 이런 기능이 있으니 여기에 묻어가자. 아, 이런 반복 패턴이 나오네, 묶어두자라는 식으로 다시 생각을 하면서 야기되는 결과입니다.
|
|
그것이 그 시점에 이렇게 적용하면 어떨까 해보자, 저렇게 적용해 보면 어떨까 하는 시기에 따라 달라지는 방법으로 적용하는
|
|
잡음이 들어가면서 특이한 형태가 나오는 것이 사실입니다. (물론 시작이 잘못된 경우도 많습니다만...^^)
|
|
그래서 일반적으로 생각할 수 있는 수준에서 멈추자라는 의미로 기재했습니다.
|
|
13) 일관성을 포기하자. 융통성을 추구하자. 12)와 관련이 크다. 적어도 우리는 그런 경향이 강하다.
|
|
4,5,11)에 연관되어 다른 사람과 유사한 코드를 만들고, 그 결과 적어도 욕은 안 먹을 듯 하다.
|
|
14) Version2는 생각하지 말자. 우리는 end-front라 생각하자.
|
|
뭐...... 달리 표현하면 우리는 developer가 아니라 user다...라고 되뇌이자. 적어도 나에겐 필요하다.
|
|
15) 개발 마인드를 바꾸자. 여기는 R&D가 아니다. Factory다. 현실을 도피하지 말자...
|
|
버전업하러 온 게 아니다. 찍어내려고 왔다...
|
|
왠지 표현이 과격한데, 순화시키면 부품 조립해 제품 만들러 왔지, 부품만들러 온 것 아니다.
|
|
(뭐, 이건 초기 선택 및 판단 미스이기도 하다.)
|
|
16) 9, 15)에 연관되어 정 다른 흥밋거리가 없으면 공장자동화나 디자인쪽으로 고민하자. 14)에 위배되는
|
|
상황이 발생할 텐데, 그 부분은 Win-Win 형태를 선택하자.
|
|
17) 모두 사회인이다. 기존의 것이 변경된 신규 형태에 대한 시공간적 부담감을 충분히 가질 수 있다.
|
|
모두가 나와 같다고 생각하지 말자. 14)에 연관되서 내식으로 표현하면, 모두 보드 제작자라고 생각
|
|
하자. (아마 이게 근본적인 문제일 가능성이 크다.)
|
|
18) 현실을 무시할 수 없다. 난 몽상가 기질이 강하다. 양립 자체가 쉽지는 않겠지만 양립할 수 있도록
|
|
하는 것이 나에게 지상과제라 생각하자.
|
|
=> 네 맞습니다. 은파씨 말대로 현실을 무시하는 코딩은 문제가 있습니다. "현실에 맞는 코딩"이라는 표현보다는 저는 "실용주의적인 코딩"을 지향한다고 말하고 싶네요.
|
|
프로그래밍에 관한 다양한 이론들이 나오는 이유가 무엇이겠습니까? 저는 실제 코딩 중에 일어나는 여러가지 문제점들을 해결하는 과정에서 자연스럽게 나오는 것이라고 생각합니다.
|
|
|
|
1. 유사한 문제가 재발되지 않도록 구조화 시키고 일반화시킨다.
|
|
2. 유사한 문제가 재발되지 않도록 많은 사람들에게 해당 내용을 알려서 범용화 시킨다.
|
|
3. 알리고 이해시키기 위해서는 이해하기 쉬워야 한다.
|
|
4. 유지보수가 쉬운 구조여야 한다.
|
|
|
|
좀더 생각이 날듯말듯한데 이정도로 하겠습니다. 문제의 요지는 애초에 문제점들을 해결하기 위해 혹은 실수를 방지하기 위한 목적으로 리팩토링을 하는 것인데
|
|
그것이 오히려 어려워서 작업시간이 늘어나고 다른 버그를 유발(다른 작업자가 소스분석을 잘못해서 어딘가 빠뜨리는 경우) 시킬 수 있다면 리팩토링의 목적을 상실하는 것입니다.
|
|
새로운 라이브러리를 배포할 때는 반드시 사용자의 편의를 고려해야 될 것입니다. 적어도 게임개발에서는 소소한 성능문제는 둘째 입니다.
|
|
=>=> [은파] 예. 긍정입니다. 아, 한가지만 제외하고... "우리 현실에 맞는 실용적인 코딩"으로 정정하죠.
|
|
내포냐 포괄이냐의 문제니까... 너무 일반화시키신듯. (뭐 18번 내용 자체가 두리뭉실해서 해석하기 나름이었지만.)
|
|
=>=>=> [은파](080913) 추가 정정합니다. "우리 SUN 프로그램팀에 맞는 실용적인 코딩"으로 더 구체화 시키겠습니다.
|
|
작성 시점 이후의 추가 정보수집에 의한 결과로 나온 생각입니다. 나쁜 의미는 아니고 굳이 구분하면 다른 곳보다는 비교우위라고 생각됩니다만...
|
|
|
|
|
|
2. SUN Server <-> OpServer
|
|
- 서버키 가 일전에 바뀐 뒤, SERVER_KEY, OLD_SERVER_KEY라는 두가지 버전이 생겨났다.
|
|
- 이 두가지의 차이점은 저장방식이 역으로 저장된다는 차이점만 있어야 했다.
|
|
- 그런데, OLD_SERVER_KEY는 SERVER_KEY로 입력시 반대로 바꾸고, DWORD로 입력시 그대로
|
|
입력하도록 설정되어 있었다. 뜨허~ 좀더 작업 당시에 상호간 혼동을 일으킬 만한 부분을
|
|
통일하거나 배제시켜야 했었는데... 그동안 SUN Server <-> OpServer간 발생하던 이런 저런
|
|
문제점의 상당수가 이런 문제에 기인하고 있었을 듯 하다... 지금와서 바꾸기도 뭐하고...
|
|
- 진퇴양난
|
|
- [개선점]
|
|
- 프로토콜은 상호간의 약속이다. 갑자기 바뀌는 경우를 경계해야 하며,
|
|
- 초반에 확실히 잡고 넘어가자.
|
|
[김창현]
|
|
1. define 을 잘못 걸어서 기존 코드 영역에 영향을 주게 되었음. 아하하;;
|
|
- 실수 하지 마세요, 창현씨
|
|
|
|
=============================== 2008년 01월 ========================================
|
|
[김창현]
|
|
1. DB에 저장된 스트림 계열들(인벤토리, 장비 창고 등) 은 사이즈를 늘려도 저장된 실제 데이타는 늘어나지 않으므로 주의.
|
|
- 컨버터를 이용하여 0 채워줘야한다!!!
|
|
- 근데 아이템 버전 관리가 진짜 뭐같이 되어있다. 고칠방법이 없을까요?
|
|
|
|
=============================== 2008년 01월 ========================================
|
|
[최정록]
|
|
1. 발키리 에테르웨폰 스플래쉬 데미지가 비정상 동작하였던 버그
|
|
=> [ 원인1 ] GameScriptParserManager의로컬에서 ini 파일을 읽어들이는 SolarAuth에서 읽어들이는 방식 2가지가 존재
|
|
로컬의 ini파일을 읽어들이는 정보도 _SetSectionValue에서 읽어들이는 로직에 추가해야함.
|
|
=> [ 원인2 ] ini의 값중에 백분율을 의미하는 값이 존재한다 ( ini 파일에서는 30%일경우 30으로 표기 )
|
|
하지만 실제 읽어들일 경우에는 (30 / 100.0f) 형식으로 읽어들인다. 나누기를 하지않고 그냥 적용하여
|
|
데미지가 비정상적으로 높게 적용되었다.
|
|
|
|
확율값(백분율)과 정수값은 스크립트 파일이나 ini파일에서 같은 정수 값으로 표기되기 때문에 정확한 명명이 필요하다
|
|
값으로만 보아서는 제작자가 아니면 분간하기 힘들기 때문임
|
|
|
|
[김창현]
|
|
1. 팀장님보고 점심먹으러 가자니까 아직 이르다며 버럭한다. 10초뒤에 조주임님이 가자니까 조용히 그냥 간다.
|
|
사람 차별하는것도 아니고...
|
|
|
|
[노현철]
|
|
1. 쪽지를 보낼 시 개행문자 처리가 되지 않아 보내는 쪽이 행을 구분하여 보내도
|
|
서버를 통해 상대방이 받고 나면 전부 한 줄로 보이는 버그.
|
|
=> [원인] 쪽지를 보낼 시 특수문자를 처리하지 않도록 하는 과정에서 개행 문자도 특수문자로 취급해 처리를 하지 않았다.
|
|
|
|
=============================== 2007년 12월 ========================================
|
|
[이준석]
|
|
1. [덤프 안남는 문제] 중국에서 서버가 다운되었는데 덤프가 안 남는다네요.
|
|
=> [원인] 공유 폴더가 읽기전용으로 되어 있었음.
|
|
=> 이거 여러가지로 추측이 남무했었는데 결국 원인은 단순한 데 있었네요. 에고... 요런거 자칫 원인을 몰랐으면
|
|
무지하게 삽질을 할 수 있었다는거!
|
|
2. [샵서버 아이템 등록 누락] 기간연장을 위해서 반드시 등록해야 하는 아이템이 있는데 등록이 안 됨
|
|
=> [원인] 작업당시 담당자만 알고 있었고 오랜 시간이 지난 후 그 내용에 대해 잊고 있었음
|
|
=> [개선점] History_Cooperation.txt를 적극 활용하는 수 밖에 없음. 협업과 관련된 중요한 사항들은 모두 기록해 두자!
|
|
3. [Viewport 문제] 동일한 버프가 중복해서 걸리는 문제 발생
|
|
=> [원인1] viewport 처리시 유저가 필드를 떠날때에 대한 처리가 없었음. UpdateTime에 따라 문제가 발생.
|
|
=> [원인2] 처리로직이 알쏭달쏭 함. 원래 로직자체가 그러한 거라서 어쩔 수 없지만 소스 리팩토링은 필요한 상황임. 귀찮아서 안하고 있는중 -_-
|
|
=> [원인3] 테스트 부족! Viewport에 대해서 사전에 충분히 주의를 시키고 테스트를 요청했음에도 문제를 찾지못했음. 어떻게 테스트를 한 것인지...
|
|
|
|
[이은파]
|
|
1. [게임서버 무한 루프 문제]
|
|
=> 이래 저래 말도 많고 탈도 많았던 문제, 라이브 디버그 모니터링을 통해 문제가 생기는 위치(StatusManager)를 찾았음.
|
|
=> 한동안의 삽질하던 과정에서 무한 루프가 생길 수 있는 테스트 시나리오를 찾았음.
|
|
[원인1] : Loop시 Loop를 수행중인 자료구조의 Container의 삽입/삭제가 일어나는 위험천만 처리 형식이 존재.
|
|
이런 형태는 STL에서 보장되어 있지 않음. 사용하는 라이브러리마다 다른 결과를 보인다.
|
|
[보완1] : Loop를 도는 그 시점의 iterator들과 제거해야할 시점의 iterator들의 사본을 저장, 그리고 그 사본이
|
|
제거된 경우에 대한 예외 보장을 통한 Looping처리(StableForeach_IfTrueThenDeleteNode_TreeDS)
|
|
[원인2] : 이번에는 사본에서 제거되었을 때, 확인 가능한 처리 방법이 제대로 동작하지 않는 문제 확인
|
|
WIN32 환경에서의 free된 메모리값은 특정한 값으로 초기화 하고 있었음. SharedMemory를 사용하는
|
|
STLX를 사용하면서 문제가 발생한 형태.
|
|
이런 형태는 기존 STL allocator 스펙에서 명시하고 있지 않으며, Microsoft에서 임의로 정해놓고, 그들이
|
|
구현한 STL도 그것을 사용하는 (즉, 자기 환경에 맞춰놓은 방식) 형식이 발생했음...
|
|
[보완2] : ...일반적이지 않지만 SharedMemory도 Microsoft환경에 맞췄음.
|
|
=> [개선점] : 미정의 동작이 일어날 만한 상황은 애초 구조적으로 문제가 풀릴 수 있도록 고민해야 할 것이다.
|
|
물론 문제가 생긴 StatusManager에서 일어나는 각 Status의 행보는 골치아픈 부분들이 존재하긴 하지만,
|
|
이런 저런 방법들을 강구하다보면 해결 방안이 나올 것이다.
|
|
(발명이 아니다. 발견이다. 우리가 찾지 못하고 있을 뿐이다.)
|
|
|
|
[조재식]
|
|
|
|
[김창현]
|
|
1. [소켓 옵션 계속 추가되는 버그]
|
|
- 아이템 장착 시 _ForeachAddAttrBySocket를 호출하는데 장착 해제시에도 _ForeachAddAttrBySocket를 호출 해 버렸음.
|
|
- _ForeachSubAttrBySocket 를 호출해야 하는데 함수가 비슷해서 실수했음. ㅠ_ㅠ 정신차리고 코딩좀 해라 바보 창현아
|
|
|
|
[최정록]
|
|
1. [길드원 추방시 다른 유저가 탈퇴되는 현상] 클라에서 잘못된 유저의 ID를 보내옴
|
|
2. [삽질] 구버전의 스크립트로 작업하여 원인을 찾는데 많은 시간이 소요..
|
|
[주의점] 선 확인 후 작업.. 이랄까.
|
|
3. [마을에서 배틀존에 입장되지 않는 버그] 마을에서 배틀존의 목록은 보이나 입장되지 않던 버그
|
|
[원인] 리팩토링하면서 기존의 조건검색로직을 개선하면서 해당 조건 누락
|
|
=> 기존의 조건 검색로직을 수정할 때 효율적으로 로직은 수정하되 기존의 조건 체크가 모두 적용되도록..
|
|
4. [대만 크리스마스 이벤트 버그] 기존의 이벤트를 재 적용하는데 버그 발생
|
|
[원인] 스크립트 버그, SolarSlot.lib 구버전
|
|
=> 빌드하기 전에 라이브러리는 한번더 확인하도록 하자. 스크립트는...
|
|
5. [잘못된 문자열 처리를 통한 서버 다운]
|
|
[원인] 클라정보를 믿는 코딩을 하였고.. strlen 사용시 마지막에 NULL이 있다고 단정한 코드를 작성하여
|
|
문자열을 풀로 채워서 보내면 버퍼를 밀어버려 서버가 죽게 된다. ( NULL을 찾을때 까지의 문자열 길이 )
|
|
=> 클라로부터의정보를 믿는 코딩을 하면 안되며 문자열 처리시 서버에서 허용한 버퍼 사이즈 만큼의 처리를
|
|
보장해야 한다..
|
|
|
|
=============================== 2007년 11월 ========================================
|
|
[이준석]
|
|
1. [샵서버 패치 누락] 이번에 무기방어구 기능이 들어갔지만 샵서버 담당자는 전혀 모르고 있어서 테섭 패치가 안 이루어짐.
|
|
=> [원인] 패치 리스트 작성 때 분명히 내용이 들어갔지만 개발관리팀에서 정확한 내용파악이 안되어서 누락시켰음.
|
|
=> [개선점] 앞으로는 절대 이런 일이 안 일어나도록 우리가 신경쓰자!!
|
|
앞으로는 반드시 History_Cooperation.txt 에 외부팀과의 협업사항을 기록하도록 한다.
|
|
|
|
[이은파]
|
|
1. [잡담] 최근 심심치 않게 버그가 저로 인해 발생하고 있어와요.
|
|
=> [원인] 구조 개선 작업이 대단위로 이뤄지면서 집중력이 떨어진 모양이와요.
|
|
=> [개선점] (이은파) ...Copy & Paste ... 주의하자. 몇몇 완전 동일한 코드라면 문제 없겠지만, 미묘하게 틀려지는 부분을
|
|
복사해서 사용하면서 미스가 발생. 최근 한 달 사이의 버그는 90%이상 그런 버그들...
|
|
=> [개선점] (이은파) ...작업할 때 정신 바짝 차리자.
|
|
=> [개선점] (이은파) 그래서 이런 버그들을 줄이고자 하는 방안으로 "SUN Programming Guideline #~"로 느낀점, 개선하면,
|
|
유지보수 측면이나 버그 발생 빈도를 줄일 수 있을 듯 한 내용들을 강구해서 리포팅 중입니다.
|
|
2. [CRITICAL][Network 버퍼 결함] 서버간 연결이 끊기거나 잘못된 스트림 구조로 인해 쓰레기 패킷 수신 등의 문제 발생
|
|
=> [원인] 결함은 결함을 낳는다.
|
|
(결함 코드)
|
|
INT RingBufferEx::SkipTail( INT iLen )
|
|
{
|
|
#ifndef __WAVERIX_070911_NETWORK_BUG_FIX__BUFFER_WRITE_PROBLEM__
|
|
if( GetFreeSize() < iLen )
|
|
{
|
|
// len이 크면 아예 실패로 처리한다.
|
|
return -1;
|
|
}
|
|
#else
|
|
INT iFixLen = iLen<0 ? -iLen : iLen;
|
|
if( GetFreeSize() < iFixLen )
|
|
{
|
|
// len이 크면 아예 실패로 처리한다.
|
|
return -1;
|
|
}
|
|
#endif //
|
|
...blah~
|
|
|
|
=> [시나리오] SkipTail의 사용 사례로 봤을 때, iLen : IN 의 크기는 ( iLen <= 0 < iLen )이 될 수 있으며,
|
|
기존 코드상 iLen<0일 경우에 대해 정상 검출이 되지 않는 결함을 발견하고, 수정했다.
|
|
=> [결함] 애초 전제가 틀린 처리였음. GetFreeSize()는 현재 버퍼 가용 공간을 얻는 인터페이스이며,
|
|
iLen과의 비교대상이 될 수 없음. 굳이 따지자면 GetDataSize()와 같은 현재 쓰여진 데이터 스트림의 크기를
|
|
iLen과 비교해야 올바른 처리를 수행할 수 있게 된다. 등호도 수정되어야 함.
|
|
=> [해결과정] 상황이 이렇다 보니 결함코드를 수정해도 결함코드가 생산되는 문제로 귀결되었으며, 해당 메소드만
|
|
놓고 봤을 때는 " GetFreeSize() < iFixLen ==> GetDataSize() <= iFixLen "으로 수정해야 한다. 하지만
|
|
전체적으로 이런 인터페이스 등을 사용하면서 처리되어 왔던 기존 코드에 또 다른 예기치 못한 문제점을 양산하는
|
|
결함코드를 낳게 될 수 있다. 또한 SkilTail과 같은 함수들의 처리에 실패하는 경우에 대한 복구 코드가
|
|
존재칠 않는다. 이래저래 진퇴양난...
|
|
=> [해결책] 버퍼 처리에 관련해 철저한 명세서 구축을 바탕으로 문제점이 없도록, 문제점이 발생했을 때 또 다른 문
|
|
제점이 발생하지 않도록 코드 수정이 이뤄져야 한다. 이 경우는 그 사용 사례에 비추어 볼 때, 결함코드들로 도배된
|
|
상황으로 보이며 재 구축을 수행하고, 철저한 유닛 테스트를 수행해야 문제점이 해결될 거로 보인다.
|
|
일단 위의 실패 처리 자체는 아예 제거하는 것이 나을 거로 보인다. 그걸 복구할 수 있는 코드도 없으므로...
|
|
=> [개선점] "결함은 결함을 낳는다." 문제점이 발견되었을 때, 그 문제점을 수정하는 것만으로 모든 문제점이 사라
|
|
지지 않는다. 앞선 사례와 같이 결함을 수정하면 또 다른 결함이 생겨나는 문제도 있을 수 있다. 애초 결함이 없는
|
|
로직이 구축되면 모를까(과연)... 문제점을 보완할 경우, 이로 인해 발생할 수 있는 또 다른 문제점을 수정자는
|
|
고민해봐야 할 것이다. (뭐, 나름대로 테스트를 수행했을 때는 특정 상황보다는 랜덤 상황으로 테스트해서 걸리
|
|
지 않은 것으로 보이지만, 엎지른 물이다.)
|
|
|
|
[조재식]
|
|
|
|
[김창현]
|
|
1. [삽질] 아침부터 슬롯이 안된다고 클라이언트가 징징 거리길래 해줬다. 버전이 대만으로 체크인 되어있었다. 클라이언트가
|
|
국내로 고치더니 또 안된다고 징징 거린다. 나도 국내로 바꿔서 슬롯 lib를 줬다. 대만 버전 체크인 한 조주임님 두고 봅시다.
|
|
2. [삽질] 시리얼 작업을 하다가 이벤트 슬롯까지 건드려야 했다. 근데 다른 슬롯과 많이 다르게 생겼다. 이벤트 슬롯의 시리얼은
|
|
아이템 시리얼과 별개였다. 실컷삽질하고 깨달았다. 그냥 집에 갈걸...
|
|
=> [이준석] 니가 시리얼 발급과정 분석을 제대로 안하고 코딩부터 해서 그래 됐잖아?
|
|
작업 전에 중요한 부분이라고 판단되는 것은 분석하고 코딩을 합시다!
|
|
[최정록]
|
|
( 제가 하는 삽질이야 다들 아시겠지만 ㅎㅎ;; )
|
|
1. [삽질] AccountDBP, DBP의 인젝션을 알지 못해 하루 종일 삽질.
|
|
2. [삽질] 라이브 서버가 사용하는 포트와 개발용 서버가 사용하는 포트가 다름을 알지 못해 고생.
|
|
3. [삽질] lib파일이 읽기 전용모드로 설정되어 빌드시 에러 발생.
|
|
[노현철]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|