코딩 스타일이 copy & paste 로 골격을 늘려가는 스타일에,

네이밍 별로 신경 안쓰고 온통 재사용성 높은 반복 산술식으로 도배하는 경우 ( 이를테면 UI lowlevel 함수들 )

하루에 수천라인 짜는건 일도 아님.


90년대엔 나도 하루 수천 수만라인도 짜댔었고.

( 대신 재사용성 고려 안한 덕에 시스템 좀만 바뀌면 또 짰지. 네이밍이고 나발이고 신경을 안쓰니 광속 )

내일 다시 작성하게 될 코드는 어제의 것보다 나을거라는게 거의 확정적이었기 때문에,

필요하면 다시 만드는게 옳고

재사용성 따위는 다시짤 수 없는 애들이나 고민하는거라고 생각했었다.

그래도 최적화는 잘되어 있었고, 무결성도 완벽했다.

( 일관성은 갖고, 코드량을 희생하더라도 속도는 보장하며 작성해갔단 말 )


2000년대에 들어서 업무가 시스템 안정성 위주로 바뀌게 되면서 스타일이 점점 바뀌어갔지.

2005~6년 경에 내가 받아든 선행자들의 소스코드는 8만라인이 넘는 쓰레기더미였고,

그걸 2주만에 모조리 다시 짜면서 내가 만들어낸 코드는 2만 4천라인 정도였다.

그때까지는 업무를 나 혼자 했기 때문에 코드에 강한 약속들을 만들어 넣을 필요가 없었음.


그 후 팀플을 하게되면서 내가 만들어놓은 골격을 이해하지 못하고

망가뜨려가고, 만들어 놓은걸 안쓰고 어수룩한걸 다시 만들어 대는 멤버들 때문에 온갖 장치들을 하게 되고

단어 하나, 코딩스타일 하나 하나 훨씬 더 많은 제약들 가운데서 작성을하니 예전같은 속도는 내기 힘들지.

그리고 베이스를 만드는건 금방인데,

주로 오래하게 되는 작업들은 이미지 처리 관련한 노이즈 제거나 밴드패스 필터들 엣지 강화 같은

알고리즘적인 부분이라서 또 작업 속도가 안남. ( 거의다 물리, 수학적 해석 문제들 )


정리하면, 라인수는 땔감이냐 아니냐를 결정하는데 중요한 factor 가 아니란 것.