태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Search results for '프로젝트/구현'

  1. 2012.10.29 -- 절대 코딩하지 마라 (12)
  2. 2011.09.09 -- 주석을 달기 어려운 이유 (9)
  3. 2009.07.31 -- Copy & Paste의 종말 (12)

절대 코딩하지 마라

2012.10.29 06:21 by 전규현


잠시 후 Google blogger로 이동됩니다.






"코딩은 늦게 할수록 프로젝트가 빨리 끝난다."


대부분의 개발자들은 이 말을 제대로 이해하지 못한다. 그래서 프로젝트 일정이 촉박하면 무조건 코딩부터 시작하곤 한다. 코딩을 빨리 시작하면 프로젝트가 빨리 끝날 것으로 믿곤 한다. 말은 그렇게 하지 않더라도 일정이 부족하면 문서 작성할 시간도 없고 무조건 코딩부터 시작한다.


물론 프로젝트에 따라서 대충해도 되는 경우가 많다. 그런 프로젝트를 예로 들어서 모든 프로젝트에 확대 적용하지는 말자. 즉, 개집은 어떻게 만들어도 다 되는 것이다. 


코딩 시작은 빨리 시작할수록 재작업은 급속히 늘어난다. 코딩을 최대한 뒤로 늦춤으로써 재작업 가능성을 낮춘다. 물론 스펙이 완전히 끝나야 코딩을 시작할 수 있는 것은 아니다. 스펙을 합리적으로 작성하는 요령 중 하나가 미리 확정할 수 있는 라이브러리나 Sub system들은 인터페이스를 미리 확정하고 코딩을 먼저 시작할 수 있다.


보통 프로젝트에서 분석을 해보면 코딩부터 할 수 없다는 것을 알게 된다. 코딩부터 시작하는 경우는 무엇을 개발할지도 모르고 코딩을 시작하는 것이다. 그렇게 미리 작성된 코드는 스펙이 정해지면 버리고 다시 짜야 하는 경우가 많다. 아키텍처에 요구사항이 제대로 반영되지 않는다. 그럼에도 미리 코딩을 해 놓으면 코드를 버리기가 아까워서 그냥 사용하게 된다. 그러다보면 아키텍처는 엉망이 된다.


개발자들은 자신이 작성한 코드를 살리기 위해서 요구사항을 거부하기도 하고 코드에 꼼수를 부리기도 한다. 


가끔은 코딩만하기에도 정말 일정이 부족한 프로젝트들이 있다. 이런 경우도 코딩부터 한다고 프로젝트가 빨리 끝나는 것은 아니다. 무모한 시도를 하는 것이다. 스펙을 작성할 시간도 없는 프로젝트는 안하는 것이 낫다. 그렇다고 회사에서 프로젝트를 거부할 수는 없다. 최대한 빨리 스펙을 써서 합리적으로 가능한 일정와 범위를 제시하는 것이 더 좋은 방법이다.


일정이 촉박하다고 매번 코딩부터 시작하면 10년을 개발해도 별로 나아지는 것이 없을 것이다.









저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/구현

  1. 좋은 글. 모든 일(Task)이 그렇듯이 고민을 충분히 해서 세를 짠 후에 한 번에 몰아붙여 끝내는 것이 효율적이라고 생각됩니다.

  2. @beomjinkim 블로그에 LiveRe 붙였어요. ^^ 좋죠?

  3. @beomjinkim 다 좋은데 Tistory 기존 댓글들을 포기할 수 없어서 지금은 기존 댓글과 중복해서 사용하게 되네요.

  4. 항상 손이 먼저나가서 문제
    참을수 없는 가벼움

  5. LiveRe 붙이고 좋아진 것 같긴 한데 LiKE 버튼이 없어졌네요! 아님 제가 못찾고 있는걸까요?

  6. 없어졌네요. - -; 다시 추가했습니다.

  7. 공감합니다. 저도 경력이 늘수록 코딩시작하는데 신중해지더군요. 나중에 고생하지 않으려고.
    비록 혼자 보게되더라도 간단하게 나마 문서작성해서 다 맞춰놓고 하는게 제일 좋더군요.

  8. 그렇다면 TDD 방법론에 대해서는 어떻게 생각하시나요?

  9. 안녕하세요. 윈플님

    개발적인 방법론을 보면 잘못된 것이 하나도 없습니다. TDD방법론도 마찬가지입니다. TDD방법론은 분석단계를 강화하는 아주 좋은 수단입니다. 그렇다고 모든 프로젝트에 TDD방법론을 쓰는 것이 좋은 것은 아닙니다.

    스펙을 적는 방법은 매우 다양합니다. 특히 기능을 적을 때는 어떤 형식으로 적으라는 규칙이 없습니다. TDD도 그 방법 중 하나입니다. 단계별로도 한번에 다 적을 수도 있고 차츰 발전시켜나갈 수도 있고 가장 효과적인 방법은 경험이 많은 개발자가 프로젝트의 성격에 맞게 판단하면 됩니다.

    무슨 방법은 옳고 뭐는 잘못됐다고 기법이나 방법을 가지고 얘기하는 것은 위험합니다.

    원칙 중 하나는 이 모든 고민은 소프트웨어를 어떻게 빨리 개발할지에서 출발하는 것이고 그러기 위해서는 대부분의 소프트웨어는 바로 코딩에 들어가는 것보다는 스펙을 적절하게 적는 것이 좋다는 겁니다. TDD도 그 한 방법입니다.

  10. 만족할때 까지 생각만 하면 아무것도 안되는 것 같고, 또 나름 고심했다고 막상 코딩하면 미처 고려치 못한 부분이 생기고, 설계와 코딩의 경계점을 잡기가 참 어려운것 같습니다.

  11. 내용을 보면 분석과 설계의 경계를 구분하기 어려운 것 같군요. 코딩은 분석, 설계 어느 단계라도 필요한 부분은 미리 해 놓을 수도 있습니다. 분석은 충분히 다 되었다고 확신하는 것도 어렵고, 필요한 만큼 적당히 해야 하는데 적당히가 가장 어렵습니다.

    그래서 설계는 예술이라는 말이 나오나 봅니다.

  12. Blog Icon
    한이터

    코딩을 늦게 하면 개발기간이 단축될수도 있지만
    한국의 경우 NEXT 프로젝트에서 코딩시작하기 전기간이 삭제된채로 주어집니다.
    그리고 요즘 대부분의 프로젝트에서 설계분석기간은 처음부터 삭제되고
    개발(코딩)시작 부터 합니다.

주석을 달기 어려운 이유

2011.09.09 11:51 by 전규현


잠시 후 Google blogger로 이동됩니다.






코딩을 하면서 주석을 적절히 잘 달아야 한다는데는 이견이 없을 것이다. 하지만 현실은 주석이 제대로 달린 코드를 찾아보기 어렵다.

"주석이 제대로 달렸다"의 애매한 기준을 명확하게 정리해보면 다음과 같습니다.
  • 과도한 주석은 나쁘다. 비용이 너무 많이 들어간다.
  • 소스코드를 활용하고 유지보수하는데 어려움이 없어야 한다.
  • 업데이트가 되어서 소스코드와 일치되어야 한다. 
  • 전체적으로 일관된 표준을 지켜야 한다.  
주석하나 없이 깨끗한 소스코드나 있어도 소용없는 주석은 개발에 보통 어려움이 있는 것이 아니다. 약간의 시간을 투자해서 주석을 달게 되면 투자대비 몇배의 효과를 볼 수 있다.

그럼 가장 효과적으로 주석을 다는 방법에 대해서 알아보자.

회사의 주석 표준을 정한다.

Doxygen이나 Javadoc등의 표준 주석 Notation을 따르면 여러 툴의 많은 도움을 받을 수 있고 가독성이 높아진다. 신입사원이 들어와도 널리 알려진 표준이므로 쉽게 따라할 수 있게 된다.

주석은 소스코드보다 먼저다.

주석은 코딩하면서 짬짬히 다는 것이 아니다. 코딩 이전에 설계 시 Public function을 정의하면서 주석을 먼저 작성한다. 이렇게 설계를 해서 완벽할 때 구현(코딩)에 들어가면 된다.
코딩을 하면서 Public interface가 자주 바뀌면 주석도 바꾸기 매우 귀찮아지게 된다.
하위 설계는 코드와 주석을 적당히 이용하게 되면 문서로 작성할 필요가 없이 대부분 소스코드로 작성할 수 있다.

Public function 위주로 주석을 단다.

모든 소스코드에 주석을 달아야 한다고 하면 헬스클럽 1년 끊어 놓고 일주일 운동하고 포기하는 사태가 발생하게 된다. 당장 바쁜데 언제 시간을 내서 주석을 달 수 있겠는가? 
Public function은 다른 개발자들이 가장 빈번하게 참조를 해야 할 함수들이다. 같은 시간에 주석을 달아서 가장 효율성이 높다.
하지만 모든 함수가 Public function이라면 효과도 없고 프로그램은 뒤죽박죽이 된다. 미리 Public function을 정하게 되면 최소화를 할 수 있다. 가능하면 거의 모든 함수를 속으로 숨기고 밖으로 최소한의 Interface만 open할 경우 프로그램도 간결하게 되고 유지보수도 쉬워진다. 
Doxygen이나 JavaDoc을 이용하면 API 메뉴얼이 근사하게 나오게 된다. 이 문서만 봐도 개발자들이 개발하는데 대단히 큰 도움을 준다.
이는 소스코드와 주석/설계문서를 지속적으로 일치 시키는데 지대한 도움을 준다.

주석같은 소스코드가 좋다.

복잡한 소스코드를 작성하고 주석으로 설명하는 것보다는 약간 효율이 떨어져도 가독성 높게 소스코드를 풀어서 쓰는 것이 좋다. 따라서 함수의 크기는 작게 유지하면서 읽어 내려가기 쉽게 작성하는 것이 좋다.
성능에 목숨거는 알고리즘을 개발하는 것이 아니라면 가독성 높은 소스코드를 작성하는 것을 높은 우선순위로 두는 것이 좋다. 왜냐하면 소스코드는 개발비보다 유지보수비가 몇배 더 들기 때문이다.

Prototyping 시에는 주석이 필요없다.

Prototyping한 소스코드는 버려야 한다. Prototype은 주석도 없고 에러처리도 안하고 가장 빠르게 검증을 해보는 것이다. 제품화 할 코드는 이것보다 몇배의 시간이 더 걸린다. 따라서 Prototyping을 한 소스코드는 꼭 버리고 제대로 설계를 해서 다시 만들어야 한다. 단, 참조는 가능하다.

처음에는 강제화가 필요하다.

강제화를 위해서는 리뷰가 필수이다. 코드 리뷰보다는 설계 리뷰가 중요하다. 설계 단계에서 대부분의 Public interface의 주석을 미리 완성하고 코딩에 들어가면 협업도 원활하고 재작업도 줄어든다. 그리고나서 코딩단계에서의 주석은 크게 강조하지 않아도 될 것이다.
규칙으로 무조건 주석을 달라고 강제하는 것보다는 정공법으로 분석/설계 리뷰를 통해서 설계가 끝났을 때 주석이 이미 달린 소스코드 헤더가 나오는 것이 좋다.


무조건 코딩부터 달려드는 것보다는 한번 더 생각해보고 Public interface를 먼저 정의하고 주석을 작성해서 리뷰하고 코딩을 하는 것이 전체 개발시간을 현저하게 단축 시켜준다. 시간이 없어서 주석도 없는 코딩만 마구 해대는 것은 핑계에 불과하다. 

효과적으로 주석을 다는 습관을 가지고 있다면 여러 동료들에게 사랑을 받고 후배들의 존경을 받을 것이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by 
the|G|™

 
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/구현 주석, 코딩

  1. Blog Icon
    popopome

    사랑과 존경을 받는 주석이 맘에 와닿네요. *^^*

    제 경우에는 주석 = 종교와 동일한 방식의 자세가
    중요 포인트입니다.

    대게 모든 함수와 모듈에는 주석을 달아야하고,
    로직 코드 내의 주석은 why에 focus를 하는 것이
    여러모로 편하더군요.

  2. popopome님 반갑습니다.

  3. 후배와 동료의 사랑보다 발뺴기가 편하려고 주석을 달아 놓습니다 ㅋㅋ

  4. 구차니님 안녕하세요.
    발 못빼게 하려고 주석 안다는 사람도 많습니다.
    자기 아니면 다른 사람은 잘 못하게 만들어 놓은 것을 파워라고 생각하는 사람들이죠.
    한마디로 물귀신이죠. ^^

  5. Blog Icon
    한금이

    주석 이전에 코드에 대한 정리가 먼저 일듯 합니다.
    주석이 없는 코드로 주석을 대신할 수 있을정도로 코드에 대한 가독성을 높이는 것이 먼저일듯 하구요.

    그 다음이 주석인데... 사실은 주석을 이렇게 저렇게 달아라 하는것은 자치하면 습관성이 될수 있으므로,
    코드를 작성하는 것처럼 주석을 작성하는 연습과 교육이 필요할듯 합니다.

  6. Blog Icon
    황석주

    저는 개발자가 아니지만 주석은 개발자의 발자취라고 생각되며, 또한 주석 한줄한줄이 소스 못지 않은 자산이라고 생각됩니다.


    잘 지내시죠? 뵙고 싶습니다.

  7. 황차장님 오랫만입니다.
    잘 계시죠? ^^ 조만간에 또 뵐날이 오겠죠.

  8. 저는 주석을 소설처럼 다는 스타일입니다 ㅡ.-;

    지금 까지 딱3분 빼고 다들 좋아하셨죠.
    어쩌면 그만큼 개발자들이 주석달기를 싫어하는 걸 반영하는 걸지도 모르겠습니다.

    유지보수해보면 주석 재대로 달린경우를 거의 못본것 같습니다-_-;
    이름만 들어도 알만한 회사들 조차 말이죠.

    그나마 요즘은 많은 회사들이 퍼블릭펑션에 대한 주석은 강제하는것 같습니다.
    (퍼블릭펑션은 시키지 않아도 주석다는 센스는 개발자의 센스라고 생각하지만 말이죠 ㅎㅎㅎ)

  9. 안녕하세요. 당근천국님.

    Public function을 제대로 구분해서 쓰지 않는 개발자도 수두룩합니다. ^^

    public function에 Doxygen으로 주석을 달면 더 좋죠.

Copy & Paste의 종말

2009.07.31 23:53 by 전규현


잠시 후 Google blogger로 이동됩니다.




직업상 다른 개발자들이 작성해 놓은 코드를 볼 기회가 정말 많습니다.
그러다보면 자주 접하는 것이 복사된 코드들입니다. 

소소코드 Copy & Paste는 개발자의 대단히 큰 잘못입니다. 즉, 소스코드를 복사해 놓는 것은 쉽지만 그로 인해서 지속적으로 회사와 후배들이 부담을 져야 하기 때문입니다. 즉, 회사의 생산성을 갉아 먹는 행동입니다. 그런 개발자는 해고가 되어야 마땅하지요.

한쪽 제품이나 컴포넌트에서 사용한 함수나 소스코드들을 복사해 와서 다른 제품이나 컴포넌트에서 사용하는 것입니다. 동일하게 그대로 사용하는 경우도 있고, 약간 수정해서 사용하는 경우도 있습니다.

이런 일이 반복되다보면 비슷한 코드들이 회사의 전체 소스코드 중에서 여기 저기 산재하게 됩니다. 그러다가 버그가 발생하는 그중 일부는 고쳐지고, 일부는 여전히 버그를 가지고 있습니다. 또 해당 기능이 변경이 될 때도 이를 모두 찾아서 변경하기란 쉬운 일이 아닙니다. 이쯤 되면 개발은 창의적인 작업이 아닌 점점 노동이 되어 갑니다.

이런 공통적인 소스코드들은 공통모듈을 잘 계획해서 공통적으로 사용할 수 있어야 합니다. 공통모듈은 전사적으로 관리가 되어서 효율적으로 사용할 수 있도록 해야 하며, Copy & Paste의 욕구가 생겨도 시간을 약간 더 들여서 공통모듈화 하는 노력을 들이는 것이 필요합니다.

공통모듈을 관리하려면 당연히 소스코드관리시스템을 잘 사용해야 하고, 각 제품이나 컴포넌트들이 공통모듈들과 더불어 효과적으로 빌드가 가능하도록 빌드 스크립트도 준비가 되어야 합니다.

Peer review, code review가 정착되어서 다른 팀에서 서로 모르고 중복된 작업을 하는 것을 줄여야 합니다.

또, 특정 고객을 위한 커스트마이즈된 제품을 만들 때 대규모 소스코드 복사가 일어나는데, 이를 통제없이 만들고 방치하면 함수 몇개 복사한 것과는 비교도 안되는 큰 비용을 치뤄야 합니다. 물론 상황에 따라서 다르기는 하지만, 이런 경우에는 가능하면 소스코드 브랜치를 줄이고 브랜치를 만들더라도 소스코드관리시스템을 이용하여 잘 관리를 해야 합니다. 그리고 추후 Merge를 통해서 브랜치의 수명 주기를 짧게 가져갈 필요가 있습니다.

여기저기 복사된 쌍둥이 소스코드들... 참 문제가 아닐 수 없습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/구현 개발자, 구현, 복사, 소스코드

  1. 제가 생각하는 copy&paste의 문제는 이해부족에서 온다고 생각합니다.

    체계적으로, 기존에 다른 사람이 작성한 코드를 분석하지 못했기때문에,
    (이유는 여러가지가 있겠죠? 실력부족, 문서화안됨, 스파게티코드, 시간부족 등)
    기존에 잘 돌던코드는 그대로 두고 플러스 알파만 내가 했다... 뭐 이런거 아닐까요?

    또 비슷한 측면에서,
    자신이 작업하던 코드의 경우에도, 설계가 세밀하게 진행되지 않은 상태에서,
    일단 만들어보면서 얼기설기 작업해나가다 보면,
    적절한 타이밍에 리팩토링 시기를 놓쳐버린 상태가 되는 경우가 있습니다.

    시간비용 + 귀차니즘 때문에, Copy&Paste로 떡칠이 되기 시작하는 거죠.


    마지막으로는 코딩스타일에서 올 수 있겠네요.
    현재 제가 주로 작업하는 분야가 C언어를 사용한 임베디드 분야 (wipi등)쪽 인데,
    판단문과 분기문이 수도 없이 떡칠되기 시작하면서, 소스가 주렁주렁 ㅎㅎㅎ

    state머신이나 적절한(펑션포인터등 사용) 분기체계가 아닌,
    switch-case, if-else 등으로 관성이 붙어버리는 거죠.

    이상태에서 상용으로 소스는 릴리즈나가고 -_-;;;;;
    대형 리팩토링 했다가는(이것도 안습) 되던 소스도 망가지고,
    고객사에서는 최대한 손대지 말고 요거 하나만 고쳐달라고 하죠.

    저희는 견디다 못해서....
    고객사에서 version 2 만들자고 할때, 그쪽 목적은 기능개선, UI개편이었는데,
    저희내부에서 아키텍처 부터 다시 잡아서 첨부터 다시 만들었습니다.

    후우... 그나마 이제는 좀 살만해졌네요.

    며칠전부터, 이 블로그를 처음부터 정주행하고 있는데,
    오늘 정주행 완료하고 나니까, 현실적으로 와 닿는 얘기들이 왜이리 많은지요 ㅠㅠ

    계속 분발해야겠습니다.

    현실적 고민이 뭍어나오는 좋은 글들 감사합니다.

    p.s. 3일에 걸쳐 블로그글을 다 읽고 났더니.. 진작에 신경쓸걸 하는 울컥한 마음에, 댓글이 횡설수설 합니다. 양해부탁드립니다.

  2. 하늘이아빠님 안녕하세요.
    장문의 댓글을 남기셨네요.^^
    결국은 "조삼모사"죠. 그런데, 아침에 4개 먹기를 원하는 개발자나 경영자가 너무 많죠. 아침에 4개 먹으면 저녁때 3개가 아니고 1개 먹기도 어려운 것이 현실입니다. 아침에 3개만 먹으면 저녁에 4개 아니고 7,8개를 먹을 수도 있습니다.

  3. 확실히 와닿네요!! 고객사별로 소스가 따로 노는데 그 소스 통채로 복사해와서 붙여넣고 다른 고객사 나갈 때 커스터마이징한 소스도 그대로 붙어서 나가지요~ 보고 있으면 숨이 꽉꽉 막힙니다~

  4. 두렁청해님 안녕하세요.
    고객사별로 소스가 따로 노는 회사는 어느 순간 성장의 한계에 부딪히게 됩니다. 그 순간이 오면 이미 되돌릴 수 없는 상태가 된 겁니다.

  5. 몇개 부분에서 리팩터링을 해야할 필요성을 느낌에도 불구하고
    계속 일에 치여서 다른 부분을 작성하다 보니 주렁주렁 늘어나는 코드를 보면서 눈물만 머금게 되는군요 ㅠ.ㅠ

    음.. copy&paste문제는 아마도 설계상의 문제가 가장 크지 않을까 생각이 듭니다.
    비슷한 기능이지만 약간의 다른 처리를 요구하는 함수가 발생할 때,
    전용 함수로 만들면 간단하게 해결되는데
    copy&paste하지 않기 위해서 두가지 기능을 하나로 합치다 보면 범용 함수가 되고
    그렇게 되면 상당히 귀찮아 지니 말이죠. 물론 범용 함수가 좋고
    여러개의 함수를 합쳐서 하나로 쓰는 것도 좋지만 대부분의 외각체크 루틴들은 거의 copy&paste 식으로
    비슷비슷하게 쓰여지는데, 이 부분을 명확하게 처리할 방법이 없는거 같더라구요.

    머.. 저의 프로그래밍 실력의 부족이 가장 큰 원인이겠죠 ㅠ.ㅠ

  6. 구차니님 안녕하세요.
    범용함수란 그리 좋은 선택이 아니죠. 함수는 한가지 일만 하면서 간결하게 작성되어야 하죠. 그리고 리팩토링 시기를 놓치면 점점 혼란스러워지죠. 뭐든지 제때에 해야죠.

  7. Blog Icon
    [1002]

    C&P 를 하고 향후에도 계속 C&P 를 하는 것이 과연 '개발자의 잘못' 으로 '해고되어야 마땅한' 일인지는.. 모르겠군요. 개발자 중 C&P 를 좋아서 하는 사람이 있을까요?

    C&P 에 대해 이리저리 생각하면..
    * 어찌 되었건 회사 입장에선 가장 빨리 답을 냈고 (해당 기능에 대해선 가장 빨리 답을 낼 가능성이 높습니다.)

    * C&P 를 한 다음에 부정적 피드백이 바로 날라오는 것도 아닙니다. (CPD 나 simian 같은 것을 회사차원에서 daily test 로 돌리지도 않고) 매일 매일 다음 할 작업으로 로드가 걸린 개발자 입장에선 일종의 시간 벌기가 됩니다. 밑의 돌 빼서 위에 꽂기 같은.

    * C&P 를 하는 당시에는 '이건 잠깐이고 언젠가 다시 리팩토링 할꺼야' 라 생각한 뒤, 실제로 리팩토링을 하지 않거나 하지 못하게 될 상황이 바로 닥치게 될 경우가 많습니다. 예전에 어떤 분 말씀처럼 '지금 당장 정리 하지 않으면 지는거다' 라고 강하게 생각하지 않고선 쉽지 않습니다.

    * 코드리뷰의 경우 리뷰를 1주일 이내 단위로 자주 하는 것이 아닌 이상 C&P 가 고쳐질 것이라고는 생각치 않습니다. 리뷰의 주기가 길 경우, 이미 리뷰 받고 난 뒤엔 돌이킬 수 없게 되는 경우가 많습니다. 리뷰 중 자주 나오는 말 중 하나가 '이번엔 어쩔 수 없으니.. 다음번엔..' 일겁니다. 소 잃고는 외양간 고치려고 해봤자 고칠 맘은 안생깁니다.

  8. 안녕하세요. 질문도 답도 댓글에 다 포함되어 있군요. :)
    개발자 중에는 C&P의 폐해를 모르고 마구 해대는 사람들도 많습니다. 이미 많은 고민을 하고 계시네요.

  9. Blog Icon
    깜순이아빠

    글 잘 읽었습니다 좋은 내용이 많아서 이건 무슨 말인가 하고 봤는데 흠.. 저는 Copy & Paste 신봉자거든요.
    API에 대한 오타를 막을 수 있고, 생산성도 향상된다는 점에서 무척 좋아합니다. 단지 이 글의 요지를 제가 처음에 오해했나봅니다.

    진짜 요지는 공통되는 부분을 모듈화하지 않고, 여기저기 똑같은 소스를 산재하는 것을 말하는거군요. 그건 저 역시 반대합니다!! 여기저기 같은 소스를 복사&붙여넣기 하면.. 자원낭비도 심하고
    유지보수하기도 여간 까다롭죠! 근데 ㅋㅋㅋ 재미는 있네요 ㅋㅋㅋ 고쳐야 할게 많아서 ㅋㅋㅋ

  10. 빈익빈 부익부 라는 말이 떠오릅니다. 크고 체계가 잘 잡혀 있는 회사에 들어가서 체계적으로 일을 하면서 성장해 가는 사람이 있겠지만, 중소기업이나 그이하의 작은 업체에서 일하는 사람들에게 C&P의 남발은 도무지 버릴수가 없는 기술(?)이겠죠. 물론 작은 업체라고 해서 다 그렇지는 않겠지만요..

  11. 우리나라에서는 대표적인 큰 회사들에서 이런 일이 흔히 벌어지고 있습니다. 모 휴대전화 회사도 수천개의 모델을 Copy&Paste에 기능 추가해서 만들어서 소스코드가 수천벌이 있다고 합니다. 과정이야 문제가 있고 개발자들이 고생하고 역량이 바닥이라고 해도 휴대전화를 잘 만들어서 팔고 있으니 이또한 대단한 역량이라고 하지 않을 수 없습니다. ^^
    이런 예를들어서 일반화하면 곤란하겠죠. :)

  12. c&p 를 많이 한 것이 문제기도 하지만, 주기적으로 리팩토링을 해서 이런 부분을 없애지 않는 것도 큰 문제입니다. 일을 하다 보면 무엇이 공유될 지 미처 생각지 못한 부분이 생기기도 하고, 공유하려면 더 많은 고려를 해야 하기 때문에 일정상 미뤄놓을 때가 많습니다. 이런 것들은 주기적으로 공통 요소들을 찾아내 따로 관리하고, 이렇게 만든 공식 코드를 사용하도록 기존 프로젝트를 수정하는 작업이 필요합니다. 하지만 현실은? ㅡ,ㅡ;;

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바