///////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // 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파일이 읽기 전용모드로 설정되어 빌드시 에러 발생. [노현철]