이 문서 내용은 좀 낡았습니다.
60일이나 편집 안된 오래된 망한 문서니 개발 문서인 경우 참고할 때 조심하세요. 최신 정보를 알고 싶으면 게시판에 글 써주세요
최근에 개발 지지부진한 이유에 관해서 여러 방면으로 고민해보는 내용
그냥 다른 일이 바빠서 전체 개발 총량 자체가 다른 일에 쓰이고 있기 때문이기도 하다
시간 분배를 효율적으로 해야하는데 지금 그게 잘 안되고 있다 만성 피로가 와서 모든 일이 딜레이 걸렸다
최근 Golang으로 이전을 결심하면서 리팩토링을 조금씩하고 있는데
문제는 이게 같은 기능을 다시 만드는 거다보니 겉으로 봤을 땐 기능 추가 같은 게 일절 없는 것처럼 느껴지는 문제가 있다
가능하면 리팩토링하면서 기능 추가도 겸사겸사 하려고 하는데 문제는 그 과정에서 당초 예상했던 것과 달리 더 지연되는 문제가 발생하고 있다
예전에는 그래도 기능 추가에 대한 플랜을 구체적으로 정해놓고 그걸 그대로 만드는 느낌이였는데
요즘은 그냥 즉흥적으로 기능 추가할 때가 많아서 이것도 나름 문제인 것 같다
그리고 그렇게 완성된 무언가는 뭔가 이도저도 아닌 기능 같은 느낌이 되는 것도 문제인 것 같다
2.4. 오래 걸리는 기능을 자꾸 미룸 ✎ ⊖
이건 위와 관련 있는 문제인데 무계획 + 바쁜 게 겹쳐지다보니 한번 코드 손을 봤다가 다 완성 못하고 다음으로 미뤄지면
그게 다음엔 언제 건들 지 모르고 그러다보니 다음에 코드를 봤을 땐 이거 왜 이렇게 만들었지라는 생각이 들고 또 엎어버리는 게 문제인 것 같다
주석을 달면 되는 거 아니냐 생각하겠지만 그게 사실 문제가 아니라 왜 이 코드를 만들었는 지는 알겠는데 그 땐 왜 이렇게 만들었지?라는 생각이 드는 게 문제이다
3. 이 문제를 어떻게 해결해야할까 ✎ ⊖
문제의 우선 순위를 도입해서 급한 불부터 끄는 게 맞는 것 같다
물론 현생 우선 순위가 가장 높은 것은 여전히 개발의 걸림돌이긴 하다
3.2. 왜 이렇게 만들었지라는 생각이 들어도 일단 진행 ✎ ⊖
결국 계획이 없기 때문에 중간에 코드를 갈아 엎으면 그건 진짜 큰 딜레이 요소로 작용하는 것 같다
일단 선 제작 후 개선으로 코드를 만들어야 적어도 기능 구현이 딜레이 없이 제작될 수 있는 것 같다
물론 그냥 계획을 세우면 되는 거 아니냐? 라는 의견이 있을 수도 있는데
그 계획도 다음에 보면 뭐 이따구로 계획을 만들었지라는 생각이 들기 때문에 의미가 없다...
결국 그건 1인 개발의 한계다 같이 검토할 사람이 없으니... 어쩔 수 없다
3.3. 처음부터 너무 이상적인 기능 구현하지 말고 단계적 진행 ✎ ⊖
처음부터 너무 큰 목표를 가지고 기능 구현을 시작하면 결국 중간에 퍼지는 것 같다
적당히 단계별로 구현하고 단계별로 구현해도 돌아는 가도록 하는 게 중요한 것 같다
가장 최근에 이런 방법을 적용한 게 최근 변경 개편이였다
사실 기능의 개발 기간은 짧고
(1) 비용도 없으니 SI 개발 환경과 완전 동일한 상황이 아닐까...
아무리 좋은 개발 방법론이 있어도 환경적 여유가 안되니 뭘 가릴 처지가 안되는 것 같다
이래서 대기업 개발팀은 사람 좀 넉넉하게 구비해놓는 건가...