음 테스트 삼아서 해보았는데 페북에 잘올라가는군요 ㅎㅎ

결국 냄새에 대한 리팩토링 을 각자 알아서 그때 그때 하시는지 "자 매주 금요일은 리펙토링 하는 날이야" 하면서 기간을 정해서 하는건지요??

@양완수 오호. 페북 테스트까지 해주고 고맙네. 내 계정으로는 정상 동작해서 그 동안 버그가 있는 줄도 몰랐네. 오늘 이 버그 잡느라 시간 소비하는 바람에 야근하고 있다.

기본적으로 코드를 clean한 초기 생성을 유지하도록 개발자들은 지속적인 노력을 해야하며 코드리뷰를 통해 코드의 평준화를 통해 후불로 지불되는 리팩토링을 감소시켜야 한다고 생각합니다.

리팩토링은 날을 잡아서 하는 것이라는 생각보다는 늘 하는 것이고 업무에 녹여 낼 수 있는 활동을 지속적으로 문화로 만들어야 한다고 생각합니다.~

참고로 문화로 정착하는 일은 시간이 필요하고 이는 역사로 남게 된다고 생각합니다.

@newoverguy 저도 의견에 공감합니다. 아마도 많은 개발자가 이 의견에 공감하고 있을 겁니다. 하지만 현실은 쉽지 않잖아요? 왜 그럴까요? 이를 실천하는 어려움은 유독 우리나라만의 문제는 아니라고 생각합니다. clean code에도 비슷한 내용이 나오는 것을 보면 외국에도 이 같은 문화를 만드는 것이 쉽지 않다는 것을 느낍니다.

그렇다면 이런 문화는 어떻게 만들 수 있을까요? 어떻게 군대에서는 가능할까요? 군대에서는 매일 하던 일들이 제대하고 나면 쉽게 무너지잖아요. 그 만큼 습관을 만드는 것은 어려운데 깨지는 것은 한순간이라는 생각이 듭니다. 그렇다면 군대에서는 어떻게 그런 습관이 잘 유지될 수 있을까요? 강제하기 때문일까요? 강제하는 것이 방법이라면 일반 회사에서도 강제하면 쉽게 해결할 수 있는 방법 아닌가요? 아니 많은 회사들이 프로세스라는 이름하에 강제하고 있지 않나요? 문화도 군대와 비슷한 곳도 많고요. 하지만 제대로 유지되는 곳은 많지 않잖아요. 강제하는 것이 성공하는 것은 아니라고 생각합니다.

저는 다른 관점에서 봤을 때 그 조직에 참여하는 사람들의 끊임없는 견제가 한 몫 한다고 생각합니다. 주변에 같이 일하는 개발자들이 자기들이 만드는 코드에 대해 자존심을 가지고 품질 관리를 하고 리팩토링하는 문화라면 그런 생각을 가지지 않은 개발자도 자연스럽게 따라갈 수 밖에 없다고 생각합니다. 하지만 이 같은 문화를 만드는데 많은 시간과 노력이 필요한데 국내 기업들은 이 같은 시간을 기다려주지 않네요. 물론 해외도 비슷할 겁니다. 어차피 프로그래밍을 해보지 않은 사람들은 소프트웨어 개발의 복잡도를 이해할 수 없습니다. 복잡도를 이해하는 사람들은 우리들 밖에 없는 거죠. 우리가 전문가로서의 자존심을 가지고 대응할 수 밖에 없다고 생각합니다. 계속해서 설득하고, 힘들지만 개선의 노력을 지속하는 마음 가짐을 가져야 한다고 봅니다. 왜냐고요? 우리가 프로그래밍에 있어서는 전문가이니까요.

우리가 전문가로서 목소리를 자존심을 가지려면 전문가가 되도록 끊임없이 노력하고 공부할 수 밖에 없다고 생각합니다. 우리가 끊임없이 노력하는데 외부 환경이 그렇지 못하다면 어쩔 수 없다고 봅니다. 내 자신에게 부끄럽지 않으면 되는 거잖아요. 내가 부끄럽지 않게 행동하려면 자신에게 집중하고 자신의 역량을 키워야 한다고 봅니다.

TPS의 T가 Toyota아니였던가요?

군대에서 가능한건 위로 갈수록 그런 생각을 가지고 있다는 것입니다. 개발에서도 지속적으로 개선하려면 먼저 조직장의 생각이 있어야 하구요.. 조직장은 적어도 랩장(실장) -> 팀장 순서겠죠. 그리고 나서 팀내에서는 딱히 직급이 없더라고 DL을 포함한 과장급 이상의 리더가 행동을 보여야 합니다. 하지만 현재 있는 곳에는 조직장부터 생각이 없어 보이구요.. 운영조직으로 들어가면서 더 힘들어지기도 했죠.. 저 또한 그런 비난에서 자유롭지는 못한거 같습니다.

다른 사람을 이끄는 리더부터 생각이 변해야 한다고 생각합니다만 현실이 그렇지 않아 굉장히 안타깝습니다. 이번에 옮기는 팀에서는 좀더 노력해보려구요. 잘될지는 모르겠지만..

얼마전 권남씨와 커피 마시면서 했던 얘기가 생각나네요.

"지속적으로 프로그램을 개선하려는 노력을 해야한다"

그것을 습관처럼 지속한다면 자신의 성장 뿐만 아니라, 자신이 맡고 있는 서비스의 품질도 한껏 올라가겠죠.

재성이형 댓글중에 "전문가로서의 자존심" 저도 잊지 않으려 노력하겠습니다 ㅎ

"나중은 결코 오지 않는다." - 르블랑의 법칙

"정리되지 않은 서랍에서 물건 찾기"

이제 남는 문제는 "어떻게 같이 지속적으로 할까?" 어떻게 접근해야 개발자의 존심? 을 건드리지 않고 클린한 상태를 유지 할 수 있을까요??

괜시리 리펙토링하고 눈치 보게되네요 ㅎㅎ

적절한 비유..감동적이기까지하네요

@양완수 Refactoring to patterns에서는 bad smells를 설계 부채로 비유를 하며 부채가 커지면 점점 이자비용이 비싸진다는 이야기를 합니다. 저는 이 비유가 더 맞다고 생각합니다. 우리가 전기를 쓰자마자 돈을 지불하지 않듯이(즉시 비용지불이 없으니 부채), 다른 개발자가 이해할 수 있을 것 같으면 리팩토링을 안하기도 합니다. 부채를 충분히 감수할 자신이 있는거죠.

그 보다 저에게 더 큰 문제는 경력이 부족했을 때 언제까지 리팩토링해야할지 감을 잡을 수 없었습니다. 나쁜 코드의 기준을 이해하지 못했고, 당연히 좋은 코드의 기준도 부족했습니다. 그래서 마음에 드는 코드가 나올 때까지 리팩토링을 했고 그 결과 끝없는 야근으로 이어졌죠. 리팩토링 작업이 눈치보이시나요? 적당한 시간을 리팩토링에 할당하세요. 30분 코딩 15분 리팩토링 이런식으로요. 남을 생각하면 나는 어디로 가야하나요? 나의 기준을 만들어보시는게 어떠실지 ...

끝으로 생각해보시면 도움이 될 것 같은 질문입니다. 나쁜 코드의 기준은 뭔가요? 저는 모호하다고 생각합니다.

@benghun @양완수 리팩토링을 어느 수준까지 할 것인지를 판단하는 것은 참 힘든 일이라는 생각이 듭니다. 이에 대한 감을 얻는 것은 끊임 없이 고민하고 경험을 쌓는 길 밖에 없지 않을까라는 생각을 해봅니다. 소프트웨어를 공학에 비유하기도 하고 예술에 비유하기도 하는데요. 저는 리팩토링에 대한 감을 얻는 것은 예술과 비슷한 측면이 있지 않나라는 생각이 듭니다. 정량적으로 판단할 수 없고, 정성적인 부분이 더 많다는 생각이 듭니다. 항상 옳은 정답은 없고 그때 그때의 상황에 따라 판단해야 한다고 생각합니다. 이는 다분히 정성적인 감(sense)이 있어야 된다고 생각합니다.

위에 완수가 공유한 그림처럼 이런 sense는 쉽게 얻어지는 것이 아니고 관련 소스 코드에 대한 이해가 낮은 관리자가 조언하기에는 힘든 일이겠죠. 물론 관리자는 새로운 영감을 주기위해 가볍게 조언을 줄 수는 있지만 그 조언에 따라 리팩토링을 할 것인지 말 것인지는 전문가인 우리 프로그래머가 담당해야 하는 영역이 아닌가 생각합니다. 최종 판단은 우리들이 결정하는 것이 맞겠죠. 그리고 그런 습관은 누군가에 의해서 하는 것이 아니라 우리 자신들이 평소에 끊임없이 수련하고 연습할 수 밖에 없다고 생각합니다. 이런 연습은 다른 사람의 강요에 의해 할 수 있는 것은 아니잖아요. 물론 조직의 문화가 중요하기도 하지만 개인의 습관도 상당히 중요하다고 생각합니다.

@자바지기 개발자 스스로가 잘나야 한다고 돌직구를 던지시네요 ㅎㅎ

@benghun 감사합니다. 클린한코드는무엇일까?에 대해서 고민해보고 있습니다. 앞서서 클린한코드는 정량적으로 절대적인가에 대해서도요...

비유를 해보자면 잘정돈된방은 어떤것인가? 에 가까운것같습니다.

잘정돈된방의 기준은 기 방의 주인들에게 있겠죠. 방을 같이 공유한다면 여기서 충돌이 발생할것입니다. 어떤사람은 잘 정돈 되었다고 생각하고 어떤사람은 거울의 위치가 저쪽이 좋다고 하고 쓰레기통에 비닐을 사용해야하는지...방은 쓸고 닦아야 하는지 자주 쓸고 2:1의 비율로 닦아야하는지... 속옷전용빨래통에 위치는 다용도실구석이 좋은지..등등.. 헥헥헥 와이프와 다른 환경에 살다 살기 시작하면서 5년 넘게 정리정돈에 대한 견해가 충돌하더군요...

결론적으로 정량적 으로 어떤 절대적 기준을 들이데는것은 무리인것 같습니다.

하지만 청결하고 잘 정돈된 방은 누구나 좋아하고 즐거운 마음을 들게 한다는 것은 모두 공감하는 바이입니다. 클린코드가 필요하다는 점에 공감한다면 절대적 기준으로 클린코드를 바라보는것은 의미가 없다고 생각이 들었습니다.

방법에 차이 주기의 차이 만이 논의에 대상이 되지 않을까요 ???

클린코드에 대한 감은 위에서 @자바지기 님께서 말씀하신데로 꾸준한 습관과 충돌에서 비롯된다고 생각합니다.

아직 이런말할 자격이 주어지는지 모르겠습니다만... (사실 이런 말들은 할 자격이란게 무엇인지 모르겠지만서도...)

두려움으로 인하여 충돌자체를 피하고 유구한 역사와 업적을 답습하는 경우가 만연한것 같습니다...

요지는 클린코드의 중요성을 서로 공유하고 의사가 수술하기전 당연히 손을 씻고 수술을 하듯 클린코드는 특별한 것이 아니라 개발자에게 공기와 같아야 한다는것이죠...

두려움이 그 호흡을 막는다면 그 두려움에 대해한 해결책을 서로 공유하고 해결해야지않을까요???

PS/ 아 그리고 제가 이 글타래를 쓰는 이유는 현실에 대한 불만을 가지는게 아니에요 ㅜㅜ 다들 주변에서 걱정어린 시선으로 보고 계셔서... 글타래를 생성하는 이유는 오랜만에 다시 펼친 책에서 보물같은 경험들이 다시 살아나기에 두근대는 마음을 주체할수 없어 남기는 것입니다. ...

@양완수 두근거리다니 대단하시군요. 말씀하시는 바에 대해서는 저도 대체로 같은 생각을 가지고 있어요. 그리고 클린 코드에 대한 가치기준은 켄트 백의 책들에서 종종 나오죠. 저는 큰 도움을 받았어요.