336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.





백팩킹을 시작하기위해 이것저것 알아보고 준비하던 중에

지인을 통해 알게된 2016 국제캠핑페어 정보가 있어 이렇게 글을적어봅니다.


2월 26일(금)~2월 28일(일) 킨텍스 7,8홀 에서 미니멀웍스가 참가한다고합니다.


아래 링크 방문하시면 초대권을 받을수 있는 이벤트도 안되도고 있으니 

관심있으신분들은 링크클릭!!


2016 국제캠핑페어에는 과연 어떤 텐트들이 나오게될지 궁금궁금 꼭 가보고싶은 전시~~


링크 : http://blog.naver.com/mnmalworks/220614879298





블로그 이미지

By훈트

,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

작은 솔루션회사의 개발자이다. 


회사의 규모가 작다보니 개발인원이 10명도 채 안되는 소규모팀이다. 회사에서는 소스코드관리를 MicoroSoft 사의 Visual SourceSafe(이하 VSS)를 이용해 왔다. 


내가 그간 사용하면서 느낀 VSS장점은 간단하게 아래와 같다.

1. 같은 소스에 대해서 한 사용자가 수정을위해 체크아웃을 하면, 다른사용자는 수정을 할 수 없다.

2. MicroSoft 사의 Visual Studio와 연동이되어 사용이 편리하다.

3. 파일단위로 소스버전관리가 가능하여 파일단위의 부분롤백이 가능하다.


적은인원의 프로젝트팀이나 규모가 작은 프로젝트를 소수로 진행하거나 유지보수할때에는 VSS는 사용하기 편리한 장점이있다.


하지만 VSS는 아래와같이 여러가지 단점도 있다.

1. 파트별로 소스를 관리하게되는 경우 해당파트 담당자가 자리를 비울경우 문제 처리가 어렵다.

2. 동일소스 동시수정이 불가능하여 많은 인원이 공동개발하는 대형 프로젝트에는 사용이 부적합하다.

3. 중앙통합관리 방식인 VSS는 중앙서버에 문제가 생기면 소스관리시스템을 이용할수 없다.

4. VisualStudio가 아닌 다른 개발툴에서는 소스는 관리가 불가능하다. (Eclipse, IOS 등)


나는 VisualStudio를 이용하여 C#을 이용한 윈폼 솔루션을 개발해왔고 특정파트만을 담당하여 관리해왔다. 추가로 이 솔루션을 지원하는 모바일 Android 앱을 개발하여 서비스하고 있다. 

그동안 윈폼 쪽은 내가 담당한 파트에 한해서만 개발하고 수정해왔고 모바일은 내가 단일개발로 진행해왔기 때문에 특별히 소스관리가 필요하지 않아서 VSS의 사용만으로 크게 무리는 없었다.


하지만 백업 인원의 충원과 업무 공유차원에서 다른사람과 공동으로 진행하는일이 점점 많아지고..

특히 모바일 앱의 개발 및 유지보수를 다른이와 공동으로 해야하는 상황에 오고보니 VSS로는 역부족이어서 대체 소스관리시스템에 대해 찾아보았다.


소스관리 시스템을 알아보며 크게 중요시한 사항들은 아래와 같다.

1. 현재 개발중인 MS의 VisualStudio의 C# 와 Eclipse 의 Android 프로젝트의 툴 지원여부.

2. 프로젝트 소스관리에 있어서 자유로운 공동개발과 버젼관리.

3. 소스관리는 중앙집중방식이아닌 분산버전관리방식.(Main 소스관리서버에 문제가생겨도 기존작업에 문제를 주지않고 소스 백업 및 복원까지 가능한)


이래저래 검색도중 SVN Git 에 대한 글들이 많이 보였다. 이중 위 요건에도 모두 충족하며 SVN보다 다양하고 좋은 기능들을 갖춘 Git을 선택했다. Git에대해 1주일정도 개념이해부터 설치와 활용등 VisualStudio와 Eclipse 툴을 통해 격은 내용들을 정리해보고자한다.



혹시 SVN과 Git의 차이첨에 대해 궁금하거나 어떤걸 쓸지 고민중이라면 아래 링크의 블로그 글을 읽어보면 조금 도움이 될거같다.

1. SVN과 Git의 비교와 Git의 차별점을 다룬

출처 : http://seungzzang.blogspot.kr/2013/04/git-svn-svn-git.html


2. SVN을 쓸까? Git을 쓸까? 고민에 대해 다룬

출처 : http://allofsoftware.net/entry/SVNGIT 

블로그 이미지

By훈트

,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

 출처 - http://www.cyworld.com/gaephlhome2/7832995 


낭비를 제거하라

 - 소프트웨어 개발에서의 가장 큰 낭비 세가지

   : 가외기능 (80%의 가치를 제공하는 20%의 기능에 초점을 맞춰 개발하는 프로세스가 필요하다)

   : 혼란 (요구사항 혼란을 겪는 다면 스펙을 너무 일찍 결정한 것이다. 테스트하고 수정하는데 혼란을

             겪는 다면 테스트를 너무 늦게 하는 것이다.)

   : 경계넘어가기 (조직간의 경계는 통상 25% 이상의 비용을 증가시키는데, 버퍼를 만들고 응답시간을

                         늦푸며 커뮤니케이션을 방해하기 때문이다.)

 

품질을 내재화하라

 - 검증단계에서 늘상 결점이 발견된다면 그 프로세스에 결함이 있는 것이다.

   : 테스트 주도 개발을 통해 코드의 실수를 방지하라. (요구사항 문서 대신 실행 가능한 명세를 작성하라.)

   : 레거시 코드를 만들지 마라. (레거시 코드는 자동화된 단위 테슨트와 인수 테스트가 없는 코드다.)

   : 빅뱅 통합은 진부하다. (지속적 통합과 중첩된 동기화 기법을 사용하라.)

 

지식을 창출하라.

 - 계획은 유용한 것이며, 학습은 필수적인 것이다.

   : 과학적 방법을 사용하라. (가설을 세우고, 신속하게 다양한 실험을 해보고, 문서를 간결하게 작성하고, 최선의

                                        대안을 구현할 수 있도록 답을 가르쳐라.)

   : 표준은 도전받고 개선되기 위해 존재한다. (모든 사람들이 따라하고 잘 알려진 실천법을 표준에 포함하되,

                                                               누구든지 표준에 도전하고 변경하도록 장려한다. )

   : 예측 가능한 성과는 피드백에 기반한다. (예측 가능한 조직은 미래를 추측하고 그것을 계획이라고 하지 않으며,

                                                         그 보다는 미래가 펼쳐질 때 신속하게 대응하기 위한 역량을 개발한다.)

 

확정을 늦춰라

 - 완벽한 명세서를 가지고 개발을 시작하는 것이 좋은 아이디어라는 생각을 버려라

   : 의존성을 깨뜨려라 (시스템 아키텍처는 언제 어떤 기능이 추가 되더라도 그것을 수용할 수 있어야 한다.

   : 옵션을 유지하라 (코드를 실험으로 생각하라. 변화를 수용 할 수 있게 작성하라.)

   : 돌이킬 수 없는 결정은 마지막 결정의 순간에 하라. (돌이키 ㄹ수 없는 결정을 내리기 전에 가능한 많이 학습)

 

빨리 인도하라.

 -  리스트와 대리열은 일의 속도를 늦추는 조직간의 버퍼다.

   : 신속한 인도, 고 품질, 저 비용은 공존할 수 있다. (속도의 경쟁에서 승리하는 회사는 큰 비용우위를 갖고

                                                                     월등한 품질의 제품을 인도하며 고객의 요구에 더 귀기울인다.)

   : 대기행렬이론을 개발에 적용하라. (가동률을 강조하면 오히려 정체를 일으켜 가동률이 떨어진다.

                                                    배치 크기를 작게하고 진행중인 작업량을 줄여 주기시간을 줄여라)

   : 일의 양을 할 수 있는 만큼으로 제한하라. (반복 개발에 안정적이고 반복가능한 속도를 가져라.

                                                고객에게 인도할 수 있는 역량에 맞게 대기열의 길이를 정지적으로 제한하라.)

 

사람을 존중하라.

 - 주도적으로 참여하고 연구하는 사람들이 최고의 지속가능한 경쟁 우위를 제공한다.

   : 팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성한다.

                           (무엇이 팀을 만드는가? 팀원들은 공동 목표를 달성하기 위해 상호간 책임의식으로 뭉쳐있다.)

   : 효과적인 리더쉽을 제공하라. (효과적인 팀에는 팀을 최고로 이끄는 훌륭한 리더가 존재한다.)

   : 파트너를 존중하라. (조인트 벤처를 위한 헌신은 절대로 이해상ㄹ반을 만들지 않는다.)

 

전체를 최적화하라.

 - 빼어난 제품은 기회와 기술의 특별한 만남에서 나온다.

   : 전체 가치 흐름에 초점을 맞춰라. (컨셉에서 현금까지, 고객요구에서 소프트웨어 배포까지)

   : 완전한 제품을 인도하라. (소프트웨어만이 아닌 완전한 제품을 개발하라.

                                        완전한 제품은 완전한 팀에 의해 만들어 진다.)

   : 더 높은 것을 측정하라. (주기시간으로 프로세스 역량을 측적하라. 인도된 비즈니스 가치로 팀 성능을

                                      측정하라. 순추천고객지수<NPS>로 고객만족을 측정하라.)

Ps. 린소프트웨어 개발의 적용 이라는 도서에 대한 요점이다. 요즘 정체기인 나에게 자극이 될수 있을거같다.

* 관련도서

1. 린 소프트웨어 개발의 적용
2. 린 소프트웨어 개발



 

'Daily > 훈트의일상' 카테고리의 다른 글

나이키 신발 사이즈  (0) 2011.03.11
Dr.Dre 헤드폰  (0) 2010.12.28
와우 방문자 1만찍었...ㄷㄷㄷ  (3) 2010.11.19
토탈 5000 뿌 ㅎㅎㅎ  (0) 2010.10.02
Total 1004 기념~~  (0) 2010.08.18
블로그 이미지

By훈트

,