Development Experience/Philosophy (3) 썸네일형 리스트형 프로그램 구현할 때 깨달은 점 프로그램을 만들 때 상식적으로 있어야 할 기능들은 문제가 되지 않는 선에서 미리미리 구현해두자. 교통량 측정 프로그램에서 회전 교통량을 좌회전, 우회전, 유턴 교통량으로 각각 나누지 않고 저장하는 프로그램을 몇달전 인수인계 받았다. 그 당시 구분해서 저장하는 게 낫지 않나 싶어서 이슈를 제기했었지만 당장 급한 일들이 많았던 시기라 해당 이슈는 진행하지 않는 걸로 얘기가 됐었다. (여기서 한가지 실수한 게 구두로만 간단히 얘기하고 text로 남기지 않은 게 좀 아쉬웠다. 당시에는 그냥 내 머리속에서 나온 안건이라 사업적인 우선순위에서 이 안건이 후순위임을 인지하는 정도에서 멈췄었는데, 이를 text로 남기지 않았다 보니 삼자간의 의사소통이 원활하지 않았다.) 그 이후에 어느 정도 여유가 생겼을 땐 이 이슈.. 서버 프로그래밍 시 유의 사항 끄적임 서버 프로그래밍을 할 때에는 업데이트의 유연성을 확보하는 게 좋다. 예를 들어 어딘가로 전송해야 할 메시지를 별도의 파일로 빼놓고 이 파일을 서버 프로그램이 읽는다든가, 여러가지 서버 옵션을 켜고 쓸 수 있도록 별도의 버튼, 커맨드, 백도어등을 만들어 둔다든가 해서 이미 구동중인 서버를 끄지 않으면서 서버의 동작을 변경할 수 있는 경로를 되도록 많이 만들어두는게 정신건강에 좋을 듯 하다. DLL 모듈화 이전 Winform 프로젝트에서 C++로 구현된 기능을 사용해야 할 일이 있었다. 당시의 사용방법은 C++ 로 만들어진 dll을 C#으로 감싼 후, 이 wrapper 를 통해 필요한 기능을 수행하는 것이었다. 그럭저럭 프로젝트가 마무리되었고, 한동안 해당 코드를 건드릴 일이 없었다. 최근 WPF로 새로운 프로젝트를 시작하면서 예전에 만들어두었던 Wrapper 를 사용해야 할 일이 생겼다. 그냥 가져다 쓰면 되겠거니 했는데... 예전의 그 Wrapper는 Winform 프로젝트에 너무 종속되어 있었다. Winform과 WPF의 차이라기 보다는, namespace가 예전 프로젝트와 너무 얽혀있는 게 문제였다. 애초에 Dll Wrapper를 만들 때 특정 프로젝트 내에서 만들지 말고 따로 빼내어서 구현했더라면.. 이전 1 다음