개발이야기2013.05.29 22:31




●●● 장비 제어 개발 및 코딩에 대한 조언 몇가지 ●●●


장비 제어 SW 개발과 관련된 특수한 환경이 있기 때문에 , 일반적인 소프트웨어 개발과는 다른 점이 있을 수 있습니다.



◆  디버거의 사용은 최소화 하고 로그를 적극 활용하라 . 장비가 동작중일때는 디버거를 사용할 수 없고 문제 생길때마다 디버거에 의존하다 보면 소스 코드 분석 능력이 떨어지게 된다.


◆  구조를 잡거나 조건을 생각할때는 나무를 보지 말고 숲을 보라. 코딩을 할때는 숲을 보지 말고 나무를 보라.



◆  고객사 담당자가 원하는것을 얘기하면 원하는대로 해주려고 하지 말고, 그 기능을 원하는 진짜 이유를 먼저 생각해 보고 근본적인 원인을 찾으려고 노력하라


◆  고객사 담당자가 원하는 조건을 얘기하면 그 조건만 생각하지 말고 기존의 조건과 그것을 포함하면서  핵심을 관통할 수 있는 가장 단순하고 공통된 조건을 찾아서 적용하라


◆  한가지를 수정하면 10가지의 문제가 생긴다. 한가지 기능을 추가하면 기존의 10가지 기능에서 문제가 발생할 수 있다.  CheckBox 옵션 한가지는 모든 경우의 수를 2배로 늘어나게하고 버그의 가능성을 2배로 늘린다.


◆  같은 장비의 실행파일이 고객사 요구에 따라  2개로 분리되고 소스 코드를 개별 관리하기 시작하면 코딩 업무량은 1.5배로 늘고, 유지보수비와 버그는 2배로 늘어난다.


◆  신규 드라이버는 처음 설치 후 바로 양산 장비에 적용하지 말고 , 1대에서 충분한 테스트를 하라.


◆  프로그램을 배포할때는 실행파일만 배포하지 말고 , 버전 업 되면서 필요한 파일이 추가 되었는지 한번 더 생각하고 배포 하라.  고객사 담당자가 프로그램을 받아서 장비PC에 복사까지 했는데.. 실행조차 안되는 문제가 발생하는것은 가장 짜증나는 일 중에 하나이다.


◆  핵심적인 조건, 시퀀스, 데이터는 반드시 로그를 남길수 있도록한다. 특히 예외 상황으로 빠지는 조건에서는 무조건 로그가 남아 있게 한다. 동시에 로그 데이터는 최대한 적게 남도록 쓸데 없는 로그는 항상 정리하는 습관를 들이자


◆  UX 디자인의 기본은 사용자에 대한 배려심이다.


◆ 조건문을 만들때는 조건의 내용을 읽어가면서 이해가기 쉬운 어순으로 배열하라.



◆ 조건문은 조건들 중에서 가장 큰 대전제가 되는 조건을 우선 배열하고, 비슷한 레벨이면 가장 참(true) 이 되기 어려운 조건을 먼저 배열하라.



◆  전체 부정 !을 사용하는 조건문은 만들지 않는다.

GOOD : if( A==false && B==false && C==false)

BAD : if( ! (A || B || C ) )  : 코드는 짧지만 읽기가 어렵다.



◆  조건문의 비교식에서는 앞쪽에서 가변값(비교항목)을 넣고 뒷쪽에 상수(또는 기준값)을 넣는다.

GOOD : if ( A > 2 )

BAD  : if ( 2 < A ) :   조건문 읽기가 부자연스럽다.



◆  포인터를 리턴하는 함수에서 에러의 경우에는 NULL을 리턴하지 말고 , Dummy 데이터의 포인터를 리턴하라 . 프로그램 죽는것을 방지할수 있다. 대신 로그 기록은 필수 !  (Dummy데이터는 글로벌 더미 데이터 )


◆ XEdit를 추가할때는 항상 적당한 기본값(Default Value) 을 설정한다.


◆ 저장 하지 않고 화면을 빠져 나올때는 항상 데이터가 원상복귀 하도록 한다.


◆  고객사 담당자의 요구를 너무 쉽게 들어주다 보면 , 그것을 당연한 것으로 생각하게 된다.



◆  중복 코드가 만들어지는 순간 바로 함수로 만들어라! ( CTRL+C , CTRL+V를 하기 전에 함수로 모듈화 할수는  없는지 다시한번 생각하라 )



◆  Include Path 옵션은  C++빌더 전체 옵션에 넣지 말고 개별 프로젝트 옵션으로 넣어라


◆  모든 개발 프로젝트는 중반 이후에는 출구 전략을 생각하라 . 언제까지나 한 프로젝트에만 매달리면 그 프로젝트는 완벽해질지 모르지만 회사는 망한다.



◆  로그 내용  자체에 함수이름을 쓸때는 괄호()를 사용하지 말자.

코드중에서 함수를 검색하고 싶을때 로그 내용까지 너무 많이 검색되서 불편한 경우가 있다

GOOD  : LOG_PRINTF(“”, “DoFunc함수 실행 ")

BAD: LOG_PRINTF(“”, “DoFunc() 실행 ")



◆ 기능을 추가할때는 항상 기존의 데이터와 호환이 가능한지를 먼저 생각해보고, 이미 납품되어 양산중인 장비에 적용했을때 문제가 없을지를 항상 생각하라



◆ 시퀀스 동작에 문제가 발생했을때는 그 문제가 발생할수 있는 명확한 타이밍과 시나리오를 찾을때까지는 만족하지 마라






Posted by ICT 이성열

댓글을 달아 주세요

  1. 양승민

    좋은 내용이네요.. 장비 개발해오면서 고민하던 중요한 내용들은 다 있어요 ^^
    심지어 저는 주석도 통일화하도록 합니다. 예를 들어 임시로 수정했거나 나중에 재확인이 필요한 부분에는
    //@@ 로 시작하는 주석을 달도록 하는 형태입니다. 나중에 저것으로만 검색해도 굉장히 빠르게 접근이 가능하더군요.
    근데 사실 딜레마는 저런 좋은 내용을 아래 직원들에게 가르쳐도 잘 따르지 않는다는 점 ㅜ.ㅜ;; 인거 같습니다.

    2014.10.27 15:39 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 솔희

    안녕하세요~ 현재 장비제어 소프트웨어 개발 유지보수 업체에서 근무하고 있는 사람입니다.
    입사한지 이제 1년 되었는데요. 질문하나만 할게용~
    1. 현 직장에선 장비를 따라 인원이 출장을 가서 3~6개월을 지내다 와야 하는 상황인대요.. 혹시 이쪽 분야에서 출장을 잘 안가는 직장을 얻고싶은데. 경력은 얼마가 적당하며. 어떤 종류의 장비가 출장이 많지 않고 적당할까요? 어려운 질문이지만 많은 분들의 답변 부탁드립니다 ㅠ.ㅠ

    2017.02.17 17:09 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 이성열

      사실 장비 제어 소프트웨어 개발이라는 이 분야에서 출장을 잘 안가는 직장은 별로 없습니다. 다만 LCD 장비등 디스플레이 장비쪽은 최소 수개월씩(6개월정도?) 출장을 가게 되고요. 장비 종류에 따라서 1~2주 출장을 가는 분야는 있습니다.

      2017.02.24 01:16 신고 [ ADDR : EDIT/ DEL ]