'코드'에 해당되는 글 7건

  1. 2011.09.16 티스토리 스킨 변경후 SyntaxHighlighter 설정하기
  2. 2007.10.13 자주 리펙토링을 하라.(1)
  3. 2007.08.19 테스트 코드.. 우선 개발할 것인가?
  4. 2007.06.12 소스를 모두 다 만들려고 하지 마라.
  5. 2007.06.01 소스코드 버전관리를 활용하라. (2)
  6. 2007.05.21 프로토타입을 통해 학습하라.
  7. 2007.05.16 프로그래머?!?

티스토리 스킨 변경후 SyntaxHighlighter 설정하기

|



오랜만에 스킨을 변경했더니.. 여러가지 설정들이 다 날라가 버렸네요.. 에휴~

그중에서 SyntaxHighlighter를 이용한 소스코드 보여주는 부분이 전부다 이상해져버려서..
해당 설정 다시 하면서 내용 정리해 봅니다.

SyntaxHighlighter의 경우 3.0 버전까지 나와 있는 것 같은데요..
http://alexgorbatchev.com/SyntaxHighlighter/ 

기존 블로그들이 1.5.1 버전으로 되어 있어서 해당 버전으로 정리하도록 하겠습니다.  
설정 측면에서 보면 jQuery 관련된 코드 넣어주는 것 제외하고는 큰 차이는 없습니다.
http://code.google.com/p/syntaxhighlighter/ 

먼저 위 사이트에서 SyntaxhHighlighter 1.5.1 버전을 다운로드 합니다. rar 파일로 압축되어 있네요. 
압축을 풀면 다음과 같은 폴더들이 존재합니다. 



위 내용 중 Scripts 폴더와 Styles 폴더의 내용을 업로드하면 됩니다. 
업로드 위치는 티스토리의 "스킨" 메뉴의 "파일업로드"입니다.



 업로드가 끝나면 "HTML/CSS 편집모드"로 들어가서 먼저 CSS 를 아래와 같이 첨부합니다. 

 

이어서 맨 아래로 내려가 </body> 윗부분에 다음 코드를 추가합니다. 


"저장"을 하고 나면 자유롭게 SyntaxHighliter를 사용할 수 있을 겁니다.
글쓰기에서 적용하는 방법은 다음에 기회되면 다시 올릴께요~

그럼.. 좋은 하루 되세요~ 
 



Trackback 0 And Comment 0

자주 리펙토링을 하라.(1)

|



프로그래머들은 한번쯤 리펙토링이라는 것을 들어봤을 겁니다.
리펙토링이 좋다는 것은 익히 들어 알겠는데 실제로 못하는 경우가 대부분입니다.

왜 그럴까요?

우선, 리펙토링이 무엇이고 어떻게 하는 것인지 모르기 때문인 것 같습니다.
솔직히 저도 리펙토링 관련 책을 이번에 읽어보기는 했지만,
아직도 어떤 경우에 리펙토링을 해야 하는지 느낌이 확 오지는 않습니다. -.-

A->B로 변경하는 것이 설명되어 있으면, 바로 B->A로 바꾸는 것도 설명되어 있습니다.
즉, 경우에 따라 적용하는 리펙토링이 다르다는 것인데.. 이건 경험이 필요한 것 같습니다.~
끊임없이 생각해보고 변경하다보면 어떤 것이 올바른 리펙토링인지 알수 있지 않을까 합니다.

다음으로는 리펙토링을 하고 있으면, 윗분들은  아무것도 하지 않고 있다고 생각하는 경우가 많을 것 같습니다.
열심히 뭔가 코드를 고치고는 있는데, 프로그램 결과물이 바뀐게 없으니까요..
리펙토링은 기능개선이나 디버깅과 달리 프로그램을 현재 상태 그대로 두고 소스코드만 이해하기 쉽게 바꾸는 것이니까요..

하지만 이 작업의 중요성을 충분히 설명해 주어야 한다고 생각합니다.
프로젝트가 대규모가 될수록.. 추후 유지보수를 위해서도 리펙토링은 반드시 필요하거든요.

방법론에 따른 산출물이 있지 않느냐? 하고 반문할 수도 있지만..
글쎄요~~ 산출물은 끊임없이 바뀌는 프로그램을 모두 반영할 수 있을지 솔직히 의문이거든요
특히, 산출물에 기반하는 개발이 아닌, 개발후 형식적으로 만드는 산출물은 더욱 문제겠지요..
리펙토링을 통해 소스 자체가 훌륭한 산출물이 된다면 더할 나위 없지 않을까 합니다. ^^

사용자 삽입 이미지



마틴파울러(Martin Fowler)의 다음 이야기가 떠오르네요..
"컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다."
그렇다면, 리펙토링은 언제 해야 할까요?
자주.. 생각날 때마다 하는 것이 따로 일정을 잡아서 하는 것보다는 수월하다고 하네요..

그리고 리펙토링을 하려면 잘못됐을 때 소스를 이전 버전을 바꿀 수 있는 버전관리와..
현재 프로그램 전체를 테스트할 수 있는 테스트코드 또한 중요한 요소라고 합니다.

리펙토링을 통해서 잘 디자인된 소스코드를 만드시기 바랍니다.




Trackback 0 And Comment 0

테스트 코드.. 우선 개발할 것인가?

|



요즘 테스트 코드와 관련해서...

테스트 코드를 먼저 만들고 난 후, 코딩을 진행하는 것이 좋다...
또는 프로그래밍 코딩을 하면, 테스트 코드를 만들어 확인해야 한다..
리펙토링을 하기 전에는 반드시 테스트 코드가 있어야 한다..

라는 이야기를 많이 합니다.
 
테스트 코드라는 것이 매우 중요한 개념이라는 것은 많이 들어서 알 것 같습니다.
그런데.. 실천이 매우 어렵다는 것을 한번 느낀 적이 있어 글을 써봅니다.
 
최근 프로젝트에서 JUnit이라는 테스트 프레임워크와
Ant 툴을 이용해서 프로젝트에서 테스트 프로그램을 구성해 보았습니다.

흔히 말하듯 빌드 한방에 테스트가 완료되구요..
테스트 전후의 데이터도 변화가 없게 만들고...
나름 머리써가면서 잘 만들어 놨었죠~~

하지만, 테스트 구현에 있어 약간의 한계가 있었는데요..

첫째로, 테스트 코드를 만든 사람과 실제 프로그램 소스를 구현하는 사람이 달랐다는 점입니다.
팀원간의 소스코드에 대한 이해도 높인다는 (실은 프로젝트 관리자로서 개발자들의 코드를 살펴본다는 의미가 더 강했죠.. -.-) 명목하에 그렇게 구성했었죠..
그러다 보니.. 소스 코드가 명세 변경에 바뀌어 갈 때마다 테스트 코드도 업버전 되어야 하는데. 그렇게 되지 못했다는 겁니다.
결국 나중에는 테스트 코드는 쓰레기 코드가 되어 버려지게 되었죠.. -.-
(이 점이 아쉬웠는데요... 테스트 코드를 계속 발달시켜야 하는데.. 프로젝트 중간에 그러기가 어려웠거든요.)

둘째로, 테스트 프로그램이 모든 소스 코드를 커버해 주면 좋겠지만...
웹에서 받아들이는 부분은 일단 커버를 못해줬다는 점입니다.
Junit에 살펴보면 request, response를 가상으로 제어하는 부분이 있기는 하지만,
거기까지 적용하기는 복잡해서.. 내부 프레임워크에서 비즈니스 로직을 처리하는 부분부터만 테스트 코드를 적용한 거죠..
(이 부분은 이렇게 하는게 오히려 단순해 지기 때문에 테스트 구현에 도움이 되기는 하지만, 전체 프로젝트를 커버할 수없다는 단점도 있는 것 같더라구요.. )

어쨌든 처음으로 테스트 코드를 만들어 프로젝트에 넣어보았지만, 일단 성공하지는 못한 것 같습니다.
다음에는 테스트 코드를 먼저 만들고 코딩을 진행하는 방법도 한번 시도해 보려고 합니다.

혹시 이 부분에 대해서 좋은 경험 가진 분들의 댓글 부탁드립니다.
그럼.. 좋은 일요일 저녁 되세요~~




Trackback 0 And Comment 0

소스를 모두 다 만들려고 하지 마라.

|



요즘~ 필요하다고 생각하는 소스는 공개되어 있는 것도 많고
또.. 컴포넌트 단위로 저렴하게 구입할 수 있는 것도 많습니다.

그러므로 모든 소스를 직접 구현하겠다는 생각은 굉장히 위험한 것이라고 생각합니다.
비록 프로그래밍 코딩에 자신도 있고, 알고리즘 구현도 잘 한다고 할지라도
이미 만들어진 것을 구현하는데 들어갈 노력을...
더 나은 사용자 환경 구축이나 최적화 등에 힘쓰는 것이 바람직 하다고 생각합니다.

더 나아가 본인 스스로나 팀 내부에서 작성한 소스들도 재사용이 가능하도록 정리하려는 노력이 필요합니다.
경우에 따라, 같은 프로젝트에 동일한 일을 하는 소스가 여러군데 존재하기도 하더라구요~
그러한 경우를 막기 위해서 재사용하기 쉽게 만들어야 합니다.
팀 프로젝트에서 소스 코드의 중복이야말로 추후 문제 해결을 어렵게 만드는 원인이 되기도 하니까요~

참고로 스마트플레이스에 올라온 소프트웨어 개발자를 위한 컴포넌트 판매 사이트 글을 보니,
예전에 많이 보던 컴포넌트 판매 사이트들이 나오더군요..

component source.. 오랜만에 들어보는 이름이네요. ^^
공개된 소스로는 코드그루코드프로젝트 등이 유명했었죠..




Trackback 0 And Comment 0

소스코드 버전관리를 활용하라.

|



프로젝트의 규모가 점점 커지면서, 소스코드의 버전관리가 중요한 요소로 자리잡아 가고 있습니다.

혼자서 단독으로 프로그래밍을 하던 시기에는 백업 파일만 잘 보관하면 됐지.. 버전관리가 왜 필요할까? 하고 생각했던 것이 사실입니다.
하지만, 협업을 하게 되면서.. 단순히 백업만 가지고서는 발생할 수 있는 문제점들을 해결하는데 어려움이 있게 됩니다.

소스코드를 누가 변경한 것인가?
현재 소스와 이전 소스의 차이점은 무엇인가?
현재 소스를 릴리스(release)에 어떻게 반영할 것인가?
동시에 동일 파일에 대한 변경이 발생할 경우, 충돌을 어떻게 해결할 것인가?

단순한 백업에서는 해결하지 못했던 것을 소스코드 버전관리를 통해서 처리할 수 있게 되는 것입니다.

그래서 어떤 프로젝트를 막론하고.. 심지어 프로토타입이라 할지라도 소스코드 관리를 활용하는 것이 바람직하다고 생각합니다.

이런 소스코드 버전관리 프로그램으로는 CVS, Subversion, SourceSafe 등이 있습니다.
제 경우에는 CVS를 주로 사용하고 있는데요.. VC++ 프로젝트의 경우에는 SourceSafe를 사용하기도 합니다.

기본적인 소스코드 버전관리 프로그램의 특성들은 비슷하니..
한가지를 기본적으로 잘 익혀 두시면 다른 것들도 파악하는데 어려움은 없지 않을까 생각합니다.
(CVS와 Subversion의 차이 설명 : http://www.word.pe.kr/bbs/view.php?id=term&no=5)

추가적으로 CVS와 함께 ANT와 같은 툴도 병행해서 사용하기도 합니다.
기본적으로 주어진 툴을 잘 활용해서.. 노가다하는 시간을 줄이는 것도 훌륭한 프로젝트 관리의 하나가 아닐까 합니다.

CVS에 대한 설명은 다음 사이트를 참고하시기 바랍니다.

CVS를 이용한 프로젝트관리 : http://joinc.co.kr/modules.php?name=News&file=article&sid=60
CVS 이야기 : http://kldp.org/KoreanDoc/html/CVS-KLDP/index.html
CVS 사용 : http://kldp.org/KoreanDoc/html/CVS_Tutorial-KLDP/






Trackback 0 And Comment 2

프로토타입을 통해 학습하라.

|



실제로 프로젝트를 진행할 때, 프로토타입을 만든다는 이야기를 많이 합니다.
이런 프로토타입(prototype)의 사전적인 의미를 살펴보도록 하죠.

prototype  [출처 : 네이버영어사전]
━ n.
1 원형(原型)(archetype);견본, 전형;(후대 사물의) 선조, 원조(元祖)
   the prototype of a character (소설에서) 인물의 원형
2【생물】 원형(原形)
━ vt. …의 원형[견본]을 만들다

원형이나 견본이라는 의미로 주로 사용되고 있는데요..
프로그래밍에서는 언제 프로토타입(원형, 견본)을 만들어야 할까요?
당연히 이미 해봤던 것이나, 전체적인 로직과 흐름을 잘 알고 있으며, 구현이 가능한 것에 대해서는 프로토타입이 필요 없을 것입니다.
처음 시도해 보는, 이 기능이 구현될지 안될지.. 의심스러운 부분에 대해서 프로토타이핑을 해야 하지 않을까 합니다.

실용주의프로그래머란 책에서 다음과 같이 이야기 하고 있습니다.

프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고,
여러분이 배운 교훈에 있다.

몇몇 고객들이 잘못 이해하고 있는 것 중의 하나가
프로토타입이 완성되면 기능 구현이 완료되었다고 생각하는 경향이 있습니다.
물론 프로토타입이 제대로 만들어졌다면, 실제 구현에 있어서 개발속도나 기술구현에 큰 어려움은 없을 것입니다.

하지만, 위에서 이야기 했듯이 프로토타입의 가치는 학습에 있으므로…
프로토타입의 완료가 해당 기능의 완성이라고 보기에는 무리가 있다는 것이죠.
고객들에게 프로토타입에서 만들어진 코드는 폐기할 것이고, 불완전하며 완성할 수 없다는 사실을 분명히 주지시켜야 합니다.

또한 프로토타입에서 가장 중요한 요소는 바로 스피드라고 생각합니다.
물론 프로젝트 규모에 따라 다르겠지만 너무 오래 걸리는 프로토타입은 좀 생각해 봐야겠죠~~
최대한 빠르게 구현하고, 실제 필요한 기능들을 습득하는 것이 프로토타입이라고 생각합니다.

어쨌든 개발자에게 있어 프로토타입이라는 것은 매우 중요합니다.
실제 구현할 기능을 테스트해 보기도 하고~
새로운 기술을 배울 수 있으며..
향후 보다 안정된 프로젝트 진행을 할 수 있기 때문입니다.

다음은 프로토타입을 만들 때 무시해도 좋은 세부사항이라고 합니다.

Correctness : 적절한 Dummy Data의 사용
Completeness : 제한된 기능만을 사용
Robustness : 불완전할 수 있음
Style : 코드에 주석등이 필요하지 않음 (그러나 학습한 내용을 따로 문서화 하는 것은 의미가 있다고 봅니다.)

윗 부분에서는 개발과 관련된 부분의 프로토타입에 대해 이야기 했습니다만,
좀 더 내공을 키워 아키텍처 프로토타입까지 나아간다면
어떤 프로젝트의 진행에 있어서도 자신감을 가질 수 있지 않을까 생각합니다.

 




Trackback 0 And Comment 0

프로그래머?!?

|



  마틴파울러는 이렇게 말했습니다.
컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

워드 커닝햄은 다음과 같이 이야기했습니다.

저는 작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다. 누군가가 똑같거나 혹은 더 나은 걸 이미 만들었다는 데에 절대 신경쓰지 마세요. 유용성과 복잡성 간의 균형 감각을 얻기 위해서는 당신 자신이 만든 프로그램의 유용성을 직접 느껴봐야만 합니다.

둘 다 매우 감동적인 이야기입니다. 정말 부럽기도 하구요~~
그러나 IT 개발자의 현실은 그렇게 여유롭지만은 못한 것 같습니다.

몇주전 블로고스피어에 올라왔던 아메바님의 그림일기를 보면 아주 적나라하죠.. ^^

사용자 삽입 이미지


이런 현실을 벗어나 즐겁게 일하면서 사람이 이해할 수 있는 코드를 만드는 방법을 함께 고민해 보도록 하겠습니다.

그래서 모두 불쌍한 개발자가 아닌 생명력이 있는 프로그램을 만드는 창조자가 되시기 바라겠습니다. ^^

# 참고할 만한 글:
김창준님의 “프로그래머의 위기지학
신영진님의 “Why Programming is Fun
미니님의 “Refactoring - 마틴파울러






Trackback 0 And Comment 0
prev | 1 | next