Life/Software Engineer

기술 허세

자신의 지식이나 기술을 보여줄 목적으로
불필요하게 과도한 기술을 언급하거나 도입하여 것을
나는 '기술 허세'라고 부른다.
최신 유행하는 기술을 마구 늘어놓는 것이 전형적인 형태이다.

기술과는 관련이 없지만, 주변에서 '허세'라는 것을 종종 접한다.
뒷동산에 올라가도 너나 할 것 없이 전문 등산 장비를 몸에 두른다.
최소한 수십만원 때때로 그 이상의 가격이 붙은 등반의 명품을 차려입는다.
장비에 비해서 산이 초라하게 느껴질 정도이다.
자전거 동호외에 참여해도 다르지 않다.
가벼운 라이딩을 즐기는 사람이 장비는 프로들의 그것에 견주어 볼 만 하다.

그들은 비록 닭을 잡지만 소잡는 칼이 있음을 자랑하고 싶다.
수단은 목적에 이르게 하는 도구이다.
목적에 맞게 과하지도 부족하지도 않은 것을 택하는 것이 합리적이다.
합리적이지 않은 이유를 설명하는데 '허세'만큼 적절한 용어가 없다.

이와 같은 현상이 IT에도 있다.
해결할 문제에 대한 분석없이 첨단 기술이나 최신 유행을 떠든다.
예를 들면, 사내 데이터를 분석하는 문제에 대해서
데이터의 형태나 크기 등을 살펴볼 생각을 하지 않고
최근에 좀 주워들은 하둡, 스플렁크, 스파크 등의 지식을 나열한다.

이런 태도는 해결 방법의 선택을 매우 제한하기 때문에 문제가 된다.
쉽고 간단하게 해결할 수 있는 문제를 필요 이상으로 어렵게 만들 수 있다.
이전 단락의 '사내 데이터 분석'의 예를 다시 꺼내보자.

  • 간단한 것은 grep 등을 이용한 간단한 쉘스크립팅으로 분석 가능하다.
  • 엑셀과 VB스트립트로 웬만한 규모의 데이터는 손쉽게 처리하는 분을 본적도 있다.
  • 좀 더 복잡하다면, 자신이 익숙한 스크립트 언어(perl이나 python 등)으로 처리하는 것도 한 방법이다.
  • RDBMS 쿼리에 익숙하다면, RDBMS와 아름다운 쿼리로 멋지게 끝내는 것을 어떨까?
    쿼리 마스터의 능력은 위대하다.
  • 기존 방법으로는 해결하기 힘들어서 새로운 기술 중에서 골라야 하는 경우도 더러 있다.

즉, 자신(팀)이 가진 기술, 데이터의 형태나 크기, 원하는 정보에 따라서 다양한 해결 기술이 있다.
'닥치고 스파크'를 외치는 것은 전문가답지 않다.
단지, 최신의 기술인 스파크를 알고 있다는 알리고 싶은 허세스러운 행동일 뿐이다.
아니면 스파크 밖에 모르는 햇병아리임을 스스로 자인하는 꼴이다.

최신 기술을 안다는 것은 새로운 무기를 더하는 것이다.
기존의 좋은 무기를 쉽게 버리는 우를 범하지 않아야 한다.
상대성 이론과 양자 역학으로 패러다임은 이동했지만, 뉴턴의 고전 역학은 아직도 유용하다.
최신이 최선이 아니다.


데이터 싸이언스 계의 ‘싸이’ 김진영님의 이야기를 많이 참고하였다.

저작자 표시 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Theory/Programming Language

getter/setter를 올바로 사용하기

변수를 직접 접근하지 말고, getter/setter[각주:1]를 사용하는 것이 안전하다.
단, 변경될 가능성이 있는 getter/setter는 외부에 노출하지 않는다.
즉, 내부 구현의 변경하더라도 바뀌지 않을 getter/setter만 공개한다.


변경될 가능성이 없는 getter/setter만 외부에 노출한다.

public 속성을 지닌 모든 것(클래스, 함수, 변수 등)의 의도는
"마음대로 접근하라"는 의미만 있는 것이 아니다.
"내부가 바뀌더라도 이것은 변경되지 않는다"까지 포함한다.


getter/setter를 사용하는 것이 유연하고 일관성있다.

내부의 변경에 변수의 이름이나 규칙이 바뀔 수 있다면
setter/getter 같은 것을 한번 감싸는 것이 좋다.
예를 들면, "Null을 설정할 수 없다."라는 규칙이나,
불변성[각주:2]이 추가될 수 있다.

변수에 대한 규칙이나 제약이 없고 변수명이 절대로 바뀔 일이 없으면
변수에 직접 접근할 수 있도록 공개해도 괜찮을 듯 싶다.

그러나, getter/setter와 변수 직접 접근을 섞어서 쓰면 코드가 더러워진다.
어떤 변수는 'h = now.getHours()'
다른 변수는 'm = now.minutes'를 사용한다면,
일관성이 깨져서 불편하다.


getter/setter에 대한 오해

setter/getter 쓴다고 정보은닉이 되는 게 아니고 사실은 정보은닉을 망치게 됩니다.
저는 getter/setter 많이 쓴 것은 나쁜 냄새(bad smell)로 봅니다.
getter setter는 객체지향과 거리가 멀며 써야 할 곳은 한정되어 있다


문맥과 떨어져서 해석하면,
"getter/setter 보다는, 변수를 직접 노출하고 사용하는 것이 좋다"
라고 오해할 수 있다.


꼭 필요한 getter/setter만 공개한다.

원래 의도는 클래스 내부의 변수를 외부에 필요 이상으로 노출하는 설계는 나쁘다는 것이다.
필요 이상으로 노출하면 내부 구현이 밖으로 드러난다.
내부 구현을 변경이 이것을 사용하는 외부 모듈에도 영향을 미치게 된다.
getter/setter보다 변수를 직접 노출하는 것이 더 낫다는 것이 아니다.
내부의 변수에 대한 접근은, 어떤 방식이 되었든, 꼭 필요한 것만 공개해야 한다.
getter/setter가 많이 의존한다면 설계에 문제가 있는지 의심해봐야 한다.

  1. 언어에서 제공하는 getter/setter 포함. 예를 들면, C#의 property [본문으로]
  2. getter/setter에서 사본을 저장하고/반환하는 식으로 구현 [본문으로]
저작자 표시 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'Theory > Programming Language' 카테고리의 다른 글

getter/setter를 올바로 사용하기  (1) 2017.02.13
public, private 키워드가 필요한 이유  (0) 2017.02.08
  1. Favicon of https://justhackem.wordpress.com/2017/02/28/encapsulation-and-information-hidi.. 옮긴이 M/D Reply

    나는 응집 관점의 캡슐화 해석을 지지한다. Vector 클래스 설계법은 정보를 숨기지 않지만 이름을 가지기에 충분한 가치가 있기때문이다.
    https://justhackem.wordpress.com/2017/02/28/encapsulation-and-information-hiding/

Theory/Programming Language

public, private 키워드가 필요한 이유

public/private 키워드는 정보 은닉, 캡슐화 등에 도움을 주는 도구이다.

정보 은닉은 복잡하거나 변경 가능한 설계 결정을 안정적인 인터페이스 뒤로 숨기는 기본 설계 원리이다.
정보 은닉은 모듈을 분할하기 위한 기본 원리다.
모듈은 변경될 가능성이 있는 비밀을 내부로 감추고 잘 정의되고 쉽게 변경되지 않을 공용 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 한다.
캡슐화는 ‘온갖 방법의 숨기기’라고 생각하면 쉽다. 캡슐화를 통해 데이터를 숨길 수 있다. 그리고 구현 코드, 파생 클래스 또는 여러 가지의 것들을 숨길 수 있다.
- 알란 섈로웨이, 제임스 트로트, “알기 쉬운 디자인 패턴
캡슐화는 가해지는 변경에 대한 파급 효과를 일정한 영역 내부로 제한시킬 수 있다.
대부분의 컨텍스트에서 캡슐화와 정보 은닉은 동일한 의미를 지니다.

Information Hiding by 이터너티


private 키워드의 불편함을 호소하며 무용론을 펼치는 이들이 있다.

public/private 키워드는 필요없다.
구현하면서 접근자에 대해서 신경쓰느니 그냥 public으로 모두 공개하겠다.
필요하다면 주석이나 문서로 설명하면 충분하다.

라고 주장한다.

흔히 접하는 전형적인 부채의 한 유형이다.[각주:1]
당장은 편하고 빠를 수 있겠으나,
프로젝트가 커지고 복잡해지면 결국 이것이 발목을 잡는다.

프로그램의 곳곳에서 백여 번에 걸쳐서 주의력을 소진하는 것보다는 당연히 단 한 번만 주의를 기울이는 편이 훨씬 행복한 경우일 것입니다.

- Modern C++ Design

언어적으로 제약 조건을 기술하는 기능을 활용하면 여러모로 편하다.
컴파일러, 또는 자동 오류 검사 도구를 사용하여 제약 조건 위반을 바로 찾아낼 수 있다.
심지어, 요즘 개발 툴은 제약 조건을 반영하여, 자동 완성, 오류 검사 등으로 코딩을 도와준다.
개발자는 제약 조건에 신경쓸 필요없이 코딩에만 집중하면 된다.

  1. 또 한가지 흔한 유형은 테스트 코드를 전혀 만들지 않기 [본문으로]
저작자 표시 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'Theory > Programming Language' 카테고리의 다른 글

getter/setter를 올바로 사용하기  (1) 2017.02.13
public, private 키워드가 필요한 이유  (0) 2017.02.08
Theory/Data Exchange

JSON

JSON은 XML에 비해 상대적으로 가벼운 데이터 교환 형식이다.
C 언어의 영향을 받은 언어[각주:1]의 구조체/배열 형식과 유사하여 프로그래머에게 매우 친숙한 형태이다.
특히, 고대의 JavaScript의 일부에 토대로 두고 있어서 JavaScript와 그 구조가 매우 유사하다.[각주:2]


XML과 많이 비교되는데

공통점으로

  • 뛰어난 호환성을 제공한다. 많은 프로그램 언어와 웹, 소프트웨어에서 JSON을 지원한다.
  • 텍스트 파일로서 사람이 읽을 수 있다. 이는 디버깅에 매우 효과적이다.
  • 텍스트 파일임으로 이진 데이타보다 더 많은 용량을 차지한다.

다른점으로는

  • 상대적으로 가벼워서 구조가 간단한 데이타에 사용하기에는 적합하다.
  • 반면, DTDXML 스키마와 같이 언어를 정의하고 확장, 검사하는 도구가 부족하다.
  • 메타데이터와 네임스페이스를 제공하지 않는다.


JSON은 오브젝트(object)를 기본 요소로 한다.
오브젝트는 '{'로 시작하여 '}'로 끝난다.
오브젝트는 이름/값의 쌍을 포함한다.
이름/값은 사이에는 ':'이 들어간다.

{"foo":1}

오브젝트 내에 이름/값의 쌍은 ',' 구분한다.
마지막 이름/값 쌍에는 ','를 붙이지 않는다.

{"foo":1, "bar":"baz", "qux":true}


여러개의 값을 나열할 때는, 배열(array)를 사용한다.
배열은 '['로 시작하여 ']'로 끝난다.
값은 ','로 구분한다.

["foo", 1, "bar", "baz"]


이름(name)은 반드시 문자열(string)이어야 한다.
문자열은 큰따옴표(")로 감싼다.

큰따옴표 없이 사용하거나,

{foo:1}

작은따옴표(')로 감싸는 것 모두 올바른 표기가 아니다.

{'foo':1}


값에는 문자열, 숫자, true, false, null, 객체, 배열이 올 수 있다.


json.org의 예제를 첨부한다.

{
  "glossary": {
    "title": "example glossary",
    "GlossDiv": {
      "title": "S",
      "GlossList": {
        "GlossEntry": {
          "ID": "SGML",
          "SortAs": "SGML",
          "GlossTerm": "Standard Generalized Markup Language",
          "Acronym": "SGML",
          "Abbrev": "ISO 8879:1986",
          "GlossDef": {
            "para": "A meta-markup language. ...",
            "GlossSeeAlso": ["GML", "XML"]
          },
          "GlossSee": "markup"
        }
      }
    }
  }
}

두번째 줄 이름 "glossary"의 값은 객체이다.
세번째 줄 이름 "title"의 값은 문자열이다.
열다섯번째 줄 이름 "GlossSeeAlso"의 값은 배열이다.


2012/12/21 - [Theory/Data Exchange] - XML

  1. C++, Java, JavaScript, Perl, Python 등 [본문으로]
  2. JavaScript의 부분 집합으로 많이 알고 있는데, 일부 형식만 차용한 언어 중립적인 형식이다. [본문으로]
저작자 표시 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'Theory > Data Exchange' 카테고리의 다른 글

JSON  (0) 2017.02.01
XML 스키마  (0) 2012.12.28
DTD  (0) 2012.12.27
XML  (0) 2012.12.21
Life/Society

I am not scared. I just wish I had more time...

I am not scared. I just wish I had more time. To show mommy and daddy how much I love them.

- "Who is the most interesting person you've ever sat next to on an airplane?" 질문의 최고의 답변 중에서...

저작자 표시 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 14
Yesterday : 105
Total : 158,502

티스토리 툴바