iamyhs

현재 진행형인 프로젝트의 총 개발리더의 입장에서,뷰단을 바라본다면 과연 이 프로젝트가 성공적으로 가는 프로세스인가,아니면 그 반대인가.

거의 900명에 육박하는 이정도 규모의 프로젝트는 앞으로도 접하기 힘든 프로젝트 일것 같다.

이런 대규모의 프로젝트의 전형적인 문제들인 커뮤케이션,의사결정,정치역학,인력관리등등의 논외로 하고, 내가 속한 뷰단에 초점을 맞춰보고 싶다.

프로젝트 초반에(현재는 중반에 접어들고 있는 시점이라 본다) 총 책임자의 골짱,몸짱,얼짱 이란 표현이 무척 와닿는다.

내 관점으로 재 해석하면 골짱의 역할은 모델링이고, 몸짱의 역할은 프로세스이고, 얼짱의 역할은 플렉스이다.


과연, 골짱과 몸짱과는 별개로 얼짱이 될수 있을까?
과연, 골짱,몸짱,얼짱이 효과적으로 분할 및 통합의 프로세스가 이뤄질수 없나?
과연, 얼짱을 위한 골짱(데이타 모델링)이 필요할까?
과연, 얼짱다운 화면이란건 뭔가?


솔직히 순서대로,

없다.
    아주 순진한 원론적인 이야기 이다.이중적이게도,현실에선 이렇게 할수 있는 방법을 찾아내야 한다.

있어야 한다.
    현실적으로,이건 기술의 문제라기 보다는 조직의 구조적인(커뮤니케이션,정치역학등) 인자에 더 영향을 받는것 같다.
    이 정도 대규모라면? 복잡다단하다.

없다.
    용어도 생소한 UI 컨설턴트중에는 뷰단을 위해 모델단의 변경을 말하는 이들이 있다, 꼬리가 머리를 흔드는 꼴이다.

시행 착오중이다.
    한도 끝도 없는 주제이다.
    이 부분은 선택한 기술과는 무관한 부분이 더 많다고 생각한다.플렉스 다운 화면이란 말에서, 플렉스를 다른 신기술 용어로 대체해보라.


다시 내가 총 결정권자이라면

과연 뷰단의 솔루션으로 선택한 플렉스가 올바른 선택인가?

개발편이성,유지보수성,비용면 등등에서 상대적 우위를 차지하고 있나? UI 가 이쁜건 알고 있으니 고만해라.

지금까지 내린 부분적 결론은 성급한 선택이었다.

현 시점에서 얼짱 역할을 맡은 뷰단은 기묘하게 성형수술을 시도한 추녀같다.수술비용도 만만치 않지만,아마 나중에는 코가 주저앉을지도 모른다.



아침에 Ryan Stewart 포스팅에 링크된  Flex Interface Guidelines 을 보다 문득 들었던 생각을 적어본다.

그리고, 다시 DATA MODELING FUNDAMENTALS A Practical Guide for IT Professionals - Paulraj Ponniah  pdf를 보고 있다.


ps
한달전쯤에 WallMart 의 GXXX 시스템의 구축의 프로젝트를 설명하면서 자사의 솔루션을 소개하러 HP 차장님 세분이 강좌를 한적이 있었다.

'EIS 같은 기보적인(?) 수준에서, IDM,EDW,DPP ' 도표를 보여주면서, 상당히 깊이있게 번갈아 가면서 진행을 했었다.

커뮤니케이션 문제를 어떻게 풀었냐는 질문에,총 리더와, 부 리더, 그리고 그 밑의 7개파트(?) 정도의 중간 리더가 프로젝트 전반에 걸쳐서 지속적으로 협력햇었다 라는

아주~ 일반적인 답변을 들었다.

대규모 프로젝트의 접근방식은 말 그대로 특화된 방법론이 필요한것 같다.수준이,차원이 틀리다.

1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
    기본 사양은 완성품을 고객이 보고 나서 결정된다.
    상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.
    하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
    다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
     디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
    주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
    이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1＋1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
       나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
      시스템 엔지니어에게 고객은 돈이다.
      프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
      웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
      시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
      프로그래머는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은,
프로그램의 목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
      운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
      따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번 일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이, 쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와  납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는 것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
      영업은 꿈을 말한다.
      시스템 엔지니어는 공상을 이야기한다.
      프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
      1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지 않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
      시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
      프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을 깨닫고 빨리 최종요구조건을 확정하는 것이다.
SE가 고객에게  사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
     개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
     개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
     개발비의 10%만이 프로그램의 개발에 사용된다.  


볼랜드 포럼의 링크 오래된 것이지만..... 프로그래밍 격언

ps
한참을 웃었다.조금씩 바꿔보자!

이번 프로젝트 SAP<->Flex 간의 파서를 만들때 Flex단에서(View) 파서를 만들어서 처리했는데, 구조상 Java(Controller)단에서 처리하는게 더 알맞다고 본다.

개인적으로 자바 파서로 포팅하면서 느낀건대,그 동안 내가 자바로 짜본게 뭔가 잠깐 생각해봤다.

사실 DB 프로그래밍이 거의 전부다.자바로 GUI 형태로 짜본건 몇년전 처음 배울때 예제수준이 전부였던것 같다.

그래서 요즘 조금씩 보는 책이 바로, Java™ After Hours: 10 Projects You'll Never Do at Work 이다.

제목 그대로다,실제 프로젝트로는 시도도 않을법한 프로젝트도 있지만 상당히 유용한 테크닉을 배울수 있는것도 많다.아니면 최소한 한동안 잊고 있엇던 부분들을 일깨우는 내용들이다.

Chapter 1.  Making Fish Swim in the Multithreaded Aquarium
Chapter 2.  Slapshot! The Interactive Hockey Game
Chapter 3.  The Graphicizer Image-Editing and Conversion Tool
Chapter 4.  Creating Stunning Graphics with Painter
Chapter 5.  Chatting on the Internet with the Chat Room
Chapter 6.  Who's There? Logging Access to Your Website with WebLogger
Chapter 7.  Running Any Program Via Remote Control with the Robot
Chapter 8.  Creating a Custom Web Browser in Java: The Browser Project
Chapter 9.  Typing Across the Internet: The Intercom Project
Chapter 10.  Getting a Graphical Weather Forecast: The Forecaster Project


심심풀이로 따라해보기 딱 좋다.

이 책을 보면서, 어 이거 리팩토링하면 쓸만하겠네 하면서 책장에 고개를 돌리니 ,

리팩토링책 아직도 퇴사한 회사에서 못 가져왔다.들은 바로는 회사 직인이 아주 선명하게 찍혀있다구 하더라.

그거 내 책이야!


ps1
내가 정말 신나서 프로그래밍해본게 언제인가?

사실 참여하고 있는 프로젝트에서 내 개인적인 작은 프로젝트를 만들어보고 있다.

프로토타입 수준의 코딩이지만, 만들어지면 꽤 쓸만할듯 싶다.

ps2
최근에 짧게 열정적으로 봤던 책은 작년 10월에 샀던 이클립스 플러그인 개발 책이다.플렉스 플러그인 확장팩을 만들겠다는 무모한(?) 생각을 하고 곧바로 뛰어가서 샀는데,아직도 헤매고 있다.

다 못본책이 옆에 한두권씩 늘어나는데도,아침 부터 책을 또 주문하는 내 모습은 뭐냐 ㅡㅡ;;;

올해도 책만 쌓아 놓기 시작하는건가.

마치 엊그제 봤던 '와탕카 시즌2 증거' 패러디 같은 내 모습이다.

바보같은 표정으로 SAP,Flex,Java 책을 들고 있는 ㅋㅋㅋ

1)시스템의 본질이 되는 부분인가?

2)이것은 도대체 무슨 의미죠?

3)도대체 어떻게 해야 하죠?

도대체 이 화면을 누가 볼것이고, 뭘 원하는가.

요구사항 변경은 당연하다.

효과적인 기술을 채용했는가.

기술에 묻혀있지는 않는가.

기술은 잊어라.

각개 격파할수는 있는가.

깨진 창문은 없는가.

삶은 개구리꼴이 되고 있지는 않는가.

주변 사람들을 웃겨주고 있는가.

넌 뭐하고 있는가.

누구냐 넌?

개발환경은 Flex,Java,SAP 이다

JCO를 이용해서 SAP 쪽 연결은 아래 여섯 단계를 거친다.

Step 1: Initialize the RFC Connection


Step 2: Create a JCo Repository


Step 3: Retrieve a Specific Function from the Repository


Step 4: Populate the Metadata Structures


Step 5: Execute the Call to SAP


Step 6: Read the SAP Return Structure


package com.sec.global.mysap;
import com.sap.mw.jco.*;
public class SAPJCOTest {
    public static void main(String[] args) {
        
        final String SAP_CLIENT ="100";
        final String USER_ID ="username";
        final String PASSWORD = "password";
        final String LANGUAGE = "en";        
        final String IP_ADDRESS = " xxx.xxx.xxx.xxx";
        final String SYSTEM_NUMBER = "00";
        
        JCO.Client aConnection;
        IRepository aRepository;

        System.out.println("JCO를 이용한 SAP 연결 테스트");
        try {
            
            aConnection = JCO.createClient(SAP_CLIENT,
                    USER_ID,
                    PASSWORD,
                    LANGUAGE,
                    IP_ADDRESS,
                    SYSTEM_NUMBER);

            aConnection.connect();
            aRepository = new JCO.Repository("SAP", aConnection);
            IFunctionTemplate functionTemplate = aRepository.getFunctionTemplate("RRW3_GET_QUERY_VIEW_DATA");
            
            JCO.Function function = functionTemplate.getFunction();            
            
            //I_INFOPROVIDER,I_QUERY,I_VIEW_ID,I_T_PARAMETER
            function.getImportParameterList().setValue("xxxxx", "I_INFOPROVIDER");
            function.getImportParameterList().setValue("xxxxx_Qxxxx", "I_QUERY");
            function.getImportParameterList().setValue("", "I_VIEW_ID");
            function.getImportParameterList().setValue("", "I_T_PARAMETER");
            
            aConnection.execute(function);
            
            System.out.println("연결 성공");            
        }
        catch (Exception ex) {
            System.out.println("연결 실패");
        }
    }
}


I_INFOPROVIDER,I_QUERY,I_VIEW_ID,I_T_PARAMETER 에 대한 세부 사항은 SAP 개발자가 명세서를 보내준다.

프로바이더 테크 네임, 쿼리 테크 네임 이런식으로 표현하고,Vairiable에 대한 세부사항은, I_T_PARAMETER(일종의 테이블 형태) 변수의 내용이다.
소스에서 I_VIEW_ID와 I_T_PARAMETER 값은 빈값인대,
이 값들은 쿼리테크 별로 다르다 I_T_PARAMETER 값은 보통 테이블 형태로 주어지고, I_VIEW_ID 는 공백인 경우가 많다.

이 예제는 연결 테스트 만이다. 실제로 Step 6 처럼 결과값을 가지고 가공을 해야한다.

이 과정에서 해당 리턴값을 어디에서 파싱할지가 아키텍처상 중요하다.

현재는,View(Flex) 단에서 파싱(다차원 구조이므로)하는 파서를 제작했지만, View단에서 파싱하는 것보다 Java 단에서 파싱하는 구조가 더 적절해 보인다.

SAPGUI_640 을 기준으로 설명한다면,

1)SAP GUI 실행

2)T-Code 입력, 예)/nse37

3)Funtion Module 이름 입력, 예)RRW3_GET_QUERY_VIEW_DATA

4)Display 버튼 클릭하면, Source Code 화면으로 이동

5)Break Point 찍고 싶은 라인으로 이동, 보통 결과값을 던져주는 마지막 행쯤.

6)Break Point 설정(Ctrl+Shift+F9 키, 혹은 위쪽 stop아이콘)

7)그런다음 실행(F8)

8)변수 값 설정, I_INFOPROVIDER,I_QUERY,I_VIEW_ID,I_T_PARAMETER

9)다시 실행(F8)

10)정상적으로 동작한다면, 새창이 열리고 중단점에서 멈춘다

11)오른쪽 탭에, variable1,variable2,local,global 탭 중에서 local 탭 클릭

12)던진 변수값과 리턴된 값들중에서 원하는값을 더블 클릭 예)E_AXIS_DATA

13)보고싶은 테이블을 더블클릭하면 해당 정보가 펼쳐진다.


Flex 디버깅 창을 열어서 직접확인하는 방법도 있다.

혹시 SAP 프로젝트를 하게 되면 무척 유용하게 쓸일이 있을꺼다.나 역시 기억하고 싶어서 다시 적어둔다.


ps
동영상 캡쳐까지 떠 놨는데, 문제가 생길것 같아서 올리진 않는다.

현재 SAP 프로젝트에 쓰고 있는 RRW3_GET_QUERY_VIEW_DATA FM이(Function Module) 스탠다드가 아니란다.

SAP 쪽 전문가가 아니어서 뭐라고 말할수가 없지만, 왜 이걸 이제 알았을까.

그 적지않은 관계자들은 무슨 생각을 한걸까.

이 참에 동료 개발자들과 "초난감 프로젝트의 조건"을 집필할까 한다.

여러가지 면에서볼때 책나오면, 벌써 대박 예감이다.

규모가 큰 프로젝트의 전형적인 문제점이 수면위로 그 몸통를 보여주기 시작한다.

이건 빙산의 일각일꺼란 생각이든다.

자,본격적으로 프로젝트 시작인거다.

SE나,SD 자격증을 취득할때보면 항상 시험문제중에 나오는게 있다.한쪽은 하드웨어이고 다른 한쪽은 소프트웨어 개발인대도 공통된 사항은 용어만 다를뿐 같다,그건 바로

maintainability, flexibility, extensibility, scalability,

물론 여기에 몇가지가 더 있지만, 오늘 회의를 주관한분이 유지보수성을 강조하면서 최대한 개발자의 flexibility를 지양하고 오히려 템플릿 형태의 개발 방식을 제시해줬다.
꽤 면밀하고 냉정한 판단을 한것 같다.

속단일지 모르지만,상황상 제품의 질을 따질 계제가 아니다.1년전부터 프로젝트를 시작했으니 상당한 준비기가인대,앞단에 아직은 그 성능과 안정성에서 만족할만 테스트를 거치지 않는 제품을 채택했다.

그 와중에 이미 일정을 정해져있고,규모 측정도 제대로 한걸로 보여지는데 리스크 관리를 어떤식으로 할지 두고봐야겠다.이정도 규모인대 여러 복안을 가지고 있으리라 기대한다.

회의때 이 부분을 대 놓고 물었었다.

"프렘임웍을 선택하면 복잡도는 커진다,어쩌면 투입되는 개발자들에게 교육시간을 따로 들어갈지도 모른다.이런 리스크는 고려되어졌습니까?"

"개발자를 더 뽑아야죠, 그리고 프레임웍을 선택하고 한번 익숙해지면 속도는 오히려 더 빠르리라 예상합니다"

다시한번 유지보수성을 일순위로 강조하면서 언급한 말이다.물론 동의한다.걱정되는건, 사내에서도 프레임웍을 적용해본 결과,처음은 적응시간이 필요하다.많던 적던간에 그리고 개개인의 저항감도 상당하다.

지금이야 그 효용성과 유지보수성의 힘을 느끼고 있지만,
이 프로젝트는 추가로 한꺼번에 들어오지도 않을껀데,개발자들을 위해서 만들어진 프레임웍의 효율성과 그 복잡도의 상관관계가 어떻게 될까, 고민된다.

어쨋든 덕분에 국내에 나와있는 관련 프레임웍과 컴포넌트 차트등등 모두 다 테스트해볼수 있게됐다.

인터뷰때 각 티어별로 프레임웍을 써서 붙였던 경험을 언급했는데 그게 화근(?)이 된것 같다.알고 봤떠니 날 인터뷰 했던 그분이 회의를 주관하더라.
내 이름과 딴분의 이름을 언급하면서 그 파트를 맡어라했다.뜨끔했다!! 아니 사실, 그 순간 도망가고 싶엇다.

회의실 분위기가 인상적이었다.사방 벽면에 씌어져 있는 각 파트들과 개발자들 이름과 진척율을 보니 나도 모르게 얼굴이 굳어졋다.

맥시멈 리스크에 좋은 기회다.아자!

ps
개발자 서버에 산출물만, 얼핏 봐도 몇십기가다.거기에 따로 개인폴더를 만들게되어있었고,각 사용자가 1기가씩 쓸수 있었다.

가장 인상적인건(좋다는게 아니다) 최신 영화,만화 올릴 폴더도 함께 있었는데, 그 안을 살펴보다가 올라온 날자를 무심코 봤다.

..... ㅡㅡ;;;;;;;  당최 여긴 뭐하는곳이냐.