버그 같은게 아니고 저 옵션의 기본 값이 제공으로 바뀐듯...

번역 옵션 제공을 비활성화하면 안 뜸.



Chrome에서 웹페이지 번역

모르는 언어로 작성된 페이지를 방문할 때 다음 단계에 따라 Chrome이 페이지를 번역하도록 할 수 있습니다.

  1. 컴퓨터에서 Chrome을 엽니다.
  2. 다른 언어로 작성된 웹페이지로 이동합니다.
  3. 상단의 번역을 클릭합니다.
  4. Chrome이 웹페이지를 이번 한 번만 번역합니다.

작동하지 않나요? 웹페이지를 새로고침해 보세요. 그래도 작동하지 않을 경우 마우스 오른쪽 버튼으로 페이지의 아무 곳이나 클릭한 다음 [언어](으)로 번역을 클릭합니다.

번역 사용 또는 사용 중지

Chrome은 기본적으로 모르는 언어로 작성된 페이지를 번역하도록 제안합니다.

Chrome의 웹페이지 번역 제안 여부를 관리할 수 있습니다.

  1. 컴퓨터에서 Chrome을 엽니다.
  2. 오른쪽 상단에서 더보기 더보기 다음 설정을 클릭합니다.
  3. 하단에서 고급을 클릭합니다.
  4. '언어'에서 언어를 클릭합니다.
  5. '이 언어로 된 페이지에 대한 번역 옵션 제공'을 선택 또는 선택 해제합니다.




출처: Chrome 언어 변경 및 웹페이지 번역 - 컴퓨터 - Google Chrome 고객센터 || https://support.google.com/chrome/answer/173424?co=GENIE.Platform%3DDesktop&hl=ko




1. 접근성 > 키보드 > 고정키 토글 여부 확인. 켬이면 꺼줌.
2. 꺼져 있다면 화상 키보드 실행하여 눌려 있는 것으로 인식하는지 확인
3. 눌려 있다면 TouchEn key 등 키보드 보안 프로그램 제거
4. 제거 해도 안되면 노트북? 제조사 쪽 드라이버 재설치
5. 그래도 안 되면 키보드 물리적 고장


참고자료

HP EliteBook 8460p 노트북 PC - Ctrl 키가 계속 눌려 있는 것처럼 노트북이 동작함 | HP® 고객 지원 | https://support.hp.com/kr-ko/document/c03150784
bbs > FAQ > Ctrl (컨트롤키 눌려지는 현상) 원인과 해결 방법 | http://cherryko.co.kr/bbs/bbs/board.php?bo_table=faq&wr_id=11


https://yangbuk.blogspot.kr/2018/01/windows-ctrl.html

[.Windows] 윈도우 단축키와 실행창 명령어 모음

2010/04/19 07:37
Apr192010

MaruKimm Online/OS, Software windows View Comments


안녕하세요. 마루군입니다.

오늘 끄적일 내용은.
각종 윈도우 단축키 & 실행창 명령어 모음입니다.

이리저리 키보드 가지고 끄적이다 보면.
마우스를 이용하기 위해 손을 움직이는게. 엄청나게 귀찮아지는데요.

조금이나마 마우스를 덜 쓰기 위해.
쓸 수 있는 명령어 들입니다.

Windows Vista / 7 에서는 '시작' 메뉴에.
설정을 검색해서 사용할 수도 있지만.
그래도 명령어를 친다면 신속하게 쓸 수 있겠네요.
물론 Windows XP에서도 잘 쓸 수 있습니다.

하지만, OS에 해당 메뉴 자체가 없다면 실행이 안되겠죠. ^^;;

참고하시길 바랍니다.


  

1. 윈도우 단축키 모음

   



윈도우 단축키

단축키 기능

기타



윈도우 키 + E

윈도우 탐색기 실행

'내 컴퓨터' 와 동일



윈도우 키 + F

윈도우 검색창 실행

'시작 - 검색' 과 동일



윈도우 키 + R

윈도우 실행창 실행

'시작 - 실행' 과 동일



윈도우 키 + D

모든 창 최소화

다시 단축키 누르면 창이 원래대로 돌아옴



윈도우 키 + M

모든 창을 최소화

다시 단축키를 눌러도 창이 최대화되지 않음



윈도우 키 + Shift + M

최소화한 창을 최대화

'윈도우 키 + M' 단축키의 반대 동작



윈도우 키 + L

컴퓨터 잠금

잠금 해제시 사용지 비밀번호 필요



윈도우 키 + Pause/Break

시스템 등록정보 창을 띄움

'시작 - 제어판 - 시스템' 과 동일





   

   

2. 실행창 명령어 모음

   



2.1. 실행창 명령어 사용 방법



'시작-실행' (단축키 : 윈도우즈키 + R )을 하셔서 입력하면 됩니다.

  





   

   



2.2. 실행창 명령어 목록



 

2.2.1. 기본 명령어

   

notepad : 메모장

regedit : 레지스트리 편집기

calc : 계산기

mspaint : 그림판

clipbrd : 클립북 뷰어

cmd : 도스창

dxdiag : 다이렉트X 진단도구

iexplore : 익스플로러

mstsc : 원격 데스크탑

osk : 화상 키보드

winword : MS Office 워드

powerpnt : MS Office 파워포인트

excel : MS Office 엑셀

outlook : MS Office 아웃룩

wordpad : 워드패드

winmine : 지뢰찾기

sndvol : 볼륨조절

rstrui : 시스템 복원

msconfig : 시작프로그램 제어 등 시스템 상태 기초 환경설정

sysedit : 시스템구성편집기 (autoexec.bat , config.sys ,win.ini, system.ini)



 

2.2.2. 제어판 명령어

   

control : 제어판

Access.cpl : 내게 필요한 옵션

appwiz.cpl : 프로그램 추가/제거

bthprops.cpl : 블루투스장치설정

desk.cpl : 디스플레이 등록정보

firewall.cpl : Windows방화벽

hdwwiz.cpl : 새하드웨어추가마법사

inetcpl.cpl : 인터넷등록정보

intl.cpl : 국가및언어옵션

irprops.cpl : 적외선포트 설정

joy.cpl : 게임컨트롤러

main.cpl : 마우스등록정보

mmsys.cpl : 사운드및 오디오장치등록정보

ncpa.cpl : 네트워크연결

netsetup.cpl : 네트워크설정마법사

nusrmgr.cpl : 사용자계정

nwc.cpl : 네트워크 게이트웨이

odbccp32.cpl : ODBC데이터원본 관리자

powercfg.cpl :  전원옵션 등록정보

sysdm.cpl : 시스템등록정보

telephon.cpl : 전화및모뎀 옵션  

timedate.cpl : 날짜 및 시간 등록정보

wscui.cpl : Windows보안센터

wuaucpl.cpl : 자동업데이트

Sapi.cpl : 텍스트 음성 변환설정

control admintools : 관리도구

control folders : 폴더옵션

control userpasswords : 사용자 계정



 

2.2.3. 관리콘솔 명령어

   

certmgr.msc : 인증서

ciadv.msc : 인덱싱서비스

ntmsmgr.msc : 이동식저장소

ntmsoprq.msc : 이동식저장소 운영자 요청

secpol.msc : 로컬보안정책

wmimgmt.msc : WMI(Windows Management Infrastructure)

compmgmt.msc : 컴퓨터 관리

devmgmt.msc : 장치관리자

diskmgmt.msc : 디스크 관리

dfrg.msc : 디스크 조각모음

eventvwr.msc : 이벤트 뷰어

fsmgmt.msc : 공유폴더

gpedit.msc : 로컬 컴퓨터 정책

lusrmgr.msc : 로컬 사용자 및 그룹

perfmon.msc : 성능모니터뷰

rsop.msc : 정책의 결과와 집합

secpol.msc : 로컬 보안설정

services.msc : 서비스

C:\WINDOWS\system32\Com\comexp.msc : 구성요소서비스

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorcfg.msc : .NET Configuration 1.1





   



2.3. Tip



단순 실행 파일이라면 C:\Windows\System32 폴더에 집어 넣으면,

시작 - 실행에 해당 파일 이름을 실행시키는 것으로 편하게 사용할 수 있습니다.

   

ex) Putty.exe 파일을 System32 폴더에 집어넣고. 이런식으로 사용 가능합니다.

  





   

   

   

이상입니다.





마루군

였지요

출처: http://www.moreagile.net/
정말 좋은 포스팅이 많은 곳입니다 꼭 가보세요~

TDD는 벌거벗은 임금님의 투명옷인가? (1) - TDD는 죽었다. 테스트여 영원하라!

지난주 금요일 밤 10시.
StackOverflow를 비롯해 많은 IT커뮤니티를 술렁거리게한 IT업계의 드림매치가 30분간 차분히 이루어졌다.

발단은 Ruby on Rails의 개발자로 유명한 David Heinemeier Hansson(이하 DHH)가 자신의 블로그에 'TDD는 죽었다. 테스트여 영원하라!TDD is dead. Long live testing.'라는 다소 자극적인 제목으로 블로그 포스트를 올린데서 시작되었다.

David Heinemeier Hansson. 덴마크 출신 프로그래머로 Ruby on Rails의 제작자로 알려져 있지만 르망 24에 출전하는등 프로 레이서 로서의 일면도 가지고 있다.(엄친아?) 사진의 포즈는 보통 중딩들이 새로 산 시계를 자랑하고 싶을때 하는 포즈이지만 신경쓰지 말도록 하자.

여기에 XP와 TDD의 창시자인 Kent Beck선생은 RIP TDD 라는 페이스북 포스팅을 통해 DHH의 의견에한 자신의 생각을 밝힌다.

여기에 쌈구경에 재미가 들린 Martin Fowker선생이 멍석을 깔아준다.
바로 구글 플러스를 통해 두사람의 토론을 온라인 생방송 이벤트로 만들어 버린 것이다.
Is TDD dead?

일단 내용이 만만치 않으므로 이번 포스팅은 세 단원으로 나눠서 작성할 예정이다.

  1. TDD는 죽었다. 테스트여 영원하라! - David Heinemeier Hansson의 블로그 번역
  2. TDD여 편히 잠들라 - Kent Beck의 페이스북 번역
  3. TDD는 죽었는가? - DHH, Kent Beck, Martin Fowler의 온라인 토론 이벤트 정리

아직 국내에는 이름이 생소한 DHH이지만 비교적 젊은 나이에도 불구하고 (79년생) 프레임워크에 있어서 Ruby on Rails가 지닌 지위와 영향력을 생각해 본다면 결코 무시할 수 있는 인물이 아니다.

오늘은 첫번째로 DHH의 주장을 담은 블로그의 글을 번역하는것으로 TDD에 대한 논쟁을 시작해 보고자 한다.

TDD는 죽었다. 테스트여 영원하라!

원문: TDD is dead. Long live testing.

테스트 우선Test-first개발 근본주의는 금욕만을 강조한 성교육과 같이 자기혐오를 불러오는 비현실적이자 비효율적인 도덕 캠페인과 같다.

처음시작은 달랐다. 내가 처음 TDD를 접했을때, 그것은 마치 프로그래밍의 신세계가 내 눈앞에서 열리는것 같았다. 그것은 테스트가 없는 세계로부터 테스트를 당연히 여기는 세계로의 의식개혁과도 같은 것 이었다. TDD는 제대로 테스트된 코드가 주는 평온함에 눈을 뜨게 해 주었고, 소프트웨어 변경시에 안정감을 가져다 주었다.

테스트 우선 개발은 자전거의 보조바퀴와도 같은것으로, 테스트를 통해 프로그램을 보다 싶도있게 통찰 하는데 많은 도움이 되었으나 나는 곧 그만두었다.

시간이 흐르면서 테스트 우선이란 슬로건은 점점 더 큰고 격렬한 목소리를 내기 시작했다. 테스트우선 개발을 실행하지 않는것은 죄악시 되었고 나 자신도 그러한 근본주의 소용돌이에 휘말려 들었는데, 그것은 마치 종교적인 금욕주의 가르침을 따라가지 못하는 자신이 부끄러워지는 느낌이었다. 그리하여 나도 테스트 우선 개발을 시험해 보기로 했지만 몇주만에 결국 그만 두었다. 테스트 우선 개발이 내 설계를 망쳐놓기 시작했기 때문이다.

테스트 우선 개발은 마치 광신도의 자부심과도 같이, 오직 교리에 적힌 한구절 한마디를 충실히 지키는 것 만이 천국에 이르는 유일한 길이고, 그대로 하지 않으면 지옥에 떨어진다고 하는 희열과 절망의 요요였다. 그리고 그것을 그만둔 나는 모두 함께 가는 버스에서 혼자만 내린 기분이었다.

아마도 처음에는 자동화된 회귀 테스트 따위는 없어도 된다라고 하는 업계의 관행을 부수기 위한 충격요법으로서 테스트 우선 개발이 필요 했을지도 모른다. 아마도 처음에는 글자 곧이곳대로 일상적으로 수행하는 프로그램 개발에 적용하는것을 의도하지는 않았을지도 모른다. 하지만 어찌되었든 시작을 한다고는 해도 금방 중단되기 일쑤였지만, 불경한자를 단죄하는 헤머와도 같이 TDD를 성실히 행하지 않는것은 프로 소프트웨어 개발자로서의 자격이 없다고 낙인 찍혀 버린다. 이것은 리트머스 테스트이다. (단순한 기준으로 흑백이 구분되어버린다는 뜻:역자주)

이제 충분하다. 그만 두겠다. 나 데이빗은 더이상 테스트 우선 개발을 하지 않는다. 나는 더이상 그것에 대해서 사과하지도 숨기지도 않겠다. 나는 TDD가 회귀 테스트에 눈 뜨게 해 준것에 감사한다. 하지만 더이상 TDD에 끼워 맞춰 프로그램을 설계하지는 않는다.

나는 여러분께 TDD적인 접근이 정말로 당신의 시스템의 완전성과 일관성에 어떠한 영향을 주고 있는가를 진지하게 다시 검토해 보기를 권한다. 만약 이것이 정말 좋은것은 아닐지도 모른다는 가능성을 심각하게 받아들이게 된다면, 당신은 메트릭스에 등장하는 붉은 알약을 먹는것이 될 수도 있다. 그리하여 직면하게된 현실 세계는 당신이 원하던 것이 아닐 수도 있다.

그럼 이제 어디를 향해야 하는 것 인가?

최초의 한걸음은 문제의 존재를 인정하는 것 이다. 여러분도 여기까지는 동의할 것으로 생각한다.  그 다음은 메소드에서 시작해 시스템 전체에 이르는 다양한 범위의 테스트에 대해 균형을 잡는것이다. 지금의 열광적인 TDD열풍은 유닛(메소드) 단위의 테스트에 초점이 맟춰져 있다. 왜냐하면 이름 그대로 유닛테스트의 범위는 유닛에 한정되어 버리기 때문이다. (원래부터 테스트 우선 개발의 근거가 이것이다.)
하지만 나는 이것이 올바르지 않다고 생각한다. 테스트 우선개발의 유닛테스트는 중간적인 오브젝트나 간접적이고 지나치게 복잡한 구조를 낳기 십상이다. 게다가 느려지는것을 피하려고 하다보니 데이터베이스나 I/O관련 테스트도 기피하게 된다. 브라우저를 이용한 시스템 전체의 테스트도 지양하게 되어 버린다. 그 결과, 진정 무서운 괴물과도 같은 프로그램 구조가 탄생하게 된다. 서비스오브젝트라던지 커맨드패턴이 형편없이 얽히고 설킨 정글과도 같은 아키텍쳐 말이다.

나는 전통적인 의미의 유닛테스트는 거의 하지 않는다. 모든 의존관계를 목(Mock)으로 하면, 수천건의 테스트가 수초만에 끝나는 유닛테스트 이지만, 레일즈Rails 어플리케이션의 테스트에 있어서 좋은 방법은 아니라는, 단지 그 이유 한가지이다. 나는 실제레코드를 직접 데이터베이스에 억세스하여 동작시키는 방식으로 테스트를 진행한다. 상위레이어에는 컨트롤러 테스트가 있지만, 나는 어느쪽인가 하면 상위레이어에 대한 시스템 테스트는 Capybara나 이와 비슷한 것을 사용하여 테스트하는 편이다.

나는 이것이 우리가 가야 할 방향이라 생각한다. 유닛테스트의 중요도를 내리고, 설계의 일부로서 테스트 우선 개발을 사용하지 않는것이다. 그리고, 보다 시간이 오래 걸리긴 하지만 시스템 테스트의 중요성을 부각시켜야 한다.(게다가, 클라우드의 등장으로 테스트조차도 클러스터링이 가능해 짐에 따라 더이상 시스템 테스트도 느리지만은 않다.)

Rails는 이러한 전환에 도움이 된다. 오늘, 우리는 풀 시스템 테스트 자동화를 권장하기 위한 아무것도 가지지않고 있다. 정답은 미리 준비되어있지 않다. 단지 실수를 고쳐나갈 뿐이다. 하지만, 여러분은 실수가 일어나기를 기다릴 필요는 없다. 오늘 당장 Capybara를 돌려보라. 그리고 내일이면 좋은 아이디어가 우리들 머리속에 가득할 것이다.

자, 우선은 심호흡을 하자. 우리가 지금 하려는 것은 신성한 암소를 도살하는 것 이다. 고통스럽고 피를 보는 과정이 수반될 것이다. TDD는 이미 성공적으로 많은 프로그래머들의 머리속에 자리잡고 있다. TDD는 그들이 하는 행위가 아닌 그들 자신이 되어버린 것 이다. 그러한 사람들을 원래대로 돌리기 위해서는 커뮤니티를 만들어 진지하게 임하지 않으면 안되고, 시간또한 오래 걸릴 것 이다.

여기서 우리가 선택 할 수 있는 최악의 방법은 또다른 테스트 종교를 만드는 것이다. 이를테면 "시스템 테스트야 말로 진리이다!"와 같은 또다른 황금소의 우상을 만드는것이 눈앞에 선하다. 제발 그러지는 말았으면 한다.

그렇다. 나에게 있어서 테스트 주도 개발은 죽었다. 하지만 그 죽음을 축하하며 무덤앞에서 춤을 춘다던지 단점을 조롱하기 보다는, TDD가 소프트웨어 개발에 가져온 기여에 존경을 표하고자 한다. TDD는 우리들의 역사에 중요한 족적을 남겼다. 그리고 지금은 그 다음을 향해 가야할 시간이다.

테스트여 영원하라!

http://blog.powerumc.kr/

출처: http://blog.powerumc.kr/460


최근 재미있는 글을 봤다. C 언어로 모바일을 위한 API 서버를 만들었는데, 이에 대해 댓글의 토론이 가관이 아니다. 물귀신들이 들러 붙고 난리도 아니다.

  1. 아파치 모듈로 개발된 API 서버, 이음 베이론을 소개합니다.
  2. C언어로 API 서버 개발, 생각보다 나쁘지 않아요

글의 결론은 ‘모바일 API 서버를 C 언어로 만드니 성능이 좋네요’.. 이에 대항하는 물귀신들은 ‘나를 납득시킬만한 근거를 대라’, ‘C언어로 만들었다고 자랑질이냐’ 등등…



모든 사람이 경험도 다르고, 깊이도 다르니 글쓴이야 모든 눈높이에 맞춰 대응하기도 힘들겠다. 그냥 나는 내 생각대로 얘기하자면…

  • 글쓴이가 모바일 API를 C언어로 만든 글은 필자가 보기에 자랑질도 아니고, 이런 사례를 만들었는데 놀랍더라.. 정도인 것 같은데, 글쓴이가 무슨 비윤리적인 짓을 한 것 마냥 댓글러들의 오두방정이 지나치다. C언어로 만들어서 만족한다는 데 왜 주변에서 C로 만들었냐고 오두방정일까… C언어로 만들면 우리나라 박대통의 창조경제에 어긋나기라도 하나?

  • DB 부하가 가장 많은 상태에서 C언어로 API 성능을 극대화 한 것 자체 무용론… 댓글러들은 무슨 ’하드웨어 스팩을 대라..!’는둥, 저렇게 차이가 나는데 ‘프로파일링을 해봤느냐.. 당연히 해봐야 하는거 아닌감?’ 하는 뉘앙스들… 글쓴이가 자기들 따까리도 아니고… 프로파일링 해봤는 지 궁금하면 직접 자바가 왜 느린지 프로파일링 해보는 게 더 빠르지 않을까 생각드는데…

  • C는 시스템 프로그래밍에 적합한 로우레벨, 자바나 트랜드한 스크립트 언어들은 고급언어… 정말 욕 한 바가지 하고 싶다. 정말 지랄 옆차기도 제대로 헛발이다. 초기에 어느 정도 프레임과 API가 정의되면, API 코딩하는 건어느 언어로 하던 그 표현력은 거의 비슷하다. 10줄 짜리 1줄로 표현한다고 생산성이 좋고, 유지보수, 리팩토링까지 좋은 건 아니다. 언젠가 요구 사항으로 인해 1줄 짜리를 10줄로 풀어낼 날이 올거다.

  • C/C++/Objective-C 등 C 계열의 언어로 만들어진 라이브러리가 없다고들 하는데 C 계열의 오픈 소스가 가장 많다. (근거는 직접 찾아보세요) 이제 슬슬 트랜드의 정점을 찌르는 파이썬, 루비, 자바스크립트 등의 스크립트 언어들의 오픈 소스를 다 합쳐도 C 계열을 추월하지 못한다. 물론 댓글러들의 눈높이에 맞는 C 계열 오픈 소스는 그리 많지 않을 뿐이다.

  • 모바일 API 서버에 대한 글이라 웹 개발자만 우루루 죽자고 달라 붙는다. C언어로 만든 API 서버가 자바 서버 10대를 5대로 줄인거면 좋은 성과 아닌가? 100대라면 산술적으로 무료 50대나 줄일 수 있는데도… C언어로 만들면 마치 유지보수 헬게이트라고 하는데, 필자는 JavaScript가 최고의 헬게이트 아닌가 뼈저리게 느낀다.

  • 나는 개발자들이 포지셔닝된 트랜드를 어느 정도 따라갈 수 있으면, 더 이상 죽자살자 트랜드를 쫓지 않길 바란다. 그래봐야 빨리 은퇴하는 길이고, 나이들면 더 할게 없어질거다. 트랜디한 기술은 치고 올라오는 귀염둥이 신입들에게 넘기고… 

    그때가 되어도 귀염둥이들과 트랜디한 기술 가지고 ‘그거 써봤니?’, ‘써보니 어떻드라’, ‘버그 있더라’ 농담 따먹고 놀 순 없지 않는가…?
 
 본격적으로 개발을 하던 시점에서 트랜드는 천천히 따라가고, 점점 그 이전 기술을 공부할 필요가 있다고 본다. 소프트웨어 공학도 공부하고, C 언어, 그리고 어셈블리어, 그리고 운영체제까지… 그럼 댓글러들이 하는 토론보다 더 발전적인 이야기와 비전이 보일거다.


저작자 표시 비영리 동일 조건 변경 허락
Posted by POWERUMC POWERUMC



문서화의 다섯 가지 원칙

이병준 | 2013/12/23 17:35 | Thoughts |  15
댓글 0
SNS로 공유하기더보기

개발자는 대체로 문서 작업을 "오버헤드"로 받아들이는 경향이 있습니다. 품질 관리자 가운데는 이런 경향에 섭섭함을 토로할 분도 계시겠습니다만, 이건 엄연한 사실입니다. 개발자 가운데, 문서를 요구하는 관리자와 언쟁을 벌여본 경험이 없는 사람은 없을 겁니다. 


http://www.challengefuture.org/news/707


개발자에게 한가지 불행한 일은, 누군가는 그렇게 생산된 문서를 본다는 사실입니다. (편의상 문서 소비자라고 해 봅시다.) 그러니 문서화를 완전히 피할 방법은 없지요. 


문서 소비자에게 불행한 일은, 개발자가 생산한 문서 가운데 상당수에 적힌 내용이 실제 소프트웨어와 다르다는 사실입니다. 그런 상황이라면 소프트웨어를 만든 사람의 역량을 의심하게 되는 것도 무리는 아니지요.


이 불행은 무엇에서 비롯된 것일까요? 저는 '가치'에 대한 오해에서 비롯되었다고 봅니다. 개발은 고객에게 반드시 전달되어야 하는 가치를 만드는 행위입니다. 그렇다면 문서는 어떻습니까? 고객에게 보여주어야 하는 문서라면, '문서화'의 목적 또한 '고객에게 가치를 전달하는 것'이 되어야 마땅합니다. 내부 개발자들만이 공유할 문서라면요? 그럴 때는 이야기가 좀 달라집니다. 개발자들만이 볼 문서라면, 개발자들에게 최선의 가치를 전달할 수 있는 형태의 문서가 되어야 맞습니다. 관리자에게 보고할 문서라면요? 관리자들이 개발 진행상황을 쉽게 이해할 수 있도록, 최대한 간략화되고 개조식으로 정리된 문서가 되어야 맞을 겁니다. 그것이 관리자가 요구하는 '문서의 가치'이니까요. (관리자에게 가장 중요한 것은 '의사결정'임을 상기합시다.)


자. 그렇다면 우리는 비교적 쉽게, 문서화를 하는 데 있어 지켜야 할 원칙들을 뽑아낼 수 있을 것 같습니다. 문서화 작업에 있어서 우리가 지켜야 할 원칙들은, 의외로 우리가 개발할 때 지키는 원칙들과 비슷합니다. 


1. 단순성 (Simplicity) - 쓸데 없는 이야기를 하지 않는다. 


문서를 만들 때 중언부언 하지 않습니다. 가치에 반하는 것은 없앱니다. 개발자 내부적으로만 공유할 문서에 참여자들의 사인을 전부 받을 필요는 없습니다. 그런건 이슈 관리 시스템의 동료 검토 기능을 활용하면 됩니다. 개발자들만 볼 문서에 API의 상세 스펙을 넣을 필요는 없습니다. 그런건 JavaDoc에나 넣으면 됩니다.  단순하게 만들면 정보 중복이 줄어들고 관리 비용이 하락합니다. 필요한 내용만 넣고, 쓸데 없는 건 다 빼버리세요. 그런건 누가 요구할 때나 추가해 넣으면 됩니다 (규칙 5 참고).


2. 무결성 (consistency) - 소프트웨어의 실제 상태에 부합한다.


문서는 언제나 소프트웨어의 실제 상태에 부합해야 합니다. 고객이 어떤 사람이건 간에, 실제 상태에 부합하지 않는 문서는 언제나 실패한 문서입니다. 실패한 문서를 만들지 않는 몇 가지 방법이 있습니다. 첫 번째는 필요한 순간에 문서를 만들어 전달하고 해당 문서에 유효기간을 두는 것입니다 (규칙 4 참고). 두 번째는 개발자로 하여금 언제나 문서 창을 열어놓고 시스템을 변경할 때 마다 문서까지 변경하도록 요구하는 것입니다. 세 번째는 개발자가 언제나 주석에 가장 정확한 내용을 반영하도록 권하고, 필요할 때마다 주석에 적힌 내용을 갈무리해 문서를 만드는 것입니다. (세 번째 가이드라인을 따르는 문서가 JavaDoc같은 것입니다.) 


3. 독자 지향 (reader-oriented) - 문서를 읽을 사람을 고려한다. 


문서를 읽을 사람이 용역을 준 갑이라면 클래스 다이어그램이 필요할 것입니다. 그러나 고객이 시스템 사용자라면 클래스 다이어그램까지 그려진 문서를 주는 것은 과도합니다. 그런 경우에는 웹에 '사용자 가이드'와 'API 명세서'만 올려놓으면 충분합니다. 누가 문서의 고객인지를 생각하고, 거기 맞는 문서를 만드세요. 10명도 안되는 팀에서 다섯명 정도의 개발자들만이 돌려볼 문서라면, 아예 문서화를 포기하는 것도 생각해 보세요. 그런 팀에서라면 문서화 보다 잡담을 장려하는 쪽이 훨씬 나을지도 모릅니다. (그 팀의 진정한 목적이, 고객에게 '훌륭한 소프트웨어'라는 가치를 전달하는 것이라면 말이에요.) 


4. 적시성 (timeliness) - 문서가 필요한 시점을 고려한다. 


프로토타이핑이 진행된 결과로 이미 돌아가는 시스템이 있는 상태인데 굳이 설계 문서를 만들어서 클래스 다이어그램을 넣을 필요는 없습니다. 그런 것은 고객의 요구가 없는 한, 쓸데 없는 짓입니다. 문서가 여섯달 뒤에 필요한데, 지금부터 문서를 작성하는 것도 쓸데 없는 짓입니다. 그렇게 되면 문서의 무결성을 확보하기 위해 너무 많은 수고를 들여야 합니다 (규칙 2 참고). 언제 문서가 필요한지를 보고, 그에 맞는 문서화 계획을 세우세요.


5. 요구 지향 (demand-oriented) - 문서에 대한 고객의 요청을 고려한다. 


요청이 있다는 것은 고객이 문서를 통해 얻고자 하는 가치가 있다는 뜻입니다. 고객의 요구를 추정하다보면 문서에 너무 많은 내용을 담게 됩니다. 한 번에 완벽한 문서를 만들기 보다는, 고객의 요구를 받아들여 필요한 문서를 작성하는 것이 바람직합니다. 위키는 이런 용도에 적합한 시스템입니다. 위키에 기록된 사항만 언제나 무결하게 정리해 놓으면, 고객의 요구에 즉시 응답할 수 있습니다. 새로운 요청은 위키에 먼저 반영하여 고객의 반응을 살피고, 고객이 만족할 때 공식 문서로 변환할 수 있습니다. 그러니, 필요하지도 않은 문서를 만드는 데 너무 많은 시간을 쓰지 마세요. 


그리고 이 모든 원칙들이 너무 복잡하다면, 이것만 항상 생각하세요. '이 문서는 고객(문서를 읽을 사람)에게 어떤 가치를 주게 될까?' 이것만 기억한다면, 과도한 문서화의 함성에서 조금은 벗어나게 될 수도 있습니다.


내가 다니는 회사도 어찌보면 딱 저 글에서 말하는 그런 회사니까...


그래도 난 운이 좋아서 제때 월급 나오고 그렇게 말도 안되는 임금을 받는 것도 아닌데다


운이 좋았는지 심각하게 야근을 하거나 주말 출근을 해야 하는 경우도 거의 없었던게 다행이라면 다행...

+ Recent posts