한방에 빌드
'기반시스템 > 빌드/릴리즈' 카테고리의 다른 글
| 한방에 빌드 (2) | 2009/08/06 |
|---|---|
| Build Script를 C언어로 작성하기 (2) | 2009/02/24 |
| Daily Build를 하십니까? (0) | 2009/02/04 |
| 빌드와 컴파일의 차이 (6) | 2008/11/14 |
| 빌드가 먼저일까? 베이스라인 설정이 먼저일까? (8) | 2008/11/12 |
| Broken tree (0) | 2008/11/12 |


All of Software소프트웨어 경영/개발 컨설턴트와 소프트웨어 공학 전문가들이 말하는 소프트웨어 개발 이야기...
여러분들의 의견 적극 환영합니다.
by Ray.전규현 [메일보내기] |
SW개발역량분석 서비스(Free) |
| 한방에 빌드 (2) | 2009/08/06 |
|---|---|
| Build Script를 C언어로 작성하기 (2) | 2009/02/24 |
| Daily Build를 하십니까? (0) | 2009/02/04 |
| 빌드와 컴파일의 차이 (6) | 2008/11/14 |
| 빌드가 먼저일까? 베이스라인 설정이 먼저일까? (8) | 2008/11/12 |
| Broken tree (0) | 2008/11/12 |
| 베이스라인 (2) | 2009/08/04 |
|---|---|
| 이 소스코드는 나 밖에 못 건드려! (10) | 2009/07/19 |
| 누가 소스코드를 몰래 바꿔놨다. (0) | 2009/07/13 |
| 소스코드관리 상세 조사 결과 리포트 (6) | 2009/03/08 |
| 사라진 소스코드 (4) | 2009/02/28 |
| Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18) | 2009/02/25 |
구차니님 안녕하세요. 개발팀 규모가 아무리 작아도 Baseline은 설정해죠. ^^ CVS의 단점 중의 하나가 프로젝트의 규모가 커지면, Tag, Branch 생성에 시간도 오래 걸리고, 시스템 공간을 많이 차지하는 것입니다. 대규모프로젝트를 하다보면 CVS의 불편함을 종종느끼게 됩니다.
"우리 팀은 각자 맡고 있는 소스코드가 다 달라서 서로 충돌 날 일이 전혀 없어요"
"이 소스코드를 수정해야 하면 나한테 얘기해, 내가 고쳐 줄게"
"내가 지금 고치고 있으니 너도 고치려면 내가 끝낼 때까지 기다려"
"지금 이거 한창 고치고 있으니 중간에 다른 것은 끼어들 수 없어요. 이거 다 끝날 때까지 기다려주세요."
이와 같은 현상이 친숙하나요? 그럼 Parallel Development(병행개발)와는 거리가 멉니다.
개발을 이런 식으로 순차적으로 기다렸다가 해야 한다거나 다른 사람이 이 소스코드를 고치고 있지 않은지 걱정을 하고 있거나 이것 때문에 소스코드를 고칠 때 항상 Lock을 걸어야 한다면 이만 저만 불편한 것이 아닙니다. 개발 속도도 떨어지게 됩니다.
아키텍처적인 이슈를 제외하고는 개발자들은 서로 같은 소스코드를 얼마든지 동시에 수정할 수 있고, 소스코드가 충돌이 일어나더라도 얼마든지 쉽게 해결할 수 있어야 합니다. 또한 동일한 소스코드를 기반으로 길고 짧은 프로젝트를 동시에 진행하면서 나중에서 손쉽게 Merge를 할 수 있어야 합니다. 이런 식으로 개발을 하지 않으면 대형 프로젝트는 너무 오래 걸릴 수 밖에 없습니다.
또한 이 때문에 각 개발자들이 Component Owner식으로 자신만 소스코드를 다룰 수 있다면 개발자들간에 소스코드 공유가 취약해지며 서로 단절된 개발을 하기 십상이 됩니다.
하지만 이런 Component Owner방식에 익숙한 환경에서는 이것이 너무 당연하게 생각이 되므로 이것을 바꾸려는 생각을 하기란 쉽지가 않습니다. 지금이 방식이 익숙하고 별 문제가 없어 보이고 또 이런 환경에서 발생한 문제들을 온갖 편법으로 피해 왔기 때문에 바꾸기가 쉽지 않습니다. 하지만 이로 인해 발생하는 문제들은 무시할 수 없습니다.
Parallel Development를 제대로 수행하려면 소스코드관리시스템을 단순히 소스코드 저장소 용도로 사용해서는 부족합니다. 소스코드관리시스템을 제대로 사용하기 위한 프로세스와 규칙이 필요하며 Branch와 Tag, Merge를 용도에 맞게 능숙하게 사용할 수 있어야 합니다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
| 베이스라인 (2) | 2009/08/04 |
|---|---|
| 이 소스코드는 나 밖에 못 건드려! (10) | 2009/07/19 |
| 누가 소스코드를 몰래 바꿔놨다. (0) | 2009/07/13 |
| 소스코드관리 상세 조사 결과 리포트 (6) | 2009/03/08 |
| 사라진 소스코드 (4) | 2009/02/28 |
| Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18) | 2009/02/25 |
지금 회사에서 svn을 쓰고 있습니다. 그냥 깔아서 쓰고 있죠. 문서공유와 프로젝트 소스코드를 관리하기 위함입니다.하지만 svn담당자는 branch가 뭔지,tag가 뭔지, merge기능이 뭔지 모르더군요. 그냥 계정주고 인스톨만 하면 끝인줄 압니다. 안타깝죠~.그렇게 깔아놓고 후배들에게 무언가를 가르칩니다. 안타깝죠.~
안녕하세요. SVN을 그렇게 사용한다면 SVN이 주는 혜택의 5%정도밖에 못보는 거죠. "소스코드관리시스템을 사용하고 있습니까?"라는 질문에 "Yes"라고 답하기 곤란한 경우죠.
안녕하세요. 구차니님
결론이 버전컨트롤이라기보다는 이것은 소프트웨어를 개발하는데 있어서 아주 기초가 되는 사항이기 때문에 결론보다는 시작이라고 해야 적당한 것 같습니다. 단순히 소스코드를 공유하고 백업 받는 기능을 익히는데는 5분이면 족하지만, 그 외에 중급/고급 기능은 제대로 익히는데 몇년이 걸리기도 합니다.
안녕하세요. whitekid님
불변의법칙이죠. 먼저 커밋하는 사람이 장땡이죠. ^^
거대한 프로젝트에서는 나중에 커밋하는 사람이 Merge하는데 며칠이 걸리기도 합니다. 아무리 툴의 지원을 받아도 그런 경우도 있죠.
저희는 ClearCase를 쓰고 있는데...
"소스코드관리시스템을 이용하고 계십니까?" 라는 질문에 "No"라고 해야 할듯 싶네요..에공~
| 베이스라인 (2) | 2009/08/04 |
|---|---|
| 이 소스코드는 나 밖에 못 건드려! (10) | 2009/07/19 |
| 누가 소스코드를 몰래 바꿔놨다. (0) | 2009/07/13 |
| 소스코드관리 상세 조사 결과 리포트 (6) | 2009/03/08 |
| 사라진 소스코드 (4) | 2009/02/28 |
| Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18) | 2009/02/25 |
| 버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요. |
| 버그관리시스템 사용 vs. 미사용 비율 |
| 전체 투표 결과 |
| 버그관리시스템의 사용 비율 |
| 결론 |
| 버그관리시스템 사용 현황 조사 결과 (2) | 2009/04/12 |
|---|---|
| 효과적인 버그 처리 방법 (6) | 2008/12/09 |
맨위에 도표를 보고 생각보다 많이 쓴다고 생각했었는데...;;
저희회사도 이제막 도입을 검토중이거든요..
프로젝트에 적용할려면 또 얼마나 걸릴지 모르겠지만;;
늦게나마 도입하려는 시도가 보인다는것만으로도 감사하다고 해야할까요 ㅎㅎ;
그나저나 RSS보다 블코 위젯 메인에뜬걸 보고 들어오다니;; 축하드립니다 ^^
어떤 시스템을 도입하려하시나요? Mantis? JIRA? 도입과정에서 어려움이 있거나 사용상의 이슈등 궁금하신 것이 있으면 언제든지 문의하세요. 감사합니다.
| 이 소스코드는 나 밖에 못 건드려! (10) | 2009/07/19 |
|---|---|
| 누가 소스코드를 몰래 바꿔놨다. (0) | 2009/07/13 |
| 소스코드관리 상세 조사 결과 리포트 (6) | 2009/03/08 |
| 사라진 소스코드 (4) | 2009/02/28 |
| Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18) | 2009/02/25 |
| 소스코드 관리 방법 조사 결과 (8) | 2009/02/22 |
헝그리맨님 안녕하세요.
코드리뷰는 가장 정착시키기 어려운 개발문화 중의 하나입니다. 실리콘밸리에서도 귀찮기는 마찬가지이지만, 규칙으로 정해 놓고 누구나 따릅니다.
3번 Rule 에서 8,9번 항목의 경우 처음 질문 때 의도가 명확치 않으면 구분해서 쓰지 않고 중복 체크를 할 것 같습니다만.
그리고 버그트래커-버전관리툴 이 연동된 시스템을 쓰는 개발자 입장에선 버그 번호를 쓰는게 더 쉽습니다. 아무 설명도 안쓰고 버그 번호만 쓰면 되거든요. (상세 내용은 어차피 버그트래커에서 계속 덧글로 달리므로. 그리고 버그 트래커와 버그 번호 연동되는 시스템인 경우 버그 번호만 룰에 맞춰 남기는게 훨씬 보기에도 좋고 추적성 면에서도 좋습니다. 그리고 SVN Log 로 쓸 수 있는 텍스트 양은 한계가 있습니다. 차라리 별도 문서를 남기죠)
3 way merge 의 경우.. 툴 자체가 편하긴 하나, 자동 테스트가 구축되고 커밋 빈도가 높은 곳의 경우 그냥 눈으로 비교하는 것으로도 충분합니다. (한 changeset 당 코드 변화량이 적은 경우) changeset 당 코드 변화량과 conflict 단위가 큰 경우 툴의 편의성 문제로 보기보다는 그렇게 conflict 단위가 크게 가는 상황 자체가 문제일지도 모르죠.
그리고 질문이 있다면.. '팀/프로젝트 규모 대비 필요한 만큼의 성숙도' 의 기준이 정해진 것이 있는지 궁금합니다.
좋은 의견 감사합니다.
8,9번 항목의 경우 실제로 그렇게 하고 있는 개발자라면 다 이해를 할 것입니다. 제대로 하고 있는 곳이라면 8,9번을 다 체크하겠지요.
머지는 팀이 커질수록 머지에 많은 노력이 들어가는데, 눈으로 비교해서 머지하는 것은 시간도 많이 걸리고 실수의 가능성도 크다고 생가가합니다. 팀이 커지고 동시에 많은 사람들이 소스코드를 중복해서 수정하더라도 Conflict가 가능하면 적게 생기도록 하는 것이 좋습니다. 이런 경험이 쌓이면 자연스럽게 어떻게 해야 Conflict가 적게 생기는지 요령이 생깁니다.
3,4명의 개발자들이 동시에 개발하는 팀에서는 어떻게 해도 큰 문제가 되지는 않습니다. 개발팀이 커질 수록 신경을 써야겠지요.
제가 소프트웨어공학 컨설팅을 하기 때문에 '팀/프로젝트 규모 대비 필요함 만큼의 성숙도'에 대한 기준은 가지고 있습니다. 하지만 많은 회사들이 그 기준에 미치지 못하고, 발생하는 수많은 문제를 피해 다님으로서 스스로의 생산성과 역량을 떨어뜨리는 결과를 가져오고 있습니다. 팀의 규모와 역량에 알맞은 규칙과 툴을 적절하게 이용하면 훨씬 더 생산성을 높일 수 있는데, 심지어는 자신만의 세계에 갇혀서 이러한 변화를 거부하는 개발자도 많답니다.
안녕하셔요?
이제는 개발자에서는 조금 멀어진 애 늙은이 입니다.^^
제가 종사하는 분야에서는 아직도 주먹구구식으로 개발이 이루어지고 있습니다.
후배들에게는 체계가 갖추어진 환경을 물려주기 위해 공부 중입니다.
그런데, 코드리뷰는 어떻게 해야 하나요?
막연한 질문이지만, 간단히 설명 부탁드립니다.
혹시, 좋은 무료도구가 있을까요?
집필하신 책을 주문했는데, 그 안에 답이 있을까요?
그리고, 버그추적시스템을 소개와 비교 부탁드립니다.
감사합니다.
한인철님 안녕하세요.
코드리뷰는 가장 필요하면서도 매우 정착시키기 어려운 개발문화입니다. 코드리뷰는 종류가 여러가지고 있고, 개발 조직에 따라서 알맞은 방법을 써야 하며 제도적으로, 시스템적으로 뒷받침이 필요합니다. 여러 도구가 있기는 하지만 당장 도구가 없어서 코드리뷰를 못하는 것은 아닙니다. 일단 시작하는 것이 중요하고 시작하기 위한 기본적인 지식은 갖춰야죠. 좀더 구체적인 것이 필요하면 연락주세요.
그리고 버그추적시스템은 제 책에도 소개가 되어 있고, 현재 투표가 진행중인데, 투표가 끝나면 글을 올릴 예정입니다.
감사합니다.
제가 이전에 올린 글을 보면 소프트웨어를 개발하는데 있어서 그 팀의 성숙도에 따라서 무엇을 우선 도입해야 하고 무엇은 좀더 성숙도가 높아진 다음에 도입해야 하는지 설명한 적이 있습니다.
이중에서 가장 중요한 소스코드관리시스템과 버그관리시스템은 좋은 무료 툴들이 정말 많습니다. 하지만 이러한 무료 툴조차 쓰지 않거나 쓰더라도 아주 기초적인 기능만 사용을 하고 제대로 활용을 못하면서 정작 문제를 엉뚱한 곳에서 찾으려고 합니다. 그래서 비싼 툴을 팔고 있는 영업사원들에게 현혹되어서 몸에 걸맞지 않은 액세서리를 걸치듯 효용성도 떨어지는 툴을 사놓고 제대로 활용 못하는 경우가 많습니다.
쓰다 보면 그리 좋지 않다는 것을 느끼게 되도, 이를 도입한 담당자는 자신의 실수와 미숙함을 숨기기 위해서 효과를 과대포장하는 경우가 많습니다.
제가 장담 하건데 대부분의 소프트웨어 회사들은 무료 개발툴(기반시스템)로 충분히 좋은 소프트웨어를 만들 수 있습니다. 제가 이 블로그에서 소개하는 툴이나 기반시스템도 대부분은 Open Source나 무료 소프트웨어에 포커스를 하고 있습니다. 이러한 것들이 유료툴에 못지 않게 좋으니까요.
하지만 결국 무료냐 유료냐를 떠나서 얼마나 툴을 잘 사용하느냐가 중요합니다. 소프트웨어 개발에 문제가 있는 개발팀이 어느날 툴하나 도입했다고 해서 갑자기 드라마틱하게 상황이 바뀌지는 않습니다. 결국 사람들이 바뀌어야 하는데, 프로세스, 조직도 바꾸고, 각 개발자들의 마인드도 바꿔야 합니다. 스스로의 노력으로 오랜 시간에 걸쳐서 바꿀 수도 있고, 전문가의 도움을 받을 수 있죠.
앞으로도 이와 같은 툴을 유용하게 쓰는 법이나, 개발 프로세스 등 소프트웨어 개발에 우선적으로 필요한 요소들을 계속 올릴 겁니다.
감사합니다.
| 몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다. (0) | 2009/03/05 |
|---|---|
| 깨끗한 개발 환경, 빌드 환경, 테스트 환경 (6) | 2009/02/05 |
| 서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System) (11) | 2009/02/03 |
| 이클립스 프로젝트 필수 유틸리티 개정판 : Subversion, Ant, JUnit, Trac (2) | 2009/01/28 |
| 우리 개발자는 뭐든 뚝딱 잘 만들어요. (0) | 2008/12/08 |
| 기반시스템(Infrastructure System)을 사용하고 계신가요? (4) | 2008/11/05 |
| 누가 소스코드를 몰래 바꿔놨다. (0) | 2009/07/13 |
|---|---|
| 소스코드관리 상세 조사 결과 리포트 (6) | 2009/03/08 |
| 사라진 소스코드 (4) | 2009/02/28 |
| Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18) | 2009/02/25 |
| 소스코드 관리 방법 조사 결과 (8) | 2009/02/22 |
| VSS, CVS, SVN 비교 (12) | 2009/01/08 |
예전에 만든 프로그램에서 버그가 발견되었지만, 소스파일을 날려버려서 새로 만든 적이 있습니다. 그 이후로 항상 웹과 USB, HDD에 삼중보관을 하고 있죠. 그런데 솔직히 위의 방법은 지나친 감이 있네요. 회사 차원에서 별도의 백업팀이 있으면 할만할지 모르겠지만 개인에게는 어려울 것 같습니다.
아리새의 펜촉님 안녕하세요.
누구나 자신에게는 큰 사고가 일어난다고 생각하지 않습니다. 경험하신 일은 소스코드를 날려버리신 일인데, 보통 자신이 경험한 일 정도만 대응을 합니다.
위와같이 3단계로 백업을 하려면 백업팀은 아니고 백업담당자는 필요합니다. 대부분의 백업은 자동화를 하고, 주간백업정도는 수동으로 해야할 일이 있습니다. 백업담당자는 자신의 일중에서 10~20%정도는 백업을 해야합니다.
위와 같이 3중보관을 하고 계신다면 99.9%의 사고에는 완전할 수 있습니다. 0.1%의 사고까지 방지를 할지는 비용대비 효과를 생각해서 스스로 판단해야 할 일입니다. 작은회사들이 그렇게 투자하는 일은 흔하지 않습니다.
하지만 회사의 규모가 커질수록 큰 사고에 대해서 생각하지 않을 수 없습니다.
하루님 안녕하세요.
형상관리를 적용하는 것은 기본이죠. 위의 모든 얘기도 형상관리를 적용한 다음의 얘기입니다. 단, 저는 형상관리라는 말은 잘 사용안합니다. 가능하면 소스코드관리라고 얘기합니다. SVN을 백업받는 얘기라고 생각하시면 됩니다. ^^
| 총점 |
| 비교 데이터 |
| 실행 |
| 비교 화면 |
| Merge시 Conflict를 알려주는 다이얼로그 |
| Merge 화면 |
| Conflict 해결 |
| Unicode 지원 |
| 총평 |
| 소스코드관리 상세 조사 결과 리포트 (6) | 2009/03/08 |
|---|---|
| 사라진 소스코드 (4) | 2009/02/28 |
| Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정 (18) | 2009/02/25 |
| 소스코드 관리 방법 조사 결과 (8) | 2009/02/22 |
| VSS, CVS, SVN 비교 (12) | 2009/01/08 |
| 하루에 몇 번 커밋하세요? (22) | 2009/01/07 |
안녕하세요. 영회님
3way-merge 기능을 위주로 비교했기 때문입니다. 그리고 Araxis Merge가 기능이 더 좋기는 하지만, 가격 점수 때문에 그렇게 평가를 했습니다.
헝그리맨님 안녕하세요.
Unified Diff는 Text포맷으로 Merge를 할 수 있는 하나의 Format입니다. SVN과 TortoiseSVN에서 기본적으로 제공합니다. GUI가 불편하므로 GUI가 편리한 다른 툴들을 사용하는 것이고요.
저는 보통 단순히 2개의 파일비교를 위해 winmerge를 사용하는데
3-way merge 라는 것과 새로운 툴들 정보 잘 봤습니다.^^
언제나 유익한글 감사드립니다. 최근에 가장 자주오게되는 블로그네요.^^ 저도 현재 급한 프로젝트때문에 ClearCase를 사용하는 회사임에도 너무나 자주바뀌는 코드로인해 WinMerge를 통하여 급 머지를 하고있습니다.-_- 머지에 대해서 좀 자세하게 알고싶은데요.. 왜 3 way merge가 필수인가요? 아직 3 way merge에 대한 개념이 잘없네요. Tunk,와 Branch의 개념도 알고싶습니다. 감사합니다
뽕삼님 안녕하세요.
http://allofsoftware.net/entry/Release-Branch-Function-Branch-and-Customer-Branch 과 http://allofsoftware.net/entry/diffandmerge 를 읽어보세요. 더 궁금한 것이 있으면, Email을 보내주세요.
Perforce의 P4Merge도 무로이면서 좋은 3-way merge tool중에 하나라고 생각됩니다.
http://www.perforce.com/perforce/products/merge.html
p4 merge툴 자체는 무료라고 하는데.. 가격이 ㄷㄷㄷ..
http://perforce.com/perforce/products/merge.html
안녕하세요. kkurrung님 블로그에 오류가 있네요. 지금 다시 확인해보니, Perfoce Merge는 무료네요. 제가 적어 놓은 것은 서버의 가격이네요. 수정하도록 하겠습니다. 지적해주셔서 감사합니다.
국산 3 Way Merge 도구도 있습니다. (물론 우리팀이 만들고 있고, 상용입니다. ![]()
http://www.snh.co.kr/?s=product&m=shape4 여기에서 평가판을 받으실수 있습니다.
물론, 우리팀은 Merge Tool만을 전문적으로 만들지 않고, 형상관리에 관련된 전반적인것을 함께 개발하고 있기때문에, 총력을 다하고 있지만 못합니다만. 국산제품도 있다는 점을 알려드리고 싶어요...
머샤머샤님 안녕하세요.
개발을 하시면서 소스코드관리시스템은 물론 실루엣을 쓰시겠죠? ^^ 이런류의 질문들이 항상 궁금했습니다. ㅎㅎ 나중에 기회가 되면 같이 검토를 해봐야겠네요.
araxis가 좋긴한데.. syntax highlight가 안되서 간간히 winmerge를 사용하고 있습니다만
디렉토리 비교 측면에서는 araxis가 좋더군요. 3way까지 잘 쓰질 않아서 유용한지는 잘 모르겠습니다 ^^;
구차니님 안녕하세요.
3-way merge를 사용하지 않을 거면 winmerge로 충분하죠. 소프트웨어를 개발하다보면, 브랜치, 머지, 롤백 등 수많은 상황에서 3-way merge는 이런 활동을 몇배 편하게 해줍니다. 3-way merge도 익숙해질 필요가 있습니다.
Build Script를 Script언어가 아닌 C언어로 작성하시거나 그런 경험이 있으십니까?
저는 Build Script를 C언어로 작성하는 것을 본 적이 있습니다. 이 경우에 Build Script라고 하기에 좀 그렇군요. Build Program이라고 해야 할까요?
누구나가 Build Script라고 부르는 이유는 Script언어로 작성하기 때문이기도 합니다.
물론 IDE에서 공식 빌드를 하는 것이 아니고 Build Script를 작성한 것은 긍정적으로 볼 수 있지만 Build Script를 사용하기 위해서 다시 Build를 해야 한다면 우습네요.
Build Script를 C언어와 같이 Build가 필요한 언어로 작성하는 경우는 이러한 경우가 있을 수 있습니다.
Script언어를 하나도 모른다면 어쩔 수 없겠지만, Script언어로도 빌드에 필요한 정도의 모든 기능은 쉽게 구현할 수 있습니다. 오히려 Build를 위해서 만들어진 Ant같은 경우는 더 효율적입니다. Script언어에 아직 익숙하지 않다면 간단하게 Batch 파일로 작성할 수도 있습니다. 그리고 C언어와 유사한 Python을 이용하면 Python을 아주 잘하지 않더라도 간단한 Build Script 정도는 만들어 낼 수 있습니다.
Build Script는 처음부터 모든 원하는 기능을 다 자동화 할 필요는 없습니다. 우선 기본적인 빌드 기능부터 구현을 한 다음에 사용을 해보면서 자동화가 필요한 부분을 차례차례 추가해 넣으면 무난히 효율적인 Build Script를 만들 수 있습니다.
| 한방에 빌드 (2) | 2009/08/06 |
|---|---|
| Build Script를 C언어로 작성하기 (2) | 2009/02/24 |
| Daily Build를 하십니까? (0) | 2009/02/04 |
| 빌드와 컴파일의 차이 (6) | 2008/11/14 |
| 빌드가 먼저일까? 베이스라인 설정이 먼저일까? (8) | 2008/11/12 |
| Broken tree (0) | 2008/11/12 |
make를 빼고는 얘기가 안되죠 ![]()
C만 쓸 줄 알다가 처음 make를 혼자 익혀보고는 감탄했던 때가 생각나는군요. 사람은 배워야죠...ㅡㅡ;
Eminency님 안녕하세요.
make도 제대로 사용하려면 공부를 많이 해야하죠. 대부분들 선배들이 만들어 놓은 makefile 그냥 조금씩 수정해서 사용을 하고 전체 의미는 잘 모르고 쓰는 경우들이 많더군요. 또 Windows플랫폼에서 개발하는 개발자는 그냥 IDE에서 만들어주는 대로 그냥 빌드를 하기 때문에 make의 과정이나 옵션등을 속속들이 모르고 그냥 쓰고 있는 경우가 많습니다. 빌드 자동화를 위해서는 make나 nmake에 대해서 잘알아야죠.
소프트웨어 업계에는 빨리 망해야 서로 도움이 되는 회사들이 매우 많지만 악착같이 버티면서 소프트웨어 생태계를 좀먹고 있습니다. 이렇게 좀비화 된 "좀비 회사"들은 또다른 "좀비 회사"를 만들어 내는 악순환의 고리를 만듭니다...
안녕하세요. 블로그 독자 여러분! 대한민국의 소프트웨어 토양에 좋은 밑거름이 되고자 하는 제 블로그에 많은 호응을 해주셔서 감사드리며 이에 보답코저 아래와 같이 이벤트를 실시합니다. 많은 참여 바랍니다. 제목 : 저자 사인..
소프트웨어 업계만큼이나 "세계 최초"라는 수식어를 자주 듣는 곳도 드물 것입니다. 이러한 수식어가 붙는 이유는 세간의 이목을 끌기 위함이 명백합니다. 하지만 세계 최초라고 하는 것들의 99%는 아래 범주에 속합니다. 나는 세..
소프트웨어 회사의 일들은 대부분 사람, 특히 개발자에 의존하는 일이 많습니다. 따라서 인건비는 가장 큰 비중을 차지하는 고정비입니다. 그런데 일단 뽑아 놓은 직원들의 야근은 공짜로 생각하는 경우가 많습니다. 게다가 몇몇 기업..
최근 삼성과 소프트웨어에 대한 글들을 몇 건 올리면서 정말로 다양한 의견을 접하게 되었습니다. 댓글뿐만 아니라 메일을 통해서도 의견을 들을 수 있었습니다. 2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를..
최근에 블로그에 올린 글들의 댓글을 보면 소프트웨어를 잘 개발하는 것이 어떤 것인지 바라보는 시각이 무척 다릅니다. 필자는 주장하는 바가 있어서 소프트웨어 개발에 대한 생각을 꾸준히 공유하고자 합니다. 제 블로그의 미션은 어..
아이폰을 사용하기 시작한지 오늘로 꼭 2달이 되었습니다. 2달동안 아이폰을 사용하는 재미, 아이폰 앱 개발 관련 공부하는 재미에 빠져있었습니다. 그런데, 아이폰 다국어 설정에서 이상한 것을 발견했습니다. 언어어 설정에 떡하니..
요즘 스마트폰이 IT 이슈의 정점에 있어서 스마트폰 관련 글을 계속 올리게 됩니다. 개발자의 한사람으로서 스마트폰의 급속한 확대는 좋은 징조임이 분명합니다. 하지만 종종 스마트폰 어플리케이션을 만들어서 앱스토어에 올리면 쉽게..
저는 이미 삼성의 소프트웨어에 대한 글을 몇개 올린 적이 있습니다. 2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까? 2010/01/23 - [소프트웨어이야기] - 삼성이 바다를 출시해..
일전에 삼성이 왜 소프트웨어를 잘 개발하지 못하는지에 대한 글을 쓴적이 있습니다. 2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까? 개인적인 생각이지만 바다의 정식 출시가 임박할수록 점..
한방에 빌드 만들기.. 완전 순수히 귀찮아서 만들기 시작했는데 한번 스크립트로 만들고 나니 이거 없었으면 어떻게 했냐 싶습니다. 명령 한방으로 빌드, 셋업, CVS 관리까지 한번에 끝나니..
그래서 팀에 자주 하는 말이 있습니다. 프로그래머는 귀차니스트가 되어야한다. 반복적인 작업 귀찮아.. 자동으로 할 수 있는 방법없나?? 라고 말이지요.
아직 daily 빌드는 하지 못했는데, 글을 읽다가 다시 생각이 나네요.. 이것도 시도해봐야겠네요.
Whitekid님 안녕하세요.
귀찮아서 자동화하지 않는 개발자도 많습니다. ^^