- 블로그 이전 하였습니다. http://www.withdev.com 으로 오세요. -
오늘 예전에 만든 부분을 수정하게 되어 변경 작업을 하였습니다.
문득 수정 하려니 내가 왜이렇게 코드를 만들었지 하는 의문이 들었습니다.
처음 혼자 작업하다 보니 머릿속에 있는것 코드로 바로 집어 넣고 체계적인 프로세스를 확립 하지 않은 상태에서 기능에 주안점을 두다 보니 그렇다고 변명은 한다지만.....
요즘 수정 작업하다 보면 이런부분이 간간히 보여 수정을 하지만 오늘 수정해야 할 부분은 정말 손을 못델정도로 ㅠ.ㅜ 추후 시간날때 하자고 다짐은 했지만 문든 이것이 나에게 부메랑으로 돌아왔구나라는 생각을 지울수가 없습니다. 엉망인 프로세스에 의해 서버와 클라이언트 다 수정해야 할 사항이 될듯한 어두운 그림자가 저를 뒤엎고 있습니다.
그간 몰랐는데 요즘 이것저것 생각하면서 정리를 하다보니 안보이던게 보입니다.
단적으로 잠깐 설명을 하겠습니다.
기능은 서버에서 특정 설정값들을 받아 오는 단순한 DLL입니다.(처음엔 단순했습니다.)
처음 구조체는 설정된 값을 주고 받는 다음과 같이 정의 했습니다.
typedef struct test {
int test;
.
.
} TEST_ST;
물론 확장성을 고려해 리저브 영역을 두었습니다. 그러다가 이게 어느듯 계속적인 확장으로 인하여 리저브 영역이 줄고 또한 독립적인 설정값이 나와 다른 Structure들을 정의 하였습니다.
1. 일차적으로 리저브 영역을 너무 믿었던 것이 잘못입니다.
그리고 다른 structure를 받는 부분이 추가 됩니다.(패킷이 하나 더 늘어납니다.)
이렇게 몇개가 더 추가가 되었습니다. 이제는 패킷이 많아졌습니다. 여기서 또하나 잘못이 있습니다.
결국 이렇게 코드가 되어 버렸습니다.(아 쪽팔려 죽겠습니다. 이 자체를 포스팅 한다는 것이 ㅠ.ㅜ)
서버 접속
if(첫번째 설정 바꼈나? == yes)
설정 받자.
서버 끊자.
서버 접속
if(두번째 설정 있나? == yes)
설정 받자.
서버 끊자.
....
....
(이따위 코드가 어디있냐구요... 하나정도 추가는 괜찬다는 귀차니즘에 의해 계속적인 추가로 이따위 코드가..)
2. 설정값을 받고 보내는 부분을 너무 확장성 없게 만들어 패킷이 늘어남과 동시에 커넥션도 늘어납니다.
다양한 요구 조건을 충분히 인지 하지 않고 즉흥적인 설계로(물론 다 알수 없지만..) 결국 지금 더욱 머리 아픈 그리고 퍼퍼먼스의 하락이 저에게 부메랑 처럼 오고 있습니다.
기분 같아선 다 갈아 없고 싶지만 또 그렇다면 제품의 안정성을 점검해야 하는 난제에 부디칩니다.
요즘들어 느끼는 문서화에 대한 생각과 체계적인 프로세스 정의라는 기본적인 간과한 것이 드디어 현실적인 문제로 대두 될 위기입니다.
오늘 정말 내가 만든 코드(물론 몇년전에 만들어진거지만) 다시 보니 정말 얼굴을 못들 정도이네요. 밑에 직원들에게 조차 부끄럽습니다. 정리가 다 되는대로 프렉스블하게 코드와 함께 프로세스를 재정의 해보아야겠습니다.
개발 10년이 다되가는 현재 이런 코드 보고 있노라니 헛 개발한것 갔습니다.
대략 어떻게 수정해야 할지 가이드는 나와있지만 체계적으로 문서화 작업 및 검정을 거쳐 확장성이 충분히 확보되도록 검토 해야 되리라 봅니다.
안내 1 : IT 관련 개인메타블로그 개설 하였습니다. 많은 동참 바랍니다.
안내 2 :
안내 3 :
문득 수정 하려니 내가 왜이렇게 코드를 만들었지 하는 의문이 들었습니다.
처음 혼자 작업하다 보니 머릿속에 있는것 코드로 바로 집어 넣고 체계적인 프로세스를 확립 하지 않은 상태에서 기능에 주안점을 두다 보니 그렇다고 변명은 한다지만.....
요즘 수정 작업하다 보면 이런부분이 간간히 보여 수정을 하지만 오늘 수정해야 할 부분은 정말 손을 못델정도로 ㅠ.ㅜ 추후 시간날때 하자고 다짐은 했지만 문든 이것이 나에게 부메랑으로 돌아왔구나라는 생각을 지울수가 없습니다. 엉망인 프로세스에 의해 서버와 클라이언트 다 수정해야 할 사항이 될듯한 어두운 그림자가 저를 뒤엎고 있습니다.
그간 몰랐는데 요즘 이것저것 생각하면서 정리를 하다보니 안보이던게 보입니다.
단적으로 잠깐 설명을 하겠습니다.
기능은 서버에서 특정 설정값들을 받아 오는 단순한 DLL입니다.(처음엔 단순했습니다.)
처음 구조체는 설정된 값을 주고 받는 다음과 같이 정의 했습니다.
typedef struct test {
int test;
.
.
} TEST_ST;
물론 확장성을 고려해 리저브 영역을 두었습니다. 그러다가 이게 어느듯 계속적인 확장으로 인하여 리저브 영역이 줄고 또한 독립적인 설정값이 나와 다른 Structure들을 정의 하였습니다.
1. 일차적으로 리저브 영역을 너무 믿었던 것이 잘못입니다.
그리고 다른 structure를 받는 부분이 추가 됩니다.(패킷이 하나 더 늘어납니다.)
이렇게 몇개가 더 추가가 되었습니다. 이제는 패킷이 많아졌습니다. 여기서 또하나 잘못이 있습니다.
결국 이렇게 코드가 되어 버렸습니다.(아 쪽팔려 죽겠습니다. 이 자체를 포스팅 한다는 것이 ㅠ.ㅜ)
서버 접속
if(첫번째 설정 바꼈나? == yes)
설정 받자.
서버 끊자.
서버 접속
if(두번째 설정 있나? == yes)
설정 받자.
서버 끊자.
....
....
(이따위 코드가 어디있냐구요... 하나정도 추가는 괜찬다는 귀차니즘에 의해 계속적인 추가로 이따위 코드가..)
2. 설정값을 받고 보내는 부분을 너무 확장성 없게 만들어 패킷이 늘어남과 동시에 커넥션도 늘어납니다.
다양한 요구 조건을 충분히 인지 하지 않고 즉흥적인 설계로(물론 다 알수 없지만..) 결국 지금 더욱 머리 아픈 그리고 퍼퍼먼스의 하락이 저에게 부메랑 처럼 오고 있습니다.
기분 같아선 다 갈아 없고 싶지만 또 그렇다면 제품의 안정성을 점검해야 하는 난제에 부디칩니다.
요즘들어 느끼는 문서화에 대한 생각과 체계적인 프로세스 정의라는 기본적인 간과한 것이 드디어 현실적인 문제로 대두 될 위기입니다.
오늘 정말 내가 만든 코드(물론 몇년전에 만들어진거지만) 다시 보니 정말 얼굴을 못들 정도이네요. 밑에 직원들에게 조차 부끄럽습니다. 정리가 다 되는대로 프렉스블하게 코드와 함께 프로세스를 재정의 해보아야겠습니다.
개발 10년이 다되가는 현재 이런 코드 보고 있노라니 헛 개발한것 갔습니다.
대략 어떻게 수정해야 할지 가이드는 나와있지만 체계적으로 문서화 작업 및 검정을 거쳐 확장성이 충분히 확보되도록 검토 해야 되리라 봅니다.
아직 많은 개발을 하지 않은 개발자분들에게...
안내 1 : IT 관련 개인메타블로그 개설 하였습니다. 많은 동참 바랍니다.
안내 2 :
안내 3 :
이올린에 북마크하기
이올린에 추천하기



