상대방의 눈을 보면서 말하고, 가슴과 가슴으로 말하고, 대화에 고개를 끄덕이는 등 구체적인 대화방법이 있지만 간단하게 말한다면,
"진심으로 대화하라는 것"
이겠습니다. 이 글에서 이어질 장황한 설명을 줄여 기존의 개념과 다른 점을 핵심만 뽑아 보자면,
1. 기존 프로그래밍 언어의 패러다임이 컴퓨터 안에서 그쳤다면 OOLP는 생각하는 방식 자체를 일컫습니다.
2. OO의 개념인 것(상태, 행동)에서 목표가 추가되며, 상시적으로 다른 객체와의 연관을 고려합니다.
3. 주요 질문은 다음 세 가지입니다. 1목표(Object, 목적)는 무엇인지 2 객체(Object)는 무엇인지 {상태(데이터 구조), 행동(알고리즘)}은 무엇인지, 3 다른 객체와의 관련성(Link)입니다.
목적(Object), 객체(Object), 관계(Link)를 생각하는 방식이 바로 OLPP(Object Linked Programming Paradigm)입니다.
Fin.
장황한 설명의 시작(2020년까지 수정 예정)
1. GOTO의 유무
goto 없이 구현 못하는 알고리즘도 있습니다. goto는 프로그래머 취향에 따라 쓸 수 있었기에 코드의 가독성이 떨어졌습니다. 혼자 모든 것을 만들 수 있다면 goto 는 굉장히 좋은 명령어입니다. 기계어도 사실상 goto의 향연입니다. RETN도 따져보면 GOTO이지요. 순차, 조건, 반복의 구조화 프로그래밍이 나온 이유는 이런 goto를 제거하고자 위함이었습니다. 각자의 취향에 맞추지 않고, 코드를 위에서부터 아래로 읽고 싶은 것이었죠. 실무를 해 보면 goto의 유무는 중요하지 않습니다. 상대방을 실력을 얼만큼 파악하고 얼마만큼의 모듈을 떼어 주는지가 더 중요합니다. 아키텍트는 리턴값만 받으면 됩니다. 화이트박스 검증으로 코드 패턴은 알려 줄 수 있지만 해당 개발자가 걸었던 모든 길을 일일이 되짚을 필요는 없습니다. OLPP에서 GOTO의 유/무는 중요치 않습니다. 해당 개발자에게 떼어줄 모듈이 객체(Object)의 형태인지, 아닌지가 중요합니다. 해당 객체의 목적인 return 에 의하여 제대로 수행되는지 아닌지가 중요합니다. 해당 객체를 isolation 시킬 것인지 다른 객체들과 어우러져 사용될 수 있도록 할 것인지. link를 생각하는 것이 중요합니다.
2. 기존 OO와의 차이점
OO에서 말하는 Object는 autonomous agent(지능형 에이전트)에서 말하는 다음의 모습과 비슷합니다.
function Agent
Environment e; //환경
RuleSet r; //규칙의 집합
while(true) do //지속적인 동작
state = senseEnvironment(e); //환경의 감지
a = chooseAction(state, r); //행동의 결정
a.applyAction(e); //결정한 행동을 실행 //return(원문에서 추가됨)
end-while;
end-function.
[출처:knou.ac.kr]
OO에서는 Object(목적)과 Linked(관계)를 기본적으로 고려하지 않습니다. 객체지향 설계 원칙에 따라 설계할 때 해당 오브젝트를 호출하는 환경에 따라서 출력 형태가 달라집니다. 또한 수많은 useless object가 생성되는 이유는 Object(목적)을 고려하지 않았기 때문입니다. 이에, OO의 개념에 목적과 관계를 추가하여 생각한다는 개념이 Object Linked Programming Paradigm입니다. 이미 개발자들 몸에는 체득되어 있으나 개념적으로 정의되어야 지식 전달에 용이합니다. 또한 능동적 객체를 만들기 위해서는 목표지향적인 설계가 되어야 합니다.
3. 용어의 정의
개발 = 창조 : 개발은 새로운 것을 만들어 내는 행위입니다. 이에 창조와 같습니다.
프로그래밍=알고리즘 : 문제 해결을 위한 코드를 작성하는 과정을 뜻하는 말로 동의어입니다. 알고리즘의 종류는 많지만 https://brunch.co.kr/@hajunho/239
개발을 위한 알고리즘에 국한하여 말합니다.
알고리즘>자료구조 : 자료구조는 궁극적으로 문제 해결을 위한 도구로서 알고리즘의 하위 개념입니다. 그러나 객체의 주요 개념인 상태(속성)와 행동(행위)를 나타낼 때 상태를 말합니다. 한 객체의 행동의 다른 객체의 상태가 될 수도 있습니다. 실무를 결합하여 atomic한 개념으로 접근하면 primitive type 이 기본이며 그들을 이용하여 만든 자료구조가 객체 상태의 기본 골격이라고 할 수 있습니다. 이에 알고리즘이 자료구조를 포함하는 개념이긴 하나, 개념을 고려하여 앞으로는 자료구조와 알고리즘은 따로 분리하여 생각합니다. 규모도 꽤 크기에 분리하여 생각합니다.
4. 실생활에 적용
주도적으로 밥값 계산을 하는 이는, 돈이 많아서 그런 것이 아니라 돈보다 우정을 더 중히 생각하기 때문이다. 일할 때 주도적으로 하는 이는, 바보스러워서 그런게 아니라 책임이라는 것을 알기 때문이다. 말싸움 후에 먼저 사과하는 이는, 잘못해서 그러는게 아니라 주변의 사람을 아끼기 때문이다.너를 나서서 도와주려는 이는, 너에게 빚진 게 있어서 그런게 아니라 너를 진정한 친구로 생각하기 때문이다. 늘 너에게 좋은정보를 주는 이는, 한가하고 할 일이 없어서 그러는게 아니라 마음 속에 너를 두고 있기 때문이다.
SNS에서 찾을 수 있는 작자 미상의 글입니다. 객체는 실생활과 밀접합니다. 프로그래밍에서 객체의 최소 단위는 프리미티브 타입, 배열, 트리 등 자료 구조 단위가 많긴 합니다. 그러나 그것들이 모여 하나의 객체를 생성하고 운영체제가 보는 입장에서는 그들의 모임이 하나의 어플리케이션 객체로 발현됩니다. 사람도 똑같습니다. 사람의 구성하는 백혈구, 적혈구를 하나의 객체로 보면 그것들을 구성하는 화학식도 모두 객체(것, object)입니다. 그러나 의사, 간호사, 제약회사 연구원등 전문 의학인이 아니고서야 해당 객체가 다른 객체들에 대한 관계(link)를 알거나 목적(object)을 알기는 힘듭니다. 백혈구의 구성(object)은 몰라도 병균을 죽이는 목적(object)를 어렴풋이 알긴 합니다.
실생활에서 객체의 생각 단위는 할 수 있는 한
입니다. 능력이 된다면 객체를 구성하는 객체들을 쪼개고 쪼개어서 생각하고 그것들의 구성하는 객체(Object)와 목적(object), 그리고 다른 객체와의 관계(link)까지 전부 파악하면 됩니다. 개개인의 능력은 모두 다르니까요. 그러나 정규분포의 양 끝단이 아닌 평균치를 보았을 때 객체는 흔히 사람 단위로 보면 됩니다. 아빠, 엄마, 나, 동생 등... 한명 한명의 사람 단위 입니다. 각 객체를 이루는 구성 단위는 나누는 것에 따라 다르겠지만 크게 몸과 마음으로 나눌 수 있겠지요. JAVA 코드로 표현하면
private 몸 mBody;
private 마음 mHeart;
입니다. 자바 교육 할 때는 사람 몸 단위로 코드를 짜고 최소 단위는 단순 String 형으로만 해도 수많은 예제가 나옵니다. 그만큼 사람 몸의 구성에 대해서는 어릴적부터 교육을 하기 때문입니다. 5살 딸애도 머리, 어깨, 무릎, 발 등 신체 각 부위를 알고 있습니다. OLPP를 실생활에 대입했을 때 달라지는 점은 객체(Object)뿐 아니라 목적(Object)과 Link(관계)를 항상 고려하기에 존재 이유에 대한 질문이 달라집니다. 즉, 삶의 목적을 항상 생각해야 한다는 것입니다. 꿈일수도 있겠습니다. 그리고 다른 객체와의 관계도 항상 모니터링하고 스스로에게 질문을 하게 됩니다. 부모를 만드는 것은 부모 자신의 객체가 아니라 자식입니다. 자식이 태어나면서 부모를 만들게 되는 것입니다. 또한 아이를 키우면서 어른이 됩니다. 아이와 어른은 존재 목적이 달라질 수도 있습니다. OLPP에서 Object 2개(목적, 객체)와 link(관계)를 항상 질문해야 하는 이유는 여기 있습니다. 해당 객체의 목적도 달라지고 목적에 따라 객체도 변화합니다. 다른 패러다임이 객체 자체를 정의하려고 애쓴다면 OLPP로 생각하는 것은 판이하게 다른 방식으로 대상을 바라본다는 것입니다. 그리고 실세계를 더욱 잘 반영합니다. 프로그래밍에서는 제네릭 또는 템플릿이 비슷한 개념입니다. 그러나 객체형을 해당 파라미터로 받고 리턴을 해당 파라미터로 한다고 해서 해당 객체 자체의 목적이 바뀌지 않습니다. 관계된 객체가 변화하면 해당 객체도 변화하도록 생각해야 합니다. 판단 단위가 너무 작은 제네릭 모듈은 예외겠습니다. 큰 목적이 있는 객체겠네요. 백엔드 서버의 오토스케일이나 예약 서비스의 경우 예약이 밀리는 경우를 미리 고려해서 DB를 바꾸거나 관련 시스템을 구성하는 기술 스택이 모두 바뀌는 경우가 되겠습니다. 좀 더 개발자식으로 표현하면 코더가 보는 객체의 시각에서 아키텍트가 보는 객체의 시각으로 바뀌게 만드는 것이 OLPP입니다. 최근 아키텍트 위에 슈퍼코더가 나타나면서 실 구분은 없다고 봐야겠습니다만 이해가 쉽도록 해당 용어의 뜻을 살려 설명해 보았습니다.
난 누구인가?(Object)
나의 존재 목적은 무엇인가?(Object)
나와 관계가 있는 객체와 그 안에서 나의 역할은 무엇인가?(Link)
Object Linked Programming Paradigm
Programming paradigm은 프로그래밍을 보는 시각을 결정하는 안경과 같습니다. 빨간색 안경을 쓰면 세상이 빨갛게 보이고, 파란색 안경을 쓰면 세상이 온통 파랗게 보이는 것과 같습니다. 프로그래밍 패러다임은 크게 논의된 적이 없습니다. 깊게 공부를 하다 보면 결국 CPU와 메모리를 벗어날 수 없기 때문입니다. 너무 복잡해진 이론은 실무에 적용되기도 힘듭니다. 해당 이론을 공부하는데 너무 많은 비용을 지불해야 하기 때문입니다. 이에, 대표적인 Procedural programming languages, Object oriented programming language만 해도 충분한 안경이 됩니다. 최근 급부상하는 functional 혹은 logical programming paradigm도 있습니다. 이 장에서는 새로운 Object Linked Programming paradigm을 소개하고자 합니다. 좋아하는 설명 방식대로 두괄식으로 간단하게 한 줄로 표현하고 그치고 싶습니다. 그러나 컴퓨터를 잘 모르는 사람도 너무 간단하게 설명해 버리면 사색, 고뇌의 과정을 전혀 거치지 않는다는 경험을 얻었습니다. 정수만 가르쳐 준다고 해서 명확히 이해하는 것도 아닙니다. 이에, 일련의 구색은 갖추어 설명하고자 합니다.
세상의 모든 것을 뜻합니다. 한편으로는 목적, 반대의 뜻도 있습니다. Object Linked Programming Paradigm은 Object Oriendted 특징을 포함하며, 기존의 paradigm을 반대하는 뜻도 내포하고 있습니다. 또한, Machine code를 만드는 목적에 집중하는 Multi-paradigm입니다.
탄생 배경
개발을 가능케 하는 도구를 Programming language처럼 하나의 언어로 부릅니다. 언어의 주목적은 communication. 언어의 존재 이유는 소통입니다. programming language 의 목적도 컴퓨터와의 소통입니다. 소통을 배우는 가장 좋은 방법은 TTL 칩으로 CPU를 만드는 것이 아니라도
CPU 외에 FPGA를 이용해서 임베디드 MCU를 만들어 본다면 좋을 것 같습니다. Verilog 보다는 System C가 좋습니다. 디자인 하우스에 소프트웨어를 구워 달라고 부탁해 보면, 소프트웨어와 하드웨어의 경계가 없다는 것을 알게 됩니다. 상용 컴파일러나 리눅스, 윈도, 맥과 같은 OS를 혼자 만들 수는 없습니다. 오픈소스로 되어 있어서 컴파일러를 컴파일해 보거나 커널 컴파일은 할 수 있습니다. 자신만의 작은 리눅스를 패키징 해 볼 수도 있습니다. 이 모든 것을 상용과는 거리가 멀고, 교육용과 가깝습니다. 교육용에서 가장 좋은 일은 적당한 임베디드 하드웨어를 선정해서 하드웨어를 제어하는 Firmware를 만들어 보는 것입니다. 그렇게 하드웨어를 이해하는 소프트웨어 엔지니어가 볼 수 있는 세상이 있습니다. 교육용 디자인 패턴, 교육용 알고리즘, 교육용 개발 방법론 등에 정통하여 목소리를 내는 사람들이 많습니다. 또한 하나의 언어에 갇혀 사는 프로그래머도 많습니다. 이해합니다. 저 역시 전문성을 위해서 하나의 언어만 하고, 기초 회화를 하는 사람이 아닌 TED에서 발표할 정도의 실력을 가지는 것이 중요하다고 합니다. 프로그래밍 언어도 마찬가지라고 말합니다.
기업에서의 개발과 학교에서의 학위를 밟는 공부는 크게 다른 것이 없습니다. 해결이 어려운 문제에서 알고리즘 공부를 하다 보면 결국 다시 학교로 돌아가야 합니다. 공부의 깊이를 정하는 것이 중요합니다. 중요 논문에서 코드로 옮기는 연습을 해서 개발을 할 것인가? 다른 사람들의 개발을 하는 것에 도움이 되기 위하여 연구를 하고 실무적으로 적용될 수 있도록 기록을 남길 것인가? 많은 고민을 하게 됩니다.
AR, VR, AI(머신러닝, 딥러닝) 등 미래 먹거리가 나오면 또 그것을 해야만 할 것 같습니다. 돈 되는 기술 트렌드에 맞춰서 이래저래 공부의 방향을 바꾸는 후임을 많이 보게 되고 그것이 사회 현상이 되어 가는 것 같습니다. 결과적으로는 효율적이지 않은 사람들이 해당 산업에 모이게 됩니다. 치열해지는 경쟁은 뛰어난 사람을 더 뛰어나게 만들긴 하겠지만 효율적이지 않습니다. 힘들게 돈을 버는 사람이 있는가 하면, 뜬 구름 잡는 희망에 모여진 돈을 탕진하며 아무것도 하지 않는 사람들이 많아집니다. 아무것도 하지 않는다는 말은 아무런 결과물도 아무런 연구도 없다는 뜻입니다. 물론, 열심히 하는 것과는 별개입니다. 잘못된 방향이라면 아무리 멀리간 다한들 -(negative)만 될 뿐입니다. 개발 방법론보다 기술적인 이야기보다 더욱더 원론적인 이야기를 해야 잘못된 방향으로 가는 후임들에게 옳은 방향을 제시할 수 있었습니다. 똑같은 이야기를 하는 것이 지겹기도 하여 추상화시킨 API의 하나가 바로 Object linked programming paradigm(이하 OLPP)입니다. 객체지향 5대 개념을 강의하면서 SRP(단일 책임원칙), OCP, LSP 등 객체지향 설계 원칙이나 GoF 디자인 패턴을 차용해서 코드 뭉태기를 설명합니다. 안드로이드에 녹아있는 디자인 패턴들을 설명하면서 조금 쉬운 방법을 차용을 하나 더 쉬운 방법에 대한 목마름이 있었습니다. [객체지향의 정석]에서 설명했듯 어차피 객체라는 것이 "것"인데. 저와 당신이 곧 하나의 객체인데 굳이 자기 인생 자신이 책임을 져야 한다는 말을 이론적으로 복잡하게 설명을 해야 하느냐에 대해서 궁금했습니다. 자신의 상태는 이미 자기가 가진 method를 이용해서 제어하고 있을 텐데 캡슐화나 개방 폐쇄에 대해서 이야기를 해야 하는지. 사람이 하나의 객체라면 사람과의 관계는 이미 떨어져 있기에 느슨하고 모여서 같이 일할 때는 관계를 강화할 수도 있습니다. 다친 팔을 로봇팔로 교환하는 예를 들지 않아도 됩니다. 작은 생채기로도 객체지향 설계 원칙을 설명할 수 있습니다. 피딱지던 새살이던 우리 몸에 붙을 수 있는 인터페이스를 구현한 객체 들일 테니까요.(혈소판, 백혈구 등도 같은 방식으로 설명할 수 있습니다.) 개발 영역 자체가 사회 문제를 해결하기 위한 실생활의 영역입니다. 연구를 위한 소프트웨어 개발은 연구의 영역으로 분리를 해야 합니다. 실생활과 관련된 문제를 푸는 개발 영역의 프로그래밍 패러다임이라면, 모니터의 작은 영역이 아니라 우리 삶에 코드를 녹여낼 수 있다고 생각했습니다.
5
패러다임이라고 해서 거창한 것이 아닙니다. 높은 Layer(응용 프로그래밍 레이어)에서 개발하는 사람들이 목소리가 클 수도 있듯이, 낮은 Layer라고 해서 대단하다는 것은 아닙니다. 그러나 하위계층보다는 상위 계층의 개발자들이 더 대우를 받는 지금 상호 존중을 이야기하고 패러다임을 이야기하고 싶습니다.
소프트웨어 없는 하드웨어는 벽돌일 뿐입니다. 그러나 하드웨어가 없다면 소프트웨어는 담을 곳도 없습니다. 패러다임은 더욱 중요한 것이지만 사실 그렇게 중요한 패러다임은 단지 용어를 지칭하는 수준에 그칠 뿐이었습니다. 절차 지향이던, 객체지향이던 프로그램은 돌아가면 되는 것이기 때문입니다. 재사용을 이야기하면서 재사용되는 코드는 거의 없고, 클린 코드를 말하는 사람들은 클린 코드로 대단하고 커다란 프로그램(프레임웍)을 짜기보다 클린 코드를 강조하기만 합니다. 클린하고 이론적으로 완벽하다면 굳이 블랙박스 테스팅을 거칠 필요도 없겠습니다. 그러나 개발자 대부분은 실 상품이 만들어진 후 디버깅으로 대부분의 시간을 보냅니다. 물론, 화이트박스 검증도 합니다. 하드웨어 문제도 발생합니다. C/C++, JAVA, PYTHON, SWIFT로 완벽한 코드를 만들어도 CPU의 instruct set 자체가 문제가 있다면 어떨까요? 하드웨어까지 범위를 넓힌 상태에서 "클린 코드"를 완벽하게 설명해 줄 총체적인 이론은 존재하지 않습니다. 앞으로도 존재할 수 없습니다. 존재할 수 있게 하려면 하드웨어/소프트웨어 및 관련 개발 툴들의 버전을 FIX 해야 합니다. 이미 나온 기술들의 버그만 해결하고 새로운 기술은 만들지 말아야 합니다. 그러나 기술은 발전합니다. 기존의 문제들을 해결하면서 어쩔 수 없이 새로운 기술이 나오기도 합니다. 아니면 완벽히 다른 방식이 나와서 기존의 것들을 해결하기도 합니다.
이 글에서 "클린 코드"란 용어가 마음에 들지 않으면서 쓰는 것도 참 우습지만, 이해하기 쉬운 용어를 선택한 것뿐입니다. 하드웨어/소프트웨어를 아우르는 완벽한 클린 코드를 말해야 하는데 미래에도 그런 이야기는 존재할 수 없습니다. 해결할 수 있는 패러다임이 없었기 때문입니다.
6
객체지향과 절차 지향을 간단하게 설명하는 방법은 객체지향은 다형성, 추상화, 동적 바인딩, 상속, 클래스, 캡슐화 등 몇 가지 안되지만 "등"으로 표현해야 합니다. C++에서는 다중 상속이 되지만 JAVA에서는 지원되지 않습니다. 상속을 객체 복사의 개념으로 접근하면 우회 구현은 어렵지 않습니다. 인터페이스로 흉내 내도 됩니다. 어느 언어든 이미 나온 개념들을 구현하지 못할 것은 없습니다. 그러나 정해진 개념들은 지켜야 합니다. 규칙이라고 하지요. 그러나 이러한 규칙들을 말하는 것이 패러다임은 아닙니다. Procedural programming, Object Oriented programming, Functional programming, 이름이 비슷한 OLE(Object Liniking and Embedding)처럼 기술적 패러다임, 용어를 말하지 않습니다.
이보다 더 단순하고 강력합니다. 그리고 생활과도 관련되어 있고, 기술적이며 누구나가 해당 기술을 만들 수 있을 정도로 자유롭습니다.
1. OLPP는 코딩 방식이기도 하지만, 생각하는 방식을 일컫습니다. Object(것, 목적) + Link(연관)
2. 객체(Object) 및 대상(Object)이 있어야 합니다. 객체는 상태와 행동을 가집니다. 목적, 대상이란 목표, 궁극적으로 추구해야 할 것입니다.
3. Object은 "것", 그리고 개발할 "무엇"입니다.
역순으로 간단한 예를 들겠습니다.
모든 프로그래밍 언어를 이용해서 하나의 프로그램을 만들 수 있습니다. 소통은 어떻게 할까요? shared memory, FIFO, message queue 등 여러 프로토콜을 설계하고 만들 수 있습니다. 가장 간단하게 생각해보면 "파일"을 이용하면 됩니다. 동기화, 속도, 흐름 제어 등 문제 될 사항을 수없이 이야기할 수 있지만 해결책은 더 많이 이야기할 수 있습니다.
모든 것이 구체적으로 이야기되려면 목적이 있어야 합니다. 단순한 계산기 만드는데 많은 기술 스택을 이용할 필요는 없기 때문입니다.
객체지향에서의 객체는 기본입니다. 다만 OOP를 할 때 객체를 만들면서 항상 어느 객체와 관계되는지 고민해야 합니다. 각 연계된 부분이 flag를 이용하던, 파라미터로 공유하던, 혹은 하드웨어에 특정 레지스터를 객체 간 연관(link)에 이용하던 수없이 많은 communication 방법 고려 전 어디와 연결되는지 분명히 알아야 한다는 것을 항상 염두해야 합니다.
사람과 사람 사이에도 요리를 하는 후추통을 볼 때 그 안에 후추를 볼 때, 눈 앞에 돌고 있는 선풍기를 볼 때 선풍기뿐 아니라 모든 기계들을 객체로 보고 그 내부로 분해하여 생각하는 하나하나의 객체 모두. 해당 객체와 link를 고려한다면 생각하는 방식에 녹여낼 수 있습니다.
패러다임의 활용
- 새로운 프로그래밍 언어를 만들거나 객체지향 언어에 Funtional paradigm 인 람다식이 추가되듯이 기존 프로그래밍 언어에 차용되어 구현 될 수 있습니다.
- 생각의 방식이 변화 됩니다. 목적, 존재, 관련성에 관하여 끊임없이 생각하게 되고 해당 개념이 프로그래밍에 녹아듭니다.
- Writing 이 아닌 Reading 수준까지만 바라는 고급 언어(누구나 알아 들을 수 있는)프로그래밍 언어 습득의 경우 다음과 같은 방법으로 매우 빠르게 배울 수 있습니다.
1. 목표(Object)를 정합니다. 원하는 프로그램(프레임웍, 모듈 등) 이 해당 프로그래밍 언어로 만들 수 있는지 검토 합니다. 코볼 구문으로 웹을 짜는 프레임웍을 만들지 않는 이상 코볼로 웹을 짤 수는 없습니다.
2. 차례에서 객체(Object)를 뽑아냅니다. 객체는 2가지 입니다. 자료 구조(자료형, 구조체, 클레스, 인터페이스 등), 알고리즘은 알고리즘을 만들기 위한 흐름제어구문, 해당 언어 특유의 문법을 공부 합니다.
3. 짜여진 프로그램과 다른 프로그램을 이을 수 있는 connection(Link) 을 고려합니다. COM, AIDL, JNI, TCP/IP, shared memory, file 등 많은 고려사항이 있을 수 있습니다.
Fin.
이 아이디어는 수십 년 간 개발자와 이야기할 때 가장 중요한 첫 질문은 무엇을 만들 것인가? 였기 때문에 나왔습니다. link 의 경우 사회학에서 나왔다고 할 수 있습니다. 사람은 모여 살 수밖에 없고 모든 것은 그런 connection에서 나왔기 때문입니다. 최종적으로는 순수학문과 맞지 않는 paradigm 이 완성됩니다. 사람과의 약속에서 출발하는 수학에는 들어갈 수가 없고(수학은 근본적으로 틀렸다고 생각하기 때문에) 순수과학의 경우 사람이 주창하는 이론과는 달리 진리가 정해져 있기 때문입니다.
이와 파생하여 더없이 많은 이야기가 오가는 것보다 이미 나와있는 많은 것들이 더욱 단순하게 되었으면 합니다. 물론, 이 글은 패러다임을 증명하기 위해 틈틈이 할 논리 증명으로 지저분해지겠지만요.
이 패러다임으로 초심자의 많은 질문에 대해서 공통적으로 답을 할 수 있습니다. 어떤 질문이 오던, 뭘 만들건대? 해당 모듈은 무엇을 하기 위한 것인데? 해당 펑션은 무엇이며, 어디와 연결되어 있는 것이지?... 등 Object(것, 대상), Link(관계, 연결) 이론만 있다면 콜백이던 absract, factory, observer 어떤 디자인 패턴이던 쉽게 설명, 답변이 가능합니다. same page에 있지 않은 질문자라면 이 이론을 알려주고 재 질문이 가능합니다. 더욱 나은 질문을 받을 수 있습니다. 물론, 해당 모듈에만 국한되지 않고 하고자 하는 프로젝트를 왜 하는지도 질문할 수 있습니다. 해당 프로젝트가 개인 성장에 link 되어 있는지 물어볼 수 있습니다. 실생활에도 이용이 가능하고 생각하는 능력이 코딩 능력과 이어집니다.
대학생 독자를 고려하였으나, 각 회사에서 뛰어난 퍼포먼스로 여러 언어, 툴을 사용하여 개발하며 머리가 빠지고 있는 지인 및 생면부지의 개발자 동료의 스트레스를 낮춰줄 이론으로 다듬어 지길 바랍니다.
노파심에 또 말하지만, 여러 글에 걸쳐 이야기를 하고 있지만 Reading 할 언어와 Writing(주 언어)할 프로그래밍 언어를 잘 구분하셨으면 합니다. 스탯 잘 찍어서 망캐 되지 말고 휠 윈드 돌아야죠. 디아블로에서 바바 막 캐라서 캐삭 했었던... 우리 인생은 캐삭 못하잖아요 ^^ 오버 워치를 해서 최신 예를 들어야 하는데, 저도 노땅이군요.
댓글 없음:
댓글 쓰기
국정원의 댓글 공작을 지탄합니다.