어느 평범한 개발자의 회고록...

프로그램을 globalizing 시키기 위해서는 localize한 언어를 리소스화 시켜서 저장시키는 것이 중요한데 요즘 작업중 느낀점이 많음 > LocalizeResourceKey값 Naming에 대한 고찰. 1. 현재 프로젝트 상태는 localizeResource의 key값에 대한 Naming 을 해당 단어나 문장의 뜻에 대한 걸... 기준으로 만듬. 2. 나라마다 지역마다 같은 내용도 단어가 다른경우가 많고 같은 단어도 뜻이 다른게 있고 해서 이렇게 짜다보면 리소스데이터자체가 변경될 가능성이올라감. 3. 그래서지금 불편한게 한두개가 아님,, 차라리 key값은 어떤 뷰에서 어떤 위치에서쓰이는지를 중심으로 Namin하는게 확실하고 마음이 편함. ( 수정가능성 ▽ ) 4. 따라서지금 이걸 바꿀까 하는데 아..

최근 내가 개발하던 프로그램이 릴리즈 되면서, 급하게 SVN을 사용만 하다가 관리하게될 일이 생겼다....아무것도 모르는 상태에서 이것저것 형상관리 계획을 수립하는 과정에서 보기엔 굉장히 비효율적으로 보이는 SVN 파일시스템에 대해 그리고 SVN기능들에 대해 궁금증이 생겼다.. 단도직입적으로는. 지금 trunk폴더에 정상은 아니지만 용량이 꾀나 큰 IDE설치셋을 들고 있어서 빌드중 태깅을 하다보면 이것들이 전부 copy되는데 저장공간이 남아나나 의심을 하게되었다. 결론적으로는 태깅방법이 fullcopy가 아니라서 괜찮다는 것인데 아무튼 이 과정중에서 찾게된 좋은 svn 기능 관련 포스팅이 있어서 링크해본다. http://www.pyrasis.com/main/Subversion-HOWTO

이라고 한다. 구글 모든 제품의 소스코드를 저장소 딱 하나로 관리한다. 소스코드 관리도구는 Perforce 라는 것을 사용한다. 그러나 개인적으로는 Git 을 사용하고 Git -> Perforce 변환하여 올린다. 성능보다 코드의 읽기 쉬움이 중요하다. 코드를 최적화 하여 서버 비용을 100만원 아꼈다고 할지라도 변경된 코드가 읽기 어려워져서 개발자 인건비 300만원을 소모한다면 커밋이 안된다. 소스코드를 청소하는 팀이 있다. 인수한 회사의 소스코드도 모두 컨벤션에 맞추도록 변경한다. 구글은 개발 문서 거의 없다. 소스코드에 개발 문서 거의 담는다. 어떤 코드는 처음 300줄이 문서다. 클래스에 입력과 출력에 대해 자세히 쓴다. 퍼왔지만 이분도 퍼온거라고 한다. 퍼온곳은 트랙백에

1. OCP(Open-Closed Principle) 개방-폐쇄원칙모듈 구현은 확장에는 개방되어있어야 하지만, 변경에는 폐쇄되어 있어야 한다.이미 구현 해 놓은 로직에서 새로운 모듈 추가에는 유용하게 되어야 하지만 추가 한다고 해서, 구현된 코드가 변경 되면 안된다.이를 지원하기 위해서, 추상메소드, 인터페이스가 존재함.JAVA 개발시 유의할 점. (해당 모듈 개발 시, 같은 기능의 다른 모듈 을 붙일 수 있는가? 그렇게 만들 수 있는가? 생각하고 반드시 추상메소드, 및 인터페이스를 활용하여 작성해 볼 것.)2. LSP(Liskov Substitution Principle) 리스코프 치환 원칙기반이 되는 부모클래스를 참조하는 다른 클래스들의 경우 부모 클래스의 자식 클래스를 알아야 할 필요를 느끼면 안된..

패키지의 설계 원칙은 클래스의 설계원칙과 기본적인면에서 큰 차이가 없다. 현재까지 잘 알려진 설계 원리들은 다음과 같다. CRP (Common Reuse Principle) - 패키지의 클래스들은 전체적으로 재사용됨.CCP (Common Closure Principle) - 패키지의 클래스들은 동일한 유형의 변경에 대해서 닫혀있어야 함. 만일 클래스가 변경되어야 한다면 패키지의 모든 클래스들은 마찬가지로 변경되어야 함.그정도로 서로 강하게 결속된 것 들만 한 패키지로 모으라는 뜻 같다.SOC (Separation Of Concerns) - 여러 관심사를 혼합시키지 마라.세개 모두 High Cohension에 관한 얘기이다. 하나의 패키지는 하나의 클래스와 마찬가지로 Single Responsibility..