반응형

Hain(하인) 오픈소스 프로그램 사용 후기

다운로드 홈페이지

https://github.com/appetizermonster/Hain/releases

64비트 운영체제일 경우 (2016년 4월 13일 오후 11:15 시간 기준으로) v0.1.0을 받으시면 되고요. 

32비트 운영체제일 경우 v0.0.4를 받으시면 됩니다.

프로그램 설명

https://github.com/appetizermonster/hain

Electron으로 빌드한 윈도우즈 운영체제를 위한 alt+space launcher(실행을 돕는 프로그램)입니다.

저(이 프로그램을 만드신 분)는 윈도우즈에서 Alfred를 대신하는 프로그램을 꿈꾸었습니다. 그래서 이를 자바스크립트로 만들었고, 이루어냈습니다.

An alt+space launcher for Windows, built with Electron.

I always dreamed an alternative to Alfred on Windows, that is made with JavaScript. so, I made it.

사용후기

저는 개인컴퓨터로는 Macbook을 사용하고 회사에서는 Windows 8을 사용 중에 있습니다. Macbook에서 Alfred프로그램을 사용하고 있어서 저도 Windows 상에서 이러한 종류의 프로그램을 사용하길 꿈꾸고 있었습니다. 우연히, facebook에서 이 프로그램의 존재를 알게 되어 위 홈페이지에서 프로그램을 다운로드 받아 사용하게 되었습니다. 

Alfred에서 alt+space를 누르면 위에처럼 창이 뜹니다. 원하는 프로그램 명을 입력하면 그에 대응하는 프로그램을 찾아줍니다. Hain 프로그램도 Alfred 기능이 똑같이 실행이 되어서 좋았습니다. 또한, /hpm이란 플러그인 기능이 있어서 자바스크립트로 코드를 작성하여 새로운 기능도 만들 수 있습니다.

그리고 오픈소스라 Github에 소스가 올라와 있습니다. 프로그램을 사용하던 중 VirtualBox가 실행이 안되는 버그를 발견하였습니다. 그래서 Github에 issue 등록 기능을 이용하여 버그에 대한 증상을 작성하였습니다. 4월 11일 버그의 원인을 제작하신 분께서 알려주셨습니다. 4월 13일 오늘 버그를 해결한 프로그램을 release 하셨습니다. 바로 확인을 해보니 VirtualBox 프로그램이 잘 실행됨을 확인할 수 있었습니다. 직접 소스를 다루어 본 거는 아니지만 저의 첫번째 오픈소스 활동이라 기쁩니다. 

반응형
반응형

출처 : http://serverfault.com/questions/62411/how-can-i-sort-du-h-output-by-size

크기로 du -h의 출력을 정렬할 수 있나요?

저는 du 출력을 사람이 읽을 수 있는 목록으로 얻고 싶습니다.

하지만, du는 "크기로 정렬"이란 옵션이 없기 때문에 sort로 pipe하는 것은 사람이 읽을 수 있도록 하는 플래그(human readable flag)가 작동하지 않습니다.

예를 들어 다음 명령을 실행하면

du | sort -n -r 

(내림차순으로) 크기로 정렬된 디스크 사용량이 출력됩니다.

du |sort -n -r
65108   .
61508   ./dir3
2056    ./dir4
1032    ./dir1
508     ./dir2

하지만, 사람이 읽을 수 있도록 하는 플래그(human readable flag)를 사용하여 실행하면 적절하게 정렬되지 않습니다.

du -h | sort -n -r
508K    ./dir2
64M     .
61M     ./dir3
2.1M    ./dir4
1.1M    ./dir1

크기로 du -h를 정렬하는 방법을 아시는 분이 계신가요?


39 개의 답변 중 1개의 답변

2009년 8월에 GNU coreutils 7.5 가 나오고 부터, du -h와 같은 종류의 접미사를 사용하는 -h 파라미터를 sort에서 쓸 수 있습니다.

du -hs * | sort -h

만약 -h를 지원하지 않는 sort를 사용하신다면, GNU Coreutils를 설치할 수 있습니다. 다음은 오래된 Mac OS X 입니다.

brew install coreutils
du -hs * | gsort -h

다음은 sort 매뉴얼 내용입니다.

-h, --human-numeric-sort 사람이 읽을 수 있는 숫자를 비교한다 (예시, 2K 1G)

반응형
반응형

출처

http://stackoverflow.com/questions/750172/change-the-author-of-a-commit-in-git

Git에서 commit의 author(작가)를 변경하기

저는 학교 컴퓨터로 간단한 스크립트를 작성하면서 (집의 컴퓨터에서 복제된 내 pendrive에 있던 저장소에 있는) Git의 변경사항들을 commit하였습니다. 몇 개를 commit하고 나서 저는 root user로 commit했다는 것을 알았습니다.

제 이름으로 이 commit들의 author(작가)를 변경할 수 있는 방법이 있을까요?


39 개의 답변 중 1개의 답변

참고: 이 답변은 SHA1을 변경하므로 이미 push된 branch에서 사용할 때 주의하십시오. 이름의 철자를 수정하거나 오래된 이메일을 업데이트하려는 경우 git을 사용하면 .mailmap을 사용하여 기록을 다시 쓰지 않고도 이 작업을 수행할 수 있습니다. 저의 다른 답변을 참조하십시오.

Interactive Rebase 사용

당신은

git rebase -i -p <변경할 모든 commit 이전의 임의의 HEAD>

합니다. 다음에 rebase 파일에서 당신이 변경할(bad) commit에서 "edit"로 변경합니다. 만약 당신의 첫 번째 commit을 변경하고 싶다면, rebase 파일에 (다른 줄에 있는 포멧에 따라) 첫 번째 줄에 commit할 내용을 추가해야 합니다. 그리고 git에게 각 commit을 변경할 때 마다 다음을 수행합니다.

git commit --amend --author "New Author Name <email@address.com>" 

수정 또는 열었던 편집기를 닫았으면 다음을 수행합니다.

git rebase --continue

이 명령을 rebase를 계속 이어서 합니다.

만약 --no-edit을 추가함으로서 편집기를 열지 않을 수 있고 그 명령은 다음과 같습니다.

git commit --amend --author "New Author Name <email@address.com>" --no-edit && \
git rebase --continue

하나의 commit

몇몇 댓글달은 분들의 글로부터, 만약 가장 최근 commit만 변경하고 싶으시면 rebase 명령은 필요없습니다. 단지, 다음 명령만 수행하면 됩니다.

git commit --amend --author "New Author Name <email@address.com>"

이는 특정 이름의 author(작가)로 바뀌겠지만 committer는 당신이 git config user.namegit config user.email으로 설정했던 사용자로 설정될 것입니다. 만약 committer를 같이 설정하고 싶으시면 다음처럼 쓰시면 됩니다.

git -c user.name="New Author Name" -c user.email=email@address.com commit --amend --reset-author

commit을 merge하는 것에 대한 참고 사항

원래 답변에 약간의 오류가 있었습니다. 현재 HEAD<모든 잘못된 커밋 이전의 일부 HEAD> 사이에 commit을 merge할 경우 git rebase는 이를 병합합니다(그런데 GitHub pull 요청을 사용하는 경우 병합이 엄청나게 많을 것입니다. 기록에 커밋). 이것은 매우 자주 매우 다른 기록으로 이어질 수 있으며(중복된 변경 사항이 "리베이스 아웃"될 수 있으므로) 최악의 경우 git rebase가 어려운 병합 충돌(이미 commit을 merge했을 때 해결되었을 가능성이 있음)을 해결하도록 요청할 수 있습니다. 해결책은 git rebase-p 플래그를 사용하여 기록의 merge 구조를 보존하는 것입니다. git rebase에 대한 맨페이지는 -p 및 -i를 사용하면 문제가 발생할 수 있다고 경고하지만 BUGS 섹션에는 "commit을 편집하고 commit 메시지를 다시 작성하면 잘 작동해야 합니다."라고 나와 있습니다.

위의 명령에 -p를 추가했습니다. 가장 최근 커밋을 변경하는 경우에는 문제가 되지 않습니다.

최신 git 클라이언트용 업데이트(2020년 7월)

-p 대신 --rebase-merge를 사용합니다(-p는 더 이상 사용되지 않으며 심각한 문제가 있음).

반응형
반응형

문제점

맥북을 사용하면서 사파리와 크롬을 사용할 때 https 사이트가 공인인증서가 필요하다고 물어보면서 접속이 되지 않는 문제가 있었습니다. 

또한,  맥북 앱스토어도 접속이 되지 않는 문제가 있었습니다.


해결과정

우선, Mac 서비스 센터를 검색하여 찾아보았습니다.

https://locate.apple.com/kr/ko/service/?pt=4&lat=37.547895&lon=126.941893&address=서울시

전화를 해보니 Mac 서비스 센터에서는 '하드웨어'적인 문제만 해결할 수 있다고 하였습니다.

저는 '소프트웨어'적인 문제이기 때문에 애플고객지원센터 전화번호 '080-333-4000'을 알려주었습니다.


토요일에 해당 전화번호로 전화를 하였습니다.

iCloud를 통해 원격제어를 해 가면서 문제가 무엇인지 직원분께서 찾으면서

직원분이 컴퓨터를 재부팅 하는 등의 지시를 했고 저는 그 지시를 따라하였습니다.

첫 번째 전화에 문제가 해결되지 않자 고객지원센터에서 제 이메일로 번호를 남겨주었습니다.


다시 전화해서 이메일에 남은 번호를 말하자 계속해서 문제를 해결해 나갔습니다.

전의 직원 분이 해결 할 수 없어서 전문 상담사가 내용을 이어받아 처리를 하기 시작하였습니다.

인터넷 뱅킹이 문제가 된거 같아 해당 보안 프로그램을 지워보았지만 문제가 해결되지 않았습니다.

그래서 다음날 다시 전화 하기로 하였습니다.


일요일에 다시 전화를 하였습니다.

다른 전문 상담사를 통해서 처리를 해 나갔고

iCloud의 원격제어를 하며 전문 상담사가 해당 내용을 찾아가면서 지시대로 여러가지를 시도해 보았습니다.

결국은 avast 프로그램의 보안 설정 때문에 문제가 됨을 알았고 해당 프로그램을 닫고 지우자 문제가 해결되었습니다.


후기

문제를 해결하는 데는 오래걸렸지만 전문 상담사가 차근히 찾아가면서 문제를 해결할 수 있어 좋았고 고맙습니다.

또, Mac을 사용하면서 문제가 발생하면 전화하게 될 듯 합니다. 

그리고 토요일 일요일 주말인데도 아침 9시부터 저녁 9시까지 고객지원센터를 운영한다는 점도 놀랍고 좋은 점이라 생각합니다.



반응형
반응형

출처 

http://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit-in-git

Git에서 특정 commit만 수정하는 방법?

저는 리뷰하면서 commit의 모든 목록을 제출합니다. 만약, 

- HEAD

- Commit3

- Commit2

- Commit1

저는 git commit --amend로 HEAD commit을 수정할 수 있다는 걸 알지만, 어떻게 HEADcommit이 아닌 Commit1을 수정할 수 있을까요?

----

4 개의 답변 중 1개의 답변만 추려냄.

당신은 git rebase를 사용할 수 있습니다. 만약 commit bbc643cd으로 돌아가서 수정하고 싶으시면, 다음을 실행합니다.

$ git rebase --interactive 'bbc643cd^'

기본 편집기로, 수정하고 싶은 commit의 줄에서 'pick'을 'edit'로 변경합니다. 원하는 대로 작업 디렉터리를 변경하고 이전과 같은 메세지로 다음처럼 commit 합니다.

$ git commit --all --amend --no-edit (1)

commit을 변경하고, 다음을 입력하여

$ git rebase --continue

이전 HEAD commit으로 돌아옵니다.

경고 : 이는 모든 자식들까지 포함하여 SHA-1 commit이 바뀌게 됨을 아셔야 됩니다. 다른 말로, 이는 그 지점부터 앞으로 history (commit)을 다시 쓰게 됩니다. 만약 git push --force명령을 사용하여 push를 하면 이를 수행한 저장소는 망가질 수 있습니다.

---

역자주

https://git-scm.com/docs/git-commit

(1) git commit --all --amend --no-edit

--all : -a와 같은 의미로 수정되거나 삭제된 파일을 자동으로 stage 영역으로 올립니다.

--amend : commit을 추가하지 않고 마지막 commit을 수정합니다.

--no-edit : --amend와 결합하여 commit 메세지 변화없이 마지막 commit을 수정합니다.



반응형
반응형

출처 

http://stackoverflow.com/questions/7872846/how-to-read-from-standard-input-non-blocking

자바에서 표준 입력을 non-blocking으로 읽는 방법?

    long end=System.currentTimeMillis()+60*10;
    InputStreamReader fileInputStream=new InputStreamReader(System.in);
    BufferedReader bufferedReader=new BufferedReader(fileInputStream);
    try
    {
        while((System.currentTimeMillis()<end) && (bufferedReader.readLine()!=null))
        {

        }
        bufferedReader.close();
    }
    catch(java.io.IOException e)
    {
        e.printStackTrace();
    }

저는 600밀리초 안에 읽기 위해 위에처럼 시도하였습니다만 bufferedReader가 blocking되어 readline에서 읽기가 되지 않습니다. 제발 도와주세요.

----

5 개의 답변 중 1개의 답변만 추려냄.

역자주 : available() 메소드가 Java 1.5에는 없어서 ready() 메소드를 사용하여 문제를 해결하였습니다.

long end=System.currentTimeMillis()+60*10;
InputStreamReader fileInputStream = new InputStreamReader(System.in);
BufferedReader bufferedReader = new BufferedReader(fileInputStream);
try {
    while ((System.currentTimeMillis() < end)) {
        if (bufferedReader.ready()) {
            System.out.println(bufferedReader.readLine());
        }
    }
} catch (IOException e) {
    e.printStackTrace();
} finally {
    try {
        if (bufferedReader != null) {
            bufferedReader.close();
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}


반응형
반응형

출처 : http://stackoverflow.com/questions/8494209/modulus-in-django-template

Django Template의 나머지(%) 연산

저는 django에서 나머지 연산자 같은 것을 사용하는 방법을 찾고 있습니다. 제가 하려고 하는 것은 루프문에서 4번째 요소마다 클래스 이름을 추가하는 것입니다.

나머지 연산자를 사용하여 다음처럼 작성하였습니다.

당연히 %가 탬플릿에서 예약된 문자이기 때문에 작동을 안할 것입니다. 이를 할 수 있는 다른 방법이 있을까요?


3 개의 답변 중 1개의 답변만 추려냄.

내장된(build-in) django filter인 divisibleby가 필요합니다.

{% for p in posts %}
    <div class="post width1 height2 column {% if forloop.counter0|divisibleby:4 %}first{% endif %}">
        <div class="preview">

        </div>
        <div class="overlay">

        </div>
        <h2>p.title</h2>
    </div>
{% endfor %}
반응형
반응형

출처 : http://stackoverflow.com/questions/1191374/using-module-subprocess-with-timeout

timeout과 함께 'subprocess' 모듈 사용하기

여기에 stdout 데이터를 리턴하는 임의의 명령어를 실행하거나 0이 아닌 종료 코드에서 예외를 발생시키는 파이썬 코드가 있습니다.

proc = subprocess.Popen(
    cmd,
    stderr=subprocess.STDOUT,  # Merge stdout and stderr
    stdout=subprocess.PIPE,
    shell=True)

communicate는 프로세스가 종료하기를 기다리는 데 사용합니다.

stdoutdata, stderrdata = proc.communicate()

subprocess 모듈은 몇 초 이상 실행하고 있는 프로세스를 없애는(kill) timtout 능력을 지원하지 않습니다. 그래서 communicate는 영원히 실행될 수 있습니다.
윈도우즈나 리눅스에서 실행하는 데 파이썬 프로그램에서 timeout을 구현할 수 있는 간단한 방법이 있을까요?


20 개의 답변 중 2개의 답변만 추려냄.

Python 3.3+ 에서

from subprocess import STDOUT, check_output

output = check_output(cmd, stderr=STDOUT, timeout=seconds)

output은 명령어의 표준 출력, 표준 에러 데이터가 합쳐진 것을 포함하는 바이트 문자열입니다.

check_output(check_output)은 proc.communicate() 메소드와는 다르게 문제 텍스트에 지정된 대로 0이 아닌 종료 상태에서 CalledProcessError를 발생시킵니다.

저는 불필요하게 자주 사용되기 때문에 shell=True를 제거하였습니다. cmd에서 실제로 필요한 경우 언제든지 다시 추가할 수 있습니다. shell=True를 추가하면 즉, 자식 프로세스가 자체 하위 항목을 생성하는 경우; check_output()은 시간 초과가 나타내는 것보다 훨씬 늦게 반환 할 수 있습니다. Subprocess timeout 실패를 참조하세요.

타임 아웃 기능은 3.2+ subprocess 모듈의 subprocess32(subprocess32) 백 포트를 통해 Python 2.x에서 사용할 수 있습니다.


유닉스를 사용하신다면,

import signal
  ...
class Alarm(Exception):
    pass

def alarm_handler(signum, frame):
    raise Alarm

signal.signal(signal.SIGALRM, alarm_handler)
signal.alarm(5*60)  # 5분
try:
    stdoutdata, stderrdata = proc.communicate()
    signal.alarm(0)  # 알람을 리셋한다.
except Alarm:
    print "헉, 너무 오래 걸립니다!"
    # 그 밖에 무엇이든
반응형
반응형

출처 

http://unix.stackexchange.com/questions/44266/how-to-colorize-output-of-git

git의 출력에 색을 입히는 방법?

git(또는 명령어)에 대한 출력에 색을 입히는 방법이 있을까요?

다음은 예시입니다.

not stage

baller@Laptop:~/rails/spunky-monkey$ git status
# On branch new-message-types
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   app/models/message_type.rb
#
no changes added to commit (use "git add" and/or "git commit -a")
baller@Laptop:~/rails/spunky-monkey$ git add app/models

stage

baller@Laptop:~/rails/spunky-monkey$ git status
# On branch new-message-types
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   app/models/message_type.rb
#

출력은 같아보입니다만, 정보는 완전히 다릅니다. 파일이 위는 unstaged 상태이고 밑은 stage로 이동한 상태입니다.

이 출력에 색을 입히는 방법이 있을까요? 예를들어 unstage된 파일은 빨간색, stage된 것은 녹색으로요?

또는 Changes not staged for commit:는 빨간색, # Changes to be committed:은 녹색으로요?

Ubuntu에서 작업중입니다.

구글링해서 잘 작동하는 답변을 찾았습니다 : git config --global --add color.ui true

하지만 명령어 출력에 색을 추가하는 더 일반적인 해결책을 알고 싶습니다.

----

4 개의 답변 중 1개의 답변만 추려냄.

~/.gitconfig 파일에서 [color] 섹션을 생성합니다. 예를 들면 다음처럼 하실 수 있습니다.

[color]
  diff = auto
  status = auto
  branch = auto
  interactive = auto
  ui = true
  pager = true
또한, 어떤 부분에 색을 입히길 원하는 지도 제어하실 수 있습니다. 예를 들면,
[color "status"]
  added = green
  changed = red bold
  untracked = magenta bold

[color "branch"]
  remote = yellow
이를 통해 시작하시길 바랍니다. 당연히 색 입히는 걸 지원하는 터미널이 필요할 것입니다.


반응형
반응형

테스트 주도 개발
Test-driven development
 테스트 주도 개발(TDD)은 매우 짧은 개발 사이클에 의존하는 소프트웨어 개발 프로세스입니다. 첫째로 개발자는 새로운 함수나 원하는 향상을 정의하면서 1. (처음에 실패할) 자동화된 테스트 케이스를 작성하고, 2. 그 테스트를 통과할 최소의 코드를 제작하며, 마지막으로 3. 받아들일 수 있는 표준으로 새로운 코드를 리팩토링 합니다. 이 기술을 개발해 왔고 재발견한 Kent Beck은 TDD가 간단한 설계와 자신감을 북돋게 한다고 2003년에 주장하였습니다.
 Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered'[1] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[2]
 테스트 주도 개발은 1999년에 시작한 XP의 테스트 우선 개발과 관련 있지만, 최근들어 자신의 권리에 더 관심이 있는 듯 합니다.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,[3] but more recently has created more general interest in its own right.[4]
 프로그래머들은 더 오래된 기술로 개발된 레거시 코드를 디버깅하고 향상시키기 위해 이 컨셉을 적용합니다.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.
테스트 주도 개발 주기
Test-driven development cycle
  1. 테스트를 추가하기
  1. Add a Test
테스트 주도 개발에서 각각 새로운 특징은 테스트를 작성하는 것으로 시작한다는 점입니다. 테스트를 작성하기 위해 개발자는 분명하게 업무 상세와 요구사항을 이해하여야 합니다. 개발자는 이를 요구사항과 예외 조건을 만족하기 위해 use cases와 user story를 통해 달성할 수 있고 소프트웨어 환경에 적절한 테스팅 프레임워크에서 테스트를 작성할 수 있습니다. 이미 있는 테스트의 수정된 버전이 될 수도 있습니다. 이는 테스트 주도 개발과 코드가 쓰여진 후 유닛테스트와 구별되는 특징입니다. 코드를 작성하기 전에 개발자로 하여금 요구사항에 집중하도록 합니다. 미묘하지만 중요한 차이입니다.
In test-driven development, each new feature begins with writing a test. To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. It could be a modified version of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.

     2. 모든 테스트를 실행하고 실패한 것을 알아보기

     2.  Run all tests and see if the new one fails
이는 어떤 새로운 코드 요구하는 거 없이 새로운 테스트가 실수 없이 통과하고 요구된 특징이 이미 존재하지 않는지에 대해 테스트 자동화 도구(자동화된 테스트 프레임워크)가 정확히 작동하는지 검증합니다. 이 단계는 그 테스트 자체를 검사합니다. 반대로 새로운 테스트가 항상 통과할 가능성을 정하기 때문에 유용합니다. 새로운 테스트는 기대한 이유에 대해 실패할 수 있습니다. 이 단계는 정확한 제약조건에서 유닛테스트가 테스트되고 있는지 의도된 경우에서만 통과하는지 개발자에게 자신감을 심어줄 수 있도록 합니다.
This validates that the test harness is working correctly, that the new test does not mistakenly pass without requiring any new code, and that the required feature does not already exist. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This step increases the developer's confidence that the unit test is testing the correct constraint, and passes only in intended cases.

     3. 일부 코드를 작성하기

     3.  Write some code
이 단계는 테스트를 통과하는데 몇몇 코드를 작성합니다. 이 단계에서 쓰여진 새로운 코드는 완벽하지 않은데 예를 들어 우아하지 않는 방법으로 테스트를 통과합니다. 이는 받아들일만 한데 5단계에서 코드의 질이 높아질 것이기 때문입니다. 요점은 이 단계의 목적은 테스트를 통과하는 것입니다. 더이상 (테스트를 하지 않는) 기능은 예측되지 않으며 어떤 단계에서도 '허용되지' 않을 것입니다.
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect and may, for example, pass the test in an inelegant way. That is acceptable because it will be improved and honed in Step 5.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted nor 'allowed for' at any stage.

     4. 테스트 실행하기

     4. Run tests
모든 테스트 케이스가 통과하였다면 새로운 코드는 테스트 요구사항을 만족하며 현재 존재하는 특징에서 지위를 낮추거나 멈출 필요가 없이 프로그래머는 자신감을 가질 수 있습니다. 그렇지 않으면 새로운 코드는 통과할 때까지 수정되어야 합니다.
If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.

     5. 코드를 리팩토링하기

     5. Refactor code
증가하는 코드는 테스트 주도 개발 동안에 정기적으로 정리되어야 합니다. 새로운 코드는 더 논리적으로 테스트에 통과되기에 편리하도록 바뀌어야 합니다. 중복은 제거되어야 합니다. 부가 기능이 추가될 때 객체, 클래스, 모듈, 변수와 메소드 이름은 현재 목적과 사용을 분명히 표현해야 합니다. 특징이 추가됨으로서 메소드의 body는 더 길어지며 다른 객체들도 더 커질 것입니다. 소프트웨어 라이프사이클에서 나중에 가치가 있기 위한 가독성 및 유지보수를 향상시키기 위해 주의깊게 더 커진 body 부분을 명명하고 코드를 쪼개면 이득을 볼 수 있습니다. 상속 관계는 더욱 논리적으로 정리되게 도울 것이며 디자인 패턴으로 알려진 방법으로 이득을 볼 수 있습니다. 깔끔한 코드를 작성하고 리팩토링하는 상세하고 일반적인 가이드라인이 있습니다. 각 리팩토링 구간동안 테스트 케이스들을 계속해서 재실행함으로서 개발자는 현재 기능을 수정하기 않는 프로세스를 만들 수 있습니다.
The growing code base must be cleaned up regularly during test-driven development. New code can be moved from where it was convenient for passing a test to where it more logically belongs. Duplication must be removed. Object, class, module, variable and method names should clearly represent their current purpose and use, as extra functionality is added. As features are added, method bodies can get longer and other objects larger. They benefit from being split and their parts carefully named to improve readability and maintainability, which will be increasingly valuable later in the software lifecycle. Inheritance hierarchies may be rearranged to be more logical and helpful, and perhaps to benefit from recognised design patterns. There are specific and general guidelines for refactoring and for creating clean code.[6][7] By continually re-running the test cases throughout each refactoring phase, the developer can be confident that process is not altering any existing functionality.
소프트웨어 디자인에서 중복을 제거하는 개념은 중요한 요소입니다. 그러나 이 경우 테스트 코드와 운영 코드 사이에 중복 제거를 적용할 수도 있습니다. 
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to the removal of any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in Step 3.
반복
Repeat
새로운 테스트를 시작하고 사이클은 다음 기능으로 반복됩니다. 각 단계의 크기는 각 테스트 사이에 1~10번정도 교정할 정도로 항상 작아야 합니다. 새로운 코드가 새로운 테스트를 갑자기 만족하지 않는다거나 다른 테스트가 예상치 못하게 실패한다면 프로그래머는 이 작업을 undo하거나 과도한 디버깅보다는 우선 이전 소스로 복귀해야 합니다. 계속된 통합은 되돌릴 수 있는 체크포인트를 제공하는 데 도움을 줍니다. 외부 라이브러리를 사용할 때 단기 그 라이브러리 자체를 테스트 하기 위한 코드 추가를 하지 않도록 하는 게 중요한데, 그렇지 않으면 개발 중인 모든 소프트웨어의 요구를 제공하기 위해 충분하지 못한 특징이나 라이브러리에 이유가 있다고 판단할 수 있기 때문입다.
Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. Continuous integration helps by providing revertible checkpoints. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself,[4] unless there is some reason to believe that the library is buggy or is not sufficiently feature-complete to serve all the needs of the software under development.


반응형

'번역' 카테고리의 다른 글

MEMORY Storage Engine  (0) 2016.11.04
Computer virus  (0) 2009.10.07
악성코드  (0) 2009.10.07
BHO  (0) 2009.10.07
행성의 정의  (0) 2009.08.03

+ Recent posts