개발은 많이 보고 많이 짤 수록 좋다.

유지보수도 중요하긴 한데, 개발은 '많이 보고, 많이 짤 수록' 실력이 상승한다. 

그래서 유지보수만 하는 건 실력 향상에 도움이 크게 되지 않는다. 

유지보수는 해야 할 경우에는 하지만 굳이 선호하지 않는다. 

왜냐하면, 대부분 난이도는 높지만 실력 상승에는 도움이 많이 되지 않기 때문이다. 

그리고 지금에야 이르러서 생각하기를 유지보수는 결국 문제 해결의 방법이기 때문에

신규 개발을 하면서도 디버깅을 연구하고 여러 문제해결 방법을 도모하기 때문에

 

유지보수를 하려면 양을 많이 하기보다는 '최악 수준의' 유지보수를 담당해서

그 퀄리티를 극한으로 올리는 게 좋다. 

나 또한, 대부분 유지보수를 할 때에 제일 '거지같은' 이슈를 고른다. 

그래야 그나마 '실력 향상'에 도움이 되기 때문이다. 

 

예를 들면, 한 5년 간 아무도 손 안대고 해결 못해서 매우 더럽고 복잡한 스파게티 소스를

리팩토링 한다든가. 기술적으로 난이도가 높아서 고치지 못하거나, 

누구나 문제를 알고 있지만 기간 내에 해내지 못할까봐 엄두를 못내는 것을 맡는다. 

 

좋은 점은 아무도 손대고 싶어하지 않기 때문에 나 혼자 연구하고 나 혼자 주도할 수 있다. 

그렇기 때문에 유지보수를 양으로 하는 건 진짜 안좋아하고, 하려면 가장 거지같고 더러운걸 

골라서 한다. 그것은 '반드시' 실력 상승이 된다. 

왜냐고? 더럽게 복잡하고 어렵기 때문에 리팩토링 및 디자인 패턴, 그리고 코드를 보는 눈, 

이슈에서 문제를 찾는 눈, 직관력, 그냥 거지같은 상황을 이겨내는 극강의 인내심이 생기기 때문이다. 

그러나 굳이 '찾아서'는 하지 마라. 온갖 거지같은 이슈를 당신이 다 맡게 된다. 

굳이 선택하라면 쉬운 여러 5개의 유지보수보다 어려운 1개의 유지보수를 맡겠다고 선택하라는 것이다. 

 

그럼에도 불구하고, 내가 추천하는 것은, 

주로 많은 코드를 보고 많은 코드를 짜고, 

남이 짠 코드를 고치고, 깃허브에서도 찾아보고,

책에서도 많이 보고 쳐보고, 고쳐보고, 자신의 코드로 만들어보고, 

뜯고 씹고 맛보고 즐기고

 

보고 치고 보고 치고 보고 치고 보고 치고

이래야 실력이 빠르게 많이 는다. 

 

자신이 코드를 짜면서 습득했던 이전의 지식들이 통합되어 코드로 발현되는 것을

깨닫게 되면 꾸준히 학습을 하게 되고 꾸준히 남의 코드를 보게 되고 

꾸준히 노력을 하게 된다. 

 

즉, 개발자가 공부를 하고 학습을 하고 꾸준히 코딩을 하는  건

어쩌면 당연한 과정이고, 더 높은 개발자가 되기 위해서는 

당연히 그렇게 수순을 밟게 되어 있다. 

 

그러니, 많이 보고 많이 짜고 많이 리뷰받고

그렇게 하다보면

 

초고수가 될 것이다. 

 

나는 어떠한 거지같은 이슈도 해결할 수 있지만 

나 또한 신규 개발을 하고 연구를 하고 아키텍팅을 하고 싶다. 

그게 사람이니까 .