[TreeCanvasView] 늦은 개발 완료 후기 Ruin 공방 - 개인 작품



기획부터 실제 배포까지 약 2달 정도의 시간이 걸린 것 같다.

중간에 쉬는 날이 좀 길어서 그렇지... 순수 작업일은 한 달이 좀 넘을까하는 수준.

하지만 막상 깃허브에 올려봐도 만족감보다는 허무함이 더 크다. 조금 더 잘 만들 수도 있었을텐데...

기본 코드 구조상 불안한 점도 적지 않고 애초에 좋은 코드가 아니라고 생각한다.

한 번에 한 가지 이상을 하는 함수들.

미련한 설계의 부산물을 어떻게든 극복하기 위한 여러 사이드 이펙트.

UI 와 데이터의 결합도 끝내 합쳐지지 못하고 각각인 채로, 그리 견고하지 않다.

설계의 문제, 그리고 코드 스타일의 문제. 모두 공부가 모자르다는 증거다.

이 라이브러리를 누군가가 쓴다고 했을 때, 나는 책임질 수 있는 코드를 만들었던걸까.

...스스로 좀 한심하다는 생각이 든다.

어떻게 해야 더 좋은 프로그램을 설계하고 더 끝내주는 코드를 쓸 수 있는걸까.

언젠가는 누군가 내 코드를 보았을 때, 감탄사를 내뱉을 정도로 내 실력이 위치해있으면 좋겠다.

모든 요소를 고려하여 최적의 선택을 하고, 그 선택을 한 치의 오차 없이 코드로 옮길 능력을 갖고 싶다.

더 높은 곳으로 향하고 싶다...


각 언어에 대한 짧은 생각 Ruin 공방 - 자재 창고

조금이라도 써본 것만 위주로.


C : 별 찍을 때 빼고는 써본 적이 많지는 않다. C++ 흉내를 내려고 매우 불편했던 점만 기억난다.

C++ : 대학교 때부터 배웠지만 점점 자신감이 없어져 바닥을 치는 언어. 진짜 C++ 을 다 아는 Human 이 이 세상에 존재할까...? 지금은 좋은 문제 풀이용 언어일 뿐. 그래도 쓰면 고향에 온 것 같은 느낌은 든다.

Java : 한국에서 일을 하니 주력으로 쓰게된 놈. 그런 것 치고 기초가 약하다는 생각은 항상 든다. 라이브러리, 프레임워크가 너무 많아...

Javascript : 제일 좋아하고, 좋아하고 싶은 언어. 심연에 도사린 예측 불가능성이 혈압을 오르게 하지만 그만큼 매력적이다.

Python : 학습 용도로 여러 번 써보았지만 정말 '잘 썼다' 라는 느낌이 한 번도 안들었다. 코드 한 줄 쓸 때마다 더 스마트한('파이썬한') 방법이 있다는 느낌이 들고, 실제로도 그 방법이 어딘가 있다! 그리고 2, 3 파편화 무엇?

Swift : 나름 밥줄 언어. 사실 얘도 잘 쓴다는 느낌은 안들지만 그 지점이 어딘지는 어렴풋이 보인다. 슬슬 FRP 해야지...

Objective-C : 지구-2 에서나 온 것 같은 외견은 진짜 끔찍함. 그런데 해야겠지? 일단 써본 사람 말로는 좋다고... 는 한다.



그리고 아래는 관심 목록.

Scala : 진짜 그렇게 재밌나?

Go : Node.JS 1위 컨트리뷰터가 노드 버리고 간 이유가 대체 뭘까?

Elixir : Erlang 의 병행 프로그래밍 언어의 피가 흐른다는 그 언어. Phoenix 도 그렇게 좋다던데?

C# : 조만간 할 듯. 꽤 쉽게 배울 수 있다고... 는 한다.


[TreeCanvasView] 개발 ??? 일차 Ruin 공방 - 개인 작품

모든 로직이 완료 되었다.

자잘한 남은 작업과 라이브러리로 만드는 작업이 남았을 뿐.

(사실 많이 남았다...)

그러면 이쯤에서 정리 - TreeCanvasView 는 무엇을 하는 라이브러리인가?

Tree 구조의 데이터 구조를 만들고, 해당 구조를 Table 에 그려주는 라이브러리이다.

즉, 각각의 행이 추상 트리의 데이터 노드와 일대일 매칭이며 각 위, 아래 행과 부모, 자식, 형제 중 하나의 관계를 갖는다.

핵심 기능은 이 커스텀 테이블 UI 상에서 행 생성, 삭제, 변경, 이동을 지원한다는 것.

왜 만들었을까? 이런 테이블이 없었기 때문이다.

다음 단계로 가기 위한 작업에는 이 테이블이 반드시 필요했기 때문이다.

(가끔, 정말 이런 기능이 필요했던 사람이 없는지 의문이 든다. 아니면 다들 직접 구현해서 썼던걸까?)

잘 만들었나? 아뇨.

기획과 달리 TreeCanvasView의 데이터 셋과 UI 는 별개로 놀고 전체 아키텍처도 분명하지 않다. (MV...C?)

컴포넌트간 의존성은 끔찍한 수준이고 전역 변수의 난발은 처참할 정도.

조금의 변경만 가해져도 이건 그냥 전체를 들어내야할거 같다. 아니 그 전에 사용상 에러는 없을까?

정말 이렇게 구현하는게 최선이었을까?

일단 서비스가 아닌 라이브러리를 만드는 작업은 상용 버전의 서비스와는 너무 달랐다...

어떻게 만드는게 가장 사용하기 좋은 형태일까?

이 라이브러리는 어떻게 활용되어야 하나?

지금 당장 마감 작업을 하고 라이브러리로 묶는 것도 문제지만 정말 반성해야할 점이 많아 보인다.

다음엔 좀 더 잘할 수 있을지..



1 2 3 4 5 6 7 8 9 10 다음


통계 위젯 (화이트)

71
25
15670