하나 고쳤는데 다른문제 '하나만' 터져도 다행이죠

심지어 고쳐달라고 했던것도 안 고쳐져있습니다.

자잘한 버그 패치판 배포 후에 대형사고가 터지죠.

막짤에 무념무상으로 큰 파이프 때리는거 댕 공감이네요 ㅋㅋㅋ

계획없이 만든 복잡한 코드를 보고 있으면 멀티버스에 있는거 같은 느낌이 들어요. 조금만 손대도 나비효과처럼 영향은 막대해지죠. 생각만해도 으으.. 끔찍하네요. 고쳐놓고 밤에 잠 못잠

정상적으로 녿담이 아닌 이야기를 하면 버그가 안나는 것은 버그가 없는게 아니라 숨겨진거죠.
가장 흔한 일이 A라는 버그로 인해서, 그 처리상 다음 단계라 할 수 있는 영역인 B/C/D에는 버그가 있지만 거칠 일이 없거나 제대로 안거치기 때문에 문제가 없는거고, 그 다음인 E/F/G/H.......도 마찬가지고......
근데 기능이 정상 작동하고 있다면?......... 아..음.....

변명을 해보자면.. 다는 아니겠지만 숙련 기술자 한명에 초급 여러명 붙여서 단가 맞추려고 프로젝트 하는 경우가 많은데 그런 경우에 관리 문제로 그런 경우 많구요
또 다른 케이스로 설계를 전체적으로 해야 하는데 개발 일정땜에 또는 요구 사항이 명확하지가 않아서 우선 개발을 진행하다보니 난리가 나는 경우죠
그 외에도 유지보수 과정에서 매뉴얼화가 제대로 안되서 파악이 불가능하거나 매뉴얼을 안 보는 경우가 있구요
협업 과정에서 피엠이나 피엘이 그걸 잡아줘야 하는데 일정이 촉박하거나 요구사항 변동이 심하고 하면 다들 멘붕 와서 일단 되게 하는 경우가 허다하죠
거기에 기획 할때 제대로 요구사항 도출해야 하는데 추진하는 높으신 분 입맛에 맞게 하느라 말도 안되게 기획 설계 하고 진행하고 보니 엉망이라 나중에 부랴부랴 스파게티성으로 난잡해지는 경우도 있죠
기획 단계에서 제대로 도출 안된 요구 사항이 베타때 써보니 오.. 이것도 이렇게 하거 저렇게 하면 좋겠다 하고 막 수정 사항 나오는 경우도 많구요
그럴거면 POC는 왜 한건지..
아무튼 전체적인 모습을 확인이 가능해야 하고 컨트롤 할 수 있어야 하고 변동 사항 발생하면 시간이 주어져야 하구요 뭐 그런데.. 제대로 되는 경우가 거의 없죠

사용자분이 하나 추가요청했는데 ..
테스트는 기존 사항 다 해야 하는 경우도
생각보다 빈번해서... 놓치고 안하면
오류가 됩니다 ㅠㅠㅠ

사실 테스트코드를 제대로 안만들어서 생기는 이유가 가장크죠
단위 테스트코드를 촘촘히 만들면 a기능을 수정했는데.. 뜬금없이 d기능의 테스트 코드에서 깨지는 경우가 있습니다

a기능이 사실 내부적으로는 d의 기능과도 연관이 있었던 거죠