일하면서 다시 생각해보니까 61.76 말이 맞는 것 같다.
어찌 되었건 여러 시스템의 허브로 돌아가는 웹과 그 서버가 죽으면 더 크고 더 광범위한 문제를 일으킬 것 이고
여기에 연동되어서 돌아가던 물건이나 시스템들이 무엇이느냐에 따라서 그 오류의 파급력이 가공할 수준으로 거대해질 수 있을것 같다.
너 말 듣고 다시 생각해보니 그렇다.
그러니 웹도 대충 만들어서 나중에 다시 해준다고 유야무야 처리하는 일도 있는 반면
데이터 하나하나 잘못들어간게 나비 효과로 크리티컬 이슈를 일으키는 웹도 있을 것 이라는 것 충분히 이해했다.
오히려 내가 웹이라는 분야를 너무 좁고 국소적으로 생각했던것 같다.
잘 모르면서 아는척 해서 미안하다.
그런데 나는 다중이짓 같은 졸렬한 짓은 안한다.
나는 그런 인간은 아니다.
그것만은 알아달라.
앞전 글은 그냥 같이 개발하던 시스템에서 관제 웹 만드는 개발자가 자꾸만 기능 빼먹고, 오류 정정 요청 후 개선 되었다는 리포트 받았을때
막상 시스템 접속해보면 세션 여기저기 꼬여서 로그인 유지도 안되고, 고객은 현장 왔다 갔다 하며 안면텄다고 시스템 문제 생길때마다. 개발자는 같은 개발자 아니냐며 나에게만 계속 민원 접수 해대니 거기에 빡쳐가지고 그런 글을 썼다.
다시 생각해보니 그따위로 일하는 조직에서 일하는 나도 수준이 낮은것을 자각해야 할 것 같다.
빡치게 해서 미안하다.
글삭은 내가 일부러 졸렬짓 안하려고 비밀번호 랜덤 입력하는지라 못한다.
그냥 박제하고 조리돌림해라. 그게 다 내 업보지뭐.. 미안하다.
업보지?? 보지??
유닛테스트나 TDD같은 방법론들이 어찌보면 그러한 실수를 변태적일정도로 집요하게 사전예방하자는건데, 그러한 방법론들이 웹개발에서 많이 쓰이는덴 이유가 있음 ㅇㅇ
먼일인진 모르지만 삼촌의 자세는 훌륭한 것입니다. - dc App
개추