본문 바로가기
정보/IT

코딩하다 문득 들은 생각

by 키운씨 2019. 11. 9.

프로그램을 설계하면서 클래스, 함수, 변수들을 선언하고 이름들을 명명하고 관계들을 정의하다보면

유독 서로간에 관계를 더더욱 견고하게 하려는 버릇이 생겨버린다

 

이는 되도록 중복 코드를 없애고 간결하게만 만드려는 집착증과 강박증이 발현되는 것인데 

그래서 중복된 기능들을 상속을 통해 부모에게 최대한 올려버리고 자식 클래스에는 최소한의 변수값을 통해서만 동작하게 하려고만 한다

 

그렇게 설계된 프로그램의 문제점은 의존성과 영향도에 있다

하나의 클래스 함수를 조금만 수정해도 그 클래스를 inheritance(상속)하거나 composition(구성)하는 클래스들에게 영향을 주게 되버린다

그리고 그것은 디그라데이션이라는 지저분한 문제를 야기시키기 때문에 

결국 기존의 프로그램을 포기하고 새롭게 리뉴얼 할 수 밖에 없게 만든다

 

10년전 SI 할때 접한 Spring 프레임웍의 사상이었던 Dependancy Injection이 필요한 부분이다

그래서 나는 최근 들어 코딩시의 몇가지 규칙을 정하게 되었는데

 

1. 최초 작성하게 되는 클래스의 구성은 목표로하는 동작 한가지에만 집중하여 설계하고 확장성은 전혀 고려하지 않는다

    -> 이것은 최초 아키텍쳐 설계 속도를 가장 빠르게 완성하도록 이끈다

2. 프로그램을 완성해 가면서 기능을 Fix할거라면 그땐 상속과 구성을 통해 클래스 설계를 확정하도록 한다

    -> 1차 마일스톤을 찍어 개발자로써 하나 완성했다는 성취감을 고취한다

3. 최종적인 리팩토링에서는 TDD 적용으로 단위테스트가 가능한 수준으로 다시 쪼개는 작업을 통해 유지보수성을 높인다

    -> 마지막으로 오래가는 프로그램을 위하여 1년후에 코드를 수정하게 되더라도 빠르게 이해하고 손이 좀 덜가게 만드는게 목표다

 

 

위와 같은 나만의 원칙을 갖추는데 지금까지의 프로그램 경력이 필요했지만

그럼에도 불구하고 항상 내가 만든 프로그램을 유지보수 할땐 부족함이 재발견되곤 한다

나조차도 그런데 남들이보면...

그걸 알기에 항상 코드를 작성할땐 꽤 많은 시간을 소비하게 되버린다

'정보 > IT' 카테고리의 다른 글

서버 관리에 대하여  (0) 2021.08.28
버그이지만 오동작이 아닙니다  (0) 2021.03.24
OAuth에 대하여  (0) 2019.08.25
윈도우 바로가기 명령어 mklink(교차점생성)  (0) 2019.07.21
AutoSet 설치후 보안 점검  (0) 2019.07.19