core code 란?


    일반적인 의미에서는 프레임웍 혹은 솔루션의 핵심 부분을 말한다.

    해당 솔루션의 기술력과 생산성을 책임지고 있는 부분이다.


cose 가 정의 하는 core code 란?


    개발자가 평생을 스스로의 기량과 함께 성장시켜나갈 코드를 의미한다.

    회사 업무의 코어코드랑 물리적인 분리가 필요하다. ( 라이센스 문제를 분명히 해야함 )

    시간이 지나면, 젊었을 때 자신이 적립한 노력들의 대가를 추수할 수 있다.

    즉 니들의 미래다.


core code 의 요건.


    명료성. 재사용성. 중립성. 효율성. 심미성. 수명. 확장성 있는 언어.


    1.  comment free

        comment 없이 작성되어야 한다.

        미세하게 비직관적으로 작성된 코드는 당장 구현이 끝난 시점에서는 알기 어렵다.

        당면 과제라는 context 로부터 벗어나봐야 객관화가 가능하다.

        몇 달 지나서, 혹은 수준있는 동료가 직관적으로 파악하지 못하는 코드는

        잠재적으로 오류를 일으킬 가능성이 크다.

        이건 말로 때워서 될 문제가 아니다.


            "커피메이커에 뜨거운 물을 담으면 튜브가 손상될 수 있습니다."

            이런 경고문구 메뉴얼에 있어봐야 메뉴얼 안읽을 놈들은 안읽고 정수기에서 뜨거운 물 담을 놈들은 담는다.

            뜨거운 물을 담을 수 있는 튜브를 쓰는게 만드는게 가장 좋고,

            온도센서나 차폐기능을 만드는건 삽질에 가까운 방법이고,

            icon 정도로 필요한 정보를 전달할 수 있으면 naming 으로 해결하는 것과 비슷하다.

            뜨거운물_못쓰는_물통 이란 네이밍을 물통에 붙일 수도 있겠지.

            매뉴얼 안읽은 넘 책임이라고?

            그 고객은 두고두고 니네 제품페이지를 들락거리며 악플을 남길꺼다.


        그런데 만약 주석을 달았다면 어떻게 될까?

        비직관적 / 불합리한 인터페이스가 시스템어딘가를 변형 시켰을 것이다.

        이게 성능 / 유지보수의 용이성등 여러가지의 문제를 끌고 나오게 된다.

        논리적으로 심플한 방법들은 구현도 심플하고 성능도 좋게 마련이다. ( 대체로 )


    2.  설계의 과정이 코드로 녹아나야 한다.

        상수나 수열조합, 매직넘버, 미리 계산된 테이블 등을 생성시켜주는 과정이 코드로 만들어져 있어야 한다.

        계산기 쫌 두드리고 도형 좀 그려보다 수학공식 대충 만들면,

        대체로 나중에 반드시 그 짓을 또하게 된다. ( core code 일 수록 )

        한 번 할때 뽕을 뽑는게 좋다.

        나이들면 그런거 잘 못한다.


    3.  비슷한 일을 하는 다양한 함수 보다, 일반적인 요구를 대표하고 조합가능한 소수의 함수가 좋다.

        특히나 void return 일 경우 그 함수 내부의 context 중 외부에 노출했을 때 잇점이 있는 녀석을

        리턴해주고 필요없을땐 안쓰는게 낫다. ( C / C++ 유사 언어의 경우지만 )


    4.  극도로 최적화된 코드는 lowlevel module 로 분리해두는게 좋다.

        그렇지 않으면 다른 플랫폼에 가서 무용지물이 되어버린다. ( back-end 분리 )


    5.  마찬가지 이유에서 system 종속적이지 않은 프레임웍을 사용해야 한다.

        STL, boost, OpenGL 등등 ( atoi 니 fflush( stdin ) 니 하는 녀석들은 MS 빠돌이 전용 )

        하지만 성능이나 융통성을 위해서 다양한 플랫폼에서 각각 제공하는 built_in 코드들은 별도로 수집해두자.


    6.  debug 코드는 별도의 레이어로 분리되는게 좋다.

        logging 은 굉장히 비싼 작업이다.

        타이밍을 틀어놓기도 한다.

        코드는 깨끗해야 한다.


    7.  parameter 를 생성해주는 테스트 코드를 가지면 좋다.

        평가해주는 코드도 필요하다.

        이 또한 독립 모듈로 가져가야 한다.

        테스트가 힘들었던 situation 들을 최대한 살려

        복잡한 실행단계에서 특별한 위치로 jump 할 수 있는 비절차적 구조를 가져야 한다.

        ( 특히 게임 같은데서의 level / stage test 나 처리시간이 긴 프로세싱의 경우 )


    8.  device 를 사용하는 경우 emulator 가 필요하다.

        HEL 라고도 부른다. ( Hardware Emulation Layer )

        network 모듈의 dummy client 라든지, 여러 vender 의 장치들을 통합하기 위한 middle ware 라든지,

        DB adapter 나 VR / Graphic 카드들, 개발중인 하드웨어를 하드웨어 없이 테스트할 수 있게하는 객체를 말함.

        이게 개발과 생산의 시간을 극도로 단축해 준다.

        솔까말 객체지향이 촥 달라붙는 영역이기도 하다. 사실 middle ware 라는게 abstraction layer 니까.


    9.  가져다 쓰기 쉬워야 한다.

        헤더 파일 형식의 라이브러리 좋다.

        단일 헤더로 가겠다고 다 때려박는건 바보짓이다. 그건 분할 헤더파일을 머징해서 따로 릴리즈하는게 맞음.


    10. 성능 평가를 위한 benchmark 환경이 필요하다.

        파라다임은 늘 바뀐다. 영원히 바뀔꺼다. 그래도 최적화는 해야 한다.

        내일도 중요하지만 오늘도 중요하기 때문이다. 그래야 배가 덜 고프다.


    11. 모든 코드는 같은 룰로 깔끔히 정리되어 있어야 한다.

        함수의 이름이나 중괄호의 위치 같은걸 찾기 위해서 시선을 어지럽히지 마라.

        가장 생각을 적게 하고, 가장 덜 암기하고 찾아갈 수 있는게 좋은 코드의 배치다.

        최근 hot 하게 수정하던 함수는 제일 하단으로 빼 두면 좋다.

        코드 정리를 위한 파서나, 정리된 코드를 구사할 수 있는 에디터가 있으면 좋다.


    12. 관용적인 형태를 제외한 약어는 네이밍에 사용하면 안된다.

        암기 강요 행위다.


    13. 예제는 별도의 프로젝트로 꼭 필요한 만큼 다양하게 만들어져야 한다. ( 이경우 실행파일도 보관하는게 좋다 )

        초보자 학습용 예제를 만들면서 자신의 설계 구조에 대해 다시 한 번 생각할 기회가 온다.

        아이쉬 이건 괜히 두 번 불러야 되네. 이건 별로 쓸모없네. 그런것 말이지.