토요일이고 해서, 내가 사용하는 윈도우용 텍스트 에디터나 적어볼까 한다.

 

1.Visual Studio

c++ 코드를 작성할 때에는 VS만한 편집기가 없다. 직장인이지만, 학생인 관계로. :) Jetbrains의 Resharper for C++ 플러그인을 집 컴퓨터에서는 설치해 사용한다. IntelliSense 기능도 좋고, Refactoring 기능도 좋다. 회사에서는 관리자인 관계로 그냥 맨 VS를 사용하지만, 팀원들에게는 VisualAssistX를 설치해서 사용하도록 지원하고 있다.

 

2.Sublime Text

일반 텍스트 파일,JSON 파일과 파이썬 코드를 작성할 때 주로 사용한다. JSON은 Pretifier 플러그인이 워낙 잘 되어 있어서 애용하고 있다. 줄단위 편집 등이 편리하고, 파이썬 코드를 Ctrl=B를 통해 간단히 실행해 볼 수 있기 때문에 파이썬 스크립팅시에는 서브라임을 사용한다.

 

3.NotePad++

여러 파일(디렉터리 검색) 찾기를 한 결과를 별도 패널에서 쉽게 검색하면서 볼 수 있기 때문에 그 용도로 주로 사용한다. 예전에는 매크로 기능을 잘 사용했는데, 요즘은 매크로를 사용할 일이 별로 없다.

 

4.VisualStudio Code

그냥 가벼운 편집기를 사용해야 할 경우 사용한다. 최근에는 몇몇 Extension이 마음에 들어서 사용하고 있다. 주로 mermaid나 PlantUML을 작성할 때, Markdown 문서를 이용할 때 Preview 기능을 제공해 주기 때문에 유용하게 사용할 수 있다.

 

5.HxD

아주 가끔 이진 파일을 살펴보고 싶을 때 사용하는데, 요즘은 점점 빈도가 낮아진다.

 

6.VI

WSL에서 편집할 때는 아무래도 VI가 편하다. 물론 WSL일 경우에는 윈도우에서 편집기를 실행한 다음, WSL의 파일들에도 접근할 수 있지만, 그래도 리눅스 환경에서는 리눅스용 도구가 편하다.

 

대충 이정도만 사용하고,  다른 개발용에는 주로 JetBrains에서 나온 개발 도구를 사용하게 된다. 며칠전 Fleet이라는 새로운 텍스트 편집기를 내놓긴 했던데, 개발환경이 아닌 일반 가벼운 텍스트파일 편집기가 JVM 위에서 동작해야 하는가에 대해 부정적이라 설치도 안해봤다. 

 

반응형

 

 트위터에서 위 그림을 보게 된 것이 이 글을 쓰는데 출발점이 되었다.그림에서는 너무 재미있게 표현했지만, 디버깅도 나름의 전략이 필요하다.

 

 버그라는 것은 언제 발생하는가? 대다수의 버그는 개발자가 코드를 작성할 때 가지고 있던 문제에 대한 인지모델이 실제 현실과 다를 경우 발생한다. 개발자의 머리속에 모습을 갖춘 모델은 개발자의 편향이 반영되어 있으므로,  기대한 동작과 현실동작이 다를 경우 이러한 편향성을 극복하기 위해 잠시 걷거나(일종의 context switching), 설명서를 읽거나, 문제가 될만한 지점에  중단점을 설정한 다음 주변 코드를 살펴보면서 자신이 가진 모델/이론의 한계나 문제점을 극복하는 계기를 마련해야 한다. 비슷한 경험을 가진 다른 사람과 이야기를 나눠보는 것(구글링 첫번째 페이지)이나 누군가에게(자신 포함) 문제를 설명하면서 모델을 객관적인 시선으로 재검토해보는 것(오리인형/테디베어에게 말걸기)등의 방법이 있다. - 나는 코드 리뷰도 같은 맥락으로 바라본다. 코드 커밋 이전에 제 3의 시선으로 코드를 살펴 보는 것이 코드 리뷰의 진짜 가치아닐까? 다른 사람이 코드를 검사한다는 행위 자체는 중요한 포인트가 아니라고 생각한다.

 

하지만 위 그림에서도 나와있지만 대부분 너무 쉽게 Print문을 찍거나, 그냥 반복실행해 보면서 정상동작하기를 기대하는 경우도 많다. 물론 Print문을 찍는다고 문제가 될 것은 아니다. 정작 중요한 것은 그렇게 메시지 출력을 찍어가면서 머리속에 자신이 작성한 코드의 동작 모델을 재 검토하고 수정/보완할 수 있는지가 중요하다고 생각한다. 반복 실행도 마찬가지.. 전략없이 문제를 바라보면 해답을 찾을 수 없다.

 

아인슈타인이  이런 말을 남겼다.

" 어제와 똑같이 살면서 다른 미래를 기대하는 것은 정신병 초기증세이다.
insanity : doing the same things over and over again and expecting different results."

 

그러면 디버깅하는 접근법은 어떤 것들이 있을까?코넬대 전산과 수업중 한 강의 내용을 소개한다.

 

  • 코드를 점진적으로 개발하면서 자주 테스트하기다. 그러다 보면 마지막 변경 코드부분이 원인일 가능성이 높다. 중요한 것은 버그/오류의 영향력을 지역화(국소화;localization)시키는 것임.
  • 로그 많이 남기기. 많이 남기기만 해서는 덜 유용. 시각화 도구를 작성하면 원인 파악이 용이
  • Assertion 도구 사용.
  • 디버거 사용.: 중단점 설정. 함수 코드 이해, 실행중 선택 지점에서 메모리 내용 검사하면 런타임에 정보를 얻을 수 있음.
  • 역추적: 문제가 발생한 지점에서 부터 호출한 코드로  역으로 추적해 가는 기법
  • 이진 검색: 오류원인이 증상이 발생한 코드 부분과 거리가 멀면 역추적이 힘듦. 분할 정복 방식으로 코드를 탐색하여 버그 찾기.
  • 문제 단순화: 버그와 관련이 없는 코드를 점진적으로 제거하면서 문제가 될만한 부분 찾아가기
  • 가설 수립을 통한 검증.
  • 버그 클러스터링: 버그 보고를 카테고리로 나누어 분석하기.
  • 오류 감지 도구: Coverity등의 도구를 사용하기
  • 버그가 발생한 위치는 예상과 다를 수 있다. 열린 마음 유지
  • 뒤집어 생각해 보기: 버그가 없는 곳은 어디인지를 스스로 물어보다보면 원인이 되는 코드를 찾을 수 있음.
  • 버그가 없다고 생각한 이유를 자신/타인에게 설명하기 -> 문제를 명확히 하려다보면 버그가 발견될 수 있음
  • 입력 데이터 검사하기
  • 올바른 소스코드인가 살펴보기
  • 휴식 취하기

 

소프트웨어를 개발하면서 버그는 피할 수 없다. 하지만 같은 버그를 오랫동안 만나고 싶지는 않다. 전략적으로 접근하여 버그를 자주 만나지 말고, 만나더라도 오래 보지 말자.

 

반응형

+ Recent posts