레거시 리팩토링을 나는 종종 하는 편임.

왜냐면 이전 개발자가 좆같이 짠걸 수정하거나, 일정이 급해서 내 코딩중 해당 규모의 구조로 정리한걸

나중에 내가 다시 기능 추가 보완을 하는 경우가 많음.

내가 한건 아무런 문제가 안됨.

나는 코딩을 깨끗하게 짜는 편이라 내 눈에는

다른 개발자가 싸놓은 똥은 그냥 좆같은 경우가 많음

거기에 내가 기능추가를 해야 할 경우, 적당한 프로그래밍을 할수밖에 없음.

마음 같아서는 다 코치고 싶은데, 하도 많이 해서 귀찮다.

그러면 적당한 프로그래밍 이란 뭐냐?

해당 특정 기능의 내부구조만 정리하는 행위임.

상위 구조와의 인터페이스 문제는 해결하지 않음.

해당 기능에서 사람이 직관적으로 이해가능한 코드로 수정하는 것을 목표로함.

구조 변경이 목표가 아니기에 주로 함수화, 함수 재정의를 통해서 문맥의 흐름을 드러내도록 코딩함.

이정도 정리하면 다음사람이 들어와서 기능을 파악하기도 쉽고, 내가 기능추가나 수정을 하기도 쉬워짐.

그러니까 다시 말하면

적당한 코드는 해당 기능이 구조적으로 안정되고 이해되는 코드로 개선이 되면 거기서 수정을 멈춤.

이정도가 적당한 코딩으로 보임.

나는 고등학교때 부터 어떻게 하면 구조적으로 깨끗하게 만들수 있을까?

를 고민하고 지향해 온 사람임. (25년전)

객체지향과 개발방법론 등을 배우면서 대학생때 많은 것들을 알게 되었는데, 공부에는 끝이 없고

공부에 메이는건 비 실용적이라는 것을 오랜 방황과 경험 끝에 체득함.

초보 애들은 기능을 구현하기 위해 기계스러운 c 스타일로 코딩을 많이 함.

그래서 세부구현이 문맥해석을 방해하게 만듬.

함수를 써서 상세구현이 드러나게 막으면서 문맥은 드러나도록 짜야 하는데

필드에서 이것도 안되는 부장, 차장, 과장, 대리, 신입들 수두룩 하다.

그래서 이정도만 했으면 바랄것도 없다.

결국 정당한 코드란 뭐냐면 독립적 기능의 적당한 완결임.

독립적 기능이 적당하게 완결을 시킬줄 알면 상위 구조를 개선시키기 위한 리팩토링을 시도할수 있음.

결국 아키텍쳐에 대한 고민을 하게 되는 것이지.

이게 안되면 프로그래머라고 할수가 없고, 오랜 경험을 봤을때 코딩의 실력향상은 더이상 없다.

그런 사람은 복잡한 기능 조합의 강력한 기능을 수행하는 프로그래밍을 짤수가 없음.

그리고 적당한 프로그래밍이 안되면, 공부 중독에 메이게 됨.

oop원칙, 객체지향등은 프로그래밍의 내공임.

내공이 깊을수록 고수가 될수 있으나, 내가 고수가 할수 있는 일은 생각보다 사회에 많이 없음.

그보다는 다양한 기능을 만들수 있는 외공 고수가 가치가 큼.

물론 외공고수가 내공이 안되면 절정고수에 도달할수가 없는 것은 필연임.

둘다 필요하되, 내공의 이해는 적절한 수준을 목표로 하는것이 좋음.

그 이상은 현실적으로 낭비적인 요소가 크다.