툴 Idea 관련 여러 생각들.
- 몇몇 생각 - 소스코드에 대해 flat text 관점으로 보지 못하도록 강요한다면, 구조적으로만 볼 수 있게끔 강요한다면 어떤 일이 일어날까. 어떠한 장점이 생기고 어떠한 단점이 생길까.
스몰토크 비슷한 환경이 되지 않을까. 소스 코드의 구조적 뷰로는 LEO라는 훌륭한 도구가 있다. 크누스교수의 Literate Programming을 가능케 해주지. 나는 SignatureSurvey를 지원해 주면 어떨까 한다. --JuNe
계속 생각했던것이 '코드를 일반 Editor 의 문서로 보는 관점은 구조적이지 못하고 이는 필요없는 정보를 시야에 더 들어오게끔 강요한다. 그래서 구조적으로 볼 수 있도록 해야 한다.' 였는데, SignatureSurvey를 생각하면 정말 발상의 전환같다는 생각이 든다는. (코드를 Flat Text 문서를 보는 관점에서 특정정보를 삭제함으로서 새로운 정보를 얻어낸다는 점에서.) --1002
Eclipse 쓰던중 내 코드 네비게이팅 습관을 관찰해보니.. code 를 page up/down 으로 보는 일이 거의 없었다. 이전에 VIM 을 쓰면서 'VIM 으로 프로그래밍하면 빠르다' 라고 느꼈던 이유를 생각해보면
.png "B)")
위/아래는 커서키. 클래스로의 이동은 CTRL+SHIFT+T. Source Folding 도 주로 Outliner 에 의한 네비게이팅을 이용한다면 별로 쓸 일이 없다. 보통 의미를 두고 하는 행동들은 클래스나 메소드들 단위의 이동이므로, 그 밑의 구현 코드들에 대해 깊게 보지 않는다. (구현코드들에 대해 깊게 보는 경우가 생긴다면 십중팔구 Long Method 상황일것이다.)
- 짧은 손가락 동선 - I,J,K,L - 손가락이 멀리 갈 일이 없다.
- Source Folding - 화일 하나가 긴 경우라도 짧게 줄여놓고 쓰므로.
- search - Function 이동시 편리. 게다가 일반 텍스트 에디터에 비해 search 기능을 수행하는 비용이 작다. / 한번, 그리고 바로 키워드 입력. (다른 녀석은? Ctrl+F , 키워드 입력, enter & enter. incremental search가 아닌 경우는 한단계가 더 있게 된다.)
위/아래는 커서키. 클래스로의 이동은 CTRL+SHIFT+T. Source Folding 도 주로 Outliner 에 의한 네비게이팅을 이용한다면 별로 쓸 일이 없다. 보통 의미를 두고 하는 행동들은 클래스나 메소드들 단위의 이동이므로, 그 밑의 구현 코드들에 대해 깊게 보지 않는다. (구현코드들에 대해 깊게 보는 경우가 생긴다면 십중팔구 Long Method 상황일것이다.)코드 에디터 사이즈는 큰게 좋을까? 또는, 코드 에디터 사이즈가 컸으면 하던 때는? 그 이유는 무엇이였을까?
Python 으로 HTML Code Generator 를 작성하던중. 좀 무식한 방법으로 진행했는데, 원하는 HTML 을 expected 에 고스란히 박아놓은 것이다. 이는 결과적으로 test code 를 네비게이팅 하기 어렵게 만들었고, 해당 Generating 되는 HTML 의 추상도도 상당히 낮게 된다. 한화면에 보여야 할 HTML 데이터도 많아야 한다. 이는 결국 내가 에디터 창을 최대로 놓게 만들더니, 더 나아가 에디터 창의 폰트 사이즈을 11에서 8정도로 줄이고 모니터를 앞당겨 보게끔 만들었다. (15인치 LCD 모니터여서 해상도가 최대 1024*768 임.) 해당 상황에 대해 사람이 맞추는 것이 좋을까, 또는 툴의 Viewing 이 도움을 줄 방법이 있을까, 또는 사람이 이를 문제상황으로 인식하고 프로그램 디자인을 바꾸게끔 하는것이 좋을까.
또는... 그냥 사람이 툴을 바꿀것인가. -_-; (상황에 대한 인식, 그리고 툴에 대한 선택을 하는 주체는 결국 사람이다.)
현재의 UML Case Tool들은 Beyond Literate Programming 일까?
