'분류 전체보기'에 해당되는 글 256건

  1. 2007.12.06 Junit 사용법 2
  2. 2007.12.06 [sample] request 유입경로 URL만들기
  3. 2007.12.04 내가찍은 사진
  4. 2007.12.04 처음인가요? 그럼 이것부터 보세요^^ [JSP 2.0 기초부터 중급까지]
  5. 2007.12.03 개발의 갈등을 풀어주는 책 [Effective Java]
  6. 2007.12.02 2007 동경 국제 로봇전 / 일본 /참가
  7. 2007.12.01 구체적인 행동강력이 담겨있는 빨간책!! [XP도입을 위한 실전 입문]
  8. 2007.11.30 포토샵! 전문가 까진 아니더라도 조금 알고싶은데 [포토샵 CS]
  9. 2007.11.28 ERP 매직카펫을 나르게하려면 메뉴얼봐야죠 [ERP 프로젝트]
  10. 2007.11.27 클래스 구조를알면 openSouce도 잘 보입니다. [클래스 구조의 이해와 설계]

Junit 사용법

JAVA/framework 2007. 12. 6. 14:34
   
  • Junit 3.8
  1. public class TestConvert extends MyTestCase { // TestCase 상속
       
        private boolean t = DES.t;
        private boolean f = DES.f;

        public TestConvert(String name) { // 생성자
            super(name);
        }

        protected void setUp() throws Exception { // 한 메소드 수행전에 실행되는 메소드
            super.setUp();
        }

        protected void tearDown() throws Exception { // 한 메소드 수행후에 실행되는 메소드
            super.tearDown();
        }
       
        public void testConvertToBinary() { // 일반 테스트 메소드 - test로 시작작
            String str = "dddddddd";
            boolean[] text = null;
            boolean[] expected = new boolean[str.length()*8];
            boolean[] oneByte = {f,t,t,f,f,t,f,f};
            int j=0;
            for(int i=0, n=str.length(); i<n;i++) {
                for(int k=0; k<oneByte.length; k++) {
                    expected[j++] = oneByte[k];
                }
            }
           
            text = Convert.convertToBinary(str);
            assertByteEquals(expected, text);
        }
       
        public static Test suite() { // 테스트 수위트 형식식
            TestSuite suite = new TestSuite();
           
            suite.addTestSuite(TestConvert.class);

            TestSetup wrapper = new TestSetup(suite) {
                protected void setUp() {
                    oneTimeSetup(); // 테스트 수행 전에 호출되는 함수
                }
                protected void tearDown() {
                    oneTimeTearDown(); // 테스트 수행 후에 호출되는 함수
                }
            };
            return wrapper;
        }

        protected static void oneTimeSetup() {
        }
       
        protected static void oneTimeTearDown() {
        }


  1. public class TestAll extends MyTestCase { // 전체 테스트

    public TestAll(String method) {
            super(method);
        }
       
        public static Test suite() {
            TestSuite suite = new TestSuite();
           
            suite.addTest(TestDES.suite());
            suite.addTest(TestDESKey.suite());
            suite.addTest(TestDESExecution.suite());
            suite.addTest(TestTripleDes.suite());
            suite.addTest(TestAES.suite());
            suite.addTest(TestAesKey.suite());
            suite.addTest(TestAESExcution.suite());
            suite.addTest(TestSecAlgorithm.suite());
            suite.addTest(TestConvert.suite());
            suite.addTest(TestShiftRegister.suite());
            suite.addTest(TestECBmode.suite());
            suite.addTest(TestCBCmode.suite());
            suite.addTest(TestCFBmode.suite());
            suite.addTest(TestOFBmode.suite());
            suite.addTest(TestCTRmode.suite());
            return suite;
        }
       
    }
  • Junit 4.0

    • Jnuit 4.0 뛰어 들기

      • setupBeforeClass
      1. @BeforeClass
      2. public static void setupBeforeClass() throws Exception { }
      • test 메소드
      1. @Test
      2. pubic void ...() {}
      • 예외 테스트
      1. @Test(expected = IndexOutOfBoundsException.class)
      2. public void verify() throws Exception {
      3. Matcher mtcher = this.pattern.matcher("221010-5051");
      4. boolean isValid = mtcher.matches();
      5. mtcher.group(2);
      6. }
      • 제한 시간 테스트
      1. @Test(timeout=1)
        public void verifyFastZipCodeMatch() throws Exception{       
         Pattern pattern = Pattern.compile("^\\d{5}([\\-]\\d{4})?$");
         Matcher mtcher = pattern.matcher("22011");
         boolean isValid = mtcher.matches();       
         assertTrue("Pattern did not validate zip code", isValid);
        }
      • 테스트 무시
      1. @Ignore("this regular expression isn't working yet")
        @Test
        public void verifyZipCodeMatch() throws Exception{       
         Pattern pattern = Pattern.compile("^\\d{5}([\\-]\\d{4})");
         Matcher mtcher = pattern.matcher("22011");
         boolean isValid = mtcher.matches();       
         assertTrue("Pattern did not validate zip code", isValid);
        }
      • setup
      1. @Before or @BeforeClass
      • tearDown
      1. @After or @AfterClass
      • Suit
      1. @RunWith(Suite.class)
        @SuiteClasses({ParametricRegularExpressionTest.class,
              RegularExpressionTest.class,
              TimedRegularExpressionTest.class})
        public class JUnit4Suite {

        }

String requestURL = request.getRequestURL()+"?"request.getQueryString();


요즘이야 Eclipse로 모든 함수를 볼 수 있어
그것으로 그냥 모두 printout찍어본다면 시간이 좀 걸려도 알 수 있겠지만
그렇지 않은 경우라면 이것또한 찾는것도 일이다.


사용자 삽입 이미지
지난번 중국여행 갔을적에 만리장성에서 찍은  사진입니다.
비온날의 사랑~
아름답네요 . ^^


만약 지금 JSP라는 언어를 처음 배우기 시작한다면 어떤책을 볼까?
서평자가 처음 java를 배우기 시작할 무렵 봤던 책은 "지나와 함께하는 java" 를 봤었다.
2000년 이전 개발자라면 서평자와 동일한 책들을 봤을터이다.
하지만 시간이 참 많이 지났다.
이제 JAVA도 java가 있고 jsp가 있고 프레임웍이 있고 등등.. 그 복잡도와 난이도가 많이 높아져 버렸다.

마치 오락실의 DDR이 범 대중성을 갖추다가 메니아층의 등장으로 펌프같은 고난이도
오락기계만 남아버린것 처럼 초보자는 할 오락이 없고
개발회사는 오락에 대한 자금 투입을 열심히 하지만 자사고급 오락을 이용하는 계층은 메니아층으로 한정되어 버리게 되었다.

JAVA도 비슷한 현상이 발생하고 있다는 생각이 든다.
서평자의 경우 여태 개발의 끈을 놓치고 있지 않았기 때문에 다양한 기술과 테크닉들이 별것 아니게 다가오지만
시작하는 사람들에게는 "그래 프로그래머가 되보겠어!!"라는 자신감을 포기로 바로 맘바꾸게 만드는게 요즘 개발환경이 아닌가 싶다.

그러면 서평자가 말하려는 "최범균의 JSP 프로그래밍"은 어떤책이고 뭘 담고 있는것인가?
책은 초급자와 중급자를 위한 책이다.
떠벌이위한 책도 아니고 순수 개발에 매진하기위한 개발자들을 위한 개발 양서라는 점이다.

DDR처음하는 사람에게 버튼의 역할과 언제 발판을 눌러야 하는지를 요령껏 알려주고
DDR이 펌프로 넘어오면서 무슨 무슨 기능들이 강화 되었고 간단해 졌는지를 알려주고 있는것이다.

JSP는 그간 참 많은 진화를 거듭해 왔다.
단순 Script 언어에서 이제는 JSTL의 옷을 입고 web에서 OO를 논할만큼 많은 진화를 거듭해 왔다.
책은 이런 진화의 단계와 과정을 설명해 주고 있다.
또한 JSP는 "Hello word" 하나 찍기도 어찌나 어려운지.. 그 다양한 환경을 구성하는 방법들도 설명해 주고 있다.
위의 2가지만으로도 책은 처음 접하는 사용자들에게 도움이 될것이다.

● 책 내용을 살펴보도록 하자..
1장에서 6장까지는비교적 처음 JSP를 접한 개발자 분들을 위한 설명이 들어가 있다.
7장에 접어들면서 jsp프로그래밍의 약각의 변현된 기능들을 말하고 있다. (10장에 들어서는 jsp가 taglib를 이용한 javaBen의 활용으로 객체와 연결되는 것을 설명하고 있으고
자카르타 DBCP 커넥션풀과 같은 DB를 연결하는데 그냥 연결하는게 아니라 효율적으로 연결하는 방법을 알려주고 있다.
13장부터는 본격적인 예제소스코드가 여태 배운것을 실전에 응용해 볼 수 있도록 해주고 있으며
14장부터는 JSTL/ 커스텀테그 등을 이용한 jsp기본 컬러를 탈색시켜 여러 컬러를 함께 지니는 방법을 이야기 해주고 있다.
부록의 단계까지 가면 부록ABC는 부록이상의 재미와 개발의 팁! 들을 이야기 해주고 있다.

개인적으로 이런류의 책이 많이 팔렸으면 아직 많은 사람들이 개발에 흥미를 가지고 있고
개발을 해보려고하는 인력의 유입이 많이 발생하고 있다고 믿게 될것이다.
하지만 그렇지 않다면 IT시장의 엔지니어들은 살아남은것 자체만으로 경쟁력이 될 수 있다라는 다소 엉뚱한 생각도 들것이다.
그런데 이런류의 책이 잘 팔리지도 않았는데 시장에 엔지니어들이 많다면..
음.. 이것은 공포다 ^^!! 수많은 폭탄들이 자신의 엷은 지식으로 노력도 안하고 온동네 소스코드에 흔적을 남겨놓는것이니 말이다.

책은 다양한 레벨에서 봤으면 한다.
자신의 현 주소가 어디 즈음인지 파악도하고 관심있는것은 적용해보는것도 좋을것 같다.

이팩티브 자바는 원제목처럼 "유창하게 말하기"를 목적으로 하지 않는것 같다.
서평자의 경우 단순 말솜씨를 더욱 돋보이게 하기 위해 책을 보고 또봤다기 보다는
정말 내가 개발할때 궁해서 봤기 때문이다.
개발에 임하게 되면 의례 빠지는 갈등이 "과연 이렇게 만든 소스코드가 정상인가?" 하는 의문이다.
컴파일을 하고 구동을 시켜보면 결과는 원하는 데로 출력이 되지만 왼지모를 소스코드는
아무리 개선을 하고 연구를 해도 찜찜한것은 사실이다.
그래서 종종 openSource 코드들을 찬찬히 살펴보기도 하는데 그럴때면 서평자의 경우
심한 괴리감에 빠져들게 된다.
"내가 짠것도 java이고 이것도 java인데 왜 이리 쉽게 이해가 오지 않지?? ^^"
아마도 서평자가 아직 내공이 많이 않아서이기도 하고 openSource들은 그만큼 많은
단련의 과정을 거쳐서 된것일것이다.
본 서적은 이런 단련의 과정중에 중요한 몇가지를 왜 그렇게 구연해야하는지를
친절하게도 구체적인 소스코드를 가지고 사례를 들어주었다.
최초번역서를 보고 공부하게 된게 2003년이니 시간이 생각보다 꾀 많이 흐른것을 볼 수 있다.
다른 새로운책들로 책상이 많은 변화를 가져왔을법도 한데 아직 이책이 내 책상위를 떠나지 않는것은
내가 project를 하나씩 완료해 나갈때마다아직 내 머리가 project의 열기로 식기전에
내가 구연한 방법이 올바른지를 확인해 줄 수 있기 때문이다.

● 구독방법
빈맘으로 한번 읽는다.
  > 책의 구성은 단락 단락 되어있어  단락마다의 이슈제기와 문제 해결 방법등을 이야기 하고 있다.
  > 서평자의 경우 단락의 이슈가 처음 읽을때는 딴나라 이야기 였다. 공감가는게 10개도 안되었다.
     (당신도 그러하다면 나역시 정상인 이다.^^)
project완료후 다시 읽는다.
  > 책은 java의 여러 이슈를 다루고 있다.  하나의 project를 완료했고 거기서 발생한 자신만의 깊은
     상념의 시간이 필요할것이라고 본다.   바로 이때!! 이책을 봤으면 하는 바램이다.
     project에서 장고하지 않고 일정에 밀려 짧게 생각하고 넘어가벼렸던 메소들의 사용법을
     누군가 다시 집어주는것이다.
     음..
     물론 이단계에서 봐줄만한 책은 리펙토링도 있을것이다. 함께 복용하면 좋을것 같다 ^^

Project가 끝났다고 개발이 완료된것은 아니다.
이땅의 많은 개발자들은 Project완료후 또다른 Project를 대해야 하는 밴딩머신앞 기술자 일 수 있다.
밴딩머신을 떠나지 않는한 우린 지속적으로 Project를대하게 될것이고 비슷한 문제를 대하게 될것이다.
이제 그 비슷한 문제점을 습관이라고, 이전 Project에서 성공적으로 잘 돌아갔던 프로그램이라고
말하지 말고 개선의 여지를 찾아봤으면 좋겠다.
 책에 나온 57개의 항목이 모두 맘에 와닫으면 정말 대단하신 분이다. (박수^^)
 하지만 서평자 처럼 잘 몰라도 음냐.. 그냥 Project가 하나씩 완료될때마다 보고, 또한번 봤으면 하는책이다.

오늘도 진화를 거듭해하는 당신께 응원을 보낸다. 홧팅^^


Extreme Programming Installed XP도입을 위한 실전 입문
빨간책!
불온(火溫^^ [열정적])서적이면서 선동을 유도하며 구체적인 행동강력이 담겨있는 빨간책!!
Extreme Programming Installed (XPI) 는 구체적인 실행을 위한 가이드 라인이라 볼 수 있는
빨간책으로 처음 나에게 다가왔다.
 
세상에는 XP라는 이니셜을 달고있는 많은 이론들이 있지만 그중에 XPI는 XP의 무엇을 위해
태어나게 되었고 누구를 위해 이야기 하고 있으며 최종 종착지는 어디일까?
 
론 제프리즈는 XPI의 탄생을 떠벌이 기획자혹은 엔지니어들로 인해  왜곡된 XP를 바로 펴려고
자신이 경험한 프로젝트를 중심으로 본 서적의 이야기를 풀어나가고 있다.
XP는 보다 지능화되고 향상된 프로젝트를 만들어내고 개발자에게는 "배웠구나! 얻었구나!" 하는 보람을 주려고 탄생되었다고 생각한다.

하지만 몇몇 떠벌이들이 XP의 취지를 무시한체 XP를종이 몇장에 서술해 가며 되려 고객과 관리자, 개발자들을 고생시키고 있다.
바로 이 책은 C3 (크라이슬러 급여관리) Project를 배경으로 XP가 어떻게 전계되었는지를 이야기한다.
책에 등장하는 3명의 인물은 개발을 경험한 컨설턴트이다.
그들은 고객이 일의 진행사항을 보고 싶어하고 이런 저런 기능들이 추가되길 바라지만
돈주도 말못하는 애로사항을 이해 해주었고,  관리자가 관리는 하지만 별 성과없이 스트레스만 받는말못할 사정도 풀어주려고 하였고 , 개발자의 피패함을 방지하고 보람찬 일상이 되도록 배려해주고 있다.

이말을 다시 풀이하자면!!
진정 XP는 개발자에 국한된것도 아니고 관리자, 고객에게 국한되지 않는 IT전반에 걸쳐
Project라는 미명아래 움직이는 모든 사람을 위한 방법론 인것이다.
 
● 구독방법
본 서적은 다음과 같은 구독방법을 권고한다.
만일 이와같은 방법으로 구독한다면 당신의 회사는 변화하게 될것이다.
 
1. 최초 개발자가 먼저 읽는다.
   - 개발자가 먼저 읽고 각각의 중요한 부분에 연필로 믿줄을 긋고 자신의 의견을 달아놓는다.
   - 개발자는 이때 적당한 tool이 뭐가 있는지 함께 기술하는게 좋을것 같다.
 
2. 두번째로 관리자가 읽는다.
   - 개발자가 다 읽은 책을 관리자가 받아 개발자의 사상을 이해하며 자신이 보기에 중요한 부분을 믿줄 긋는다.
   - 관리자는 개발자의 생각을 읽으려고 노력을 한다면 이보다 더 좋은 효과는 없을것 같다.
 
3. 세번째로 고객(갑)이 읽는다.
   - 개발자와 관리자가 다본 책을 봄으로써 고객은 권한과 권리의 범위를 정확하게 이해한다.
   - 책임의 입장으로써 고객의 투정 한마디가 생각보다 얼마나 크게 작용하는지를 간접적으로 보게 되는것이고 이러함으로써 정말 프로젝트를 바라보는 시선을 갖춘다.

훌륭한 프로젝트는 개발자 한사람으로 만들어 지지 않는다.
고객, 관리, 개발자 모두 훌륭해 져아한다.

하지만 이런 방법론을 함께 공유하기란 쉽지 만은 않다.
그러기에 지각있는 분이 읽어 본 책이 무술교본에 나와있는 행동하나 하나임을 알고 따라하길 바랬
으면 좋겠다.
 
 
"XP실천사항들을 그 쓰인데로 완전히 마스터 했을때에 단순한 법칙을 넘어서 형을 깨트리고 자신만의 형을 창조하시게 될겁니다."
(책속에서...)


디/자/인/??
요즘 디자인 작업을 간간히 할일이 생겨 포토샵 CS를 보게 된다.
포토샵을 아주 모르는바는 아니다. 조금 안다. 그래서 책을 골라도 초급용 고르기에는 너무 아깝고
중급용 고르기에는 이럴 필요까지는 없는데 하는 망설임이 느껴지는게 사실이다.
그러던중 "포토샵 CS - 모든걸알켜주마!"을 보게 되었다.
 
책은 저자와 독자가 이루어가는 강의와 같다.
강의는 일방적이지 않고 독자의 성향에 따라 천천히 이뤄질 수 있고 하루밤 사이에 모든 강의가 끝날 수 도있다.
이런 강의의 결과는 독자를 저자와 동일레벨 혹은 비슷한 레벨까지 끌어올릴 수 있다는 장점을 가지고 있다.
"포토샵 CS - 모든걸알켜주마!" 는 이런 부분에 있어
초급이지만 아주 초급이 아닌 사용자들을 다양한 팁! 의 세계로 인도하고 있다고 볼 수 있다.
 
책은 포토샵이 주로 사용되는 사용처에 맞게 몇가지를 이야기 한다.
그 몇몇가지는 web디자인용, 디지탈카메라 편집용, 이모티콘및 아이콘 제작용 이다.
포토샵이 많은 분야에 활용되기에 서평자 같이 초보이면서 스스로 초보아닌척 하는 사람에게는 이런
다방면에 포토샵 활용방법이나 팁들이 중요할 수 도 있다. (즉! 본책은 전문가분들이 보시기에는 아닙니다.^^)

사용처 1 : web디자인용
 > web디자인용으로 이뤄진 부분중 좀 부실한 책의 경우 아이콘 만들기만 언급하는데
      본 책은 아이콘 만들기 (이모티콘)과 홈페이지 전체 구성에 대한 접근 방법을 같이 이야기 하고 있다.
     사실 홈페이지에서 아이콘하나 못만들 사람 없겠지만 구성을 잡는것은 정말 어려운 일이다.    
     책 저자는 이런 구성의 문제를 자신이 개발한 사이트를 이용한 web구성을 보여주고 있다.    
     (배경화면 만들기도 참 깜찍하게 소개시켜 놓았음)

사용처 2 : 디지탈 카메라 편집용
 > 서평자가 가장 필요로 했던부분이다.
     내가 찍은 2%로 부족한 사진의 맹점을 충분히 극복시키게 해주고 있다.
    사진이 번졌을때,  사진을 우아하게 만들때, 사진을 적당히 오려붙이고 편집할 때..  
    전문 디지탈 카메라 사진 편집이 아니고 일반적이지만 좋은 결과를 보고 싶다면 권장한다.
      (책은 디지탈카메라 아름답게 찍는 방법도 "책속에 책" 이라고 편집시켜 놓고 있다)

사용처 3 : 이모티콘 및 아이콘 제작용
 > web사용자를 위한 이모티콘 및 아이콘 제작인데 가만히 보고 있노라면 노력의 흔적들이 보인다.
    디자인에 중초보 ^^ 인 서평자가 조금 그 퀄리티가 높아졌다고 본다면 디자인 이제 하시는분들에게는
    많은 도움이 될꺼라 생각한다.


서평자는 엉뚱한 디자인 주문에 포토샵 다루는 일이 본 책을 통해 조금 늘었났다. ^^
패턴을 뜰 수 도 있게 되었고, 조금 나아진 배경화면을 만들어 낼 수 있게 되었다.
그냥 지금 약간 다룰줄 아는 포토샵을 조금더 잘 다루고 싶었다는 생각에 사본 책인터라 가격대비 만족이였다.
책은 여느 포토샵 책과 다를바  없다.
하지만 포토샵을 이용할 수 있는 분야를 보고 싶다면 그리고 그 분야에 어떻게 이용되는지 약간의 중, 고급 팁을 보고 싶다면
본 책을 추천한다.


1999년에 들어 많은 재조업들이 IT시장의 활성화에 힘입어 ERP를 도입하게 된다.
그당시 기업환경은 단위항목에 전산화가 적용되이있는터라 진정한 통합을 위한 과정을 비롯
부서간 상호관계의 필요성이 대두된것이다.
이때즈음 ERP는 "매직카펫"과 같아서 ERP로 올라타기만 하면 어디든 자유로이 갈 수 있을것만 같았다.
 
2005년 그로부터 벌써 6년여가 흘렀다.
ERP초창기에 도입한 부서들은 정착화가 되어있지만 중반에서 말부에 ERP를 도입한 기업들은 많은 문제를 겪게 된다.
자사가 도입한 EPR는 "매직카펫"이 아니라 나르지 않는 엉성한 양탄자에 불과하다는 사실을 알게된다.
"ERP 제품은 경쟁사와 동일한데 카펫이 나르지 않는다니..."
"무엇이 문제인가? 무엇이 문제였을까?"
 
아마 이런이슈가 너무 많이 부각되어 이런책의 탄생이 필요하게 되었을지 모른다.
 
책은 ERP도입, 적용, 활용 등에 있어 각 부서마다의 역할과 CIO와 CEO 등과 같이
경영조직에 적극적인 대응을 요구하고 있다.
각부서는 통합을 위한 도메인 설정과 정확한 자기업무 진단의 과정을 거쳐야 한다.
하지만 이 과정에서 업무진단의 미숙과 Process로 뽑아낼 구분에 대한 모호성때문에 ERP도입이 어려워지게 된것이다.
이는 ERP실패의 원인이 되는것이다.
책은 실패 point를 짚어내고  성공적인 ERP로 가기위한 helper역할을 해주고있다.
하지만 안타깝게도 책의 저자가 일본인이라는 사실을 알아 두었으면 한다. (기업조직이 일본임)
(아무래도 기업의 특성이 일본이기에 우리나라같이 일본+미국의 혼용 기업구조에서는 무비판 도입 보다는 필~! 을 느껴야 할것입니다.)
 
책은 크게 2부분으로 나누고 있다.
ERP성공을 위한 필수조건 / ERP성공을 위한 부서마다 해야할일 (구매, 생산, 판매, 인사, 회개, 업무, 기술 ..)
 
제 1부
1부는 ERP 전반에 걸친 성공의 조건들과 공식에 대해 이야기 한다.
- 빅뱅도입과 점진적 도입
 전사적으로 한꺼번에 고생해서 빠르게 도입해서 비용감소를 최소화 시키는것을 "빅뱅도입"이라고 한다.
 하지만 "점진적도입"을 하게 되었을 경우 기존의 시스템과 병행운영을 통한 비용발생도 역시 위험이라고 말하고 있다.
 물론 경영조직의 선택이지만 이리가든 저리가든 수고는 반드시 따라야 한다는 점이다.
- ERP는 CEO, CIO가 직접 챙겨야 한다. (130p의 ERP 성공기업의 특징)
 CEO가 직접챙겼을때와 그렇지 않았을때의 차이가 너무 확연하게 나타난다.

제 2부
에 대항하는 부분은 부서마다 할일을 이야기 한다.
정말 지극히 업무적인 부분이기 때문에 업무에 대한 도메인 이해없는 서평자의 경우 몇번이고 되돌아 봤던것 같다.
 
책은 길을 보여주지는 못한다 하지만 길을 느끼게 해주고 내 가는 길이 맞는지 틀린지 판단하게 해준다.
이미 ERP를 활용하고 있는 기업이든 부서든 본 책을 통해서 자사의 ERP도입에 자사평가를 해보는것도 좋을것 같다.
개념으로만 존재하는 ERP를 의지만으로 도입해 어려움을 겪고 있다면
나르지 못하는 ERP 매직카펫을 수선해서 많은 기업들이 가고싶은 그곳을 향해 잘 날라다녔으면 좋겠다.


다시 기술서적으로 눈을 돌려본다.
이미 충분히 알고 있다고 생각하는 부분부터 다시 짚어보는 의미에서 찬찬히 서적을 고르던중
"클래스 구조의 이해와 설계"에 손을 데게 된다.
 
책 겉표지를 찬찬히 살펴보니 책이 나에게 물어본다.
"프로그래머가 가장 많이 만지작거리는 클레스 제대로 만들고 있습니까?"
"음.. 글쎄 ^^"
 
개인적으로 개발에 임하였을때
얼마나 많은 소스코드를 만들어 내며 얼마나 많은 소스코드를 지워댔는지..
또 얼마나 많은 중복된 역할을 하는 클래스들을 아무런 꺼리낌 없이 만들었던지..
프로젝트가 늘어날때마다,  개발의 경험이 늘어날때마다 기교와 효과는 조금씩 자라지만
결코 완벽한 프로그램개발을 했다고는 말 할 수는 없다.
 
그래서 서평자는 가끔 선진 구조기법들을 보려고 openSource코드의 package의 구조를 tray 해본다.
그때마다 느끼는 좌절감은 상속의 관계와 오버로딩이나 오버라이딩, super, this 같이 충분히
고민하고 만들어낸 부분에서 쉽사리 끈을 잃어버리기 때문이다.
물론 하는 역할이나 구조를 모르는 건 아니지만 전체 프로그램에서 이런것들을 맞딱드리면
주춤해지는건 사실이다.
 
2%.. 뭔가 2%로 부족함이 느껴진다... (결코 여러분도 예외가 아닐꺼라 생각합니다.^^)
 
책은 클래스의 구조를 차근차근 설명해 주고 있다.
처음에는 명사분석법을 통한 객체 정의 지만 나중에 가면 그 객체들간에 연관관계와 포함관계를
이야기해 주고있다.
이야기 흐름에 이용되는 주된 도구는 UML이고 필자는 UML을 단순 표기법! 으로 간주하며
초급 개발자들에게도 쉬운 UML로 접근하는 배려도 잊지 않았다.
하지만 페이지 한장 한장 뒤로 넘길때마다 깊이가 깊어져가기에 UML을 잘 아는 분이 보더라도 좋을것 같다.
 
책은 클래스 구조뿐만 아니라 추가적인 정보들을 제공해 주고 있다.
1. class Diagram을 생성하는 방법
2. class Diagram에 엮여 있는 각종 화살표(?)들의 특징과 사용관계 (집합관계, 포함관계, 연관관계 , 의존관계 ..)
3. Sequence Diagram을 생성하는 방법
4. 하나의 UML을 가지고 java와 C++간의 표현방법
5. java와 C++ 에서 발생하는 언어적 차이도 발견하게 해준다.
 
책의 내용은 모두 열거할 수는 없지만 정말 개발자에게는 계륵조차 없는 통통하게 살오른 치킨이 아닐 수 없다.
java개발자라면 C++개발자라면 한번즘 봤으면 하는 권장한다.
 
서평의 끝에 왔다.
본 책에서 내가 갈등했었던것을 시원스래 정의한것이 있어 한구절 이야기 한다.
 
-- 유/도/속/성/ --
>> 책 98p : 유도속성은 값이 항상 다른 속성으로 부터 계산은 될 수 있지만 매번 유도속성의 값을 필요할때마다 계삭하는것은 비 효율적일 수 있다.
>> 유도속성을 정의하고 안하고는 개발자 몫이다.  이것을 한다고 서비스에 크게 티나지 않을 수 도 있다.
     하지만 개발이 가져다주는 갈등이기에 책을 느끼는 한 구절로 삼아본다.
1 ··· 14 15 16 17 18 19 20 ··· 26 

글 보관함

카운터

Total : / Today : / Yesterday :
get rsstistory!