├── .github └── ISSUE_TEMPLATE │ └── Category.md ├── CONTRIBUTE.md ├── Category ├── Algorithm │ └── README.md ├── Architecture │ └── README.md ├── BuildTool │ └── README.md ├── Database │ └── README.md ├── DesignPattern │ └── README.md ├── Fade-out │ ├── ALGORITHMS_README.md │ ├── ARCHITECTURE_README.md │ ├── CODE_README.md │ ├── DATABASE_README.md │ ├── DESIGNPATTERN_README.md │ ├── GENERAL_README.md │ ├── LANGUAGE_README.md │ ├── OS_README.md │ ├── SECURITY_README.md │ ├── SOFTWAREENGINEERING_README.md │ └── WEB_README.md ├── Language │ └── Java.md ├── Network │ └── README.md ├── OS │ └── README.md ├── Security │ └── README.md ├── Testing │ └── README.md └── Web │ ├── README.md │ └── WebFramework.md ├── LICENSE ├── OriginalDocuments ├── README.md ├── databases │ ├── acid.md │ ├── bluegreen-deployment.md │ ├── db-migrations.md │ ├── lazy-loading.md │ ├── n1-problem.md │ ├── normalization.md │ ├── null-is-special.md │ ├── schema-migrations.md │ └── slowest-queries.md ├── design-patterns │ ├── active-record.md │ ├── anti-corruption-layer.md │ ├── billion-dollar-mistake.md │ ├── data-abstraction.md │ ├── data-mapper.md │ ├── dependency-hell.md │ ├── dont-repeat-yourself.md │ ├── globals-are-evil.md │ ├── goto-is-evil.md │ ├── inheritance-vs-composition.md │ ├── inversion-of-control.md │ ├── law-of-demeter.md │ └── violate-dry.md └── snippets │ └── kill-the-if-chain.md └── README.md /.github/ISSUE_TEMPLATE/Category.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: 주제 제안하기 3 | about: Backend 개발자에 필요한 주제인거 같아서 제안합니다 :) 4 | 5 | --- 6 | 7 | ## 주제 8 | - 9 | 10 | ## 왜 이 주제가 필요할까요? 11 | - -------------------------------------------------------------------------------- /CONTRIBUTE.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/NESOY/Back-end-Developer-Interview-Questions/7c075af62a0d7105a0d9190f83af909fcf45bed2/CONTRIBUTE.md -------------------------------------------------------------------------------- /Category/Algorithm/README.md: -------------------------------------------------------------------------------- 1 | ## Algorithms & Data structure 2 | ### Index 3 | - [Stack](#stack) 4 | - [Queue](#queue) 5 | - 스택(LIFO Stacks)들로 큐(FIFO Queue)를 구성 6 | - 큐(FIFO Queue)들을 사용해서 스택(LIFO Stacks)을 구성 7 | - [Map](#map) 8 | - [HashMap](#hashmap) 9 | - [Tree](#tree) 10 | - [Binary Search Tree](#binarysearchtree) 11 | - [Red-Black Tree](#redblacktree) 12 | - [Graph](#graph) 13 | 14 | - Tail-Recursion 15 | -------- 16 | ### Stack 17 | ### Queue 18 | ### Map 19 | #### HashMap 20 | - [Java HashMap은 어떻게 동작하는가?](https://d2.naver.com/helloworld/831311) 21 | ### Tree 22 | #### BinarySearchTree 23 | #### RedBlackTree 24 | ### Graph 25 | 26 | 27 | 28 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Architecture/README.md: -------------------------------------------------------------------------------- 1 | ## Architecture 2 | ### Index 3 | - [MicroService](#microservice) 4 | - [Monolithic Architecture](#monolithic-architecture) 5 | - [Event-Driven Architecture](#event-driven-architecture) 6 | 7 | -------- 8 | 9 | ### MicroService 10 | ### Monolithic Architecture 11 | ### Event-Driven Architecture 12 | 13 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/BuildTool/README.md: -------------------------------------------------------------------------------- 1 | ## BuildTool 2 | ### Index 3 | - [Maven](#maven) 4 | - [Gradle](#gradle) 5 | 6 | -------- 7 | 8 | 9 | ### Maven 10 | 11 | ### Gradle 12 | 13 | 14 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Database/README.md: -------------------------------------------------------------------------------- 1 | ## Database 2 | ### Index 3 | - [Index](#index) 4 | - [Transaction](#transaction) 5 | - [Replication](#replication) 6 | - [Partitioning](#partitioning) 7 | 8 | - [NoSQL](#nosql) 9 | - [CAP](#cap) 10 | - [Eventual Consistency](#eventual-consistency) 11 | - [Cache](#cache) 12 | - Global Cache 13 | - Local Cache 14 | - Life Cycle 15 | -------- 16 | ### Index 17 | ### Transaction 18 | ### Replication 19 | - [Database의 리플리케이션(Replication)이란?](https://nesoy.github.io/articles/2018-02/Database-Replication) 20 | 21 | ### Partitioning 22 | - [Database의 파티셔닝(Partitioning)이란?](https://nesoy.github.io/articles/2018-02/Database-Partitioning) 23 | 24 | ### NoSQL 25 | ### CAP 26 | ### Eventual Consistency 27 | ### Cache 28 | 29 | 30 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/DesignPattern/README.md: -------------------------------------------------------------------------------- 1 | ## Design Pattern 2 | ### Index 3 | - 객체 지향 프로그래밍(Object Oriented Programming) 4 | - 함수형 프로그래밍(Functional Programming) 5 | - [SOLID](#solid) 6 | - [단일 책임 원칙 (Single responsibility principle)](#srp) 7 | - [개방-폐쇄 원칙 (Open/closed principle)](#ocp) 8 | - [리스코프 치환 원칙 (Liskov substitution principle)](#lsp) 9 | - [인터페이스 분리 원칙 (Interface segregation principle)](#isp) 10 | - [의존관계 역전 원칙 (Dependency inversion principle)](#dip) 11 | - 디미터의 법칙(Law of Demeter) 12 | - 디자인 패턴 13 | - 팩토리 메서드 패턴 (Factory method Pattern) 14 | - 전략 패턴 (Strategy Pattern) 15 | - 손상 방지 패턴 (Anti-corruption Layer Pattern) 16 | - 아키텍처 패턴 17 | - 계층화 패턴 (Layered pattern) 18 | - 클라이언트-서버 패턴 (Client-server pattern) 19 | - 마스터-슬레이브 패턴 (Master-slave pattern) 20 | - 파이프-필터 패턴 (Pipe-filter pattern) 21 | - 브로커 패턴 (Broker pattern) 22 | - 피어 투 피어 패턴 (Peer-to-peer pattern) 23 | - 이벤트-버스 패턴 (Event-bus pattern) 24 | - MVC 패턴 (Model-view-controller pattern) 25 | - 블랙보드 패턴 (Blackboard- pattern) 26 | - 인터프리터 패턴 (Interpreter pattern) 27 | - Publish-Subscribe 패턴 28 | -------- 29 | ### SOLID 30 | #### SRP 31 | #### OCP 32 | #### LSP 33 | #### ISP 34 | #### DIP 35 | 36 | 37 | 38 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Fade-out/ALGORITHMS_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) 알고리즘: 2 | 3 | * ~~스택(LIFO Stacks)들로 큐(FIFO Queue)를 구성해보세요. 그리고 큐(FIFO Queue)들을 사용해서 스택(LIFO Stacks)을 구성해보세요.~~ 4 | * Stack Overflow의 영향을 받는 코드를 작성해보세요. 5 | * ~~Write a tail-recursive version of the factorial function~~ 6 | * Using your preferred language, write a REPL that echoes your inputs. Evolve it to make it an RPN calculator. 7 | * 디스크 조각 모음[defragger] 유틸리티를 어떻게 디자인 하실 건가요? 8 | * Write a program that builds random mazes. 9 | * 메모리 누수를 발생시키는 예제코드를 작성해 보세요. 10 | * Generate a sequence of unique random numbers 11 | * 간단한 Garbage collection system을 작성해보세요. 12 | * 당신이 좋아하는 언어를 사용해서 기초적인 메세지 브로커를 작성해보세요. 13 | * Write a very basic web server. Draw a road map for features to be implemented in the future. 14 | * 10GB 크기의 파일을 어떻게 정렬 하실 건가요? 10TB의 크기로 변경된다면 당신은 문제 해결 방법을 어떻게 접근하실건가요? 15 | * 파일 중복을 어떻게 프로그래밍으로 감지할 수 있을까요? 16 | * HashTable은 어떻게 동작하나요? 충돌 발생시 해결 방법은 어떤 것들이 있을까요? -------------------------------------------------------------------------------- /Category/Fade-out/ARCHITECTURE_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) 소프트웨어 아키텍처: 2 | 3 | * 언제 캐시전략이 유용하지 않고 심지어 위험스러운 상황까지 오게 될까요? 4 | * ~~이벤트 기반 아키텍쳐(Event-Driven Architecture)를 통해 확장성이 향상되는 이유는 무엇일까요?~~ 5 | * 어떻게 하면 코드를 읽기 쉽게 만들 수 있을까요? 6 | * emergent design과 evolutionary architecture의 차이점은 무엇일까요? 7 | * Scale out과 scale up의 차이점을 알고 계신가요? 어떤 상황에 적용해야할까요? 8 | * user 세션(sessions)의 장애를 어떻게 처리하실건가요? 9 | * CQRS (Command Query Responsibility Segregation)이란 무엇일까요? 기존의 Command-Query Separation 원리랑 어떤 차이를 가질까요? 10 | * The so called "multitier architecture" is an approach to design a client–server system aimed to keep physically and logically separated presentation, application processing, data management and other functions. The most widespread of the multitier architectures is the three-tier architecture. Would you discuss the pros and cons of such approach? 11 | * 당신은 소프트웨어 시스템의 확장성(scalability)을 어떻게 고려해서 디자인 하나요? 12 | * Someone gave the name "The "C10k problem" to the problem of optimising network sockets to handle over 10.000 open connections at once. While handling 10.000 concurrent clients is not the same as handling 10.000 open connection, the context is similar. It's a tough challenge anyway, and no one is expected to know every single detail to solve it. It may be interesting to discuss the strategies you know to deal with that problem. Would you like to try? 13 | * 분산화된 P2P System을 어떻게 디자인 하실 건가요? 14 | * You may recall that Common Gateway Interface (CGI) is a standard protocol for web servers to execute programs (CGI scripts) that execute as Command-line programs on a server, and that dynamically generate HTML pages when invoked by a HTTP request. Perl and PHP used to be common languages for such scripts. In CGI, a HTTP request generally causes the invocation of a new process on the server, but FastCGI, SCGI and other approaches improved the mechanism, raising the performance, with techniques such as preforking processes. Can you imagine why has't CGI eventually win, and was instead replaced with other architectural approaches? 15 | * How would you defend the design of your systems against Vendor Lock-in? 16 | * 규모에 따른 Publish-Subscribe 패턴의 단점들은 무엇일까요? 17 | * What's new in CPUs since the 80s, and how does it affect programming? 18 | * In which part of the lifecycle of a software performance should be taken in consideration, and how? 19 | * How could a Denial of Service arise not maliciously but for a design or architectural problem? 20 | * 성능(Performance)과 확장성(Scalability)의 관계는 어떠할까요? 21 | * 어떤 상황에 높은 결합도가 괜찮을까요? 22 | * What characteristic should a system have to be Cloud Ready? 23 | * Does unity of design imply an aristocracy of architects? Putting it simple: can good design emerge from a collective effort of all developers? 24 | * What's the difference between design, architecture, functionality and aesthetic? Discuss. 25 | 26 | ### [[↑]](#toc) Microservices: 27 | 28 | * SOA 관점에서 Long-Lived 트랜잭션은 되도록 사용하지 않고. 대신하여 Saga 패턴이 제안될까요? 29 | * Soa와 Microservices는 어떤 차이점을 가지고 있나요? 30 | * 웹 서비스 버젼 관리, 버젼 호환성 및 변경 사항을 어떻게 관리할까요? 31 | * SOA에서 transaction과 compensation operation의 차이점이 무엇일까요? 32 | * 언제 Microservice는 지나치게 작다고 느껴질까요? 33 | * MicroService architecture의 장단점에 대해 설명해주세요. 34 | * ~~모노리틱 아키텍쳐(Monolithic architecture)을 설명해주세요.~~ 35 | * Circuit Breaker Pattern이란 무엇일까요? 이 패턴이 왜 필요할까요? 36 | 37 | 38 | ### [[↑]](#toc) 분산 시스템: 39 | 40 | * 분산 시스템은 어떻게 테스트를 진행할까요? 41 | * 어떤 상황에서 두 시스템 간의 비동기 커뮤니케이션(asynchronously communication)을 적용할 것인가요? 42 | * 원격 프로시저 호출(Remote Procedure Call)의 일반적인 문제점은 무엇일까요? 43 | * If you are building a distributed system for scalability and robustness, what are the different things you'd think of in the case you are working in a closed and secure network environment or in geographically distributed and public system? 44 | * 웹 어플리케이션은 장애를 어떻게 관리하고 견뎌낼까요? 45 | * 분산시스템의 장애는 어떻게 해결하실 건가요? 46 | * Let's talk about the several approaches to Reconciliation after network partitions 47 | * 분산 컴퓨팅의 단점은 무엇일까요? 48 | * 당신은 언제 Request/Reply를 사용할 것이며 또한 어떤 상황에서 Publish/Subscribe를 사용할 것인가요? 49 | * Suppose the system you are working on does not support transactionality. How would you implement it from scratch? 50 | 51 | 52 | -------------------------------------------------------------------------------- /Category/Fade-out/CODE_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) Questions about snippets of code: 2 | * 이 Javascript의 함수의 출력값은 무엇일까요? 3 | ```javascript 4 | function hookupevents() { 5 | for (var i = 0; i < 3; i++) { 6 | document.getElementById("button" + i) 7 | .addEventListener("click", function() { 8 | alert(i); 9 | }); 10 | } 11 | } 12 | ``` 13 | 14 | * 타입을 지우게 되면 Java코드의 결과물은 어떻게 나올까요? 왜 그럴까요? 15 | ```java 16 | ArrayList li = new ArrayList(); 17 | ArrayList lf = new ArrayList(); 18 | if (li.getClass() == lf.getClass()) // evaluates to true 19 | System.out.println("Equal"); 20 | ``` 21 | 22 | 23 | * 메모리 누수가 발생하는 부분을 찾을 수 있으신가요? 24 | ```java 25 | public class Stack { 26 | private Object[] elements; 27 | private int size = 0; 28 | private static final int DEFAULT_INITIAL_CAPACITY = 16; 29 | 30 | public Stack() { 31 | elements = new Object[DEFAULT_INITIAL_CAPACITY]; 32 | } 33 | 34 | public void push(Object e) { 35 | ensureCapacity(); 36 | elements[size++] = e; 37 | } 38 | 39 | public Object pop() { 40 | if (size == 0) 41 | throw new EmptyStackException(); 42 | return elements[--size]; 43 | } 44 | 45 | /** 46 | * Ensure space for at least one more element, roughly 47 | * doubling the capacity each time the array needs to grow. 48 | */ 49 | private void ensureCapacity() { 50 | if (elements.length == size) 51 | elements = Arrays.copyOf(elements, 2 * size + 1); 52 | } 53 | } 54 | ``` 55 | 56 | * `if`문은 일반적으로 절차적이고 명령적인 프로그래밍으로 진행되게 만듭니다. `switch`를 제거하고 보다 객체지향적인 코드로 만들 수 있나요? 57 | 58 | ```java 59 | public class Formatter { 60 | 61 | private Service service; 62 | 63 | public Formatter(Service service) { 64 | this.service = service; 65 | } 66 | 67 | public String doTheJob(String theInput) { 68 | String response = service.askForPermission(); 69 | switch (response) { 70 | case "FAIL": 71 | return "error"; 72 | case "OK": 73 | return String.format("%s%s", theInput, theInput); 74 | default: 75 | return null; 76 | } 77 | } 78 | } 79 | ``` 80 | 81 | 82 | * `if`문을 제거하고 보다 아래의 코드를 보다 더 객체지향적으로 바꿀 수 있나요? 83 | 84 | ```java 85 | public class TheService { 86 | private final FileHandler fileHandler; 87 | private final FooRepository fooRepository; 88 | 89 | public TheService(FileHandler fileHandler, FooRepository fooRepository) { 90 | this.fileHandler = fileHandler; 91 | this.fooRepository = fooRepository; 92 | } 93 | 94 | public String Execute(final String file) { 95 | 96 | final String rewrittenUrl = fileHandler.getXmlFileFromFileName(file); 97 | final String executionId = fileHandler.getExecutionIdFromFileName(file); 98 | 99 | if ((executionId.equals("")) || (rewrittenUrl.equals(""))) { 100 | return ""; 101 | } 102 | 103 | Foo knownFoo = fooRepository.getFooByXmlFileName(rewrittenUrl); 104 | 105 | if (knownFoo == null) { 106 | return ""; 107 | } 108 | 109 | return knownFoo.DoThat(file); 110 | } 111 | } 112 | ``` 113 | 114 | * 아래의 코드를 리팩토링 해보세요. 115 | 116 | ```js 117 | function() 118 | { 119 | HRESULT error = S_OK; 120 | 121 | if(SUCCEEDED(Operation1())) 122 | { 123 | if(SUCCEEDED(Operation2())) 124 | { 125 | if(SUCCEEDED(Operation3())) 126 | { 127 | if(SUCCEEDED(Operation4())) 128 | { 129 | } 130 | else 131 | { 132 | error = OPERATION4FAILED; 133 | } 134 | } 135 | else 136 | { 137 | error = OPERATION3FAILED; 138 | } 139 | } 140 | else 141 | { 142 | error = OPERATION2FAILED; 143 | } 144 | } 145 | else 146 | { 147 | error = OPERATION1FAILED; 148 | } 149 | 150 | return error; 151 | } 152 | ``` 153 | -------------------------------------------------------------------------------- /Category/Fade-out/DATABASE_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) 데이터 베이스: 2 | 3 | * 예를 들어 MySQL에서 PostgreSQL로 어떻게 다른 Database로 Migrate 할까요? 또한 만약에 당신이 해당 프로젝트를 관리하고 있다면 어떤 문제를 직면하게 될까요? 4 | * 왜 데이터 베이스는 null을 특별한 Case로 관리할까요? 예를 들어 ```SELECT * FROM table WHERE field = null```은 ``field``가 null과 Matching이 되지 않을까요? 5 | * ACID는 대표적으로 Atomicity, Consistency, Isolation 그리고 Durability가 있습니다. 데이터베이스의 트랜잭션은 앞서 언급한 4가지 특성을 보장합니다. 위 주제에 얼마나 알고 계신가요? 조금 더 자세히 설명해주실 수 있나요? 6 | * Version차이와 Application발전으로 인해 데이터 베이스 스키마 변화가 생깁니다. 그러면 데이터 베이스 스키마 Migration 자동화 방법에 대해 어떻게 관리할까요? 7 | * 어떻게 구현하면 Lazy Loading을 얻을 수 있을까요? 언제 유용할까요? Lazy Loading에 대해 함정은 없을까요? 8 | * The so called "N + 1 problem" is an issue that occurs when the code needs to load the children of a parent-child relationship with a ORMs that have lazy-loading enabled, and that therefore issue a query for the parent record, and then one query for each child record. How to fix it? 9 | * 어플리케이션에서 가장 비싼 비용의 Query를 어떻게 찾을까요? 10 | * 데이터베이스의 정규화가 항상 필요할까요? 언제 데이터베이스의 비정규화가 바람직할까요? 당신의 의견을 들려주세요. 11 | * Of of the Continuous Integration's techniques is called Blue-Green Deployment: it consists in having two production environments, as identical as possible, and in performing the deployment in one of them while the other one is still operating, and than in safely switching the traffic to the second one after some convenient testing. This technique becomes more complicated when the deployment includes changes to the database structure or content. I'd like to discuss this topic with you. 12 | 13 | 14 | ### [[↑]](#toc) NoSQL: 15 | 16 | * ~~Eventual Consistency이란 무엇일까요?~~ 17 | * The Brewer's Theorem, most commonly known as the CAP theorem, states that in the presence of a Network Partition (the P in CAP), a system's designer has to choose between Consistency (the C in CAP) and Availability (the A in CAP). Can you think about examples of CP, AP and CA systems? 18 | * 최근에 NoSQL의 인기가 상승하고 있는 이유에 대해 설명할 수 있나요? 19 | * NoSQL은 확장 문제를 어떻게 해결할까요? 20 | * 어떤 상황에서 MySQL이나 PostgreSQL와 같은 Relational Database보다 MongoDB와 CouchBase와 같은 Document Database를 사용하는게 좋을까요? -------------------------------------------------------------------------------- /Category/Fade-out/DESIGNPATTERN_README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ### [[↑]](#toc) 디자인 패턴: 4 | 5 | * 왜 global 객체와 static 객체는 나쁜 것일까요? code를 통한 예시로 설명할 수 있나요? 6 | * 제어의 역전(Inversion of Control)에 대한 개념과 IoC가 코드의 디자인을 어떻게 향상시키는지 설명해 주세요. 7 | * ~~디미터의 법칙(Law of Demeter)을 어기는 코드를 작성해주실 수 있나요? 그리고 이 코드가 왜 나쁜 디자인인지 그리고 어떻게 고쳐야 하는지 보여주세요.~~ 8 | * Active-Record는 CRUD기능을 포함하고 데이터베이스 테이블의 기초 컬럼들을 포함하고 있는 디자인 패턴입니다. 이러한 패턴의 한계점과 단점을 이야기해주세요. 9 | * Data Mapper는 객체와 데이터베이스 사이에 데이터를 독립적으로 유지하면서 객체와 데이터베이스 사이에 데이터를 Mapping하는 Mapper Layer를 사용한 설계 패턴입니다. 반면 Active-Recorde객체에는 데이터베이스에 유지하기 위한 작업과 기본 데이터베이스 테이블에 해당하는 속성이 직접 통합되어 있습니다. 위 패턴에 대해 어떻게 생각하세요? 어떤 상황에서 어떤 패턴을 사용하는게 적절할까요? 10 | * `null`은 왜 10억 달러의 실수라고 말할까요? Null Object Pattern이나 Option 타입과 같은 `null`을 피할 수 있는 기술들에 대해 설명해주세요. 11 | * 많은 사람들이 객체지향프로그래밍에서 상속보다는 구성(Composition)이 더 나은 선택이라고 말합니다. 당신의 의견은 어떤가요? 12 | * 싱글톤은 클래스에 대해 하나의 인스턴스만 생성해서 사용하도록 제한하는 패턴입니다. Thread-Safe한 싱글톤 Singleton기법은 명확하지 않습니다. 한번 시도해보세요. 13 | * 클라이언트에게 영향을 미치지 않고 바꾸는 기능을 데이터 추상화(Data Abstraction)라고 합니다. 이 속성을 위반하는 것으로 나타나는 제품과 예를 들고 고쳐보세요. 14 | * 의존성 지옥(Dependency Hell)을 어떻게 해결하실건가요? 15 | * goto는 나쁜가요? 아마 당신은 goto를 비판하고, 구조적인 프로그래밍을 옹호하는, Edsger Dijkstra의 유명한 논문인 "Go To Statement Considered Harmful"에 대해서 들어봤을 것입니다. goto에 대한 사용은 항상 논란이 되어왔습니다. 심지어, Dijkstra의 의견을 비판한 "'GOTO Considered Harmful' Considered Harmful"이라는 글까지 있으니까요. goto에 대한 당신의 생각은 어떤가요? 16 | * 견고함의 원칙(The robustness principle)은 "당신이 하는 일은 엄하게, 남의 것을 받아들일 때는 너그럽게"라고 일컬어지는 일반적인 소프트웨어 설계 가이드라인입니다. 이는, "관대한 독자, 신중한 작가가 되어라"라는 말로써 표현되기도 하죠. 이런 법칙이 합리적인지에 대해서 얘기를 나누어볼 수 있을까요? 17 | * 관심의 분리(Separation of Concerns)는 컴퓨터 프로그램을 각자의 관심사에 따라 나누어 구분지어 개발한다는 설계 원칙입니다. 관심의 분리를 달성하기 위해서는 다양한 메커니즘을 활용할 수 있죠(MVC와 같은 설계에 기반한 객체, 함수, 모듈, 패턴 등을 사용하는 것). 이 주제에 대하여 얘기를 나누어 볼까요? 18 | 19 | 20 | ### [[↑]](#toc) 코드 디자인: 21 | 22 | * 우리가 평소에 자주 듣던 객체지향 디자인(Object-Oriented Design)은 높은 응집도와 낮은 결합도를 가장 중요한 목표로 가지고 있습니다. 이 목표가 무엇을 의미하는지? 왜 그렇게 중요한지? 무엇을 얻을 수 있는지 설명해주세요. 23 | * 대부분의 언어에서 배열의 시작은 왜 0부터 일까요? 24 | * 테스트와 TDD는 코드 디자인에 어떤 영향을 주나요? 25 | * 응집도와 결합도의 차이점은 뭘까요? 26 | * 리팩토링(refactoring)은 언제 유용한가요? 27 | * 코드에서 주석은 의미가 있을까요? 몇몇 사람들은 되도록이면 피하라고 이야기합니다. 또한 주석이 필요없기를 희망하고 있습니다. 의견에 동의하십니까? 28 | * 디자인과 아키텍처의 차이점은 무엇일까요? 29 | * 왜 TDD에서는 코드를 작성하기 전에 테스트 코드를 작성할까요? 30 | * C++은 다중 상속을 제공합니다. 또한 자바도 다중 인터페이스를 허용합니다. 이러한 기능들을 사용함으로써 개발의 직교성(orthogonality)에 대해 어떤 영향을 줄까요? 다중 상속과 다중 인터페이스의 차이점이 있을까요? 위임과 상속에 대해 차이점이 있을까요? 31 | * 저장하는 절차를 도메인 로직에 유지하는 것에 대해 장단점을 설명해주세요. 32 | * 왜 객체 지향 디자인(Object-Oriented Design)은 오랜 기간동안 시장을 지배할 수 있었을까요? 33 | * 당신의 코드에 나쁜 디자인이 있다면 당신은 어떻게 해결하실 건가요? 34 | -------------------------------------------------------------------------------- /Category/Fade-out/GENERAL_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) 일반적인 질문: 2 | 3 | * ~~왜 함수형 프로그래밍(Functional programming)이 중요해졌을까요? 언제 함수형 프로그래밍을 사용하는게 좋을까요?~~ 4 | * Microsoft, Google, Opera 그리고 Mozilla와 같은 회사들은 무엇을 얻기 위해 그들의 브라우저를 만들었을까요? 5 | * 캡슐화는 무엇을 얻기 위해 중요할까요? 6 | * Real-Time 시스템은 무엇이며 일반 시스템과 어떻게 다를까요? 7 | * 실시간 언어와 힙 메모리 할당에는 어떤 관계가 있나요? 8 | * Immutability is the practice of setting values once, at the moment of their creation, and never changing them. How can immutability help write safer code? 9 | * Mutable 그리고 immutable value의 장단점들은 무엇일까요? 10 | * What's the Object-Relational impedance mismatch? 11 | * 캐시크기를 결정하기 위해 적용하는 원칙은 무엇일까요? 12 | * 클라이언트 기반 렌더링과 서버 기반 렌더링의 차이점은 무엇인가요? 13 | * 비안정적인 커뮤니케이션 프로토콜에 기반한 안정적인 커뮤니케이션 프로토콜을 만들려면 어떻게 해야할까요? 14 | * [Tony Hoare](https://en.m.wikipedia.org/wiki/Tony_Hoare) who invented the null reference once said "*I call it my billion-dollar mistake*" since it lead to "*innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years*". Imagine you want to remove the possibility to have null references in your preferred language: how would you achieve this goal? What consequences could this have? 15 | 16 | 17 | ### [[↑]](#toc) Open Questions: 18 | * 왜 사람들은 변화하는 것을 주저할까요? 19 | * 할아버지 할머니에게 설명하는 것처럼 Thread를 설명해 보세요. 20 | * 당신은 소프트웨어 공학자로서 변화와 예측 가능성을 동시에 얻고자 합니다. 어떻게 하나의 전략으로 이 두 가지 토끼를 모두 잡을 수 있을까요? 21 | * 어떠한 것이 좋은 코드를 만들까요? 22 | * 스트리밍에 대해서 설명하고, 어떻게 구현하는지에 대해서 말해보세요. 23 | * Say your Company gives you one week you can use to improve your and your colleagues' lifes: how would you use that week? 24 | * 당신은 이번 주에는 어떤 것을 배웠나요? 25 | * 모든 디자인에 어울리는 미적으로 아름다운 요소가 있다고 생각해보세요. 이 요소는 당신에게 득이될까요 해가될까요?(is this aesthetic element your friend or your enemy?) 26 | * 최근 읽었던 5권을 설명해주세요. 27 | * How would you introduce Continuous Delivery in a successful, huge company for which the change from Waterfall to Continuous Delivery would be not trivial, because of the size and complexity of the business? 28 | * When does it make sense to reinvent the wheel? 29 | * Let's have a conversation about "*Reinventing the wheel*", the "*Not Invented Here Syndrome*" and the "*Eating Your Own Food*" practice 30 | * What's the next thing you would automate in your current workflow? 31 | * 왜 소프트웨어를 작성(개발)하는 것은 어려울까요? 무엇이 소프트웨어의 유지보수를 어렵게 만들까요? 32 | * Would you prefer working on Green Field or Brown Field projects? Why? 33 | * What does an Operating System do when it has got no custom code to run, and therefore it looks idle? I would like to start a discussions about interrupts, daemons, background services, polling, event handling and so on. 34 | * 5살 아이에게 Unicode와 Database Transactions에 대하여 설명해보세요. 35 | * 전문적인 개발자라는 사람은 어떤 의미일까요? 36 | * Is developing software an art, a craftsmanship or an engineering endeavour? Your opinion. 37 | * "이 상품을 좋아하는 사람들은 이런 상품도 좋아했습니다"와 같은 기능을 소셜 커머스 샵에서 어떻게 구현할 수 있을까요? 38 | * 왜 대기업들은 스타트업보다 혁신하는 속도가 느릴까요? 39 | * 최근에 이룬 일 중 가장 자랑스러웠던 일이 무엇인가요? 40 | 41 | 42 | ### [[↑]](#toc) 빌 게이츠 스타일의 질문: 43 | This section collects some weird questions along the lines of the [Manhole Cover Question](https://en.wikipedia.org/wiki/Microsoft_interview#Manhole_cover_question). 44 | 45 | * 스캐너에 거울 스캔하면 무슨 일이 벌어질까요? 46 | * 당신과 완벽히 똑같은 복제인간(clone)이 있다고 칩시다. 그리고 그 복제인간은 당신의 상사입니다. 당신은 그 사람과 같이 일할 것인가요? 47 | * 저를 인터뷰 해주세요. 48 | * Quora의 답변이 Yahoo의 답변보다 좋은 이유는 무엇일까요? 49 | * Let's play a game: defend Cobol against modern languages, and try to find as many reasonable arguments as you can. 50 | * 당신은 10년 후에 어떤 모습이 되어있을까요? 51 | * 당신이 나의 보스이며, 나를 해고했다고 가정해봅시다. 나에게 해고 통지를 해보세요. 52 | * I want to refactor a legacy system. You want to rewrite it from scratch. Argument. Then, switch our roles. 53 | * 당신의 상사가 당신에게 회사를 상대로 거짓말을 하라고 말했습니다. 당신은 어떻게 반응할 것인가요? 54 | * 과거로 시간 여행을 할 수 있다면, 당신의 어린 시절에게 무슨 말을 해주고 싶은가요? 55 | -------------------------------------------------------------------------------- /Category/Fade-out/LANGUAGE_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) 프로그래밍 언어: 2 | * 선호하는 언어의 단점 3가지만 말해주세요. 3 | * ~~왜 함수 프로그래밍(Functional Programming)이 떠오르고 있는지 설명할 수 있나요?~~ 4 | * 클로져란 무엇일까요? 그리고 어떤 상황에서 유용할까요? 클로져와 클래스간의 공통점은 무엇이 있을까요? 5 | * 어떤 상황에서 Generics이 유용할까요? 6 | * 고차 함수(High-order functions)란 무엇일까요? 어떤 상황에 유용할까요? 당신의 선호하는 언어로 예를 들어주세요. 7 | * Write a loop, then transform it into a recursive function, using only immutable structures (i.e. avoid using variables). Discuss. 8 | * 언어에서 함수(Function)을 일급 시민(First-Class citizens)으로 다룬다는 것은 무슨 의미일까요? 9 | * 익명 함수(Anonymous Function) 장점이 나타나는 예제를 보여주세요. 10 | * There are a lot of different type systems: let's talk about static and dynamic type systems, and about strong and weak ones. You surely have an opinion and a preference about this topic. Would you like to share them, and discuss why and when would you promote one particular type system for developing an enterprise software? 11 | * NameSpace는 어떤 상황에 유용할까요? 대안은 없을까요? 12 | * Talk about Interoperability between Java and C# (in alternative, choose 2 other arbitrary languages) 13 | * ~~왜 많은 소프트웨어 개발자들은 자바를 좋아하지 않을까요?~~ 14 | * 어떠한 점이 좋은 언어와 나쁜 언어를 만들까요? 15 | * Write two functions, one Referentially Transparent and the other one Referentially Opaque. Discuss. 16 | * 스택(Stack)과 힙(Heap)은 무엇일까요? 스택 오버플로우(Stack Overflow)는 무엇일까요? 17 | * 프로그래밍 언어에서 왜 first class citizens은 함수에서 중요할까요? 18 | * Some languages, especially the ones that promote a Functional approach, allow a technique called Pattern Matching. Do you know it? How is Pattern Matching different from Switch clauses? 19 | * 일부 언어에서는 예외처리가 없게 디자인이 되었을까요? 이런 디자인에 대해 장단점을 설명해주세요. 20 | * 만약 `Cat`이 `Animal`이라면, `TakeCare`라고 쓰는게 맞을까요 아니면 `TakeCare`라고 쓰는게 맞을까요? 21 | * Why in Java, C# and many other languages constructors are not part of the interface? 22 | * 지난 몇년 동안 Node에 대한 광고가 많았습니다. 처음에 브라우저에서 실행되도록 고안된 언어 사용에 대해 어떻게 생각하시나요? 23 | * Pretend you have a time machine and pretend that you have the opportunity to go to a particular point in time during Java's (or C#, Python, Go or whatever) history, and talk with some of the JDK architects. What would you try to convince them of? Removing checked exceptions? Adding unsigned primitives? Adding multiple-inheritance? 24 | -------------------------------------------------------------------------------- /Category/Fade-out/OS_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) 동시성: 2 | 3 | * 왜 우리는 동시성(Concurrency)이 필요할까요? 항상 그럴까요? 설명해보세요. 4 | * Multithreading / concurrent code를 테스트한다는 건 왜 어려울까요? 5 | * ~~Race Condition이란 무엇일까요? 잘하는 언어를 사용하여 코드로 예제를 보여주세요.~~ 6 | * ~~Deadlock이란 무엇일까요? Deadlock에 영향을 받는 코드를 작성해 주실 수 있나요?~~ 7 | * Process Starvation이란 무엇일까요? 필요하다면 정의에 대해 리뷰해주세요. 8 | * Wait Free algorithm이란 무엇일까요? -------------------------------------------------------------------------------- /Category/Fade-out/SECURITY_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) 보안: 2 | * 당신은 어떻게 보안성이 높은 코드를 작성하나요? 보안성이 높은 코드를 작성하는 것은 개발자의 의무인지, 아니면 회사가 전문적으로 처리해야할 일인지에 대한 당신의 의견을 말해보세요. 3 | * Why is it said that cryptography is not something you should try to invent or design yourself? 4 | * 인증(authentication)에서 필요한 두 가지 요소는 무엇인가요? 이미 존재하는 웹 어플리케이션에서 어떻게 그 요소를 작성할 수 있을까요? 5 | * If not carefully handled, there is always a risk of logs containing sensitive information, such as passwords. How would you deal with this? 6 | * Write down a snippet of code affected by SQL Injection and fix it. 7 | * How would it be possible to detect SQL Injection via static code analysis? I don't expect you to write an algorithm capable of doing this, as it is probably a huge topic, but let's discuss a general approach. 8 | * 크로스 사이트 스크립팅 공격법에 대해서 무엇을 알고 있나요? 기억이 나지 않는다면 온라인으로 정의를 확인하고 얘기해보도록 하죠. 9 | * What do you know about Cross-Site Forgery Attack? If you don't remember it, let's review online its definition and let's discuss about it. 10 | * HTTPS가 어떻게 동작하는지 아시나요? 11 | * ~~중간자 공격(Man-in-the-middle attack)은 무엇이며, HTTPS가 어떻게 해당 공격을 방어해주나요?~~ 12 | * How can you prevent the user's session from being stolen? Chances are you remember what Session or Cookie Hijacking is, otherwise let's read its Wikipedia page together. 13 | -------------------------------------------------------------------------------- /Category/Fade-out/SOFTWAREENGINEERING_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) Software Lifecycle and Team Management: 2 | 3 | * agility란 무엇일까요? 4 | * 당신은 레거시 코드(Legacy Code)를 어떻게 다루실 건가요? 5 | * Say I'm your Project Manager, and I'm no expert in programming. Would you try explaining me what Legacy Code is and why should I care about code quality? 6 | * ~~저는 당신 회사의 CEO라고 가정합시다. Kanban을 설명해 주시고 그 부분을 투자하도록 설득해주세요.~~ 7 | * 애자일(Agile)과 폭포수(Waterfall)의 가장 큰 차이점은 무엇일까요? 8 | * 팀 매니저로서 너무 많은 미팅을 하는 문제점에 대해 당신은 어떻게 해결 할 건가요? 9 | * ~~가장 최근의 프로젝트를 어떻게 관리하셨나요?~~ 10 | * "*Individuals and interactions over processes and tools*" and "*Customer collaboration over contract negotiation*" comprise half of the values of the Agile Manifesto. Discuss 11 | * Tell me what decisions would you take if you could be the CTO of your Company. 12 | * ~~프로그램 매니저(Program Managers)는 유용한가요?~~ 13 | * Organize a development team using flexible schedules (that is, no imposed working hours) and "Take as you need" vacation policy 14 | * How would you manage a very high turn over and convince developers not to leave the team, without increasing compensation? What could a Company improve to make them stay? 15 | * What are the top 3 qualities you look for in colleagues, beyond their code? 16 | * What are the top 3 things you wish non-technical people knew about code? 17 | * Imagine your company gives you 1 month and some budget to improve your and your colleagues' daily life. What would you do? 18 | 19 | 20 | ### [[↑]](#toc) Git: 21 | * GitHub Flow와 GitFlow workflows에 대해 설명해주세요. 22 | * 리베이스(rebase)가 무엇일까요? 23 | * Git을 통해 팀원들이랑 어떻게 협업을 진행할까요? Pull Request란 무엇일까요? 24 | * Pull을 받아 Merge를 하는 과정에서 충돌이나면 어떻게 해결해야할까요? 25 | -------------------------------------------------------------------------------- /Category/Fade-out/WEB_README.md: -------------------------------------------------------------------------------- 1 | ### [[↑]](#toc) Web: 2 | * 왜 first-party 쿠키들과 third-party 쿠키들을 다르게 다룰까요? 3 | * 웹 서비스 API(Web Services API) 버젼을 어떻게 관리하실 건가요? 4 | * Back-End 관점에서, Single Page Application의 단점은 무엇이 있을까요? 5 | * 왜 우리는 stateless service를 사용하기 위해 많은 노력을 할까요? stateless code가 가져다 주는 장점들과 statefullness code가 가져다 주는 단점들에 대해 설명해 주세요. 6 | * REST 그리고 SOAP: 어떤 상황에서 두가지 방법 중 하나를 선택해서 사용하실 건가요? 7 | * Model-View-Controller 그리고 Model-View-ViewModel은 웹 개발의 백엔드와 프론트엔드 관점에서 매우 일반적입니다. 그들이 무엇인지? 그리고 그들이 왜 권장되고있는지 설명하실수 있나요? 8 | -------------------------------------------------------------------------------- /Category/Language/Java.md: -------------------------------------------------------------------------------- 1 | ## Java 2 | ### Index 3 | - [transient](#transient) 4 | - [volatile](#volatile) 5 | - [final](#final) 6 | - [Reflection](#reflection) 7 | -------- 8 | ### transient 9 | ### volatile 10 | ### final 11 | ### Reflection 12 | 13 | 14 | 15 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Network/README.md: -------------------------------------------------------------------------------- 1 | ## Network 2 | ### Index 3 | - [TCP vs UDP](#tcp-vs-udp) 4 | - [브라우저에 google.com을 입력하면 어떤 일이 벌어질까요?](#브라우저에-google.com을-입력하면-어떤-일이-벌어질까요?) 5 | -------- 6 | ### TCP vs UDP 7 | ### 브라우저에 google.com을 입력하면 어떤 일이 벌어질까요? 8 | - 9 | 10 | 11 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/OS/README.md: -------------------------------------------------------------------------------- 1 | ## OS 2 | ### Index 3 | - [Process, Thread의 차이](#process-thread) 4 | - [Swapping](#swapping) 5 | - [Thread-safe](#thread-safe) 6 | - [DeadLock](#deadlock) 7 | - [Race Condition](#race-condition) 8 | -------- 9 | ### Process-Thread 10 | ### Swapping 11 | ### Thread-safe 12 | ### DeadLock 13 | ### Race Condition 14 | 15 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Security/README.md: -------------------------------------------------------------------------------- 1 | ## Security 2 | ### Index 3 | - [XSS](#xss) 4 | - [CSRF](#csrf) 5 | - [SQL Injection](#sql-injection) 6 | - [Man-in-the-middle attack](#man-in-the-middle-attack) 7 | -------- 8 | ### XSS 9 | ### CSRF 10 | ### SQL-Injection 11 | ### Man-in-the-middle attack 12 | 13 | 14 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Testing/README.md: -------------------------------------------------------------------------------- 1 | ## Testing 2 | ### Index 3 | - [Unit-Testing](#unit-testing) 4 | - [Integration-Testing](#integration-testing) 5 | - [Java](#java) 6 | - [JUnit](#junit) 7 | - [Mockito](#mockito) 8 | - [Spock](#spock) 9 | -------- 10 | ### Unit-Testing 11 | ### Integration-Testing 12 | 13 | ## Java 14 | ### JUnit 15 | - [Junit Site](https://junit.org/junit5/) 16 | ### Mockito 17 | - [Mockito Site](https://site.mockito.org/) 18 | ### Spock 19 | - [Spock Site](http://spockframework.org/) 20 | - [Spock으로 테스트코드를 짜보자 - 우아한 형제들](http://woowabros.github.io/study/2018/03/01/spock-test.html) 21 | - [Spock으로 테스트하기 - Naver D2](https://d2.naver.com/helloworld/568425) 22 | 23 | 24 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Web/README.md: -------------------------------------------------------------------------------- 1 | ## Web 2 | ### Index 3 | - [HTTP](#http) 4 | - [HTTP/1.0](#http10) 5 | - [HTTP/1.1](#http11) 6 | - [HTTP/2](#http2) 7 | - [HTTPS](#https) 8 | - [Cookie와 Session이란?](#cookie와-session이란) 9 | -------- 10 | ### HTTP 11 | ### HTTP/1.0 12 | ### HTTP/1.1 13 | ### HTTP/2 14 | ### HTTPS 15 | ### Cookie와 Session이란? 16 | 17 | 18 | 19 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /Category/Web/WebFramework.md: -------------------------------------------------------------------------------- 1 | ## WebFramework 2 | ### Index 3 | - [Spring](#spring) 4 | 5 | -------- 6 | ### Spring 7 | 8 | 9 | 10 | 11 | ### :house: [Go Home](https://github.com/NESOY/Back-end-Developer-Interview-Questions) -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | GNU GENERAL PUBLIC LICENSE 2 | Version 2, June 1991 3 | 4 | Copyright (C) 1989, 1991 Free Software Foundation, Inc., 5 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA 6 | Everyone is permitted to copy and distribute verbatim copies 7 | of this license document, but changing it is not allowed. 8 | 9 | Preamble 10 | 11 | The licenses for most software are designed to take away your 12 | freedom to share and change it. By contrast, the GNU General Public 13 | License is intended to guarantee your freedom to share and change free 14 | software--to make sure the software is free for all its users. This 15 | General Public License applies to most of the Free Software 16 | Foundation's software and to any other program whose authors commit to 17 | using it. (Some other Free Software Foundation software is covered by 18 | the GNU Lesser General Public License instead.) You can apply it to 19 | your programs, too. 20 | 21 | When we speak of free software, we are referring to freedom, not 22 | price. Our General Public Licenses are designed to make sure that you 23 | have the freedom to distribute copies of free software (and charge for 24 | this service if you wish), that you receive source code or can get it 25 | if you want it, that you can change the software or use pieces of it 26 | in new free programs; and that you know you can do these things. 27 | 28 | To protect your rights, we need to make restrictions that forbid 29 | anyone to deny you these rights or to ask you to surrender the rights. 30 | These restrictions translate to certain responsibilities for you if you 31 | distribute copies of the software, or if you modify it. 32 | 33 | For example, if you distribute copies of such a program, whether 34 | gratis or for a fee, you must give the recipients all the rights that 35 | you have. You must make sure that they, too, receive or can get the 36 | source code. And you must show them these terms so they know their 37 | rights. 38 | 39 | We protect your rights with two steps: (1) copyright the software, and 40 | (2) offer you this license which gives you legal permission to copy, 41 | distribute and/or modify the software. 42 | 43 | Also, for each author's protection and ours, we want to make certain 44 | that everyone understands that there is no warranty for this free 45 | software. If the software is modified by someone else and passed on, we 46 | want its recipients to know that what they have is not the original, so 47 | that any problems introduced by others will not reflect on the original 48 | authors' reputations. 49 | 50 | Finally, any free program is threatened constantly by software 51 | patents. We wish to avoid the danger that redistributors of a free 52 | program will individually obtain patent licenses, in effect making the 53 | program proprietary. To prevent this, we have made it clear that any 54 | patent must be licensed for everyone's free use or not licensed at all. 55 | 56 | The precise terms and conditions for copying, distribution and 57 | modification follow. 58 | 59 | GNU GENERAL PUBLIC LICENSE 60 | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 61 | 62 | 0. This License applies to any program or other work which contains 63 | a notice placed by the copyright holder saying it may be distributed 64 | under the terms of this General Public License. The "Program", below, 65 | refers to any such program or work, and a "work based on the Program" 66 | means either the Program or any derivative work under copyright law: 67 | that is to say, a work containing the Program or a portion of it, 68 | either verbatim or with modifications and/or translated into another 69 | language. (Hereinafter, translation is included without limitation in 70 | the term "modification".) Each licensee is addressed as "you". 71 | 72 | Activities other than copying, distribution and modification are not 73 | covered by this License; they are outside its scope. The act of 74 | running the Program is not restricted, and the output from the Program 75 | is covered only if its contents constitute a work based on the 76 | Program (independent of having been made by running the Program). 77 | Whether that is true depends on what the Program does. 78 | 79 | 1. You may copy and distribute verbatim copies of the Program's 80 | source code as you receive it, in any medium, provided that you 81 | conspicuously and appropriately publish on each copy an appropriate 82 | copyright notice and disclaimer of warranty; keep intact all the 83 | notices that refer to this License and to the absence of any warranty; 84 | and give any other recipients of the Program a copy of this License 85 | along with the Program. 86 | 87 | You may charge a fee for the physical act of transferring a copy, and 88 | you may at your option offer warranty protection in exchange for a fee. 89 | 90 | 2. You may modify your copy or copies of the Program or any portion 91 | of it, thus forming a work based on the Program, and copy and 92 | distribute such modifications or work under the terms of Section 1 93 | above, provided that you also meet all of these conditions: 94 | 95 | a) You must cause the modified files to carry prominent notices 96 | stating that you changed the files and the date of any change. 97 | 98 | b) You must cause any work that you distribute or publish, that in 99 | whole or in part contains or is derived from the Program or any 100 | part thereof, to be licensed as a whole at no charge to all third 101 | parties under the terms of this License. 102 | 103 | c) If the modified program normally reads commands interactively 104 | when run, you must cause it, when started running for such 105 | interactive use in the most ordinary way, to print or display an 106 | announcement including an appropriate copyright notice and a 107 | notice that there is no warranty (or else, saying that you provide 108 | a warranty) and that users may redistribute the program under 109 | these conditions, and telling the user how to view a copy of this 110 | License. (Exception: if the Program itself is interactive but 111 | does not normally print such an announcement, your work based on 112 | the Program is not required to print an announcement.) 113 | 114 | These requirements apply to the modified work as a whole. If 115 | identifiable sections of that work are not derived from the Program, 116 | and can be reasonably considered independent and separate works in 117 | themselves, then this License, and its terms, do not apply to those 118 | sections when you distribute them as separate works. But when you 119 | distribute the same sections as part of a whole which is a work based 120 | on the Program, the distribution of the whole must be on the terms of 121 | this License, whose permissions for other licensees extend to the 122 | entire whole, and thus to each and every part regardless of who wrote it. 123 | 124 | Thus, it is not the intent of this section to claim rights or contest 125 | your rights to work written entirely by you; rather, the intent is to 126 | exercise the right to control the distribution of derivative or 127 | collective works based on the Program. 128 | 129 | In addition, mere aggregation of another work not based on the Program 130 | with the Program (or with a work based on the Program) on a volume of 131 | a storage or distribution medium does not bring the other work under 132 | the scope of this License. 133 | 134 | 3. You may copy and distribute the Program (or a work based on it, 135 | under Section 2) in object code or executable form under the terms of 136 | Sections 1 and 2 above provided that you also do one of the following: 137 | 138 | a) Accompany it with the complete corresponding machine-readable 139 | source code, which must be distributed under the terms of Sections 140 | 1 and 2 above on a medium customarily used for software interchange; or, 141 | 142 | b) Accompany it with a written offer, valid for at least three 143 | years, to give any third party, for a charge no more than your 144 | cost of physically performing source distribution, a complete 145 | machine-readable copy of the corresponding source code, to be 146 | distributed under the terms of Sections 1 and 2 above on a medium 147 | customarily used for software interchange; or, 148 | 149 | c) Accompany it with the information you received as to the offer 150 | to distribute corresponding source code. (This alternative is 151 | allowed only for noncommercial distribution and only if you 152 | received the program in object code or executable form with such 153 | an offer, in accord with Subsection b above.) 154 | 155 | The source code for a work means the preferred form of the work for 156 | making modifications to it. For an executable work, complete source 157 | code means all the source code for all modules it contains, plus any 158 | associated interface definition files, plus the scripts used to 159 | control compilation and installation of the executable. However, as a 160 | special exception, the source code distributed need not include 161 | anything that is normally distributed (in either source or binary 162 | form) with the major components (compiler, kernel, and so on) of the 163 | operating system on which the executable runs, unless that component 164 | itself accompanies the executable. 165 | 166 | If distribution of executable or object code is made by offering 167 | access to copy from a designated place, then offering equivalent 168 | access to copy the source code from the same place counts as 169 | distribution of the source code, even though third parties are not 170 | compelled to copy the source along with the object code. 171 | 172 | 4. You may not copy, modify, sublicense, or distribute the Program 173 | except as expressly provided under this License. Any attempt 174 | otherwise to copy, modify, sublicense or distribute the Program is 175 | void, and will automatically terminate your rights under this License. 176 | However, parties who have received copies, or rights, from you under 177 | this License will not have their licenses terminated so long as such 178 | parties remain in full compliance. 179 | 180 | 5. You are not required to accept this License, since you have not 181 | signed it. However, nothing else grants you permission to modify or 182 | distribute the Program or its derivative works. These actions are 183 | prohibited by law if you do not accept this License. Therefore, by 184 | modifying or distributing the Program (or any work based on the 185 | Program), you indicate your acceptance of this License to do so, and 186 | all its terms and conditions for copying, distributing or modifying 187 | the Program or works based on it. 188 | 189 | 6. Each time you redistribute the Program (or any work based on the 190 | Program), the recipient automatically receives a license from the 191 | original licensor to copy, distribute or modify the Program subject to 192 | these terms and conditions. You may not impose any further 193 | restrictions on the recipients' exercise of the rights granted herein. 194 | You are not responsible for enforcing compliance by third parties to 195 | this License. 196 | 197 | 7. If, as a consequence of a court judgment or allegation of patent 198 | infringement or for any other reason (not limited to patent issues), 199 | conditions are imposed on you (whether by court order, agreement or 200 | otherwise) that contradict the conditions of this License, they do not 201 | excuse you from the conditions of this License. If you cannot 202 | distribute so as to satisfy simultaneously your obligations under this 203 | License and any other pertinent obligations, then as a consequence you 204 | may not distribute the Program at all. For example, if a patent 205 | license would not permit royalty-free redistribution of the Program by 206 | all those who receive copies directly or indirectly through you, then 207 | the only way you could satisfy both it and this License would be to 208 | refrain entirely from distribution of the Program. 209 | 210 | If any portion of this section is held invalid or unenforceable under 211 | any particular circumstance, the balance of the section is intended to 212 | apply and the section as a whole is intended to apply in other 213 | circumstances. 214 | 215 | It is not the purpose of this section to induce you to infringe any 216 | patents or other property right claims or to contest validity of any 217 | such claims; this section has the sole purpose of protecting the 218 | integrity of the free software distribution system, which is 219 | implemented by public license practices. Many people have made 220 | generous contributions to the wide range of software distributed 221 | through that system in reliance on consistent application of that 222 | system; it is up to the author/donor to decide if he or she is willing 223 | to distribute software through any other system and a licensee cannot 224 | impose that choice. 225 | 226 | This section is intended to make thoroughly clear what is believed to 227 | be a consequence of the rest of this License. 228 | 229 | 8. If the distribution and/or use of the Program is restricted in 230 | certain countries either by patents or by copyrighted interfaces, the 231 | original copyright holder who places the Program under this License 232 | may add an explicit geographical distribution limitation excluding 233 | those countries, so that distribution is permitted only in or among 234 | countries not thus excluded. In such case, this License incorporates 235 | the limitation as if written in the body of this License. 236 | 237 | 9. The Free Software Foundation may publish revised and/or new versions 238 | of the General Public License from time to time. Such new versions will 239 | be similar in spirit to the present version, but may differ in detail to 240 | address new problems or concerns. 241 | 242 | Each version is given a distinguishing version number. If the Program 243 | specifies a version number of this License which applies to it and "any 244 | later version", you have the option of following the terms and conditions 245 | either of that version or of any later version published by the Free 246 | Software Foundation. If the Program does not specify a version number of 247 | this License, you may choose any version ever published by the Free Software 248 | Foundation. 249 | 250 | 10. If you wish to incorporate parts of the Program into other free 251 | programs whose distribution conditions are different, write to the author 252 | to ask for permission. For software which is copyrighted by the Free 253 | Software Foundation, write to the Free Software Foundation; we sometimes 254 | make exceptions for this. Our decision will be guided by the two goals 255 | of preserving the free status of all derivatives of our free software and 256 | of promoting the sharing and reuse of software generally. 257 | 258 | NO WARRANTY 259 | 260 | 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY 261 | FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN 262 | OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES 263 | PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED 264 | OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 265 | MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS 266 | TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE 267 | PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, 268 | REPAIR OR CORRECTION. 269 | 270 | 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING 271 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR 272 | REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, 273 | INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING 274 | OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED 275 | TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY 276 | YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 277 | PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE 278 | POSSIBILITY OF SUCH DAMAGES. 279 | 280 | END OF TERMS AND CONDITIONS 281 | 282 | How to Apply These Terms to Your New Programs 283 | 284 | If you develop a new program, and you want it to be of the greatest 285 | possible use to the public, the best way to achieve this is to make it 286 | free software which everyone can redistribute and change under these terms. 287 | 288 | To do so, attach the following notices to the program. It is safest 289 | to attach them to the start of each source file to most effectively 290 | convey the exclusion of warranty; and each file should have at least 291 | the "copyright" line and a pointer to where the full notice is found. 292 | 293 | {description} 294 | Copyright (C) {year} {fullname} 295 | 296 | This program is free software; you can redistribute it and/or modify 297 | it under the terms of the GNU General Public License as published by 298 | the Free Software Foundation; either version 2 of the License, or 299 | (at your option) any later version. 300 | 301 | This program is distributed in the hope that it will be useful, 302 | but WITHOUT ANY WARRANTY; without even the implied warranty of 303 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 304 | GNU General Public License for more details. 305 | 306 | You should have received a copy of the GNU General Public License along 307 | with this program; if not, write to the Free Software Foundation, Inc., 308 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 309 | 310 | Also add information on how to contact you by electronic and paper mail. 311 | 312 | If the program is interactive, make it output a short notice like this 313 | when it starts in an interactive mode: 314 | 315 | Gnomovision version 69, Copyright (C) year name of author 316 | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 317 | This is free software, and you are welcome to redistribute it 318 | under certain conditions; type `show c' for details. 319 | 320 | The hypothetical commands `show w' and `show c' should show the appropriate 321 | parts of the General Public License. Of course, the commands you use may 322 | be called something other than `show w' and `show c'; they could even be 323 | mouse-clicks or menu items--whatever suits your program. 324 | 325 | You should also get your employer (if you work as a programmer) or your 326 | school, if any, to sign a "copyright disclaimer" for the program, if 327 | necessary. Here is a sample; alter the names: 328 | 329 | Yoyodyne, Inc., hereby disclaims all copyright interest in the program 330 | `Gnomovision' (which makes passes at compilers) written by James Hacker. 331 | 332 | {signature of Ty Coon}, 1 April 1989 333 | Ty Coon, President of Vice 334 | 335 | This General Public License does not permit incorporating your program into 336 | proprietary programs. If your program is a subroutine library, you may 337 | consider it more useful to permit linking proprietary applications with the 338 | library. If this is what you want to do, use the GNU Lesser General 339 | Public License instead of this License. 340 | -------------------------------------------------------------------------------- /OriginalDocuments/README.md: -------------------------------------------------------------------------------- 1 | 백엔드 개발자 면접 질문 2 | ================== 3 | 4 | 중국어 번역본 [클릭](https://github.com/monklof/Back-End-Developer-Interview-Questions) by [monklof](https://github.com/monklof). 5 | 6 | 처음에는 친구나 동료들과 기술토론을 하기 위한 질문 목록을 만들기 위해 이 프로젝트를 시작했습니다. 하지만 그보다 뭔가 더 해보고 싶어졌습니다. 7 | 8 | 저는 사실 면접장에서 기술적인 질문을 하기 보다는, 후보자와 실제 코드를 앞에 두고 같이 앉아서 키보드 위에 손을 올리고 실질적인 문제들로 하루 종일 짝코딩 하는 편을 선호합니다. 가능하다면 회사 동료들과 돌아가면서요. 하지만 이런 기술적인 질문으로 멋진 토론을 유도할 수도 있고, 서로의 지식을 공유하는 좋은 방법이기도 한 것 같습니다. 9 | 10 | 이 백엔드 개발자용 질문 목록 프로젝트는 후보자에 대해 면밀히 알고자 할 때 쓸만한 질문을 모았습니다. 단, 한 후보에게 모든 질문을 다 하지는 마세요. 몇 시간이 걸릴지도 모르고, 의미도 없습니다. 그리고 한 사람이 알기에는 너무 광범위한 지식을 다루고 있습니다. JD와 유관한 질문을 추려서 기술적인 토론이 더 의미있도록 해 보세요. 11 | 12 | ### 알림 13 | 모든 질문은 기본적으로 열린 질문이고, 정답이 없는 질문도 있습니다. 모든 질문은 대화의 물꼬를 트는 용도로 작성하였습니다. 아마 정답이 정해진 질문보다 후보자의 역량을 확인하기에 더 적합할 겁니다. 개인적으로는 제가 아직 제대로 알지 못하는 분야의 질문을 선택하기도 합니다. 14 | 15 | 다시 한번 강조하지만, 이 질문만으로는 충분하지 않습니다. 후보자와 오랫동안 짝코딩을 해 보세요. 후보자의 개발 스타일, 문제 접근 방식을 알 수 있고, 후보자 편에서는 지원 회사의 업무 방식에 대해 구체적으로 알 수 있는 기회가 됩니다. 16 | 17 | 이 프로젝트는 [Front-end Job Interview Questions](https://github.com/darcyclarke/Front-end-Developer-Interview-Questions) by [@darcyclarke](https://github.com/darcyclarke) 의 영향으로 시작되었습니다. 18 | 19 | 20 | 21 | ### 정답은 어디있나요? 22 | 23 | 조만간 완성할 것 같습니다. Contribute해 주신다면 대단히 감사하겠습니다! 24 | 25 | 26 | ## 목차 27 | 28 | * [디자인 패턴](#patterns) 29 | * [전역객체는 나쁘다](#전역객체는-나쁘다) 30 | * [역제어 패턴 (IoC)](#역제어-패턴-ioc) 31 | * [데메테르 법칙](#데메테르-법칙) 32 | * [Active-Record](#Active-Record) 33 | * [Data-Mapper](#Data-Mapper) 34 | * [억만금짜리 실수](#억만금짜리-실수) 35 | * [상속 vs 컴포지션](#상속-vs-컴포지션) 36 | * [손상 방지 레이어 (Anti-corruption Layer)](#손상-방지-레이어-anti-corruption-layer) 37 | * [싱글톤 (Singleton)](#싱글톤-singleton) 38 | * [데이터 추상화](#데이터-추상화) 39 | * [DRY (Don't Repeat Yourself)](#dry-dont-repeat-yourself) 40 | * [의존성 지옥 (Dependency Hell)](#의존성-지옥-dependency-hell) 41 | * [Goto는 나쁘다](#goto는-나쁘다) 42 | * [견고함의 원칙 (Robustness principle)](#견고함의-원칙-robustness-principle) 43 | * [관심사 분리 (Seperation of Concerns)](#관심사-분리-seperation-of-concerns) 44 | 45 | * [코드 설계](#design) 46 | * [높은 응집도 낮은 결합도](#높은-응집도-낮은-결합도) 47 | * [인덱스 0](#인덱스-0) 48 | * [TDD](#tdd) 49 | * [DRY 원칙](#dry-원칙) 50 | * [결합도 vs 응집도](#결합도-vs-응집도) 51 | * [리팩토링](#리팩토링) 52 | * [코드 주석](#코드-주석) 53 | * [디자인 vs 아키텍쳐](#디자인-vs-아키텍쳐) 54 | * [테스트 우선](#테스트-우선) 55 | * [다중 상속](#다중-상속) 56 | * [Stored Procedure의 비즈니스 로직](#stored-procedure의-비즈니스-로직) 57 | * [객체 지향 설계의 지배](#객체-지향-설계의-지배) 58 | * [악취나는 설계](#악취나는-설계) 59 | * [언어](#languages) 60 | * [세가지 나쁜 점](#세가지-나쁜-점) 61 | * [함수형 언어](#함수형-언어) 62 | * [클로저](#클로저) 63 | * [제네릭](#제네릭) 64 | * [고차 함수](#고차-함수) 65 | * [반복문과 재귀](#반복문과-재귀) 66 | * [함수를 일등 시민으로 간주](#함수를-일등-시민으로-간주) 67 | * [익명함수](#익명함수) 68 | * [정적/동적 타입](#정적동적-타입) 69 | * [네임스페이스](#네임스페이스) 70 | * [언어 상호운용성](#언어-상호운용성) 71 | * [자바를 싫어하는 이유](#자바를-싫어하는-이유) 72 | * [좋은 언어 나쁜 언어](#좋은-언어-나쁜-언어) 73 | * [참조 투명성](#참조-투명성) 74 | * [스택과 힙](#스택과-힙) 75 | * [패턴 매칭](#패턴-매칭) 76 | * [예외](#예외) 77 | * [변성과 반공변성 상속](#변성과-반공변성-상속) 78 | * [생성자와 인터페이스](#생성자와-인터페이스) 79 | * [Node.js](#nodejs) 80 | * [Java와 시간여행](#java와-시간여행) 81 | * [Web](#web) 82 | * [3rd Party 쿠키](#3rd-party-쿠키) 83 | * [API 버전관리](#api-버전관리) 84 | * [SPAs](#spas) 85 | * [Statelessness](#statelessness) 86 | * [REST vs SOAP](#rest-vs-soap) 87 | * [MVC와 MVVM](#mvc와-mvvm) 88 | * [DB](#databases) 89 | * [DB 마이그레이션](#db-마이그레이션) 90 | * [특별한 Null](#특별한-null) 91 | * [ACID](#acid) 92 | * [스키마 마이그레이션](#스키마-마이그레이션) 93 | * [Lazy Loading](#lazy-loading) 94 | * [N+1 문제](#n1-문제) 95 | * [가장 느린 쿼리](#가장-느린-쿼리) 96 | * [정규화](#정규화) 97 | * [Blue/Green Deployment](#bluegreen-deployment) 98 | * [NoSQL](#nosql) 99 | * [최종 일관성(Eventual Consistency)](#최종-일관성-eventual-consistency) 100 | * [CAP 정리](#cap-정리) 101 | * [NoSQL](#nosql) 102 | * [NoSQL과 확장성](#nosql과-확장성) 103 | * [document DB와 관계형 DB](#document-db와-관계형-db) 104 | * [버전관리](#codeversioning) 105 | * [Git에서의 branch와 HG에서의 branch](#git에서의-branch와-hg에서의-branch) 106 | * [DVCS](#dvcs) 107 | * [GitFlow와 GitHub Flow](#gitflow와-github-flow) 108 | * [Rebase](#rebase) 109 | * [Git에서의 merge와 HG에서의 merge](#git에서의-merge와-hg에서의-merge) 110 | * [동시성(Concurrency)](#concurrency) 111 | * [왜?](#왜) 112 | * [동시성 테스트](#동시성-테스트) 113 | * [경쟁 상태 (Race Condition)](#경쟁-상태-race-condition) 114 | * [Deadlock](#deadlock) 115 | * [Process Starvation](#process-starvation) 116 | * [Free 알고리즘](#free-알고리즘) 117 | * [분산 시스템](#distributed) 118 | * [분산 시스템 테스트](#분산-시스템-테스트) 119 | * [비동기 통신](#비동기-통신) 120 | * [원격 프로시저 호출](#원격-프로시저-호출) 121 | * [분산 시스템의 설계](#분산-시스템의-설계) 122 | * [장애 허용](#장애-허용) 123 | * [장애](#장애) 124 | * [네트워크 분할](#네트워크-분할) 125 | * [분산 시스템의 맹점](#분산-시스템의-맹점) 126 | * [Request/Reply vs Publish/Subscribe](#requestreply-vs-publishsubscribe) 127 | * [트랜잭션 구현](#트랜잭션-구현) 128 | * [소프트웨어 생명주기와 팀 관리](#management) 129 | * [Agility](#agility) 130 | * [레거시 코드](#레거시-코드) 131 | * [레거시 코드 ELI5](#레거시-코드-eli5) 132 | * [칸반 팔기](#칸반-팔기) 133 | * [애자일 방법론 vs 폭포수 방법론](#애자일-방법론-vs-폭포수-방법론) 134 | * [미팅에 의한 죽음](#미팅에-의한-죽음) 135 | * [늦어버린 프로젝트](#늦어버린-프로젝트) 136 | * [애자일 선언문](#애자일-선언문) 137 | * [CTO가 된다면](#cto가-된다면) 138 | * [PM](#pm) 139 | * [팀 조직](#팀-조직) 140 | * [팀 이탈](#팀-이탈) 141 | * [품질](#품질) 142 | * [코딩에 관한 세가지](#코딩에-관한-세가지) 143 | * [한 달의 혁신](#한-달의-혁신) 144 | * [알고리즘](#algorithms) 145 | * [LIFO를 사용한 FIFO](#lifo를-사용한-fifo) 146 | * [Stack Overflow](#stack-overflow) 147 | * [팩토리얼](#팩토리얼) 148 | * [REPL](#repl) 149 | * [조각 모음](#조각-모음) 150 | * [미로](#미로) 151 | * [메모리 누수](#메모리-누수) 152 | * [PRNG](#prng) 153 | * [가비지 콜렉션](#가비지-콜렉션) 154 | * [큐](#큐) 155 | * [간단한 웹 서버](#간단한-웹-서버) 156 | * [큰 파일 정렬](#큰-파일-정렬) 157 | * [중복 감지](#중복-감지) 158 | * [소프트웨어 아키텍처](#architecture) 159 | * [노 캐시](#노-캐시) 160 | * [Event-Driven 아키텍쳐](#eventdriven-아키텍쳐) 161 | * [Readibility](#readibility) 162 | * [즉각적 설계와 진화적 아키텍쳐](#즉각적-설계와-진화적-아키텍쳐) 163 | * [Scale out, Scale up](#scale-out-scale-up) 164 | * [사용자 세션 실패](#사용자-세션-실패) 165 | * [CQRS](#cqrs) 166 | * [n-계층](#n계층) 167 | * [확장성](#확장성) 168 | * [C10k](#c10k) 169 | * [P2P](#p2p) 170 | * [CGI](#cgi) 171 | * [Vendor Lock-in](#vendor-lockin) 172 | * [Pub/Sub](#pubsub) 173 | * [CPU](#cpu) 174 | * [성능](#성능) 175 | * [DDOS](#ddos) 176 | * [성능과 확장성](#성능과-확장성) 177 | * [강한 결합도](#강한-결합도) 178 | * [클라우드 준비](#클라우드-준비) 179 | * [즉각적인 아키텍쳐](#즉각적인-아키텍쳐) 180 | * [설계, 아키텍쳐, 기능성, 미학](#설계-아키텍쳐-기능성-미학) 181 | * [SOA & MSA](#soa) 182 | * [긴 트랜잭션](#긴-트랜잭션) 183 | * [SOA와 Micro Service](#soa와-micro-service) 184 | * [버전관리와 주요 변경 사항](#버전관리와-주요-변경-사항) 185 | * [Sages와 보정 작업](#sages와-보정-작업) 186 | * [Too Micro](#too-micro) 187 | * [Micro Service Architecture](#micro-service-architecture) 188 | * [보안](#security) 189 | * [기본 보안](#기본-보안) 190 | * [암호화 개발의 필요](#암호화-개발의-필요) 191 | * [2-FA](#2fa) 192 | * [로그의 민감한 데이터](#로그의-민감한-데이터) 193 | * [SQL Injection](#sql-injection) 194 | * [SQL Injection 삭제](#sql-injection-삭제) 195 | * [XSS](#xss) 196 | * [사이트 위조 공격](#사이트-위조-공격) 197 | * [HTTPS](#https) 198 | * [MITM 공격](#mitm-공격) 199 | * [세션 도난](#세션-도난) 200 | * [일반](#general) 201 | * [왜 함수형 프로그래밍인가?](#왜-함수형-프로그래밍인가?) 202 | * [브라우저](#브라우저) 203 | * [TCP 소켓](#tcp-소켓) 204 | * [캡슐화](#캡슐화) 205 | * [실시간 시스템](#실시간-시스템) 206 | * [실시간과 메모리 할당](#실시간과-메모리-할당) 207 | * [불가역성](#불가역성) 208 | * [가변 vs 불변](#가변-vs-불변) 209 | * [객체 관계의 임피던스 부정합](#객체-관계의-임피던스-부정합) 210 | * [캐시 사이즈](#캐시-사이즈) 211 | * [TCP와 HTTP](#tcp와-http) 212 | * [클라이언트 사이드 vs 서버 사이드](#클라이언트-사이드-vs-서버-사이드) 213 | * [믿을만한 채널과 믿을 수 없는 채널](#믿을만한-채널과-믿을-수-없는-채널) 214 | * [백만불짜리 실수](#백만불짜리-실수) 215 | * [열린 질문](#open) 216 | * [변화에 대한 저항](#변화에-대한-저항) 217 | * [쓰레드 ELI5](#쓰레드-eli5) 218 | * [혁신과 예측가능함](#혁신과예측가능함) 219 | * [좋은 코드](#좋은-코드) 220 | * [스트리밍](#스트리밍) 221 | * [1 주간의 향상](#1-주간의-향상) 222 | * [이번 주에 배운 것](#이번-주에-배운-것) 223 | * [미적 요소](#미적-요소) 224 | * [최근 읽은 5 권의 책](#최근-읽은-5-권의-책) 225 | * [CI/CD 소개](#cicd-소개) 226 | * [바퀴의 재발명](#바퀴의-재발명) 227 | * [Not Invented Here](#not-invented-here) 228 | * [다음 자동화 대상](#다음-자동화-대상) 229 | * [개발이 어려운 이유](#개발이-어려운-이유) 230 | * [신규 도메인 개발과 구현된 적이 있는 도메인](#신규-도메인-개발과-구현된-적이-있는-도메인) 231 | * [Google.com 동작](#googlecom-동작) 232 | * [idle 상태](#idle-상태) 233 | * [유니코드](#유니코드) 234 | * [Monolithic 변호](#monolithic-변호) 235 | * [프로페셔널 개발자](#프로페셔널-개발자) 236 | * [이것은 예술이다](#이것은-예술이다) 237 | * [연관 상품 광고](#연관-상품-광고) 238 | * [일반 기업 vs 스타트업](#일반-기업-vs-스타트업) 239 | * [자랑거리](#자랑거리) 240 | * [코드 제시형](#snippets) 241 | * [클로저 조심하기](#클로저-조심하기) 242 | * [Erasure 타입](#erasure-타입) 243 | * [메모리 누수](#메모리-누수) 244 | * [switch 제거](#switch-제거) 245 | * [if 제거](#if-제거) 246 | * [if-chain 제거](#ifchain-제거) 247 | * [빌게이츠 스타일](#billgates) 248 | * [거울](#거울) 249 | * [복제인간](#복제인간) 250 | * [반대](#반대) 251 | * [네이버](#네이버) 252 | * [Cobol](#cobol) 253 | * [10 년 후](#10-년-후) 254 | * [나를 해고하세요](#나를-해고하세요) 255 | * [레거시 리팩토링](#레거시-리팩토링) 256 | * [거짓말 하세요](#거짓말-하세요) 257 | * [스스로에게 조언](#스스로에게-조언) 258 | 259 | ### [[↑]](#toc) 디자인 패턴: 260 | 261 | #### 전역객체는 나쁘다 262 | 전역 static 객체가 나쁜 이유는 무엇인가요? 코딩으로 예를 들어 설명해 주세요. 263 | 264 | [Resources](design-patterns/globals-are-evil.md) 265 | 266 | #### 역제어 패턴 (IoC) 267 | 역제어 패턴(IoC)에 대해, 특히 설계 측면에서 설명해 주세요. 268 | 269 | [Resources](design-patterns/inversion-of-control.md) 270 | 271 | #### 데메테르 법칙 272 | 데메테르 법칙LoD(최소한의 지식 규칙)에 의하면 객체간의 정보가 제한되어야 하며 오직 직접 호출한 객체와 통신해야 한다고 합니다(낯선 객체와 통신하지 말라고 하기도 함). 이 원칙을 위반하는 코드를 작성해 보세요. 그리고 왜 나쁜 디자인인지 설명하고 수정해 보세요. 273 | 274 | [Resources](design-patterns/law-of-demeter.md) 275 | 276 | #### Active-Record 277 | ActiveRecord 는 insert, update, delete 등의 함수와 DB table의 열을 속성으로 갖는 객체를 생성하는 디자인 패턴입니다. 이 패턴의 한계와 함정이 무엇인지 귀하의 경험에 비추어 의견을 이야기 해주세요. 278 | 279 | [Resources](design-patterns/active-record.md) 280 | 281 | #### Data-Mapper 282 | Data-Mapper 는 객체와 DB 간 데이터 이동 중에 각각을 독립적으로 유지하기 위해 mapper를 사용하는 디자인 패턴입니다. 반면에, ActiveRecode 객체는 객체와 DB 간의 연결을 지속하기 위한 작업과 기본 DB 속성값을 직접 통합합니다. 이런 패턴에 대한 의견이 있으신가요? 각각 언제 사용하는게 좋을까요? 283 | 284 | [Resources](design-patterns/data-mapper.md) 285 | 286 | #### 억만금짜리 실수 287 | Null의 도입이 억만금짜리 실수로 불리우는 이유는 무엇일까요? 또, Null문제를 해결하기 위한 Null 객체 패턴(GOF)이나 옵션 자료형에 대해 이야기해 봅시다. 288 | 289 | [Resources](design-patterns/billion-dollar-mistake.md) 290 | 291 | #### 상속 vs 컴포지션 292 | 많은 사람들이 OOP에서 상속보다 컴포지션이 낫다고들 합니다. 당신의 의견은 어떻습니까? 293 | 294 | [Resources](design-patterns/inheritance-vs-composition.md) 295 | 296 | #### 손상 방지 레이어 (Anti-corruption Layer) 297 | 손상 방지 레이어(Anti-corruption Layer) 패턴이 무엇입니까? 298 | 299 | [Resources](design-patterns/anti-corruption-layer.md) 300 | 301 | #### 싱글톤 (Singleton) 302 | 싱글톤(Singleton) 디자인 패턴은 객체의 생성자를 하나로 제한합니다. 하지만 쓰레드에 안전한 싱클톤 클래스를 작성하기는 단순하지 않은데요, 한번 작성해 주시겠습니까? 303 | 304 | #### 데이터 추상화 305 | 클라이언트에 영향 없이 구현부를 변경하는 기능을 데이터 추상화라고 합니다. 이 속성에 반하는 예제를 작성해 주시고, 수정하는 과정을 보여주세요. 306 | 307 | [Resources](design-patterns/data-abstraction.md) 308 | 309 | #### DRY (Don't Repeat Yourself) 310 | DRY(Don't Repeat Yourself) 원칙을 위반하는 코드를 작성하시고, 수정하는 과정을 보여주세요. 311 | 312 | [Resources](design-patterns/dont-repeat-yourself.md) 313 | 314 | #### 의존성 지옥 (Dependency Hell) 315 | 의존성 지옥(Dependency Hell)은 어떻게 해결하는게 좋을까요? 316 | 317 | [Resources](design-patterns/dependency-hell.md) 318 | 319 | #### Goto는 나쁘다 320 | `goto` 문에 대해 어떻게 생각하시나요? `goto` 문의 사용을 비판하고 대신 구조화된 프로그래밍을 주창한 Edsger Dijkstra의 유명한 논문 "Go To Statement Considered Harmful"에 대해 들어보셨을 겁니다. `goto` 문은 항상 논란거리었는데요, 심지어 Dijkstra가 'goto가 유해한 것 같다'고 한 말조차 비판받기도 했습니다. 이 `goto` 문에 대해 어떻게 생각하시나요? 321 | 322 | [Resources](design-patterns/goto-is-evil.md) 323 | 324 | #### 견고함의 원칙 (Robustness principle) 325 | 견고함의 원칙(The robustness principle)은 "*보내기는 더디하고 받기는 쉬이하라*"는 일반적인 소프트웨어 설계의 가이드라인입니다. 때때로 "*관용적인 독자와 신중한 작가가 되라*"로 불리기도 합니다. 이 원칙에 대해 이론적인 해석을 해 봅시다. 326 | 327 | #### 관심사 분리 (Seperation of Concerns) 328 | 관심사 분리(Separation of Concerns)는 프로그램을 각각의 구역으로 격리하는 설계 원칙으로, 각 구역은 관심사가 분리된 것으로 간주됩니다. 객체, 함수, 모듈, MVC 같은 패턴 등 관심사 분리를 달성하기 위한 수많은 메커니즘이 있습니다. 이 주제에 대해 토론해 봅시다. 329 | 330 | 331 | ### [[↑]](#toc) 코드 설계: 332 | 333 | #### 높은 응집도 낮은 결합도 334 | 보통 객체 지향 설계의 가장 중요한 목적으로 높은 응집도, 낮은 결합도를 꼽는데요, 각각 어떤 의미이고 왜 중요한지, 또 어떻게 달성할 수 있는지 설명해 주세요. 335 | 336 | #### 인덱스 0 337 | 많은 언어에서 배열의 인덱스 시작이 0인 이유가 무엇인가요? 338 | 339 | #### TDD 340 | 평소에 테스트를 어떤식으로 수행하시고, TDD가 코드 설계에 어떤 영향을 주는지 설명해 주세요. 341 | 342 | #### DRY 원칙 343 | DRY(Don’t Repeat Yourself) 원칙을 위반하는 사례로서의 코드를 작성하세요. 그리고 왜 나쁜 설계인지 설명하고 수정해 보세요. 344 | 345 | #### 결합도 vs 응집도 346 | 결합도와 응집도의 차이점은 무엇인가요? 347 | 348 | #### 리팩토링 349 | 리팩토링이 어디에 유용한가요? 350 | 351 | #### 코드 주석 352 | 주석이 필요하다고 생각하나요? 가능한 주석을 쓰지 말고, 주석이 필요 없도록 코딩하라는 사람도 있는데요, 그런 방식에 동의하시나요? 353 | 354 | #### 디자인 vs 아키텍쳐 355 | 소프트웨어 디자인과 소프트웨어 아키텍처의 차이는 무엇인가요? 356 | 357 | #### 테스트 우선 358 | TDD 에서 왜 실제 코드보다 테스트 코드를 먼저 작성하나요? 359 | 360 | #### 다중 상속 361 | C++는 다중 상속을 지원하고, 자바는 하나의 클래스가 여러 인터페이스를 구현할 수 있습니다. 이는 직교성에 어떤 영향을 주나요? 다중 상속과 다중 인터페이스 구현이 주는 영향이 서로 다른가요? 위임과 상속이 어떻게 다른가요? (이 문제는 책 ‘실용주의 프로그래머’에서 발췌했습니다.) 362 | 363 | #### Stored Procedure의 비즈니스 로직 364 | Stored Procedure에 비즈니스 로직을 구현했을 때의 장단점을 설명해 주세요. 365 | 366 | #### 객체 지향 설계의 지배 367 | 수 년간 객체 지향 설계가 시장을 지배한 이유에 대해 당신의 의견을 말해주세요. 368 | 369 | #### 악취나는 설계 370 | 당신의 코드 설계에서 악취가 나는지 알려면 어떻게 해야 할까요? 371 | 372 | 373 | ### [[↑]](#toc) 언어: 374 | 375 | #### 세가지 나쁜 점 376 | 당신의 주력 언어가 왜 나쁜지 세 가지만 말해보세요. 377 | 378 | #### 함수형 언어 379 | 근래 함수형 언어가 각광받는 이유가 무엇일까요? 380 | 381 | #### 클로저 382 | 클로저가 무엇이고, 어디에 쓰이나요? 클로저와 클래스의 공통점은 무엇인가요? 383 | 384 | #### 제네릭 385 | 제너릭이 어떨 때 쓰이나요? 386 | 387 | #### 고차 함수 388 | 고차 함수란 무엇인가요? 고차 함수는 어떤 상황에서 쓰나요? 귀하의 주력 언어로 작성해 보세요. 389 | 390 | #### 반복문과 재귀 391 | 반복문을 작성한 다음, 변수를 쓰지 말고 재귀 함수로 바꿔보세요. (토론) 392 | 393 | #### 함수를 일등 시민으로 간주 394 | 어떤 언어가 함수를 일등 시민으로 간주한다는 것이 무엇을 의미하나요? 395 | 언어에서 함수가 일등시민인지 여부가 왜 중요한가요? 396 | 397 | #### 익명함수 398 | 익명함수의 유용성을 예를 들어 설명해 주세요. 399 | 400 | #### 정적/동적 타입 401 | 수 많은 타입 시스템이 있는데요, 정적/동적 타입 시스템에 대해서, 그리고 그 장단점에 대해서 이야기 해 봅시다. 아마 이 주제에 대한 의견이나 선호하는 방식이 있을 것입니다. 엔터프라이즈 급 소프트웨어를 개발하기 위해 특정 타입 시스템이 왜, 그리고 언제 쓰여야 하는지 의견을 말해주시고 토론해 봅시다. 402 | 403 | #### 네임스페이스 404 | 네임스페이스는 어떨 때 유용한가요? 네임스페이스의 대안을 말해보세요. 405 | 406 | #### 언어 상호운용성 407 | 자바와 C#의 상호운용성에 대해 이야기 해 봅시다. (다른 임의의 2개의 언어도 가능) 408 | 409 | #### 자바를 싫어하는 이유 410 | 많은 개발자가 자바를 좋아하지 않는 이유는 무엇인가요? 411 | 412 | #### 좋은 언어 나쁜 언어 413 | 무엇이 좋은 언어와 나쁜 언어를 만드나요? 414 | 415 | #### 참조 투명성 416 | 참조(Referentially) 투명 함수(순수 함수)와 참조 불투명 함수를 각각 하나씩 작성하세요. (토론) 417 | 418 | #### 스택과 힙 419 | Stack과 Heap은 무엇인가요? Stack Overflow는 무엇인가요? 420 | 421 | #### 패턴 매칭 422 | 일부 언어, 특히 함수형 언어는 패턴 매칭을 허용합니다. 이 사실을 알고 있나요? 그리고 패턴 매칭과 Switch 절이 어떻게 다른가요? 423 | 424 | #### 예외 425 | 어떤 언어는 설계상 예외를 허용하지 않는데요, 그 이유와 장단점은 무엇일까요? 426 | 427 | #### 변성과 반공변성 상속 428 | `Cat`가 `Animal` 이면, `TakeCare`는 `TakeCare` 인가요? 429 | 430 | #### 생성자와 인터페이스 431 | Java나 C# 등 많은 언어에서 인터페이스에 생성자가 없는 이유가 무엇인가요? 432 | 433 | #### Node.js 434 | 최근 몇 년간 Node가 많이 과장된 것 같습니다. 브라우저에서 실행되도록 고안된 언어를 백엔드에서 사용하는 부분에 대해 어떻게 생각하시나요? 435 | 436 | #### Java와 시간여행 437 | 만약 과거로 돌아가서 Java(C#, Python, Go 등 주력언어) 설계자와 대화할 수 있다면 어떤 부분을 바꿔야 한다고 설득하겠습니까? 명시적인 예외(checked exception)를 없애달라고 할까요? 부호 없는 기본 자료형을 추가해달라고 할까요? 다중 상속을 추가해 달라고 할까요? 438 | 439 | 440 | ### [[↑]](#toc) Web: 441 | 442 | #### 3rd Party 쿠키 443 | first-party(도메인 귀속) 쿠키와 third-party(도메인 독립) 쿠키를 다르게 취급하는 이유는 무엇인가요? 444 | 445 | #### API 버전관리 446 | 웹 API의 버전관리는 어떻게 하시나요? 447 | 448 | #### SPAs 449 | 백엔드 관점에서 SPA는 어떤 단점이나 문제점이 있을까요? 450 | 451 | #### Statelessness 452 | 상태 정보가 없는(stateless) 서비스를 만들기 위해 노력하는 일반적인 이유는 무엇인가요? 상태 정보가 없는 코드가 왜 좋으며 상태정보를 보관하는 방식(stateful)이 왜 나쁜가요? 453 | 454 | #### REST vs SOAP 455 | REST 와 SOAP: 각각 어떤 상황에서 선택해야 하나요? 456 | 457 | #### MVC와 MVVM 458 | 웹개발에서 백엔드나 프론트엔드 모두 MVC나 MVVM 패턴이 매우 일반적입니다. 각각이 어떤 의미이고, 적합한 이유는 무엇인가요? 459 | 460 | 461 | ### [[↑]](#toc) DB: 462 | 463 | #### DB 마이그레이션 464 | 서로 다른 DB간 마이그레이션을 어떻게 진행하시나요?(예: MySQL에서 PostgreSQL로) 마이그레이션 프로젝트의 관리자라면 어떤 이슈가 예상되나요? 465 | 466 | [Resources](databases/db-migrations.md) 467 | 468 | #### 특별한 Null 469 | DB가 null을 특수 케이스로 보는 이유가 무엇인가요? 예를 들면, 다음 SQL문 ```SELECT FROM table WHERE field = null```이 널을 포함하는 ``field``를 가져오지 못하는 이유가 무엇인가요? 470 | 471 | [Resources](databases/null-is-special.md) 472 | 473 | #### ACID 474 | ACID는 대부분의 DB가 지원하는 트랜잭션이 보장하는 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)의 네 가지 속성을 말하는 약자입니다. 이 ACID에 대해 알고 계시나요? 구체적으로 얘기해 봅시다. 475 | 476 | [Resources](databases/acid.md) 477 | 478 | #### 스키마 마이그레이션 479 | DB 스키마를 어떻게 마이그레이션 하시나요? 다시말해, 응용프로그램의 버전이 올라감에 따라 변경된 DB 스키마를 자동화하여 적용하는 방법은 무엇인가요? 480 | 481 | [Resources](databases/schema-migrations.md) 482 | 483 | #### Lazy loading 484 | Lazy loading을 어떻게 만들어 낼까요? 언제 유용하고, 이 설계방식의 함정은 무엇인가요? 485 | 486 | [Resources](databases/lazy-loading.md) 487 | 488 | #### N+1 문제 489 | "N + 1 문제"는 lazy-loading이 활성화된 부모-자식 관계로 설정된 ORM객체가 하나의 쿼리로 각각의 자식을 읽어올 때 발생하는 문제입니다. 이 문제를 어떻게 수정하시겠습니까? 490 | 491 | [Resources](databases/n1-problem.md) 492 | 493 | #### 가장 느린 쿼리 494 | 프로그램에서 가장 비용이 많이드는 쿼리를 어떻게 찾으시겠습니까? 495 | 496 | [Resources](databases/slowest-queries.md) 497 | 498 | #### 정규화 499 | 항상 DB를 정규화해야 한다고 생각하시나요? 언제 DB를 정규화하지 않고 쓸 수 있나요? 500 | 501 | [Resources](databases/normalization.md) 502 | 503 | #### Blue/Green Deployment 504 | Blue-Green Deployment라 불리우는 CI 기술은 동일한 두 개의 프로덕션 환경에서 한 쪽이 작동중일 때 다른 쪽에 배포하고 간단한 테스트 후 다른 쪽 환경으로 안전하게 트래픽을 전환하는 기술입니다. 이 기술은 배포시 DB 구조나 내용이 변경될 때 더욱 복잡해집니다. 이 주제에 대해 토론해 봅시다. 505 | 506 | [Resources](databases/bluegreen-deployment.md) 507 | 508 | 509 | ### [[↑]](#toc) NoSQL: 510 | 511 | #### 최종 일관성(Eventual Consistency) 512 | 최종 일관성(Eventual Consistency)은 무엇인가요? 513 | 514 | #### CAP 정리 515 | 보통 CAP 정리라고 알려져 있는 브루어(Brewer)의 정리는 시스템 설계자가 네트워크 파티션(Partition, P)에서 일관성(Consistency, C)과 가용성(Availability, A) 사이에서 하나를 선택해야 한다는 정리입니다. CP, AP, CA 시스템을 각각 예를 들어 설명해 주세요. 516 | 517 | #### NoSQL 518 | 최근 NoSQL에 대한 관심이 부상하는 현상을 어떻게 설명하시겠습니까? 519 | 520 | #### NoSQL과 확장성 521 | NoSQL은 확장성 문제를 어떻게 해소하나요? 522 | 523 | #### document DB와 관계형 DB 524 | 어떤 경우에 MySQL이나 PostgreSQL 같은 RDB 대신 MongoDB 같은 document DB를 사용하시겠습니까? 525 | 526 | 527 | ### [[↑]](#toc) 버전관리: 528 | 529 | #### Git에서의 branch와 HG에서의 branch 530 | Mercurial이나 git이 SVN 보다 branch 따기 쉬운 이유가 무엇인가요? 531 | 532 | #### DVCS 533 | SVN 같은 중앙 집중형 버전 관리 시스템과 비교하여 Git 같은 분산형 버전 관리 시스템이 갖는 장단점은 무엇인가요? 534 | 535 | #### GitFlow와 GitHub Flow 536 | GitHub Flow와 GitFlow의 업무 흐름을 설명해주세요. 537 | 538 | #### Rebase 539 | Rebase란 무엇인가요? 540 | 541 | #### Git에서의 merge와 HG에서의 merge 542 | Mercurial과 git이 SVN이나 CVS보다 merge가 쉬운 이유는 무엇인가요? 543 | 544 | 545 | ### [[↑]](#toc) 동시성(Concurrency): 546 | 547 | #### 왜? 548 | 동시성(Concurrency)이 필요한 이유를 설명해 주세요. 549 | 550 | #### 동시성 테스트 551 | 멀티쓰레딩 / 동시 코드의 테스트가 어려운 이유는 무엇인가요? 552 | 553 | #### 경쟁 상태 (Race Condition) 554 | 경쟁 상태(Race Condition)란 무엇인가요? 선호하는 언어로 예제 코드를 작성해 주세요. 555 | 556 | #### Deadlock 557 | Deadlock이 무엇인가요? Deadlock이 걸리는 코드를 작성해 보시겠습니까? 558 | 559 | #### Process Starvation 560 | Process Starvation란 무엇인가요? 정의를 확인하고 이야기 하셔도 좋습니다. 561 | 562 | #### Free 알고리즘 563 | Wait Free 알고리즘이 무엇인가요? 564 | 565 | 566 | ### [[↑]](#toc) 분산 시스템: 567 | 568 | #### 분산 시스템 테스트 569 | 분산 시스템은 어떻게 테스트 하나요? 570 | 571 | #### 비동기 통신 572 | 어떤 경우에 두 시스템 간 비동기 통신을 허용하나요? 573 | 574 | #### 원격 프로시저 호출 575 | 원격 프로시저 호출에서 일반적으로 예상되는 함정이 있다면 무엇일까요? 576 | 577 | #### 분산 시스템의 설계 578 | 확장성과 견고성이 보장된 분산시스템을 구축한다면, 폐쇄망 환경에서 작업할 때와 지리적으로 분산된 공용 시스템에서 작업할 때 어떤 부분이 다를까요? 579 | 580 | #### 장애 허용 581 | 장애 허용(Fault Tolerance) 웹 애플리케이션을 어떻게 관리하시겠습니까? 데스크탑 애플리케이션은요? 582 | 583 | #### 장애 584 | 분산 시스템의 장애를 어떻게 다루어야 할까요? 585 | 586 | #### 네트워크 분할 587 | 네트워크 재설정 이후 후처리 방법에 대해 이야기해 봅시다. 588 | 589 | #### 분산 시스템의 맹점 590 | 분산 시스템의 맹점은 무엇인가요? 591 | 592 | #### Request/Reply vs Publish/Subscribe 593 | Request/Reply와 Publish/Subscribe를 각각 언제 사용하시겠습니까? 594 | 595 | #### 트랜잭션 구현 596 | 트랜잭션을 지원하지 않는 시스템에서 작업한다고 가정해 봅시다. 어떤식으로 접근해야 할까요? 597 | 598 | 599 | ### [[↑]](#toc) 소프트웨어 생명주기와 팀 관리: 600 | 601 | #### Agility 602 | Agility란 무엇인가요? 603 | 604 | #### 레거시 코드 605 | 레거시 코드를 어떻게 처리하시나요? 606 | 607 | #### 레거시 코드 ELI5 608 | 제가 비 전문가인 PM이라고 가정하고, 레거시 코드가 무엇인지, 코드 품질을 왜 신경써야 하는지 설명해 주세요. 609 | 610 | #### 칸반 팔기 611 | 제가 CEO라고 가정하고, 칸반에 대해 설명하시고 투자하도록 설득해 보세요. 612 | 613 | #### 애자일 방법론 vs 폭포수 방법론 614 | 애자일과 폭포수 방법론의 가장 큰 차이는 무엇인가요? 615 | 616 | #### 미팅에 의한 죽음 617 | 회의가 너무 많은 문제를 관리자로서 어떻게 해결하시겠습니까? 618 | 619 | #### 늦어버린 프로젝트 620 | 너무 늦어버린 프로젝트를 어떻게 관리하시겠습니까? 621 | 622 | #### 애자일 선언문 623 | "*프로세스와 도구의 사유화 및 상호작용*"과 "*지속적 협상을 통한 고객 협업*"은 애자일 선언문의 절반을 차지합니다. 이에 대해 이야기 해 봅시다. 624 | 625 | #### CTO가 된다면 626 | CTO가 된다면 어떤식으로 회사를 꾸리시겠습니까? 627 | 628 | #### PM 629 | 프로그램 매니저(역자주: 사실상 프로젝트의 슈퍼맨)가 필요하다고 생각하나요? 630 | 631 | #### 팀 조직 632 | 휴가를 마음대로 쓸 수 있는 완전한 탄력적 근무 상황에서 개발팀을 조직해 보세요. 633 | 634 | #### 팀 이탈 635 | 이직이 잦은 팀을 어떻게 관리하고 임금인상 말고 어떤 방법으로 개발자가 떠나지 않도록 설득하시겠습니까? 회사 차원에서는 개발자가 떠나지 않도록 어떻게 해야 할까요? 636 | 637 | #### 품질 638 | 동료에게 바라는 가장 중요한 세 가지는 무엇인가요? 코드는 빼고요. 639 | 640 | #### 코딩에 관한 세가지 641 | 비개발자가 코딩에 대해 알았으면 하는 점 세 가지는 무엇인가요? 642 | 643 | #### 한 달의 혁신 644 | 회사에서 당신과 동료들의 삶의 질을 높히기 위해 한 달의 시간과 예산을 줬다면 무엇을 하시겠습니까? 645 | 646 | 647 | ### [[↑]](#toc) 알고리즘: 648 | 649 | #### LIFO를 사용한 FIFO 650 | LIFO 스택만 써서 FIFO 큐를 작성하세요. 다음으로 FIFO 큐만 써서 LIFO 스택을 만드세요. 651 | 652 | #### Stack Overflow 653 | Stack Overflow를 유발하는 코드를 작성하세요. 654 | 655 | #### 팩토리얼 656 | 재귀를 사용하여 팩토리얼 함수를 작성하세요. 657 | 658 | #### REPL 659 | 원하시는 언어로 입력값을 그대로 출력하는 REPL을 작성하세요. 그리고 후위표기법(RPN)에 의한 계산기능을 추가하세요. 660 | 661 | #### 조각 모음 662 | 조각모음 프로그램을 설계해보세요. 663 | 664 | #### 미로 665 | 미로를 랜덤으로 생성하는 프로그램을 작성하세요. 666 | 667 | #### 메모리 누수 668 | 메모리 누수를 유발하는 예제코드를 작성해 보세요. 669 | 670 | #### PRNG 671 | 유니크한 난수열을 발생시키세요. 672 | 673 | #### 가비지 콜렉션 674 | 간단한 GC(Garbage Collection) 시스템을 작성하세요. 675 | 676 | #### 큐 677 | 원하는 언어로 기본 메시지 브로커를 작성하세요. 678 | 679 | #### 간단한 웹 서버 680 | 아주 기본적인 웹서버를 작성해 보세요. 그리고 추후 구현할 기능들에 대해 방향성을 제시해 보세요. 681 | 682 | #### 큰 파일 정렬 683 | 10GB 짜리 파일을 어떻게 정렬하시겠습니까? 10TB 짜리는 어떻게 접근방식을 바꿔야 할까요? 684 | 685 | #### 중복 감지 686 | 중복된 파일을 프로그램적으로 어떻게 감지해 날까요? 687 | 688 | 689 | ### [[↑]](#toc) 소프트웨어 아키텍처: 690 | 691 | #### 노 캐시 692 | 언제 캐시가 필요 없거나 심지어 위험한가요? 693 | 694 | #### Event-Driven 아키텍쳐 695 | Event-Driven 아키텍처가 왜 확장성을 높히나요? 696 | 697 | #### Readibility 698 | 코드를 읽을 수 있게 만드는 것은 무엇입니까? 699 | 700 | #### 즉각적 설계와 진화적 아키텍쳐 701 | 즉각적인 설계 수정과 진화형 아키텍처의 차이점은 무엇인가요? 702 | 703 | #### Scale out, Scale up 704 | Scale out과 scale up의 차이점은 무엇이고 각각 어떤 경우에 적용하나요? 705 | 706 | #### 사용자 세션 실패 707 | Failover(대체 시스템, 부하분산 등)와 사용자 세션은 어떻게 다루나요? 708 | 709 | #### CQRS 710 | CQRS(Command Query Responsibility Segregation, 도메인 모델 설계시 CUD와 R을 분리)란 무엇이고, CQS 원칙과 어떻게 다른가요? 711 | 712 | #### n-계층 713 | 소위 말하는 "다중 계층 아키텍처"는 클라이언트-서버 시스템을 물리적/논리적인 구분, 애플리케이션 처리, 데이터 관리와 기타 다른 기능으로 각각 유지할 수 있도록 설계하는 접근방법입니다. 그중 3계층 아키텍처가 가장 널리 알려져 있습니다. 이러한 접근방식의 장단점에 대해 토론해 봅시다. 714 | 715 | #### 확장성 716 | 소프트웨어 시스템이 확장성을 갖기 위해 어떻게 설계하시겠습니까? 717 | 718 | #### C10k 719 | 누군가 한번에 만 개가 넘는 동시 접속을 처리하기 위한 네트워크 소켓의 최적화 문제에 "The "C10k problem"이라는 이름을 붙였습니다. 만 개의 동시접속을 처리하는 문제와 만 개의 클라이언트를 처리하는 문제는 같지는 않지만 문맥상 비슷합니다. 어쨌든 대단한 도전인데, 아무도 이 문제를 풀기 위한 모든 세부 사항을 알지 못합니다. 이 문제를 해결하기 위한 귀하의 전략이 궁금한데요, 한번 도전해 보시겠습니까? 720 | 721 | #### P2P 722 | 어떻게 분산형(중앙 서버가 없는) P2P 시스템을 설계하시겠습니까? 723 | 724 | #### CGI 725 | CGI(Common Gateway Interface)란 서버에서 CLI 프로그램으로 실행하고, HTTP 요청에 의해 동적으로 HTML 페이지를 생성하는 웹서버를 위한 표준 프로토콜(CGI scripts)입니다. Perl이나 PHP가 이에 해당하는 대표적인 script 언어입니다. CGI에서는 일반적으로 HTTP 요청에 의해 서버에서 새로운 프로세스가 생성되지만, FastCGI, SCGI 등에서는 사전 프로세스 로딩(preforking process) 같은 기술로 메커니즘을 개선하여 퍼포먼스를 향상시킵니다. 결국 CGI가 왜 성공하지 못하고 이런 다른 아키텍처로 대체되었을까요? 726 | 727 | #### Vendor Lock-in 728 | Vendor Lock-in 문제(플랫폼에 종속되어 발생하는 호환성 문제)에 대응하기 위해서 어떻게 설계해야 할까요? 729 | 730 | #### Pub/Sub 731 | 대형화된 발행-구독(Publish-Subscribe) 모델의 단점은 무엇인가요? 732 | 733 | #### CPU 734 | 80년대 이후 CPU의 새로운 기능은 무엇이며 프로그래밍에 어떤 영향을 주나요? 735 | 736 | #### 성능 737 | 소프트웨어 성능의 생명주기에서 어느 부분을 고려하는 것이 좋을까요? 그리고 어떻게 하나요? 738 | 739 | #### DDOS 740 | 누군가의 악의가 아니라 설계나 아키텍처의 문제에 의한 서비스 거부 현상이 어떻게 일어날 수 있을까요? 741 | 742 | #### 성능과 확장성 743 | 성능과 확장성의 관계에 대해 이야기해 보세요. 744 | 745 | #### 강한 결합도 746 | 강한 결합도(tight coupling)를 언제까지 쓸 수 있을까요? 747 | 748 | #### 클라우드 준비 749 | 시스템을 클라우드에 올리려면 어떤 특성을 갖춰야 하나요? 750 | 751 | #### 즉각적인 아키텍쳐 752 | 설계 통합이 최고의 아키텍트일까요? 간단히 말해서, 모든 개발자의 공동 노력으로 좋은 설계를 만들어낼 수 있을까요? 753 | 754 | #### 설계, 아키텍쳐, 기능성, 미학 755 | 설계와 아키텍처, 기능성, 미학의 차이점은 무엇일까요? 토론해 봅시다. 756 | 757 | 758 | ### [[↑]](#toc) SOA & MSA: 759 | 760 | #### 긴 트랜잭션 761 | SOA에서 긴 트랜잭션보다 saga 패턴이 권장되는 이유는 무엇인가요? 762 | 763 | #### SOA와 Micro Service 764 | SOA와 MSA 간의 차이는 무엇인가요? 765 | 766 | #### 버전관리와 주요 변경 사항 767 | 웹 서비스의 버전 관리, 버전간 호환성, 변경에 의한 잠재적 오류에 대해 이야기 해 봅시다. 768 | 769 | #### Sages와 보정 작업 770 | SOA에서 트랜잭션과 saga 내의 보정 작업 간의 차이는 무엇인가요? 771 | 772 | #### Too Micro 773 | 언제 MSA가 너무 작은가요? 774 | 775 | #### Micro Service Architecture 776 | MSA의 장단점은 무엇인가요? 777 | 778 | 779 | ### [[↑]](#toc) 보안: 780 | 781 | #### 기본 보안 782 | 어떻게 secure code를 작성하시겠습니까? 개발자의 임무인가요, 보안 전문가의 역할인가요? 그리고 왜 그렇게 생각하나요? 783 | 784 | #### 암호화 개발의 필요 785 | 왜 암호화 자체를 개발하거나 설계할 필요가 없다고 하나요? 786 | 787 | #### 2-FA 788 | 인증의 두 요소는 무엇인가요? 이미 서비스중인 웹앱에서 어떤 방식으로 구현하시겠습니까? 789 | 790 | #### 로그의 민감한 데이터 791 | 조심하지 않으면 언제든지 비밀번호 같은 민감정보가 로그에 기록될 수 있습니다. 이런 문제를 어떻게 하시겠습니까? 792 | 793 | #### SQL Injection 794 | SQL Injection에 취약한 코드를 작성하고 수정하세요. 795 | 796 | #### SQL Injection 삭제 797 | 정적 코드 분석기로 어떻게 SQL Injection을 탐지할 수 있나요? 이에 대한 알고리즘 작성까지 바라는 건 아니지만, 좀 거대한 주제이긴 해도 일반적인 접근방식에 대해 토론해 봅시다. 798 | 799 | #### XSS 800 | Cross-Site Scripting에 대해 알고 있나요? 모른다면 인터넷에서 정의를 확인해 보고 이에 대해 토론해 봅시다. 801 | 802 | #### 사이트 위조 공격 803 | 사이트 위조 공격(Cross-Site Forgery Attack)에 대해 알고 있나요? 모른다면 인터넷에서 정의를 확인해 보고 이에 대해 토론해 봅시다. 804 | 805 | #### HTTPS 806 | HTTPS는 어떤 방식으로 작동하나요? 807 | 808 | #### MITM 공격 809 | 중간자 공격(Man-in-the-middle Attack, MITM)이 무엇이고, HTTPS가 어떻게 중간자 공격을 막나요? 810 | 811 | #### 세션 도난 812 | 사용자 세션의 도난은 어떻게 막아야 하나요? 세션/쿠키 도용에 대해 기억나지 않는다면 위키 페이지를 읽어봅시다. 813 | 814 | 815 | ### [[↑]](#toc) 일반: 816 | 817 | #### 왜 함수형 프로그래밍인가? 818 | 함수형 프로그래밍이 왜 중요한가요? 언제 함수형 프로그래밍 언어를 써야 할까요? 819 | 820 | #### 브라우저 821 | Microsoft, Google, Opera, Mozilla 같은 회사는 어떻게 브라우저로 수익을 낼까요? 822 | 823 | #### TCP 소켓 824 | TCP 소켓을 열 때 오버헤드가 발생하는 이유는 무엇인가요? 825 | 826 | #### 캡슐화 827 | 캡슐화는 어디에 중요한가요? 828 | 829 | #### 실시간 시스템 830 | 실시간 시스템은 무엇이며, 일반적인 시스템과 어떻게 다른가요? 831 | 832 | #### 실시간과 메모리 할당 833 | 실시간 언어와 힙 메모리 할당 간의 관계에 대해 이야기 해 주세요. 834 | 835 | #### 불가역성 836 | 불가역성(Immutability)이란 생성시점에 값을 한 번 할당한 후 이후로는 값을 변경하지 않는다는 뜻입니다. 더 안전한 코드를 작성하는데 불가역성이 어떻게 도움을 줄 수 있나요? 837 | 838 | #### 가변 vs 불변 839 | 가변 변수와 불변 변수의 장단점에 대해 이야기 해 보세요. 840 | 841 | #### 객체 관계의 임피던스 부정합 842 | 객체-관계의 임피던스 부정합(Object-Relational impedance mismatch)은 무엇인가요? 843 | 844 | #### 캐시 사이즈 845 | 캐시의 크기를 정의할 때 어떤 원칙을 적용해야 할까요? 846 | 847 | #### TCP와 HTTP 848 | TCP와 HTTP의 차이점은 무엇인가요? 849 | 850 | #### 클라이언트 사이드 vs 서버 사이드 851 | 클라이언트 사이드 랜더링과 서버 사이드 랜더링의 절충안은 무엇인가요? 852 | 853 | #### 믿을만한 채널과 믿을 수 없는 채널 854 | 연속성을 보장할 수 없는 통신 프로토콜로 어떻게 연속적인 통신 프로토콜을 개발할 수 있을까요? 855 | 856 | #### 백만불짜리 실수 857 | Null 참조를 개발한 [Tony Hoare](https://en.m.wikipedia.org/wiki/Tony_Hoare) 는 "*셀 수 없는 수많은 에러, 취약성, 시스템 충돌을 초래하는 지난 40년 간의 백만불짜리 고통과 상처*"라며 "*저는 null 참조를 백만불짜리 실수라고 부릅니다*"라고 말했습니다. 귀하의 주 언어에서 null 참조를 없앤다면, 어떻게 해야 할까요? 또 그 결과는 어떨까요? 858 | 859 | 860 | ### [[↑]](#toc) 열린 질문: 861 | 862 | #### 변화에 대한 저항 863 | 사람들이 변화에 저항하는 이유가 뭘까요? 864 | 865 | #### 쓰레드 ELI5 866 | 조부모님께 쓰레드에 대해 설명해 보세요. 867 | 868 | #### 혁신과 예측가능함 869 | 소프트웨어 엔지니어는 혁신적이면서 예측가능해야 합니다. 동일한 전략에서 어떻게 이 두 목표가 공존할 수 있나요? 870 | 871 | #### 좋은 코드 872 | 좋은 코드를 좋은 코드답게 만드는 건 무엇일까요? 873 | 874 | #### 스트리밍 875 | 스트리밍이 무엇인지와 스트리밍을 어떻게 구현할지에 대해 설명해 보세요. 876 | 877 | #### 1 주간의 향상 878 | 회사에서 당신과 동료들의 삶의 질을 높히기 위해 일주일을 줬다면 어떻게 하시겠습니까? 879 | 880 | #### 이번 주에 배운 것 881 | 이번 주에 뭘 배우셨나요? 882 | 883 | #### 미적 요소 884 | 모든 설계에는 미적 요소가 있습니다. 질문 드리자면, 이 미적 요소가 당신의 친구입니까, 적입니까? 885 | 886 | #### 최근 읽은 5 권의 책 887 | 최근 읽은 5 권의 책을 말해주세요. 888 | 889 | #### CI/CD 소개 890 | 비즈니스의 규모와 복잡성 때문에 폭포수 방법론에서 지속적 배포(Continuous Delivery) 방식으로 변경하기 어려운 성공적인 대형 회사에서 지속적 배포에 대해 어떻게 소개하시겠습니까? 891 | 892 | #### 바퀴의 재발명 893 | 언제 바퀴를 다시 발명해도 말이 되나요? 894 | 895 | #### Not Invented Here 896 | "*바퀴 다시 발명하기(Reinventing the wheel)*", "*여기서 발명 안했음 신드롬(Not Invented Here Syndrome)*", "*니꺼 먹어라(Eating Your Own Food)*" 연습에 대해 이야기 해 봅시다. 897 | 898 | #### 다음 자동화 대상 899 | 현재 당신의 업무에서 다음 자동화 대상은 무엇인가요? 900 | 901 | #### 개발이 어려운 이유 902 | 소프트웨어 개발이 어려운 이유는 무엇인가요? 소프트웨어 유지보수가 어려운 이유는 무엇인가요? 903 | 904 | #### 신규 도메인 개발과 구현된 적이 있는 도메인 905 | 신규 도메인 개발과 구현된 적이 있는 도메인 중 어느 쪽을 선호하나요? 이유는 무엇인가요? 906 | 907 | #### Google.com 동작 908 | [브라우저에 google.com이라고 입력하고 엔터를 누르면 무슨 일이 일어나나요?(What happens when you type google.com into your browser and press enter?)](https://github.com/alex/what-happens-when) 909 | 910 | #### idle 상태 911 | 실행할 사용자 지정 코드가 없어서 idle 상태처럼 보일 때 OS는 무엇을 하나요? 인터럽트, 데몬, 백그라운드 서비스, 폴링, 이벤트 핸들링 등에 대해 이야기해 봅시다. 912 | 913 | #### 유니코드 914 | 유니코드/DB 트랜잭션을 5살 짜리 아이에게 설명해 보세요. 915 | 916 | #### Monolithic 변호 917 | Monolithic architecture를 변호해 보세요. 918 | 919 | #### 프로페셔널 개발자 920 | 프로패셔널 개발자가 되는 것은 무슨 의미입니까? 921 | 922 | #### 이것은 예술이다 923 | 소프트웨어 개발이 예술이나 장인정신, 혹은 공학적인 무언가일까요? 당신의 의견을 말해보세요. 924 | 925 | #### 연관 상품 광고 926 | 쇼핑몰에서 연관상품 광고를 어떻게 구현하시겠습니까? 927 | 928 | #### 일반 기업 vs 스타트업 929 | 일반 기업이 스타트업보다 혁신이 느린 이유는 무엇인가요? 930 | 931 | #### 자랑거리 932 | 최근에 달성한 자랑거리 하나 소개해 주세요. 933 | 934 | 935 | 936 | ### [[↑]](#toc) 코드 제시형: 937 | 938 | #### 클로저 조심하기 939 | 이 자바스크립트 함수의 출력 결과는? 940 | ```javascript 941 | function hookupevents() { 942 | for (var i = 0; i < 3; i++) { 943 | document.getElementById("button" + i) 944 | .addEventListener("click", function() { 945 | alert(i); 946 | }); 947 | } 948 | } 949 | ``` 950 | 951 | #### Erasure 타입 952 | 자바 제너릭의 타입 Erasure와 관련해서, 다음 자바 코드의 출력 결과는 무엇이고 그렇게 출력되는 이유는 무엇인가요? 953 | ```java 954 | ArrayList li = new ArrayList(); 955 | ArrayList lf = new ArrayList(); 956 | if (li.getClass() == lf.getClass()) // evaluates to true 957 | System.out.println("Equal"); 958 | ``` 959 | 960 | 961 | #### 메모리 누수 962 | 메모리 누수가 일어나는 지점을 짚어보세요. 963 | ```java 964 | public class Stack { 965 | private Object[] elements; 966 | private int size = 0; 967 | private static final int DEFAULT_INITIAL_CAPACITY = 16; 968 | 969 | public Stack() { 970 | elements = new Object[DEFAULT_INITIAL_CAPACITY]; 971 | } 972 | 973 | public void push(Object e) { 974 | ensureCapacity(); 975 | elements[size++] = e; 976 | } 977 | 978 | public Object pop() { 979 | if (size == 0) 980 | throw new EmptyStackException(); 981 | return elements[--size]; 982 | } 983 | 984 | /** 985 | 최소 하나 이상의 element를 위한 공간을 확보하세요. 986 | 배열이 커지면 용량이 거의 두 배가 됩니다. 987 | */ 988 | private void ensureCapacity() { 989 | if (elements.length == size) 990 | elements = Arrays.copyOf(elements, 2 size + 1); 991 | } 992 | } 993 | ``` 994 | 995 | #### switch 제거 996 | `if`문이나 일반적인 조건문은 프로그램을 절차지향적으로 만듭니다. 다음 코드에서 `switch`문을 제거하고 코드를 좀 더 객체지향적으로 만들어 주시겠어요? 997 | 998 | ```java 999 | public class Formatter { 1000 | 1001 | private Service service; 1002 | 1003 | public Formatter(Service service) { 1004 | this.service = service; 1005 | } 1006 | 1007 | public String doTheJob(String theInput) { 1008 | String response = service.askForPermission(); 1009 | switch (response) { 1010 | case "FAIL": 1011 | return "error"; 1012 | case "OK": 1013 | return String.format("%s%s", theInput, theInput); 1014 | default: 1015 | return null; 1016 | } 1017 | } 1018 | } 1019 | ``` 1020 | 1021 | 1022 | #### if 제거 1023 | 다음 코드에서 `if`문을 제거하고 코드를 좀 더 객체지향적으로 만들어 주시겠어요? 1024 | 1025 | ```java 1026 | public class TheService { 1027 | private final FileHandler fileHandler; 1028 | private final FooRepository fooRepository; 1029 | 1030 | public TheService(FileHandler fileHandler, FooRepository fooRepository) { 1031 | this.fileHandler = fileHandler; 1032 | this.fooRepository = fooRepository; 1033 | } 1034 | 1035 | public String Execute(final String file) { 1036 | 1037 | final String rewrittenUrl = fileHandler.getXmlFileFromFileName(file); 1038 | final String executionId = fileHandler.getExecutionIdFromFileName(file); 1039 | 1040 | if (executionId.equals("") || rewrittenUrl.equals("")) { 1041 | return ""; 1042 | } 1043 | 1044 | Foo knownFoo = fooRepository.getFooByXmlFileName(rewrittenUrl); 1045 | 1046 | if (knownFoo == null) { 1047 | return ""; 1048 | } 1049 | 1050 | return knownFoo.DoThat(file); 1051 | } 1052 | } 1053 | ``` 1054 | 1055 | #### if-chain 제거 1056 | 이 코드를 어떻게 리팩토링 할까요? 1057 | 1058 | ```js 1059 | function() 1060 | { 1061 | HRESULT error = S_OK; 1062 | 1063 | if(SUCCEEDED(Operation1())) 1064 | { 1065 | if(SUCCEEDED(Operation2())) 1066 | { 1067 | if(SUCCEEDED(Operation3())) 1068 | { 1069 | if(SUCCEEDED(Operation4())) 1070 | { 1071 | } 1072 | else 1073 | { 1074 | error = OPERATION4FAILED; 1075 | } 1076 | } 1077 | else 1078 | { 1079 | error = OPERATION3FAILED; 1080 | } 1081 | } 1082 | else 1083 | { 1084 | error = OPERATION2FAILED; 1085 | } 1086 | } 1087 | else 1088 | { 1089 | error = OPERATION1FAILED; 1090 | } 1091 | 1092 | return error; 1093 | } 1094 | ``` 1095 | 1096 | [Resources](snippets/kill-the-if-chain.md) 1097 | 1098 | ### [[↑]](#toc) 빌게이츠 스타일: 1099 | 이 섹션은 [맨홀 뚜껑 질문, Manhole Cover Question](https://en.wikipedia.org/wiki/Microsoft_interview#Manhole_cover_question)에서 좀 이상한 질문들을 모은 것입니다. 1100 | 1101 | #### 거울 1102 | 스캐너에 거울을 넣으면 무슨 일이 일어나나요? 1103 | 1104 | #### 복제인간 1105 | 귀하의 복제인간이 귀하의 상사라면 그 사람을 위해 즐겁게 일할 수 있나요? 1106 | 1107 | #### 반대 1108 | 저를 인터뷰 해보세요. 1109 | 1110 | #### 네이버 1111 | 네이버 지식인이 다음 팁의 답변보다 나은 이유는 무엇인가요?(원문은 quora vs yahoo) 1112 | 1113 | #### Cobol 1114 | 현대 언어로 부터 Cobol을 변호해 보세요. 그리고 가능한 많은 합리적인 논쟁거리를 찾아보세요. 1115 | 1116 | #### 10 년 후 1117 | 10년 후 어디에 있을 것 같나요? 1118 | 1119 | #### 나를 해고하세요 1120 | 당신이 내 상사이고 난 해고되었습니다. 그 사실을 전해주세요. 1121 | 1122 | #### 레거시 리팩토링 1123 | 저는 레거시 시스템을 리팩토링 하고 싶습니다. 당신은 처음부터 재작성 하고 싶구요. 논쟁해 봅시다. 역할을 바꿔서도 해 봅시다. 1124 | 1125 | #### 거짓말 하세요 1126 | 당신의 상사가 회사에 거짓말 할 것을 요구했습니다. 어떻게 대응하시겠습니까? 1127 | 1128 | #### 스스로에게 조언 1129 | 과거로 여행할 수 있다면 젊은 귀하에게 무슨 조언을 해 주시겠습니까? -------------------------------------------------------------------------------- /OriginalDocuments/databases/acid.md: -------------------------------------------------------------------------------- 1 | # ACID 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 1. 원자성은 단일 트랜잭션의 쿼리가 실패 할 경우 전체 트랜잭션도 실패하고 데이터베이스가 변경되지 않은 상태로 유지되도록 지정합니다. "실패"란 애플리케이션 오류뿐만 아니라 정전과 같은 외부 요인도 의미합니다. 6 | 2. 일관성은 각 트랜잭션이 하나의 유효한 상태에서 다른 유효한 상태로 데이터베이스를 유도해야 함을 지정합니다. 불변성을 유지해야합니다. 7 | 3. 격리는 각 트랜잭션이 서로 격리되어 수행되어야 함을 지정합니다. 다양한 수준의 격리가 있습니다. 8 | * "read uncommitted" - 격리 없음 - 다른 트랜잭션에서 커밋되지 않은 데이터를 읽을 수 있습니다. 9 | * "read committed" - 더 나은 격리 - 다른 트랜잭션에서 커밋된 데이터 만 읽을 수 있습니다. 다른 트랜잭션 중에 동시 트랜잭션이 시작되었지만 더 일찍 완료된 경우 불일치가 발생합니다. 10 | * "repeatable read" - 일반적으로 "충분히 좋은" 격리 - 트랜잭션의 각 쿼리는 트랜잭션 시작시 커밋된 업데이트만 확인합니다. Lock 또는 버전 관리로 구현 될 수 있습니다. 가상 읽기가 발생할 수 있습니다. 11 | * "serializable" - 최고 수준의 격리 - 트랜잭션이 동시에 실행되지 않고 연속적으로 실행됩니다. 12 | 13 | 격리의 수준에 따라 성능이 저하됩니다. 이것이 "repeatable read"가 자주 사용되는 이유입니다. 14 | 또한, 제시된 모델은 db 엔진 구현에 따라 종종 더 복잡해집니다. 자세한 내용은 [여기](https://github.com/ept/hermitage)서 찾을 수 있습니다. 15 | 4. 내구성은 트랜잭션이 커밋 된 후 정전이나 충돌 후에도 데이터가 유지되도록 지정합니다. 16 | 17 | -------------------------------------------------------------------------------- /OriginalDocuments/databases/bluegreen-deployment.md: -------------------------------------------------------------------------------- 1 | # Blue-Green Deployment 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 이것은 Blue-Green Deployment에서 가장 까다로운 부분입니다. 이 문제에 대한 일반적인 해결책은 이전 릴리즈와 다음 릴리즈와 지원이 되는 데이터베이스 스키마를 가지는 중간 릴리즈를 가지는 것입니다. 6 | 이 접근 방식을 사용하면 quick revert를 포함하여 Blue-Green Deployment의 모든 장점을 계속 이용할 수 있습니다. 비용은 중간 릴리스의 오버헤드입니다. 7 | -------------------------------------------------------------------------------- /OriginalDocuments/databases/db-migrations.md: -------------------------------------------------------------------------------- 1 | # DB 마이그레이션 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 이 전략은 다운타임 가능성에 매우 의존적입니다. 다운타임이 가능하다면, 마이그레이션이 훨씬 쉬워질 것입니다. 특히 다음 사항들을 주의를 기울일 것입니다. 6 | 1. 마이그레이션이 시작된 이후 데이터 변경의 일관성 (다운타임이 불가능한 경우) 7 | 2. 서로 다른 db 엔진 간의 데이터 타입 호환성 8 | 3. 데이터베이스 API 변경 9 | 4. 보안 이슈 (네트워크를 통해 많은 민감한 데이터들을 옮길 때) 10 | 5. 까다로운 잠재적인 복귀 11 | -------------------------------------------------------------------------------- /OriginalDocuments/databases/lazy-loading.md: -------------------------------------------------------------------------------- 1 | # Lazy Loading 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | Lazy loading은 실제로 필요할 때까지 데이터 로드를 지연하는 패턴입니다. 데이터베이스에서 데이터를 Lazy loading하는 것은 보통 적절한 프록시 클래스를 구현하여 수행됩니다. 6 | 7 | 데이터베이스에서 많은 데이터를 가져와야하는 객체가 있는 경우 유용할 수 있지만 모든 경우에 모든 데이터가 필요한 것은 아닙니다. 객체 초기화 단계와 메모리 사용량을 줄일 수 있습니다. 8 | 9 | 반면에 작은 데이터를 얻기 위해 많은 데이터베이스 쿼리가 발생하여 성능 문제가 발생할 수 있습니다. Lazy loading은 매우 유출된 추상화이기 때문에 그렇게 어렵지 않습니다. 10 | 11 | 아마도 더 중요한 또 다른 함정은 일관성 없는 데이터로 작업할 수 있다는 것입니다. 먼저 사용자 데이터를 로드한 다음 잠시 후 사용자 주문을 로드한 경우 주문 데이터가 다른 사람에 의해 이미 수정되지 않았는지 확인할 수 없습니다. 12 | -------------------------------------------------------------------------------- /OriginalDocuments/databases/n1-problem.md: -------------------------------------------------------------------------------- 1 | # N + 1 문제 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | ORM 엔진에 따라 다르지만 일반적으로 `JOIN` 쿼리를 사용하는 것이 수정됩니다. 하이버네이트에서는 `join fetch`로 `INNER JOIN` SQL query의 결과를 냅니다. 6 | -------------------------------------------------------------------------------- /OriginalDocuments/databases/normalization.md: -------------------------------------------------------------------------------- 1 | # 정규화 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 나는 데이터베이스 비정규화는 오직 우리의 쿼리의 성능을 향상시켜야하고 다른 최적화들(인덱싱, sql 뷰)로는 충분하지 않을 경우에만 필요하다고 생각합니다. 6 | 우리는 데이터베이스의 비정규화의 비용은 데이터를 일관되게 유지하기 위한 도구를 구축하고 유지하는 것임을 기억해야한다. 7 | -------------------------------------------------------------------------------- /OriginalDocuments/databases/null-is-special.md: -------------------------------------------------------------------------------- 1 | # 특별한 Null 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | "NULL", 흔히 "알 수 없는 누락된 값" 라고 표현합니다. Null은 존재하지 않는 무언가를 표현하기 때문에 특별한 처리를 하기 위해 종종 필요합니다. 6 | NULL과 NULL의 산술 비교 결과가 NULL이기 때문에 하단의 예는 동작하지 않습니다. 7 | 8 | ```sql 9 | 1 = NULL, 1 <> NULL, 1 < NULL, 1 > NULL 10 | ``` 11 | , 그리고 심지어 12 | ```sql 13 | NULL = NULL 14 | ``` 15 | 숫자를 존재하지 않는 것과 어떻게 비교하거나 존재하지 않는 것을 존재하지 않는 것과 어떻게 비교하겠습니까?! 16 | -------------------------------------------------------------------------------- /OriginalDocuments/databases/schema-migrations.md: -------------------------------------------------------------------------------- 1 | # 스키마 마이그레이션 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 버전 제어 시스템에서 추적되는 마이그레이션 스크립트를 사용합니다. 데이터베이스 스키마에 대한 각 변경 사항은 시간순으로 정렬된 스크립트입니다. (예 : `1_add_age_to_user`, `2_add_price_to_order`로 이름이 지정됩니다. )
6 | 또한 마이그레이션 스크립트가 이미 실행된 데이터베이스를 추적합니다. 이와 같은 설정을 이용하면 마이그레이션 스크립트를 자동으로 실행하기 쉽습니다 - 응용 프로그램 시작 시 개발 환경 및 배포 전 CI -------------------------------------------------------------------------------- /OriginalDocuments/databases/slowest-queries.md: -------------------------------------------------------------------------------- 1 | # 가장 느린 쿼리 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 저는 주로 mySql 데이터베이스를 다룹니다. mySql은 느린 쿼리를 모니터링할 수 있는 도구를 제공합니다. 해야할 것은 지정된 파일에 있는 느린 쿼리들을 기록하는 것입니다. 최소 시간 임계점을 지정할 수도 있습니다. 6 | 추가적으로, 앱이 클라우드에 배포 된 경우 해당 쿼리가 실행되었는지 알려주는 이메일 알림을 설정하는 옵션이있을 수 있습니다. 7 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/active-record.md: -------------------------------------------------------------------------------- 1 | # Active Record 2 | 3 | [Krzysztof Grzybek](https://github.com/krzysztof-grzybek)에 의해 제공된 관련 주제 4 | 5 | - Active Record를 이용한 코드를 테스트하는 것은 얼마나 어렵습니까? 도메인 모델은 데이터 레이어로부터 묶여있나요? 아니면 독립적인가요? 6 | - Active Record를 구현하는 객체 간의 관계는 무엇인가요? 그리고 단일 책임 원칙은 무엇인가요? 7 | - 유출된 추상화로부터 데이터베이스를 여러 번(예: foreach 루프에서) 공격하는 것은 얼마나 쉬운가요? 8 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/anti-corruption-layer.md: -------------------------------------------------------------------------------- 1 | # 손상 방지 레이어 (Anti-corruption Layer)란? 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 동일한 모델에서 작동하지 않는 하위 시스템 (대부분 외부 또는 레거시 시스템과 함께) 간의 통신을 담당하는 시스템의 계층입니다. 6 | 손상 방지 레이어의 목적은 클라이언트에게 고유한 도메인 모델의 기능을 제공하는 고립된 계층을 생성하기 위함입니다. 7 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/billion-dollar-mistake.md: -------------------------------------------------------------------------------- 1 | # 억만금짜리 실수 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | null의 존재와 모든 유형에 대한 할당 가능성은 프로그램을 에러가 잘 발생하게 만듭니다. 모든 변수가 "null"이 될 수 있기 때문에 우리는 언제 호출할 지 알 수 없습니다. 예) 실제 객체 대신 null에 대한 메소드 6 | 7 | Null 객체 패턴 메일은 조용히 에러를 유발합니다. 이것은 종종 원본 객체가 변했을 때 이것을 업데이트 해야하기 때문에 보수하기 지루합니다. 일부 경우에 기본 동작을 실제로 적용하고 싶을 때 유용합니다. 8 | 9 | 옵션 타입들은 완전히 안전하기 때문에 휼륭합니다. 하지만 추가된 많은 코드들로 인해 약간의 오버헤드가 발생하게 됩니다. 10 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/data-abstraction.md: -------------------------------------------------------------------------------- 1 | # 데이터 추상화 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | Data Abstraction violation: 6 | ```javascript 7 | class Book { 8 | constructor(pages) { 9 | this.pages = pages; 10 | } 11 | } 12 | 13 | const myBook = new Book([{ text: 'content of the title page'}, { text: '...'}]); 14 | const titlePage = myBook.pages[0]; 15 | ``` 16 | 17 | Fixed: 18 | ```javascript 19 | class Book { 20 | constructor(title, pages) { 21 | this.title = title; 22 | this.pages = pages; 23 | } 24 | 25 | getTitlePage() { 26 | return this.pages[0]; 27 | } 28 | } 29 | 30 | const myBook = new Book([{ text: 'content of the title page'}, { text: '...'}]); 31 | const titlePage = myBook.getTitlePage(); 32 | ``` 33 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/data-mapper.md: -------------------------------------------------------------------------------- 1 | # Data Mapper 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 1. ActiveRecord는 SRP 원칙을 위반하며 테스트하기 어렵습니다. 만약 비즈니스 로직을 포함하지 않고 오직 데이터를 읽고 저장하는 간단한 응용프로그램이 있다면 Active Directory가 최선의 선택으로 보입니다. 다른 모든 경우에는 Data-Mappers를 사용합니다. 6 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/dependency-hell.md: -------------------------------------------------------------------------------- 1 | # 의존성 지옥 (Dependency Hell) 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 1. 가장 기본적인 접근 방식은 수동으로 종속성을 업데이트하여 다른 패키지 버전 관리를 만족하거나 유지 관리자에게 이를 수행하도록 요청하는 것입니다. 6 | 2. 내가 사용하는 시맨틱 버전 관리 라이브러리를 신뢰한다면보다 편안한 버전 관리를 시도합니다. 7 | 3. 이 문제에 대한 더 나은 해결책은 프로젝트를 monorepo로 유지하는 것입니다. 이 접근 방식은 다른 문제를 의미합니다. 8 | 3. 또 다른 흥미로운 솔루션은 넷플릭스 엔지니어링 팀에서 발표한 [system for easier dependencies management](https://www.youtube.com/watch?v=VNqmHJtItCs)입니다. 9 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/dont-repeat-yourself.md: -------------------------------------------------------------------------------- 1 | # DRY (Don't Repeat Yourself) 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | DRY 원칙을 위반하는 코드 6 | ```javascript 7 | class Employee { 8 | calculateSalaryNet() { 9 | return this.hoursWorked * this.hourlyWage; 10 | } 11 | 12 | calculateSalaryGross() { 13 | return this.hoursWorked * this.hourlyWage + TAX; 14 | } 15 | } 16 | ``` 17 | 18 | 수정된 코드 19 | ```javascript 20 | class Employee { 21 | calculateSalaryNet() { 22 | return this.hoursWorked * this.hourlyWage; 23 | } 24 | 25 | calculateSalaryGross() { 26 | return this.calculateSalaryNet() + TAX; 27 | } 28 | } 29 | ``` 30 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/globals-are-evil.md: -------------------------------------------------------------------------------- 1 | # 전역객체는 나쁘다 2 | 3 | [Krzysztof Grzybek](https://github.com/krzysztof-grzybek)에 의한 힌트입니다. 4 | 5 | 1. 전역 객체나 스태틱 객체는 종속성/결합을 유발합니다. 그러므로 전역 객체나 스태틱 객체는 캡슐화의 개념을 깨뜨립니다. 6 | 2. 이에 대해 추론하기 어렵습니다. - 이러한 객체들의 행동을 이해하는 논리적 범위는 전체 프로그램으로 확장됩니다. 7 | 3. 이들은 mock/stub하기 어렵습니다. 8 | 4. 전역 객체는 메인 범위를 오염시킵니다. 9 | 10 | Bad: 11 | ```javascript 12 | class Player { 13 | walk() { 14 | this.x = nextDestination.x; 15 | this.y = nextDestination.y; 16 | } 17 | } 18 | ``` 19 | 20 | Good: 21 | ```javascript 22 | class Player { 23 | walk(destination) { 24 | this.x = destination.x; 25 | this.y = destination.y; 26 | } 27 | } 28 | ``` 29 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/goto-is-evil.md: -------------------------------------------------------------------------------- 1 | # Goto는 나쁘다 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 나는 어느 쪽이든 그렇게 나쁘다 생각하지 않습니다. 구조적 프로그래밍이 옳은 일이기 때문에 논쟁에서 이겼다고 생각합니다. 구조적 프로그래밍 방식으로 작성된 프로그램에 대해 추론하는 것이 더 쉽습니다.
6 | 반면, 이런 종류의 프로그램을 작성하더라도 우리는 종종 `goto`와 같은 스타일을 사용하고 이는 아무런 해를 끼치지 않습니다.
7 | 제 생각에는 `goto`문에도 똑같이 적용됩니다. 함수의 범위의 `goto`문은 여기저기서 프로그램을 더 간단하고 이해하기 쉽게 만들 수 있습니다.
8 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/inheritance-vs-composition.md: -------------------------------------------------------------------------------- 1 | # 상속 vs 컴포지션 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | 경우에 따라 다릅니다. 상속의 문제점은 캡슐화를 깨고 상위 클래스와 하위 클래스 간에 긴밀한 결합을 만든다는 것입니다.
6 | 객체와 우리의 관계가 `is a`라면 우리는 하나의 큰 클래스로 끝날 수 있습니다. 반면, 컴포지션의 경우 많은 작은 클래스들로 끝날 수 있습니다.
7 | 약간 다른 동작을 원한다면 상속을 선택하고 반대의 경우에는 컴포지션을 선택합니다. 8 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/inversion-of-control.md: -------------------------------------------------------------------------------- 1 | # 역제어 패턴 2 | 3 | ## Links 4 | 5 | * [InversionOfControl - Fowler](https://martinfowler.com/bliki/InversionOfControl.html) 6 | * [Inversion of Control Containers and the Dependency Injection pattern - Fowler](https://martinfowler.com/articles/injection.html) 7 | * [Inversion of Control Containers and the Dependency Injection pattern - Fowler](https://martinfowler.com/articles/injection.html) 8 | * [DIP in the Wild - Brett L. Schuchert](https://martinfowler.com/articles/dipInTheWild.html) 9 | 10 | ## 관련 주제 11 | 12 | * 서로 혼동될 수 있는 주제 13 | - 제어 반전 (Inversion of control) 14 | - 의존 관계 역전 원칙 (from SOLID) 15 | - 의존성 주입 (Dependency Injection) 16 | 17 | 이들은 모두 관련되어있지만 실제로는 별개입니다. 18 | 19 | ### 할리우드 원칙과의 관계 20 | 일부 사람들에게 할리우드 원칙(또는 법칙)은 제어 반전의 동의어일 뿐입니다. 몇 몇 사람들은 약간 차이가 있다고 봅니다. [Confusion between Inversion of Control and Hollywood Principle](https://stackoverflow.com/questions/43786221/confusion-between-inversion-of-control-and-hollywood-principle)를 참조하세요. 21 | 22 | 이번 맥락에서 또 다른 관련 주제는 프레임워크가 할리우드 원칙을 따른다고 명시되어 있기 때문에 라이브러리와 프레임워크의 차이점입니다. ([What is the difference between a framework and a library?](https://stackoverflow.com/questions/148747/what-is-the-difference-between-a-framework-and-a-library)를 참조하세요) -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/law-of-demeter.md: -------------------------------------------------------------------------------- 1 | # 데메테르 법칙 2 | 3 | * [Law of Demeter - Wikipedia](https://en.wikipedia.org/wiki/Law_of_Demeter) 4 | * [Law of Demeter - WikiWikiWeb](https://wiki.c2.com/?LawOfDemeter) 5 | * [Introducing Demeter and its Laws](http://www.bradapp.net/docs/demeter-intro.html) 6 | 7 | ## 데메테르 법칙에 대한 기억법 8 | [Erik Dietrich](https://github.com/erikdietrich)에 의해 작성된 [Visualization Mnemonics for Software Principles](http://www.daedtech.com/visualization-mnemonics-for-software-principles) 포스트는 데메테르 법칙이 무엇인지 이해하는 (그리고 더 이상 까먹지 않는) 매우 효과적인 트릭을 제공합니다. 이탈리아 번역은 [여기](https://github.com/arialdomartini/mnemonics/blob/law-of-demeter/README-italian.md)있습니다. 9 | 10 | ## 코드 예제 11 | [Krzysztof Grzybek](https://github.com/krzysztof-grzybek)에 의해 제공된 데메테르 법칙을 위반하는 코드의 예입니다. 12 | 13 | ```javascript 14 | class Plane { 15 | constructor(crew) { 16 | this.crew = crew; 17 | } 18 | 19 | getPilotsName() { 20 | this.crew.pilot.getName(); 21 | } 22 | } 23 | 24 | class Crew { 25 | constructor(pilot) { 26 | this.pilot = pilot; 27 | } 28 | } 29 | 30 | class Pilot { 31 | getName() { 32 | // ... 33 | } 34 | } 35 | ``` 36 | 37 | 객체 사이의 단단한 결합을 만들기 때문에 이것은 좋지 않습니다. 그들은 다른 객체의 내부 구조에 의존합니다. 38 | 39 | Fixed code: 40 | ```javascript 41 | class Plane { 42 | getPilotsName() { 43 | this.crew.getPilotsName(); 44 | } 45 | } 46 | 47 | class Crew { 48 | constructor(pilot) { 49 | this.pilot = pilot; 50 | } 51 | 52 | getPilotsName() { 53 | return this.pilot.getName(); 54 | } 55 | } 56 | -------------------------------------------------------------------------------- /OriginalDocuments/design-patterns/violate-dry.md: -------------------------------------------------------------------------------- 1 | # DRY 위반 2 | 3 | ## [Krzysztof Grzybek](https://github.com/krzysztof-grzybek) 4 | 5 | DRY 원칙을 위반한 코드 6 | 7 | ```javascript 8 | class Employee { 9 | calculateSalaryNet() { 10 | return this.hoursWorked * this.hourlyWage; 11 | } 12 | 13 | calculateSalaryGross() { 14 | return this.hoursWorked * this.hourlyWage + TAX; 15 | ``` 16 | 17 | 수정된 코드 18 | 19 | ```javascript 20 | class Employee { 21 | calculateSalaryNet() { 22 | return this.hoursWorked * this.hourlyWage; 23 | } 24 | 25 | calculateSalaryGross() { 26 | return this.calculateSalaryNet() + TAX; 27 | } 28 | } 29 | ``` 30 | -------------------------------------------------------------------------------- /OriginalDocuments/snippets/kill-the-if-chain.md: -------------------------------------------------------------------------------- 1 | # if-chain 제거 2 | 3 | 중첩된 구조는 [Vahid Najafi](https://github.com/vahidvdn)가 제안한대로 펼쳐질 수 있습니다. 4 | 5 | ```js 6 | function() 7 | { 8 | HRESULT error = S_OK; 9 | 10 | if( !SUCCEEDED(Operation1() ) return OPERATION1FAILED; 11 | if( !SUCCEEDED(Operation2() ) return OPERATION2FAILED; 12 | if( !SUCCEEDED(Operation3() ) return OPERATION3FAILED; 13 | if( !SUCCEEDED(Operation3() ) return OPERATION3FAILED; 14 | if( !SUCCEEDED(Operation4() ) return OPERATION4FAILED; 15 | 16 | } 17 | ``` 18 | 19 | 사실, 리팩토링할 공간이 더 많다고 생각하지만, 모두 프로젝트의 경제성에 달려있습니다. 20 | 21 | 리팩토링 목표를 설정하기 위해서는 코드의 냄새와 디자인 결함을 논의하는 것이 좋습니다. 22 | 23 | ## 냄새 24 | 다음과 같은 문제가 있습니다. 25 | 26 | * 이 코드는 [SOLID 원칙][2]의 일부분을 위반합니다. 코드의 변경 없이는 확장을 할 수 없기 때문에 [Open Closed Principle][3]에 위배됩니다. 예를 들어 새로운 연산을 추가하려면 새로운 `if`/`else` 구문을 추가해야합니다. 27 | * 이것은 또한 [Single Responsibility Principle][4]도 위반합니다. 너무 많은 일을 합니다. 오류 검사를 수행하고 4개의 작업을 모두 실행하고, 그것들의 구현도 포함하고 결과를 확인하고 올바른 순서로 실행을 연결해야합니다. 28 | * 이것은 [Dependency Inversion Principle][5]를 위반합니다. 높은 수준과 낮은 수준의 구성 요소간에 종속성이 있기 때문입니다. 29 | * 또한 끔찍한 [Cyclomatic complexity][6]를 가집니다. 30 | * 높은 결합과 낮은 응집력을 가지며 [권장 사항][7]과 정반대입니다. 31 | * 이것은 많은 코드 중복을 포함합니다; 함수 `Succeeded()`는 각 구문에 반복됩니다; `if`/`else`의 구조가 겹쳐있습니다; `error`의 할당이 중복되었습니다. 32 | * 순수한 기능적 특성을 가질 수 있지만 대신 상태 변이에 의존하므로 추론이 쉽지 않습니다. 33 | * 혼란을 일으키는 비어있는 `if` 문이 있습니다. 34 | 35 | ## 리팩토링 36 | 무엇을 할 수 있을지 살펴봅시다.
37 | 여기서는 C#으로 구현했지만 어떤 언어로든 유사한 단계를 수행할 수 있습니다.
38 | 명명 규칙을 준수하는 것이 리팩토링의 일부라고 믿기 때문에 일부 요소의 이름을 변경했습니다. 39 | 40 | ```csharp 41 | internal class TestClass 42 | { 43 | HResult SomeFunction() 44 | { 45 | var error = HResult.Ok; 46 | 47 | if(Succeeded(Operation1())) 48 | v { 49 | if(Succeeded(Operation2())) 50 | { 51 | if(Succeeded(Operation3())) 52 | { 53 | if(Succeeded(Operation4())) 54 | { 55 | } 56 | else 57 | { 58 | error = HResult.Operation4Failed; 59 | } 60 | } 61 | else 62 | { 63 | error = HResult.Operation3Failed; 64 | } 65 | } 66 | else 67 | { 68 | error = HResult.Operation2Failed; 69 | } 70 | } 71 | else 72 | { 73 | error = HResult.Operation1Failed; 74 | } 75 | 76 | return error; 77 | } 78 | 79 | private string Operation1() 80 | { 81 | // some operations 82 | return "operation1 result"; 83 | } 84 | private string Operation2() 85 | { 86 | // some operations 87 | return "operation2 result"; 88 | } 89 | private string Operation3() 90 | { 91 | // some operations 92 | return "operation3 result"; 93 | } 94 | private string Operation4() 95 | { 96 | // some operations 97 | return "operation4 result"; 98 | } 99 | 100 | private bool Succeeded(string operationResult) => 101 | operationResult == "some condition"; 102 | } 103 | 104 | internal enum HResult 105 | { 106 | Ok, 107 | Operation1Failed, 108 | Operation2Failed, 109 | Operation3Failed, 110 | Operation4Failed, 111 | } 112 | } 113 | ``` 114 | 115 | 단순성을 위해 각 작업이 문자열을 반환하고 성공 또는 실패는 문자열에 대한 동등성 검사를 기반으로한다고 가정했습니다.( 물론 그럴 수도 있습니다) 다음 단계에서 코드가 결과 유효성 검사 논리와 독립적이면 좋을 것입니다. 116 | 117 | ### 1 단계 118 | 일부 테스트 장치를 사용해서 리팩토링을 시작하는 것이 좋습니다. 119 | 120 | ```csharp 121 | public class TestCase 122 | { 123 | [Theory] 124 | [InlineData("operation1 result", HResult.Operation1Failed)] 125 | [InlineData("operation2 result", HResult.Operation2Failed)] 126 | [InlineData("operation3 result", HResult.Operation3Failed)] 127 | [InlineData("operation4 result", HResult.Operation4Failed)] 128 | [InlineData("never", HResult.Ok)] 129 | void acceptance_test(string failWhen, HResult expectedResult) 130 | { 131 | var sut = new SomeClass {FailWhen = failWhen}; 132 | 133 | var result = sut.SomeFunction(); 134 | 135 | result.Should().Be(expectedResult); 136 | } 137 | } 138 | ``` 139 | 140 | 우리의 경우는 사소한 문제이지만 면접 질문이어야하는 퀴즈이므로 무시하지 않을 것입니다. 141 | 142 | 143 | ### 2 단계 144 | 첫 번째 리팩토링은 변경 가능한 상태를 제거하는 것입니다. 각 if 분기는 변수 'error'를 변경하는 대신 값을 반환 할 수 있습니다. 또한 'error' 라는 이름은 성공 사례를 포함하므로 오해의 소지가 있습니다. 그냥 제거합시다. 145 | 146 | ```csharp 147 | HResult SomeFunction() 148 | { 149 | if(Succeeded(Operation1())) 150 | { 151 | if(Succeeded(Operation2())) 152 | { 153 | if(Succeeded(Operation3())) 154 | { 155 | if(Succeeded(Operation4())) 156 | return HResult.Ok; 157 | else 158 | return HResult.Operation4Failed; 159 | } 160 | else 161 | return HResult.Operation3Failed; 162 | } 163 | else 164 | return HResult.Operation2Failed; 165 | } 166 | else 167 | return HResult.Operation1Failed; 168 | } 169 | ``` 170 | 171 | 비어있는 `if` 문을 제거하여 코드를 추론하기가 약간 더 쉬워졌습니다. 172 | 173 | ### 3 단계 174 | 이제 각 `if` 문을 뒤집습니다. (Sergio가 제안한 단계) 175 | 176 | ```csharp 177 | internal HResult SomeFunction() 178 | { 179 | if (!Succeeded(Operation1())) 180 | return HResult.Operation1Failed; 181 | 182 | if (!Succeeded(Operation2())) 183 | return HResult.Operation2Failed; 184 | 185 | if (!Succeeded(Operation3())) 186 | return HResult.Operation3Failed; 187 | 188 | if (!Succeeded(Operation4())) 189 | return HResult.Operation4Failed; 190 | 191 | return HResult.Ok; 192 | } 193 | ``` 194 | 195 | 코드가 일련의 실행을 수행함을 명백하게 합니다. 작업이 성공하면 다음 작업이 호출됩니다. 그렇지 않다면 체인은 중단되고 오류가 발생합니다. GOF [Chain of Responsibility Pattern][8]가 떠오릅니다. 196 | 197 | ### 4 단계 198 | 각 작업을 별도의 클래스로 이동하고 함수가 일련의 작업을 수신하여 한 번에 실행할 수 있습니다. 각 클래스는 특정 작업 로직을 다룹니다 (the Single Responsibility Principle 준수). 199 | 200 | ```csharp 201 | internal HResult SomeFunction() 202 | { 203 | var operations = new List 204 | { 205 | new Operation1(), 206 | new Operation2(), 207 | new Operation3(), 208 | new Operation4() 209 | }; 210 | 211 | foreach (var operation in operations) 212 | { 213 | if (!_check.Succeeded(operation.DoJob())) 214 | return operation.ErrorCode; 215 | } 216 | 217 | return HResult.Ok; 218 | } 219 | ``` 220 | 221 | 우리는 'if'를 모두 제거했습니다. 222 | 223 | Notice how: 224 | 225 | * 인터페이스 `IOperation`이 도입되었습니다. 이는 Dependency Inversion 원칙을 준수하여 작업에서 함수를 분리하기위한 예비 조치입니다. 226 | * 오퍼레이션 목록은 [Dependency Injection] [9]을 사용하여 클래스에 쉽게 삽입 할 수 있습니다. 227 | * 결과 검증 로직은 별도의 클래스 `Check`로 이동하여 메인 클래스에 삽입되었습니다 (Dependency Inversion and Single Responsibility 충족). 228 | 229 | ```csharp 230 | internal class SimpleStringCheck : IResultCheck 231 | { 232 | private readonly string _failWhen; 233 | 234 | public Check(string failWhen) 235 | { 236 | _failWhen = failWhen; 237 | } 238 | 239 | internal bool Succeeded(string operationResult) => 240 | operationResult != _failWhen; 241 | } 242 | 243 | ``` 244 | 245 | 우리는 메인 클래스를 수정하지 않고 체크 로직을 전환 할 수있는 능력을 얻었습니다 (Open-Closed Principle). 246 | 247 | 각 작업은 다음과 같은 별도의 클래스로 이동되었습니다. 248 | 249 | ```csharp 250 | internal class Operation1 : IOperation { 251 | public string DoJob() 252 | { 253 | return "operation1 result"; 254 | } 255 | 256 | public HResult ErrorCode => HResult.Operation1Failed; 257 | } 258 | ``` 259 | 260 | 각 작업은 자체 오류 코드를 알고 있습니다. 기능 자체는 그것으로부터 독립되었습니다. 261 | 262 | ### 5 단계 263 | 코드를 리팩토링해야 할 것이 더 있습니다. 264 | 265 | ```csharp 266 | foreach (var operation in operations) 267 | { 268 | if (!_check.Succeeded(operation.DoJob())) 269 | return operation.ErrorCode; 270 | } 271 | 272 | return HResult.Ok; 273 | } 274 | ``` 275 | 276 | * 첫째, `return HResult.Ok;`케이스가 특수한 경우로 처리되는 이유가 명확하지 않습니다. 체인에는 실패하지 않고 해당 값을 반환하는 종료 작업이 포함될 수 있습니다. 이렇게하면 마지막 `if`를 제거 할 수 있습니다. 277 | 278 | * 둘째, 우리의 기능에는 여전히 두 가지 책임이 있습니다. 체인을 방문하고 결과를 확인하는 것입니다. 279 | 280 | 작업을 실제 체인으로 캡슐화하여 함수를 다음과 같이 줄일 수 있습니다. 281 | 282 | ``` 283 | return operations.ChainTogether(_check).Execute(); 284 | ``` 285 | 286 | 2 가지 옵션이 있습니다. 287 | 288 | * 각 작업은 다음 작업을 알고 있으므로 operation1부터 시작하여 단일 호출로 전체 체인을 실행할 수 있습니다. 289 | * 운영은 체인의 일부임을 인식하지 못합니다. 별도의 캡슐화 구조는 작업에 순서대로 실행되는 기능을 추가합니다. 290 | 291 | 나는 후자에 대해 계속하고 있지만 그것은 절대적으로 논쟁의 여지가 있습니다. 체인에서 링을 모델링하는 클래스를 소개하고 코드를 클래스에서 멀리 이동합니다. 292 | 293 | ```csharp 294 | internal class OperationRing : IRing 295 | { 296 | private readonly Check _check; 297 | private readonly IOperation _operation; 298 | internal IRing Next { private get; set; } 299 | 300 | public OperationRing(Check check, IOperation operation) 301 | { 302 | _check = check; 303 | _operation = operation; 304 | } 305 | 306 | public HResult Execute() 307 | { 308 | var operationResult = _operation.DoJob(); 309 | 310 | if (_check.Succeeded(operationResult)) 311 | return Next.Execute(); 312 | 313 | return _operation.ErrorCode; 314 | } 315 | } 316 | ``` 317 | 318 | 이 클래스는 작업을 실행하고 성공한 경우 다음 링으로의 실행을 처리하거나 올바른 오류 코드를 반환하는 체인을 중단합니다. 319 | 320 | 체인은 실패하지 않는 요소에 의해 종료됩니다. 321 | 322 | ```csharp 323 | internal class AlwaysSucceeds : IRing 324 | { 325 | public HResult Execute() => HResult.Ok; 326 | } 327 | ``` 328 | 329 | 원본 클래스는 다음과 같이 줄었습니다. 330 | 331 | ```csharp 332 | internal class SomeClass 333 | { 334 | private readonly Check _check; 335 | private readonly List _operations; 336 | 337 | public SomeClass(Check check, List operations) 338 | { 339 | _check = check; 340 | _operations = operations; 341 | } 342 | 343 | internal HResult SomeFunction() 344 | { 345 | return _operations.ChainTogether(_check).Execute(); 346 | } 347 | } 348 | ``` 349 | 350 | 이 경우`ChainTogether ()`는`List `의 확장으로 구현 된 함수입니다. 체인 로직이 우리 클래스의 책임이라고 생각하지 않기 때문입니다. 351 | 352 | 353 | ## 이것은 *정답*이 아닙니다 354 | 355 | 책임이 가장 적절한 클래스로 분리되었다는 것은 절대적으로 논쟁의 여지가 있습니다. 예로, 356 | 357 | * 체인 작업이 우리 기능의 작업입니까? 아니면 체인 구조를 직접 받아야합니까? 358 | * 왜 열거형을 사용합니까? Robert Martin이 "Refactoring : Improving the Design of Existing Code"에서 썼듯이 : 열거 형은 코드의 냄새이며 다형성 클래스로 리팩토링되어야합니다. 359 | * 너무 많지 않나요? 결과 디자인이 왜 이리 복잡합니까? 전체 애플리케이션의 복잡성에 이러한 수준의 모듈화가 필요합니까? 360 | 361 | 따라서 원래 함수를 리팩토링하는 다른 여러 방법이 있다고 확신합니다. 362 | 363 | 364 | [1]: https://stackoverflow.com/users/125816 365 | [2]: https://en.wikipedia.org/wiki/SOLID 366 | [3]: https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle 367 | [4]: https://en.wikipedia.org/wiki/Single_responsibility_principle 368 | [5]: https://en.wikipedia.org/wiki/Dependency_inversion_principle 369 | [6]: https://en.wikipedia.org/wiki/Cyclomatic_complexity 370 | [7]: https://en.wikipedia.org/wiki/Cohesion_(computer_science) 371 | [8]: https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern 372 | [9]: https://en.wikipedia.org/wiki/Dependency_injection 373 | [10]: https://refactoring.guru/smells/primitive-obsession 374 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Back-End 개발자 인터뷰 질문 2 | ====================================== 3 | ## 📌공지 4 | [![Nesoy](https://img.shields.io/badge/Author-Nesoy-blue.svg)](http://nesoy.github.io/about) [![HitCount](http://hits.dwyl.io/nesoy/Back-end-Developer-Interview-Questions.svg)](http://hits.dwyl.io/nesoy/Back-end-Developer-Interview-Questions) 5 | 6 | > Star나 Watching을 해주시면 감사하겠습니다.🙏 7 | 8 | ## 🔍목차 9 | - [Backend-Interview 번역](/OriginalDocuments/README.md) 10 | - Language 11 | - [Java](/Category/Language/Java.md) 12 | - [Web](/Category/Web/README.md) 13 | - [Web framework](/Category/Web/WebFramework.md) 14 | - [BuildTool](/Category/BuildTool/README.md) 15 | - [DesignPattern](/Category/DesignPattern/README.md) 16 | - [OS](/Category/OS/README.md) 17 | - [Security](/Category/Security/README.md) 18 | - [Database](/Category/Database/README.md) 19 | - [Algorithm & Data structure](/Category/Algorithm/README.md) 20 | - [Testing](/Category/Testing/README.md) 21 | - [Architecture](/Category/Architecture/README.md) 22 | 23 | 24 | ## 💼인터뷰 관련 정보 25 | #### Back-End 인터뷰 26 | - [영어](https://github.com/arialdomartini/Back-End-Developer-Interview-Questions) by [@arialdomartini](https://github.com/arialdomartini). 27 | - [중국어](https://github.com/monklof/Back-End-Developer-Interview-Questions) by [@monklof](https://github.com/monklof). 28 | 29 | #### Front-end 인터뷰 30 | - [영어](https://github.com/darcyclarke/Front-end-Developer-Interview-Questions) by [@darcyclarke](https://github.com/darcyclarke) 31 | - [한국어](https://github.com/h5bp/Front-end-Developer-Interview-Questions/tree/master/Translations/Korean)🇰🇷 32 | 33 | #### 한국🇰🇷 취업 정보. 34 | - [Interview_Question_for_Beginner](https://github.com/JaeYeopHan/Interview_Question_for_Beginner) by [@JBee](https://github.com/JaeYeopHan) 35 | - [junior-recruit-scheduler](https://github.com/jojoldu/junior-recruit-scheduler) by [@jojoldu](https://github.com/jojoldu) 36 | 37 | #### Developer 로드 맵 38 | - [developer-roadmap](https://github.com/kamranahmedse/developer-roadmap) by [@kamranahmedse](https://github.com/kamranahmedse/) 39 | 40 | ## 📄좋은 글 41 | - [백엔드 개발자를 꿈꾸는 학생개발자에게](https://d2.naver.com/news/3435170) --------------------------------------------------------------------------------