├── .gitmodules ├── CODE_OF_CONDUCT.md ├── COMMON └── README.md ├── CS └── README.md ├── ETC └── README.md ├── INTRODUCTION.md ├── LICENSE ├── PS └── README.md ├── README.md └── SOFTSKILL └── README.md /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule "git4newbie"] 2 | path = git4newbie 3 | url = https://github.com/rayleighko/git4newbie.git 4 | [submodule "web4newbie"] 5 | path = web4newbie 6 | url = https://github.com/rayleighko/web4newbie.git 7 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # 행동강령(CODE OF CONDUCT) 2 | 3 | 이 레포지토리가 최초의 제작 목적에 맞게 올바른 방향으로 나아가길 바라는 마음에 '행동강령'을 작성합니다. 만약 이에 반하는 내용에 대한 질문, 답변에 대해서는 그에 상응하는 불이익(무관심, 이슈 Close, 비판 등)이 가해질 수 있습니다. 4 | 5 | 우선 기본적으로 [Djangogirls COC](https://djangogirls.org/coc/ko/)를 준수합니다. Djangogirls COC의 '행사', '워크숍' 등은 이 레포지토리로 제한되어 설명될 수 있습니다. 이 내용을 '가급적' 준수가 아닌 '필시' 준수해주시길 바랍니다. 6 | 7 | 더불어 레포지토리의 특성상 '일방적 비난'보다는 '토론'을, '나'보다는 '우리'를 생각해주시길 바랍니다. 손 끝에서 전해지는 그 한 마디 문장이 누군가에게는 비수가 되기도 하고, 누군가는 'IT는 좁은 업계'라는 인식 덕분에 잘못 찍히면 커리어에 대한 마침표를 찍어야 한다는 두려움을 느낄 수도 있기 때문입니다. 8 | 9 | 그러니 자신의 권력 혹은 주변의 인맥을 자신과 혼동하여 상대방을 깔보지 말아주세요. 기분이 태도가 되지 말라는 말입니다. "노인은 죽고, 젊은이는 늙는다." 이 말처럼 당신의 작은 불씨는 사회로 돌아가기 마련이고, 그 불씨가 커져 다시 당신에게 돌아올 수 있다는 것을 명심하세요. 상대를 존중하라는 말입니다. 10 | 11 | 그리고 앞서 언급한 '일방적 비난'에 대한 내용은 수용하지 않습니다. 불편한 내용이라면 '삭제하세요', '틀렸습니다'가 아니라 '이런 부분은 이렇게 수정하면 좋지 않을까요?'라고 말해주세요. 12 | 13 | 마지막으로 이 레포지토리의 모든 내용은 주니어 개발자를 위해 작성됩니다. 당신의 기여 혹은 아이디어가 그들을 위한 것인지 생각해주세요. 물론 이 글을 읽고 계신다면 당신은 적어도 위의 내용을 부정적으로 생각하지는 않으시리라 예견해봅니다. 14 | 15 | "모두가 스스로 평등하다고 생각하기 전까지는 우리 모두 평등하지 않습니다. 하나의 문장을 작성할 때도 조심스럽게 작성해주세요." 16 | -------------------------------------------------------------------------------- /COMMON/README.md: -------------------------------------------------------------------------------- 1 | # 목차 2 | 3 | - Troubleshooting(문제 추적) 4 | - Google search(구글 검색) 5 | - Problem definition(문제 정의) 6 | - Translation(번역) 7 | - Replace in technical terms(기술적인 용어로 치환하기) 8 | - Problem solving with Datastructure, Algorithm(문제 해결) 9 | - Design(설계) 10 | - Design Patterns(설계 패턴) 11 | - Implementation(구현) - 작성중 12 | - Configuration Management(형상 관리) with Git - 작성중 13 | - Git 14 | - Git's Workflow 15 | - Efficient Development(효율적인 개발) - 작성중 16 | - Integrated Development Environment(IDE, 통합 개발 환경) 17 | - automation(자동화) 18 | - Object-oriented Programming(객체 지향 프로그래밍) - 작성중 19 | - Modularization(모듈화) 20 | - Encapsulation(캡슐화) 21 | - Function-oriented Programming(함수 지향 프로그래밍) - 작성중 22 | - Test-driven Development(테스트 주도 개발) - 작성중 23 | - 테스트 코드 작성 요령 24 | - Domain-driven Development(도메인 주도 개발) - 작성중 25 | - Application Programming Interface(API, 응용 프로그램 프로그래밍 인터페이스) - 작성중 26 | - Rest API 27 | - GraphQL API 28 | 29 | ## Troubleshooting 30 | 31 | 우리는 앞으로 다양한 문제들을 만나게 될 것이다. 하지만 이제 입문한 우리들은 문제를 어떻게 풀어야 하는지 아니, 그 전에 문제에 어떻게 접근해야 하는지조차 쉽게 가늠할 수 없을 것이다. 32 | 33 | 그래서 이번 장에서는 우리가 처한 상황에 대한 이야기를 시작으로 문제를 어떻게 정의해야 하고, 접근해야 하는지, 마지막에는 문제를 해결하는 방법을 고민해보려 한다. 34 | 35 | 처음부터 일이나 학습을 잘하는 사람은 없을 것이다. 이런 지능과 관련된 능력에 관한 자료 중에 (플린 효과](https://ko.wikipedia.org/wiki/%ED%94%8C%EB%A6%B0_%ED%9A%A8%EA%B3%BC)라는 것이 있다. 36 | 37 | 이는 자식 세대가 부모 세대보다 상대적으로 지능지수(IQ)가 높은 경향을 보인다는 효과인데, 결과적으로 주니어가 시니어보다 성장에 한해서는 상대적으로 더 나은 여건 속에 있다는 것을 알 수 있을 것이다. 38 | 39 | 더불어 사회가 성장하며 시니어에 비해 '학습에 대한 기회'가 증가한 것도 사실이다. 그렇다면, 이런 시점에서 우리는 우리가 가진 자원을 최대한 활용해야 한다. 천공 카드에 구멍 뚫던 시절, 전산실에 박혀서 교수 혹은 선배에게 얻을 수 있는 정보가 전부가 아니라는 것이다. 40 | 41 | 그렇다면 본론으로 넘어가 보자. 우리는 앞으로 어떻게 문제를 해결할 것인가? 지금까지 이런 고민을 했던 적이 있는가? 가령 토이 프로젝트 혹은 학교 과제를 개발하다 버그를 만나게 되면 문제 해결 과정을 거치는가? 이에 대해서는 좀처럼 답하기 어렵다. 42 | 43 | 하지만, 우리는 분명 문제 해결 과정을 거치고 있다! 비록 무의식 중이지만, 우리는 다음과 같은 프로세스를 거치고 있는 것이다. 44 | 45 | - 주제: 오늘 뭐먹지? 46 | - 나는 오늘 뭘 먹을지 모른다. 47 | - 먹을 것을 찾아야 한다(문제 정의) 48 | - 주변에 어떤 음식이 있는지 검색을 하자!(문제 탐색 방법 선택) 49 | - 검색 중(문제 탐색) 50 | - 그래! 이걸 먹자!(문제 해결) 51 | 52 | 이 프로세스와 같이 우리는 문제를 정의하고, 이를 바탕으로 문제 탐색 과정을 거치고 결과적으로 문제를 해결하게 된다. 그렇다면 어떻게 하면 이 프로세스를 보다 효율적으로 발전시킬 수 있을까? 이제부터 그 방법을 살펴보도록 하자. 53 | 54 | ### Google Search 55 | 56 | 우선 '검색'이라는 행위는 타자를 칠 수 있다면 누구나 할 수 있다. 하지만 검색을 '잘' 하기란 쉽다. 그래서 어떤 이는 개발 실력을 '검색 기술'이라고 이야기한다. 그만큼 검색을 어떻게 하느냐에 따라서 결과의 질이 달라지기 때문인데, 근본적으로는 '문제 해결 능력'을 이야기하는 것이다. 그러니 이번 장에서는 '문제 해결'을 중심으로 '검색'에 대해 생각해보도록 하자. 57 | 58 | 여기서는 다양한 문제 탐색 방법 중 'Google Search'를 이용해 문제를 탐색하는 방법에 대해 살펴보도록 하자. 검색을 할 때 가장 중요한 마음가짐은 '끈기'와 '인내'이다. 그 이유는 검색을 통해 원하는 결과가 나올 때까지 그 과정을 반복해야 하는 것이다. 59 | 60 | 더불어 개인 프로젝트를 하게 되면 사수나 주변에 의견을 구할 수 없을 수도 있다. 그래서 반드시 스스로의 힘으로 자신이 겪고 있는 문제를 해결하는 법을 알아야 하는 것이다! 61 | 62 | 더불어 끈기와 인내만큼 "어떻게 해야 제대로 된 결과를 얻을 수 있을까?"에 대한 고민이 필요하다. 가령 지금 가지고 있는 문제가 "이게 어떻게 동작하는지는 몰라도 서버에서 express라는 기술을 쓰는데, 클라이언트에 데이터를 동기적으로 전송하고 싶다"라면 어떻게 검색하면 좋을까? 63 | 64 | ``` 65 | 어떻게 동작하는지는 모르겠는데 express로 클라이언트에 데이터를 동기적으로 전송하는 방법이 있을까요? 66 | ``` 67 | 68 | 우리는 이렇게 검색하면 좋지 않다는 것을 어렴풋이 느낄 수 있다. 그 이유는 이미 "어떻게 해야 제대로 된 결과를 얻을 수 있을까?"에 대한 고민을 하고 있기 때문이다. 그럼 더 나아가서 생각해보도록 하자. 69 | 70 | ### 문제 정의 71 | 72 | 문제를 만나면 먼저 해야할 것은 '문제 정의'이다. 제대로 된 결과를 위해서는 제대로 된 문제가 필요하다. 그렇지 않고서는 우리가 원하지 않은 결과를 얻을 확률이 크기 때문이다. 73 | 74 | 실제로 개발을 할 때도 마찬가지다. 제대로 문제를 정의하고 이를 해결해야만 처음에 정의한 문제에 대한 답을 얻을 수 있기 때문이다. 그렇다면 어떤 방식으로 문제를 정의하면 좋을까? 우선 앞서 말한 주제를 바탕으로 생각해보자. 검색어에서 필요없는 내용은 과감히 지우도록 하자! 75 | 76 | ``` 77 | express에서 클라이언트로의 동기적인 데이터 전송은 어떻게 하나요? 78 | ``` 79 | 80 | 자, 이제 문제를 다듬어 다시 정의했다. 검색하는데 가장 중요한 건 '키워드'이기 때문에 문제를 정의할 때 우리가 원하는 키워드가 아닌(혹은 아니라고 생각하는) '어떻게 동작하는지 몰라요'를 제거했다. 그렇다면 다음에 필요한 건 뭘까? 81 | 82 | ### 번역 83 | 84 | 세계의 개발자들은 어떤 언어로 소통할까? 한글? 일본어? 그렇다! 바로 영어로 소통한다. 우리가 앞서 정의한 문제를 영어로 번역하는 작업이 필요하다. 그렇다고 영어를 공부하면서 개발을 공부할 필요는 없다. 물론 둘을 병행하면 좋지만, 근본적인 '문제 해결 방법'에 집중하도록 하자. 85 | 86 | ``` 87 | how to using the express synchronous communication? 88 | ``` 89 | 90 | 이대로 검색해도 원하는 결과를 얻을 가능성이 있다. 하지만, 여기에는 한 가지 걸림돌이 있는데, 바로 기술적인 부분에 대한 이해없이 작성되었다는 것이다. 91 | 92 | 이 다음에 소개될 내용은 개발에 대한 기반 지식의 필요성에 대한 내용이기 때문에 반드시 명심하고 넘어가야 한다. 왜냐하면 우리는 앞으로 기반 지식을 위주로 문제를 다뤄야 하기 때문이다! 93 | 94 | ### 기술적인 용어로 치환하기 95 | 96 | 이 글의 독자가 이미 개발에 대한 경험이 있다면, 손쉽게 혹은 애초에 검색어를 완성할 때 다음과 같이 기술적인 내용을 담을 수 있다. 97 | 98 | ``` 99 | how to using the synchronous request(or message) in express? 100 | ``` 101 | 102 | 여기서 다소 생소한 단어를 찾을 수 있다. 'request'라는 녀석이 그 녀석인데, 일반적으로 서버와 클라이언트의 통신에서 request(message)는 이름 그대로 '요청'을 나타낸다. 103 | 104 | 갑자기 무슨 요청을 하냐고 생각할 수도 있지만, 클라이언트와 서버는 요청(request)과 응답(response)으로 통신을 하기 때문이라는 것만 알아두고 넘어가도록 하자. 여기서는 클라이언트와 서버를 다루는 게 아닌 '문제 해결 능력'을 다루기 때문이다. 105 | 106 | 이제 우리는 '검색'에 대해 입문할 수 있게 되었다. 여기에 추가적으로 본인만의 노하우를 가미할 수도 있다. 가령 문장형이 아닌 다음과 같이 단어로 검색한다거나, 107 | 108 | ``` 109 | express synchronous request 110 | ``` 111 | 112 | 구글 검색 엔진의 다양한 키워드('', "", () 등)를 사용해서 말이다! 113 | 114 | ``` 115 | how to using the synchronous request in "express" '2015-2019'? 116 | ``` 117 | 118 | 더 자세한 내용은 구글에 'google search tips'를 검색해 [구글 검색 20가지 팁](https://www.lifehack.org/articles/technology/20-tips-use-google-search-efficiently.html)과 같은 자료를 읽어보는 거지만, 여기서는 이런 방법이 있구나만 알고 넘어가도록 하자! 앞서 말한 것처럼 중요한 건 검색해서 원하는 정보를 얻는 것이지 화려한 기술을 사용하는 게 아니기 때문이다. 119 | 120 | ### 문제 해결 with Datastructure, Algorithm 121 | 122 | 앞선 내용에서는 어떻게 하면 문제를 효율적으로 정의하고 탐색하는지를 살펴보았다. 그렇다면 마지막 주제인 '문제 해결'을 위해서는 어떤 고민이 필요할까? 그것은 바로 자료구조와 알고리즘에 대한 고민이다. 123 | 124 | 자료구조란 말 그대로 데이터의 구조를 정의할 때 주로 사용한다. 가령 데이터의 구조가 배열인지, 링크드 리스트인지, 큐인지, 스택인지 등을 이야기하며 다른 자료를 통해 살펴볼 것이다. 125 | 126 | 알고리즘은 문제의 로직을 파악하거나 문제를 해결하는 방식을 선정할 때 주로 사용한다. 가령 최단 거리를 탐색하기 위해서 Dijkstra algorithm을 사용하거나 트리를 깊이 우선 탐색(DFS), 너비 우선 탐색(BFS)하는 것이 그 예이며 마찬가지로 다른 자료를 통해 살펴볼 것이다. 127 | 128 | 여기서는 문제를 효율적으로 해결하려면 주먹구구식의 방법보다 미리 선행된 방법을 이용하는 것이 낫다는 것을 이해하고 넘어가면 된다. 위에서 언급한 자료구조와 알고리즘을 선정하는 기준이 익숙해질 때 '문제 해결'을 효율적으로 한다고 말할 수 있다는 것을 알고 넘어가도록 하자. 129 | 130 | ## Design(설계) 131 | 132 | 설계는 요구사항 정의 혹은 문제 정의 이후 진행되는 작업을 말한다. 앞으로 어떤 구조로 구현할지를 결정하는 것이다. 더불어 반드시 설계는 유지보수성과 기능 확장의 용이성을 보장해야 한다. 그러기 위해서 설계를 한다고 하는 것이 적절하다. 그러니 앞으로 설계를 할 때 무조건적으로 유지보수성과 기능 확장의 용이성을 고려하도록 하자. 133 | 134 | 우선 설계를 진행할 때는 사업적 목표를 정의해야 한다. 왜 새로운 소프트웨어를 만들어야 하는지, 이루고자 하는 목표는 무엇인지를 명확하게 정의해야 한다. 그래야만 팀원의 커뮤니케이션에서 불필요한 과정을 배제할 수 있고 협업 구성원들이 비즈니스를 쉽게 이해하게 됨으로써 각자의 문제에 집중할 수 있다. 135 | 136 | 더불어 사용자가 서비스를 어떻게 사용하는지를 유즈케이스를 고민해야 한다. 여기서의 사용자는 서비스를 직접 사용하는 이들을 말하는데, 사용자가 우리의 서비스를 어떻게 사용할지 고민해야만 유의미한 설계를 진행할 수 있다. 왜냐하면 사용자 관점의 고민이 깊을수록 예외로 인한 에러나 오류 가능성이 줄어들고 서비스 구조가 명확해진다. 137 | 138 | 마찬가지로 좀 더 현실에 가깝게 유저 시나리오를 짜야 한다. 일반적인 관점에서 무턱대고 시나리오를 짜게 되면 개발자는 하나의 모듈에 여러 기능을 담을 수밖에 없다. 이는 결코 좋은 게 아니며 앞서 말한 시나리오가 얼마나 현실에 가깝냐에 따라 구현해야 할 기능이 명확해져서 모듈이 단순해진다. 139 | 140 | 또한, 유지보수를 고려해 설계해야 한다. 누가 어떻게 유지보수할 것인지를 고민해야 하며 운영될 때 주로 어떤 일들이 일어나는지를 생각해 설계해야 한다. 그래야만 서비스의 생명주기를 관리할 수 있고, 장기적으로 운영되는 소프트웨어를 만들 수 있다. 141 | 142 | 다음으로는 행복한 고민이지만, 꼭 해야 하는 '서비스가 잘되면'이라는 고민이다. 이는 유연성과 밀첩한 관계를 가진다. 우리 서비스의 확장 가능성이 어디까지인지, 서비스가 잘 될 경우 구조가 붕괴(서버 다운 등)되지는 않는지를 명확하게 알 필요가 있다. 더불어 유연성의 고민을 대용량 트래픽에 할지, 신규 서비스 로직에 할지를 선택하는 것도 설계의 목적에 해당한다. 143 | 144 | 이와 함께 사업을 지속, 확장하기 위해서는 고객을 분석해야 한다. 사용자 로그는 서비스의 방향을 결정짓는 가장 중요한 요인이라고 할 수 있기 때문에 고객 로그 데이터는 관리될 필요가 있고, 마찬가지로 관리를 하더라도 로그를 무의미하게 남기고 지워버리는 행위는 쓸모없기 때문에 로그는 가공될 필요가 있다. 145 | 146 | 오버 엔지니어링에도 유의해야 한다. 자동화를 하거나 도구를 사용하는 목적을 명확히 해야 한다. 1회용 프로젝트에 정신적 자원을 쏟아 붓는 일 따위는 사업의 속도를 늦출 뿐만 아니라 개발자 개인의 불만을 증대시킬 수 있다. 147 | 148 | 마지막으로 앞서 언급한 기술적인 요소(자동화된 프로세스, 서비스 구조)에서는 비즈니스의 핵심적인 가치(기업가치, 금전 등)가 만들어지지 않는다. 결정적인 부가가치를 만드는 것은 '사람'의 생각과 개입이 필수적이기 때문에 항상 누가, 언제, 왜, 어떻게, 어느 부분에 개입되는지를 명확히 해야 한다. 가령 UX 디자이너의 개입없이 프로젝트를 3개월동안 개발했는데, 추후에 수정 사항이 생겨 모든 로직을 변경해야 할 때가 발생할 수도 있다. 149 | 150 | 이처럼 설계를 할 때는 개발자들도 다양한 인과관계와 비즈니스의 근본을 이해해야 한다. 그저 PM이 시키는대로 개발하고 있으면, 그 누구도 원하지 않았던 기괴한 서비스가 탄생할 수도 있기 때문이다. 151 | 152 | ### Design Patterns(설계 패턴) 153 | 154 | 설계라는 말에서 알 수 있듯이 설계의 근본은 건축학에서 왔는데, 건축학의 크리스토퍼 알렉산더가 패턴화된 문제를 해결하기 위해 '설계 패턴'을 고안하였다. 이때의 설계 패턴은 건축학에서만 적용되는 것이 아닌 이후 컴퓨터 공학에도 영향을 끼쳐 소프트웨어를 재사용하기 용이하도록 고안한 설계 패턴이 등장했다. 155 | 156 | 설계 패턴은 GoF(Gang of Four)라 불리는 소프트웨어 디자인 패턴의 선두주자 4명이 참여한 [디자인 패턴]()이 출판되면서 소프트웨어 영역에서의 설계 패턴이 처음으로 책을 통해 이야기되었다(최초의 디자인 패턴은 C++과 스몰토크라는 언어를 통해 설명되었다). 157 | 158 | 하지만, 소프트웨어를 만드는 데 있어서 디자인 패턴이 항상 적용되어야 하는 것은 아니다. 앞선 것처럼 패턴은 재사용성이 용이하고, 대부분의 문제를 해결할 수 있다는 장점이 있지만, 적재적소에 적용되지 않으면 오히려 소프트웨어에 불필요한 복잡성을 부여하게 되어 유지보수에 용이하지 않다. 하물며 시니어가 현란한 기술과 패턴으로 소프트웨어를 만들어놓으면 개발에 익숙하지 않은 주니어는 접근하기 어렵기 때문에 디자인 패턴을 적용하기 전에 항상 유지보수성을 방해하지 않는지 고민해야 한다. 159 | 160 | 패턴의 종류는 크게 '생성', '구조', '행동' 3가지 패턴이 존재한다. 여기서는 자세히 언급하지 않고 목록만 나열할 것이며, 추후에 다른 자료에서 각각의 패턴을 살펴보도록 하자. 161 | 162 | #### Creational Patterns(생성 패턴) 5가지 163 | 164 | - 추상 팩토리 패턴: 동일한 주제의 다른 팩토리를 묶어 준다. 165 | - 빌더 패턴: 생성(construction)과 표기(representation)를 분리해 복잡한 객체를 생성한다 166 | - 팩토리 메서드 패턴: 생성할 객체의 클래스를 국한하지 않고 객체를 생성한다. 167 | - 프로토타입 패턴: 기존 객체를 복제함으로써 객체를 생성한다. 168 | - 싱글턴 패턴: 한 클래스에 한 객체만 존재하도록 제한한다. 169 | 170 | #### Structural Patterns(구조 패턴) 7가지 171 | 172 | - 어댑터 패턴: 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌운다. 173 | - 브리지 패턴: 추상화와 구현을 분리해 둘을 각각 따로 발전시킬 수 있다. 174 | - 합성 패턴: 0개, 1개 혹은 그 이상의 객체를 묶어 하나의 객체로 이용할 수 있다. 175 | - 데코레이터 패턴: 기존 객체의 매서드에 새로운 행동을 추가하거나 오버라이드 할 수 있다. 176 | - 파사드 패턴: 많은 분량의 코드에 접근할 수 있는 단순한 인터페이스를 제공한다. 177 | - 플라이웨이트 패턴: 다수의 유사한 객체를 생성·조작하는 비용을 절감할 수 있다. 178 | - 프록시 패턴: 접근 조절, 비용 절감, 복잡도 감소를 위해 접근이 힘든 객체에 대한 대역을 제공한다. 179 | 180 | #### Behavioral Patterns(행동 패턴) 11가지 181 | 182 | - 책임연쇄 패턴: 책임들이 연결되어 있어 내가 책임을 못 질 것 같으면 다음 책임자에게 자동으로 넘어가는 구조 183 | - 커맨드 패턴: 위의 명령어를 각각 구현하는 것보다는 위 그림처럼 하나의 추상 클래스에 메서드를 하나 만들고 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행하는 것 184 | - 해석자 패턴: 문법 규칙을 클래스화한 구조를 갖는SQL 언어나 통신 프로토콜 같은 것을 개발할 때 사용 185 | - 반복자 패턴: 반복이 필요한 자료구조를 모두 동일한 인터페이스를 통해 접근할 수 있도록 메서드를 이용해 자료구조를 활용할 수 있도록 해준다. 186 | - 옵저버 패턴: 어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보해주는 것 187 | - 전략 패턴: 알고리즘 군을 정의하고 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 해준다. 188 | - 템플릿 메서드 패턴: §상위 클래스에서는 추상적으로 표현하고 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 패턴 189 | - 방문자 패턴: 각 클래스의 데이터 구조로부터 처리 기능을 분리하여 별도의 visitor 클래스로 만들어놓고 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 하는 것 190 | - 중재자 패턴: 클래스간의 복잡한 상호작용을 캡슐화하여 한 클래스에 위임해서 처리 하는 디자인 패턴 191 | - 상태 패턴: 동일한 동작을 객체의 상태에 따라 다르게 처리해야 할 때 사용하는 디자인 패턴 192 | - 기념품 패턴: Ctrl + z 와 같은 undo 기능 개발할 때 유용한 디자인패턴. 클래스 설계 관점에서 객체의 정보를 저장 193 | 194 | ## implementation(구현) 195 | 196 | 구현을 효율적으로 하는 방법에 대해 살펴보도록 하자. 코드를 구현하는 것, 197 | 198 | 384 | -------------------------------------------------------------------------------- /CS/README.md: -------------------------------------------------------------------------------- 1 | ## 목차 2 | 3 | - Data Structure - 작성중 4 | - Array 5 | - Linked List 6 | - Stack 7 | - Queue 8 | - Tree 9 | - Graph 10 | - Hash Table 11 | - Network - 작성중 12 | - Protocols 13 | - TCP 14 | - TCP's History 15 | - TCP header structure 16 | - TCP 17 | - HTTP 18 | - HTTP's History 19 | - HTTP header structure 20 | - HTTPS 21 | - TLS 22 | - HTTP GET & POST 23 | - HTTP vs HTTPS 24 | - TCP 3 way handshake 25 | - TCP vs UDP 26 | - Operating System - 작성중 27 | - Process 28 | - Single-Thread 29 | - Multi-Thread 30 | - Scheduler 31 | - CPU Scheduling 32 | - Sync & Async 33 | - Critical Section 34 | - Memory Management 35 | - Virtual Memory 36 | - Caching 37 | - Database - 작성중 38 | - Index 39 | - Normalization 40 | - Transaction 41 | - MySQL 42 | - NoSQL 43 | - Design Pattern - 작성중 44 | - MVC 45 | - Factory 46 | - Singleton 47 | -------------------------------------------------------------------------------- /ETC/README.md: -------------------------------------------------------------------------------- 1 | ## 목차 2 | 3 | - English - 작성중 4 | - Web related Open source - 작성중 5 | - Cloud for FE - 작성중 6 | - AWS for FE 7 | - Azure for FE 8 | - GCP for FE 9 | - Docker - 작성중 10 | - Container 11 | - MSA 12 | - NginX - 작성중 13 | - [front-end-handbook-2019](https://frontendmasters.com/books/front-end-handbook/2019/) 14 | -------------------------------------------------------------------------------- /INTRODUCTION.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | ## V0.0.5 - 2019. Dec. 13 4 | 5 | - V1.0.0이 완성되기 전까지 모든 조언은 환영입니다. 다만, 조언을 하기 전에 생각해주세요. 그게 진짜 이 레포지토리를 위한 길인지를 말이죠. 더불어 이 레포지토리의 존재를 부정하고자 한다면, 오픈 소스의 '자유'를 생각해보시길 바라며, 조언을 하고자 할 때 이상적인 조언만이 아닌 본인 스스로도 지키고 있거나 지켜왔던 '사실'에 근거한 것인지를 다시 한 번 생각해주세요. 그래야 이 레포지토리에서 가장 중요하게 생각하는 '실질적'이라는 수식어를 붙일 수 있지 않겠어요? 6 | 7 | - 규율에 대한 더 자세한 내용은 [COC](/CODE_OF_CONDUCT.md)에서 다루고 있습니다. 8 | 9 | - 기본적인 용어 정리: 주니어(개발에 대한 입문자 및 초보자, 연차 무관), 시니어(개발에 대한 숙련자, 연차 무관) 10 | 11 | ### 만들게 된 계기 12 | 13 | - 아직 실무를 겪어보지 못한 이들을 위해 작성됩니다. 실무에서 필요한 역량(공통 지식, PS, CS부터 소프트 스킬, 글쓰기, 어휘력까지)에 대한 형식적인 이야기 풀이가 아닌 그것들을 갈고 닦기 위한 구체적인 내용을 담고자 합니다. 14 | - 세상에 완벽한 사람은 없습니다. 모든 것을 다 알 것 같은 시니어도 부족한 게 있고, 아무것도 모를 것 같은 주니어도 배울 게 있다는 말씀! 그러니 이 글을 읽는 그대가 누구라도 항상 겸손한 태도를 지니도록 합시다! be humble! 15 | 16 | #### 시니어 혹은 인사담당자에게 17 | 18 | 요즘 같은 세상에서 구현만 잘한다고 취업이 되나요? 그렇다고 알고리즘만 잘한다고 취업이 되나요? 우리는 그나마 안정적인 수입을 가지고 일하고 있습니다. 하지만, 우리의 주니어들은 어떨까요? 그들은 우리의 상식에서 벗어난 정말 혹독한 환경에서 진로를 고민하고 있습니다. 주니어에게 현실은 냉혹합니다. 그렇다고 우리 주니어들이 방향성없이 당장의 취업을 위해 주먹구구식으로 학습하면서 이상한 버릇이 든다거나 추상화나 클린코드를 지양하는 태도를 갖게 된다면 그또한 얼마나 슬픈 일이겠습니까. 19 | 20 | 혹시 당신은 회사라는 집단은 제품을 만들기 위해 가능한 빠르게 배우고 요구사항을 찰떡같이 알아들을 인재를 원한다고 생각하시나요? 맞습니다. 그렇기 때문에 우리는 주니어를 뽑는 사소한 일조차 PS니 CS니 다양한 잣대를 요구하는 것이지요. 물론 소프트 스킬이나 커뮤니케이션 능력이 얼마나 좋은지는 그 이후의 문제구요. 당연합니다. 구현조차 못하는 개발자를 뽑고싶은 사람은 어디에도 없으니까요. 21 | 22 | 하지만, 우리는 한 가지 주의해야 할 게 있습니다. 과연 당신의 집단은 주니어를 채용할 때 객관적인 지표(코딩 테스트가 객관적인가요?)를 제시하고 있을까요? 여기에 대한 답은 이 레포지토리가 만들어지는 가장 큰 이유기도 한데, 사실 그건 객관적이지 않을 확률이 큽니다. 23 | 24 | 그러니 다시 본질적인 문제를 해결해보자구요. 아마 이 레포지토리를 읽고자 하신다면 이에 대한 궁금증을 해결하고 싶으실 거에요. 하지만 이 곳에는 답이 없습니다. 무수히 많은 질문들의 결과만이 존재할 뿐이죠. 그러니 이제 생각해 보는 겁니다. 과연 이 레포지토리에서 말하는 개발자와 내가 생각하는 개발자는 어떤 차이가 있는지 말입니다. 그 간극을 해결하면 정말 당신이 원하는 인재를 뽑을 수 있을테니까요! 25 | 26 | #### 주니어에게 27 | 28 | 우리는 정말 취업하기에 혹독한 환경에 처해있습니다. 그렇다고 아무 회사나 들어가기 겁나시죠? 잘못했다가 파견직이 되어 여러 이해 관계에 휩쌓인다거나 성장의 가능성이 없는 곳으로 갈까 전전긍긍하지는 않으셨나요? 29 | 30 | 그런데 그런 고민 이전에 당신은 생각해야 할 중요한 한 가지를 잊고 있었습니다! 회사는 '일'을 하기 위해 가는 곳이지 '놀기' 위해 가는 곳이 아니라는 것을요! 만약 당신이 원하는 회사를 가려 하거나 원하는 연봉을 받고자 한다면, 그에 합당한 자격을 가져야 하는 건 당연합니다. 그런데 우리는 그 자격을 갖추고 있을까요? 주변에 큰 회사에 다니는 주니어들은 이런 타이틀을 가지고 있기도 합니다. '**대학교 4년제 출신**', '**6개월 국비지원 학원 수료**' 혹은 '**OOO 학원 출신**'말이죠. 그런데 그들이 출신덕분에 취업을 할 수 있었을까요? 그렇게 생각하신다면 이 레포지토리를 나가서 학원을 등록하세요! 31 | 32 | 여기서 말하고자 하는 것은 취업을 위해 한 번 생각해보자는 거에요. 분명 개발자도 하나의 직업이니까 일을 잘해야 될텐데, 개발자로서 일을 잘한다는 것이 무엇이고 어떻게 측정하는 것일까를 말이죠. 이 레포지토리는 답을 정의하기 보다는 그저 "우리 한 번 같이 생각해봅시다! 그런데 이 레포지토리는 이런 생각을 가지고 있어요!"를 이야기하고 싶은 거에요. 33 | 34 | 그러니 본론으로 돌아와서 다시 물어볼게요. 정말 개발자로서 일을 잘하는 사람은 어떤 사람을 말하는 걸까요? 알고리즘을 잘짜는 연구원? 구현을 잘하는 개발자? 아키텍처를 잘짜는 아키텍트? 아니면 언변이 좋은 사람? 35 | 36 | 여기에 대한 답은 여러분 스스로가 내려보도록 하세요. 저는 잘 모르겠습니다. :) 이에 대한 답은 100명에게 물어보면 100개의 정의가 돌아올테니 말이죠! 그러니 이 레포지토리를 따라가며 여러분 마음 속에 본인이 생각하는 일을 잘하는 사람을 떠올리시고 그걸 지향하도록 하세요. 요즘처럼 급변하는 세상 속에서 이에 대한 명확한 답은 없습니다. 시니어가 언제까지 시니어일까요? 현업을 벗어나는 순간 도태되기 마련이에요! 37 | 38 | 하물며 팀 버너스리의 웹이 등장한지 30년 정도된 이 시점에서 과연 누구를 웹에서의 구루(Guru)라고 불러야 할까요? Chrome, VS Code 등의 도구를 만드는 1차 생산자? 아니면 도구를 활용하는 2차 생산자? 그건 중요하지 않습니다. :) 여러분이 시니어가 될 때 쯤에 그들은 백골이 되어있을테니까 너무 고민하지 마세요! 39 | 40 | ### 그래서 뭐? 41 | 42 | 이 레포지토리는 여러분께 아무것도 알려드리지 않을 거라는 것을 명심하세요! 여기에 적힌 글은 그저 '잘' 하는 개발자에 대한 질문과 그에 대한 생각들로 이루어져있고, 이를 단편적으로 이해하고(이해했다는 착각을 하고) 넘어가는 게 아닌 현실적으로 외우면 도움이 될 내용을 함께 살펴보며 앞서서 말한 일 잘하는 방법에 대해 스스로 답해보는 겁니다! 벌써부터 신나지않나요!? :D 43 | 44 | 더불어서 이 레포지토리는 특별한 저장소가 아니기 때문에 앞서 말한 것처럼 [COC](/CODE_OF_CONDUCT.md)에 준하는 의견이라면 어떠한 피드백도 환영이에요. 만약 여기에 글을 쓰고 싶으시다면 그렇게 하시면 되고, 추가하고 싶거나 수정하고 싶은 내용이 있다면 이슈나 PR을 보내주시면 적극 반영하도록 하겠습니다. 45 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 고명진, Ray 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /PS/README.md: -------------------------------------------------------------------------------- 1 | ## 목차 2 | 3 | - Coding Test Tips - 작성중 4 | - [How to study Problem Solving?](https://subinium.github.io/how-to-study-problem-solving/?fbclid=IwAR21WCilS9SjMn0gSnOVDXacamezu2LT-pa2FWBa7IB3FByuMRCjoyQD_Io) 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Developer Guideline 🧠 based Korean 2 | 3 | Recent edit: 2019. Dec. 25 Merry Christmas!🎅 4 | 5 | [Halewira](https://medium.com/@halewira)의 사내 엔지니어링 팀 가이드라인으로 사용됩니다. 6 | 7 | > '개발자'는 단순히 프로그래밍에 국한된 것이 아닌, 하나의 제품(Product)을 만들기 위해 사용되는 모든 인적 자원을 뜻합니다. 가령 기획자, 디자이너 등으로 나뉘는 직군을 개발자라는 단어 하나로 통일했습니다. 따라서 이 글에서 IT 서비스 제품의 구현을 담당하는 직군은 Engineer로 통일합니다. 8 | > 9 | > 이 문서는 오직 엔지니어의 관점에서 작성되었고, Halewira 엔지니어링 팀의 주관적인 생각이 반영되어 있습니다. 10 | 11 | ## 들어가기 전에 ✋ 12 | 13 | 만약 시간이 되신다면 본문을 읽으시기 전에 [서문](INTRODUCTION.md)을 보신다면 레포지토리의 내용을 읽거나 기여하는 데 도움이 될 것입니다. 더불어 Halewira의 주관적인 생각이 가미되기 때문에 다소 불편한 부분이 있을 수 있으니 그 점에 유의하시기 바랍니다. 14 | 15 | ## 기여 방식 📋 16 | 17 | 기본적으로 각 주제 별로 신입 엔지니어가 꼭 알아야 할 내용에 대해서 기술합니다. 이 곳에 작성되는 모든 내용은 추상적으로 이해하는 것이 아닌 현실적으로 공감되고 도움이 되는 내용이어야 합니다. 하나의 주제와 관련된 추천 문서나 도서를 공유해주시는 것도 좋은 방법입니다. 만약 참고자료가 있다면 반드시 본문 하단에 기술해야 합니다. 18 | 19 | > 본문에 작성된 내용 외에 추가하고 싶은 내용이 있다면 먼저 [ETC](/ETC)에 적어주시면 됩니다. 20 | > 21 | > 더불어 전체적인 문맥의 어투는 '~했다', '~이다'와 같이 짧게 끊어주시면 됩니다. 더불어 존대의 표현은 각 글마다 다를 수 있으니 이 점에 유의하여 해당 글의 뉘앙스에맞게 추가/수정해주시면 감사합니다. 22 | 23 | ☝️ 목차는 트리 형식을 기반으로 최상단에는 전체 주제를 기입하고 그 하위의 세부 주제를 다시 그 하위 디렉터리로 옮기거나 해당 디렉터리의 `README.md`에 작성합니다. 그리고 읽는 이의 편의를 고려해 내가 있는 디렉터리 바로 하위의 내용에 대해서는 링크를 거는 것을 원칙으로 합니다. 24 | 25 | ### 목차 for Engineer💻 26 | 27 | - [Common](COMMON/) 28 | 29 | - Troubleshooting(문제 추적) 30 | - Design(설계) 31 | - Implementation(구현) - 작성중 32 | - Efficient Development(효율적인 개발) - 작성중 33 | - Object-oriented Programming(객체 지향 프로그래밍) - 작성중 34 | - Function-oriented Programming(함수 지향 프로그래밍) - 작성중 35 | - Test-driven Development(테스트 주도 개발) - 작성중 36 | - Domain-driven Development(도메인 주도 개발) - 작성중 37 | - Application Programming Interface(API, 응용 프로그램 프로그래밍 인터페이스) - 작성중 38 | 39 | - [PS(Problem Solving)](PS/) 40 | 41 | - Coding Test Tips - 작성중 42 | - How to study Problem Solving? 43 | 44 | - [CS(Computer Science)](CS/) 45 | 46 | - Data Structure - 작성중 47 | - Network - 작성중 48 | - Operating System - 작성중 49 | - Database - 작성중 50 | - Design Pattern - 작성중 51 | 52 | - [SOFT SKILL](SOFTSKILL/) 53 | 54 | - 글쓰기 - 작성중 55 | - 말하기 - 작성중 56 | - 동료를 위한 개발 - 작성중 57 | 58 | - [DESIGN](DESIGN/) 59 | - UI - 작성중 60 | - UX - 작성중 61 | 62 | - [WEB PROGRAMMING](https://github.com/rayleighko/web4newbie) 63 | 64 | - [Configuration Management(형상 관리) with Git](https://github.com/rayleighko/git4newbie) 65 | 66 | - [ETC](ETC/) 67 | 68 | - English - 작성중 69 | - Web related Open source - 작성중 70 | - Cloud for FE - 작성중 71 | - Docker - 작성중 72 | - NginX - 작성중 73 | - front-end-handbook-2019 74 | -------------------------------------------------------------------------------- /SOFTSKILL/README.md: -------------------------------------------------------------------------------- 1 | ## 목차 2 | 3 | - 글쓰기 - 작성중 4 | - 말하기 - 작성중 5 | - 동료를 위한 개발 - 작성중 6 | - 다양한 개발 생태계 활동 - 작성중 7 | --------------------------------------------------------------------------------