Update README.md

README.md

@@ -79,8 +79,10 @@ Based on RFC 1459 : https://datatracker.ietf.org/doc/html/rfc1459
 두 요소는 상충관계에 있으므로,  
 설계와 구현에 있어 사이즈, 수정빈도, 사용빈도, 이를 사용/수정하는 프로그래머의 실력 등을 고려하여 절충점을 찾는 것이 중요하다.  
 
+아래에서 프로젝트 설계에서 일어난 각 결정 사항들을 설명한다.  
 
-먼저 성능과 유지보수 둘 다 얻거나 한쪽을 약간만 희생할 수 있는 방법이 있다.  
+
+먼저 프로젝트 전반에 걸친 성능과 유지보수 둘 다 얻을 수 있다고 생각된 결정이다.  
 - [Shared Pointer](#shared-pointer)  
     채팅서버의 특성 상 상호관계가 많아 메모리 해제 시점이 복잡하므로  
     모든 메시지, 클라이언트, 채널 등의 리소스는 자체 구현한 스마트 포인터로 관리한다.  
@@ -92,12 +94,12 @@ Based on RFC 1459 : https://datatracker.ietf.org/doc/html/rfc1459
     메모리 풀로 메시지의 지역성을 높이고 내부 청크가 페이지 단위로 할당되도록 구현하여 page lock을 최소화함.  
 
 
-다음은 성능을 우선시해야 하는 경우이다.  
+다음은 성능을 우선시한 경우들이다.  
 
 예를 들어, 실제 kqueue와 recv/send를 처리하는 코어 네트워크 코드의 경우  
 수정빈도가 낮고, 사용빈도가 높으며, 메인 프로그래머를 제외한 다른 프로그래머가 수정할 가능성이 낮다.  
 
-이에 따라 해당 코드는 성능을 최우선으로 하여 구현되었으며,  
+이에 따라 이러한 부분들은 성능을 최우선으로 하여 구현되었으며,  
 오히려 이 부분의 복잡도를 올림으로써 다른 부분의 복잡도를 낮추는 등의 기술적인 선택이 이루어졌다.  
 - <https://ria9993.github.io/IRC_server/irc_server_kqueue_udata.html>  
     kevent의 udata필드 값으로 SharedPtr의 ControlBlock을 담는다는 복잡한 구현을 결정한 이유
@@ -111,11 +113,11 @@ Based on RFC 1459 : https://datatracker.ietf.org/doc/html/rfc1459
     이 방법은 플로우의 분기를 만들지 않고도 예외를 방지할 수 있어 선택함.  
 
 
-다음은 유지보수를 우선시해야 하는 경우이다.  
+다음은 유지보수를 우선시한 경우이다.  
 
 클라이언트의 메시지 처리나 채널 관리 등은 수정빈도가 높고, 사용빈도가 중간이며, 아무 프로그래머가 수정할 가능성이 높다.  
 
-이에 따라 해당 코드는 유지보수를 우선하는 것으로 방향을 잡았으며,    
+이에 따라 해당 코드는 유지보수를 우선하는 것으로 방향을 잡았으며,  
 다음과 같은 결정들이 이루어졌다.  
 - [Preprocessor Tuple](#preprocessor-tuple)  
     명령어나 응답 코드를 한 번에 리스트로 관리하고, 수정/추가할 때의 실수를 방지한다.