회사 개발코드 보면,,,정말 현타와서 힘드네요

BEST경력이 주니어이신지 시니어이신지는 모르겠지만.. 개인적인 의견으로는 개발할 당시에 히스토리를 모르신다면 이걸 왜 이렇게 짜셨어요 라고 물어보시는건 좀 예의에 어긋난다고 생각합니다. 그때 당시 개발할때 상황이 어땟는줄 알고..특히나 중소기업이라면 그때 당시에 급박하게 제품을 출시했어야 해서 확장성을 고려 못하고 개발했다가 리팩토링을 여태 못하고 그대로 고착됐을수도 있구요.. 사소한 리팩토링 이라면 모를까 말씀 하신것처럼 대규모 리팩토링을 정 하고싶 다면 정식으로 회의 잡고 이걸 이렇게 바꾸면 이런면에서 더 좋을거 같은데 어떨거 같으세요라던가 아예 AS IS와 TO BE 방향성의 차이점을 팩트에 기반해서 문서화 한다던가해서 본인이 동료 및 팀장을 설득을 시켜야 한다고 생각해요 근데 설득을 못 시키시면 당연히 고인물 입장에선 근래 이직해와서 맡은 솔루션에 대한 이해도 깊지 않은분이 잘돌아가고 있는 시스템을 위험성을 감수하고 굳이 뜯어고친다는 이유가?라는 말을 무조건 하게되죠..대학교에서 하던 팀 프로젝트가 아니잖아요. 회사 입장에서는 몇천, 몇억의 돈이 오가는 하나의 사업 아이템인데요..이것에 대해 전공 비전공 따질 이유는 전혀 없어요 또 하나..반대로 본인의 신념대로 갈아엎은 코드는 남들이 봤을때 무조건 정답일까요? 본인이 은근히 평가절하 하는 그 고인물들은 정작 작성자께서 입사 후 보여준 퍼포먼스가 별로 없거나 실력이 딱히 나보다 나을건 없어보인다라고 생각들어 믿음직스럽지 않아서 그렇게 말한것일수도 있어요.. 제가 이렇게 좀 쎄게 말씀 드리는 이유는.. 현재 관리자 입장에서 간혹 주니어 전공자분들중에 이러한 근자감(혹은 건방짐)을 가지고 나름 잘짜놓은 시니어 개발자 코드도 별거 아니라고 까는 분들 있었는데 어디 한번 보자해서 막상 시켜보면 약속했던 개발 기한도 제대로 못지키고 유닛테스트라는 개념도 없어서 여기저기 에러 지뢰밭을 만들어 놓는 경우가 있었거든요..아주 스트레스 받았던 경험이 있습니다..본인이 그런경우가 아니라면 죄송합니다(수정됨)