본문

1월 21일 개발 빵구 ㅜㅜ

원인

처음으로 전사규모 앱을 개발하게 되었다.


경과

is not / != 를 헷갈려 사용

Test 안하고 submit


결과

반성문 ㅜㅜ



내 인생 처음으로, 여러명이 사용중인 sytstem에 신규 기능을 추가해봤다.


그리고 그 결과는 빵구.


약 두시간동안 정상적인 진행이 안되서, 결국 전무님한테 혼났다.


임시 TF를 맡은 분은 반성문-시말서-를 제출해야 됐었다.ㅜㅜ


사실, 조금만 생각해보면 다 내 잘못이다.


그 긴 시간동안 언어를 봤으면서 is not / != 도 제대로 모르고 사용을 해서 문제를 일으킨게 제일 크다.

그거만 아니었으면 submit 이후 긴급 fix 등으로 사용자 제한을 얼마든지 할 수 있었는데,


애초에 근본적인 문제가 있었던 거다.




차후에 new request / submit 부분을 리팩토링 했는데,


이렇게 에러가 많은 코드를 내가 짠 건가... 하는 무서운 생각이 들었다.


그야말로, 돌아만 가게 만든 산소호흡기 코드였다.


몇몇 if문에 대한 예외처리조차 제대로 되어있지 않아서, 예외상황을 넣을 때마다 에러가 리턴됐다. OMG...


그 많은(사실 결코 많은 양은 아닌) 개발관련 서적에서 이런 일을 본 적이 없었던 것 같다.


왜냐면, 너무 기본적인 일이니까.


개발 절차에 있어서 테스트는 개발 이후 당연히 하는 것이고, 


모든 if에 대한 else는 대학교 1학년때면 배우는게 아니었던가.


내가 만든 코드는 놀랍게도 else 처리조차 안되고 있었던 것이고,


결국 1주 새 벌써 세번이나 방어코드 추가가 필요했고, 오늘도 두개나 더 방어코드의 삽입이 필요했다.




한편, 처음으로 내가 만든 코드에 대한 쾌감이라는 것을 느낀 몇 안되는 일 중 하나가 되었다.


처음으로 엄청 기뻤던 건, 아마 c++ 리스트를 혼자서 만들었을 때였던가...


이후 부침을 거듭하다가 이번에 처음 뭔가를 만든 건데,


그중 권한관리 부분을 담당자에게 이양하는 시스템, 그리고 history를 만들고 매일같이 들어가서 보고 있으니


이게 내가 만든 툴에 대한 자부심이라는걸 알게 되었다.


볼때마다


"세상에 이걸 내가 만들어서 난 얼마나 편해졌는가."


를 알게 되는 것이다.




다른 코드를 손대게 되더라도


항상 history viewer같은, 내가 만족할 수 있는 코드를 작성해야 한다는 걸


이제는 확실히 알게 되었다.




그리고 가장 중요한 것,


모든 소스코드에는 방어와 테스트를 함께하자!


공유

댓글