NGMsoftware

NGMsoftware
로그인 회원가입
  • 매뉴얼
  • 학습
  • 매뉴얼

    학습


    기타 훌륭한 코더가 되기 위한 5가지 팁!

    페이지 정보

    본문

    안녕하세요. 엔지엠소프트웨어입니다. 훌륭한? 또는 멋진 코더란 주제를 가지고 이야기 해보도록 하겠습니다. 이 내용은 실제 현업에서 적용하기 어려운 몇가지 문제를 가지고 있지만, 이런 부분들은 이해하고 봐주시면 좋겠네요. 회사 정책이나 여러가지 외부 환경 요인으로 못하는 경우도 많으니까요. 그리고, 젊은 리더와 늙은 개발자 사이에서 이론 기반과 경험 기반의 충돌도 무시할 수 없는 문제입니다. 조직내의 문제에 대해서는 다른 글에서 좀 더 자세하게 썰을 풀어보도록 하겠습니다^^;

    fgeQh18.jpg

     

     

    1. 풀네임을 사용하자!

    맴버나 변수, 함수, 메소드의 이름은 풀네임을 사용해야 한다는 것입니다. usrInfo, memEqp, fnd, DT, DIT...와 같은 축약어를 사용하는 곳들이 많습니다. 심지어 uInfo와 같이 처음 코드를 분석하는 개발자가 전혀 알 수 없는 것들도 있습니다. 아주~ 오래전 텍스트 에디터에서 코딩하던 시절에는 축약어가 생산성을 높이는데 많은 기여를 해왔습니다. 일부 특수한 산업군에서는 프로젝트 코드 분석을 어렵게 하기 위해 축약어를 사용하고 해석하기 위한 별도의 테이블을 사용하기도 합니다. 요즘은 모든 IDE에서 인텔리센스(Intellisense) 기능을 지원하므로, 굳이 축약어를 쓸 필요는 없습니다. 관행적으로 이렇게 하는 경우가 더 많다고 생각하는데요. 대기업 프로젝트에서는 이런 낡은 관행을 바꾸기가 쉽지 않습니다. 스타트업 또는 이제 막 시작하는 회사라면 협업하는 팀원 또는 후임자가 분석하기 쉽도록 풀네임을 사용해보세요.

     

    2. 의미를 파악할 수 있는 이름을 사용하자!

    위에 풀네임을 사용하기로 했으면 이름을 얼마나 잘 짓느냐가 개발 생산성에 큰 영향을 미치게 됩니다. 코딩을 하다보면 1회성 함수나 로컬 변수와 같은 의미 없는 이름을 사용해야 하는 경우가 많습니다. 요즘 프로그래밍 언어들은 이런 문제를 해결하기 위해 익명 함수나 메소드 또는 분석하기 어려운 for 대신에 foreach를 사용하도록 하고 있습니다. 예를 들어 for문과 같은 경우 i, x, y와 같은 변수를 사용합니다. 이를 foreach로 대체하면 foreach (var user in users) 와 같이 명확하게 이해할 수 있는 코드로 변경할 수 있습니다. 이외에도 delay(todoFunctionName, 86400)나 웹은 setInterval(todoFunctionName, 86400)과 같이 코딩할수도 있습니다. C#은 Sleep(todoFunctionName, 86400000) 처럼 코드를 작성할겁니다. 파이썬, 자바, C#등등 언어는 다르지만, 모두 하루(1일)를 기다렸다가 todoFunctionName 함수를 호출합니다. 개발자 대부분은 86400이 하루를 의미한다는걸 알 고 있습니다. 하지만, 신입 개발자의 경우 이 숫자가 어떤 의미를 가지는지 알기 어려울겁니다. 스케줄러만 관리하는 배치 프로그램에서 이런식으로 작성하는것은 바람직하지 않습니다. 아래와 같이 작성하는게 좋죠. 물론~ 함수명도 의미를 알 수 있게 작성해야 합니다.

    const int SECONDS_IN_A_DAY = 86400;
    const int EQUIPMENT_REPORT_COLLECTION = 600;
    const int EQUIPMENT_RETICLE_COLLECTION = 1200;
    
    setInterval(todoFunctionName, SECONDS_IN_A_DAY);
    setInterval(runFunctionName, EQUIPMENT_REPORT_COLLECTION );
    setInterval(runFunctionname, EQUIPMENT_RETICLE_COLLECTION );

     

    3. 함수명은 반드시 동사를 사용하자!

    함수명은 반드시 동사를 사용해서 이름을 짓는게 중요합니다. 위 내용과도 관련이 있죠^^; 언어마다 차이가 있긴하지만 자바에서는 속성(Property)은 get, set으로 시작하도록 가이드하고 있습니다. C#은 속성이 하나의 함수로 동작하기 때문에 get, set을 사용하지 않습니다. 이런 언어에서 오는 특수성은 배제하고 일반적으로 함수나 메소드명을 작명할 때 동사를 사용하면 많은 이점을 얻을 수 있습니다.

    // 안좋은 예
    public object CustomerInfo() {
        // X
    };
    
    var customer = CustomerInfo();
    
    // 좋은 예
    public object LoadCustomerInformation() {
        // O
    };
    
    var customer = LoadCustomerInformation();

     

    get, set은 속성이나 로컬 데이타를 가져올 때 사용합니다. 데이타베이스나 타 시스템에서 가져올때는 load를 사용합니다. 이런 규칙들은 심플하면서도 중요한 것들을 알려줍니다. 이렇게 이름을 짓다보면 함수가 함수가 여러개의 역할을 수행하는지 쉽게 파악할 수 있습니다. OOP에서 함수는 한가지 기능만을 처리해야 합니다. 함수가 해야할 일을 동사로 시작하는 이름으로 짓기 시작하면, 자연스럽게 여러가지 일을 하던 함수를 역할별로 분리하게 됩니다. 위의 예처럼 load를 붙여주면 데이타베이스에서 고객 정보를 가져오는 일만 수행하게 되고, 함수 내부에 다른 일을 하는 코드는 자연스럽게 분리할 수 있습니다. 이는 OOP의 중요한 개념입니다.

     

    4. 인수는 3개 이상을 넘지 말자!

    이 주제는 인수뿐만 아니라 프로그래밍 전반에 걸쳐 있는 내용이기도 합니다. 사람은 동시에 일을 처리하지 못합니다. 내가 동시에 많은 것들을 처리하고 있다는 착각을 만들뿐이죠. 소프트웨어 품질 관리에서는 복잡도를 계산합니다. 관계, 깊이, 참조 수등등에 따라 복잡도는 올라가고, 이 값이 크면 클수록 코드는 리팩토링이 필요하게 됩니다. 물론, 동료가 이 코드를 봤을 때 어떤 의도록 작성했는지 파악하기가 어렵죠. 인수는 3개를 넘지 않게 작성하는게 좋습니다. 만약, 인수가 3개 이상된다면 Configuration 객체나 구조체를 만들어서 주고 받는게 좋습니다. 저도 그렇지만 인수가 많아질수록 "이 파라메터는 사용하는가? null로 넘겼을 때 문제가 없는가?"에 대해 항상 고민하게 됩니다. 이런 노력을 최소화하고 개발 생산성을 높이려면 명확한 이름을 제시하는 2~3개의 인수만 사용하는게 좋습니다.

     

    5. 참, 거짓을 인수로 사용하지 말자!

    앞서 언급한 함수는 하나의 기능만을 수행해야 한다는 것과 같은 의미입니다. 인수로 참(true), 거짓(false)을 넘긴다는 것은 그 함수 내부에 if ~ else가 있다는 뜻이고, 이 함수는 조건에 따라 2가지 일을 수행하고 있을수도 있습니다. 물론, 아닐수도 있습니다. 단순히 예를 들어 CustomerInformation(bool cdn); 이 있다고 생각해봅시다. 이 함수는 내부적으로 아래와 같이 2가지 기능을 합니다. 고객 포인트를 추가하거나 삭제하는거죠. 외부에 공개하는 함수는 내부 함수와 같이 따로 제공해야 합니다.

    public bool CustomerInforamtion(bool cdn) {
        if (cdn) {
            this.customer.addBunusPoint();
        } else {
            this.customer.removeBunusPoint();
        }
    }

     

    이 글의 제목과 같이 훌륭한 코더가 되기 위해 앞서 언급한 5가지 규칙을 지킨다고 해서 되는걸까요? 그렇지는 않을겁니다. 혼자하는 프로젝트가 아니라면 코드도 동료를 배려하는 마음가짐(?)이 필요합니다. 하지만, 안타깝게도 대부분의 SI 프로젝트들이 이런 간단한 규칙을 지키기 어려운 환경에서 일을 하고 있습니다. 축약어는 기본이고, 파편화되어 있는 개발 관련 문서들... 그리고, 회사 보안이라는 이유로 접근할 수 없는 것들도 존재합니다. 고객사는 이런 상태고요. 제가 다니는 회사는 공장 자동화 솔루션 및 프레임워크를 만드는 소프트웨어 회사입니다. 그렇다보니, 이런 규칙들이 잘 지켜지고 있는편입니다. 이 글과 같이 보면 좋은 글들은 아래에 링크로 남겨두니 시간될 때 한번 읽어보시기 바랍니다.

    [ 개발자라면 알아야 하는 기본 원칙 1 ]

    [ 개발자라면 알아야 하는 기본 원칙 2 ]

    [ 개발자라면 알아야 하는 기본 원칙 3 ]

     

    개발자에게 후원하기

    MGtdv7r.png

     

    추천, 구독, 홍보 꼭~ 부탁드립니다.

    여러분의 후원이 빠른 귀농을 가능하게 해줍니다~ 답답한 도시를 벗어나 귀농하고 싶은 개발자~

    감사합니다~

    • 네이버 공유하기
    • 페이스북 공유하기
    • 트위터 공유하기
    • 카카오스토리 공유하기
    추천0 비추천0

    댓글목록

    등록된 댓글이 없습니다.