이재원의 티스토리

git reset 명령어는 인덱스 취소와 커밋 취소라는 두가지 동작을 한다. 커밋 취소의 경우에는 옵션에 따른 차이점을 숙지하는게 중요하다. 인덱스 취소 add 를 통해 인덱스에 추가된 파일을 취소한다. # git add a.txt 취소 git reset a.txt # 인덱스 파일 전체 취소 git reset 커밋 취소 이전 커밋 상태로 돌아간다. 실행모드(mixed, soft, hard)에 따라서 인덱스, 워킹트리까지 취소 시킬 수 있다. --mixed (기본값) HEAD 를 지정한 커밋 시점으로 복구한다. 모든 인덱스를 취소시키지만 워킹트리는 유지된다. 취소된 커밋/인덱스 내용은 워킹트리에 남아있다. --soft HEAD 를 지정한 커밋 시점으로 복구한다. 인덱스 및 워킹트리는 유지된다. 취소된 커밋..

업무중에 쉘스크립트에서 버전값을 체크할 일이 생겼다. 예를들어 버전값이 5.2.3~5.2.15 에 해당하는지 확인하는 내용이다. 즉 버전 범위 검사다. 구글링해보니 여러가지 방법들이 나온다.아래는 그 중에 적당해보이는 3가지로 테스트 해본 스크립트이다. 123456789101112131415161718192021222324252627282930313233343536#!/bin/shVERSION="5.2.13" #default if [ ! -z "$1" ]; then VERSION=$1fi echo "version is $VERSION"echo "" # 1) egrep 명령을 이용한 방법 (egrep 은 grep -E 와 동일함)echo $VERSION | egrep -q "^[5].[2].([3-9]|1..

문제를 재현하거나 가설을 세우기 전에 먼저 지금 어떤일이 일어나고 있는지부터 알아야 한다. 마찬가지로 현재 어떤일이 벌어져야만 하는지를 아는 것도 중요하다. 버그 리포트가 있다면 이미 원하는 정보가 거기에 있을 것이다. 하지만, 버그 리포트 역시 틀리기 쉽다는 점을 잊지 말아야 한다. 버그 리포트에 '~대신 ~이어야 합니다' 라고 돼 있다고 해서 이 말이 소프트웨어의 명세를 의미하는 것은 아니다. 스펙이 명확하지 않다면 정확하게 알기 전까지는 아무런 변경도 해서는 안된다. 정확한 스펙을 모르는 상황에서 제대로 돌아가던 것을 틀리게 수정하는 것이야 말로 최악이다. "나는 결코 추측하지 않는다. 추측은 논리력을 파괴하는 무서운 습관이다." (셜록홈즈 中)

디버깅을 정의해보라고 하면 대부분 수정해야 할 부분을 찾는 것 이라고 생각한다. 하지만 이건 디버깅의 여러 목표 중 하나일 뿐이고, 더욱이 가장 중요한 목표도 아니다. 효과적인 디버깅의 단계는 아래와 같다. 소프트웨어가 왜 이상하게 작동하는지 알아낸다. 문제를 수정한다. 다른 곳이 깨지지 않게 한다. 코드의 전반적인 품질(가독성, 구조, 테스트 커버리지, 성능 등)을 유지하거나 향상시킨다. 같은 문제가 다른 부분에는 없는지 살펴보고, 재발 방지책을 마련한다. 이 중 첫 번째 항목이 가장 중요하고, 디버깅의 시작이 되는 부분임을 잊지 말자.

코딩을 하다보면 같은 곳에 여러 버그가 발생하는 경우가 있습니다. 이 때 개발자는 문제들을 동시에 해결하고 싶은 유혹에 빠지게 됩니다. "이왕 하는김에 다 고치면 좋지 않나요?" 물론 너무너무너무 간단한 문제라던가 운 좋게 모든게 정상 동작할 수도 있습니다. (혹은 그렇게 보일수도) 하지만, 이는 매우 위험한 생각이며 시간 좀 아끼려다 야근각이 나오기 일수입니다. 어떤 버그를 잡으려고 실험하다 보면 다른 버그에 영향을 줄 수 있어 현재 정확히 어떤일이 벌어지고 있는지 알기 어려워집니다. 심지어 버그 하나에 원인이 여러개인 경우에는 스스로의 함정에 빠지기도 합니다. 개인적으로 아무리 경험이 쌓이고 능숙해져도 디버깅이란 이미 충분히 어렵고 고된 작업입니다. 쓸데없이 흙탕물을 만들지 말고 한 번에 한 문제 만..