style: Remove br tags

Author: eottabom

components/Panel.tsx

@@ -129,7 +129,7 @@ function extractLines(children: ReactNode): ReactNode[][] {
       });
     } else if (isValidElement(node)) {
       const { type, props } = node as any;
-      if (type === 'a' || type === 'code' || type === 'b') {
+      if (type === 'a' || type === 'code' || type === 'b' || type === 'newline') {
         line.push(node);
       } else {
         walk(props.children);

posts/clean-code/comments.mdx

@@ -812,16 +812,16 @@ public void onMouseMove(Widget sender, int x, int y) { .. }
 이러한 규칙을 따르면 시간과 좌절감을 줄일 수 있다.
 
 :::success
-<b> 개인적인 생각 & 정리</b> <br />
-의무적인 Javadoc 은 없어도 된다. <b> (Clean Code Bad Comments 6, 7, 18) </b> <br />
-API 중에서 특수한 경우 (parameter 에 대한 주석이 필요할 때) Javadoc 으로 작성하면 가독성이 좋다. <br />
-→ (반드시 best practices 를 따를 필요는 없으므로!!) <br />
-설명이나 정보를 알려주는 주석은 반드시 필요하다. <b> (Clean Code Good Comments 2, 3, 4) </b> <br />
-→ 혼란을 야기하는 내용은 안된다. <b> (Best Practices for writing code comments 규칙 4) </b> <br />
-→ 너무 많은 정보를 담지 않아야 한다. <b> (Clean Code Bad Comments 15) </b> <br />
-TODO 주석은 필요한 경우만 달자. <b> (Clean Code Good Comments 6) </b> <br />
-참고한 코드의 링크를 추가하는 것이 좋다. <b> (Best Practices for writing code comments 규칙 6, 7) </b> <br />
-버그로 인한 수정할 때 주석을 추가 하자. <b> (Best Practices for writing code comments 규칙 8) </b> <br />
+<b> 개인적인 생각 & 정리</b>
+의무적인 Javadoc 은 없어도 된다. <b> (Clean Code Bad Comments 6, 7, 18) </b>
+API 중에서 특수한 경우 (parameter 에 대한 주석이 필요할 때) Javadoc 으로 작성하면 가독성이 좋다.
+→ (반드시 best practices 를 따를 필요는 없으므로!!)
+설명이나 정보를 알려주는 주석은 반드시 필요하다. <b> (Clean Code Good Comments 2, 3, 4) </b>
+→ 혼란을 야기하는 내용은 안된다. <b> (Best Practices for writing code comments 규칙 4) </b>
+→ 너무 많은 정보를 담지 않아야 한다. <b> (Clean Code Bad Comments 15) </b>
+TODO 주석은 필요한 경우만 달자. <b> (Clean Code Good Comments 6) </b>
+참고한 코드의 링크를 추가하는 것이 좋다. <b> (Best Practices for writing code comments 규칙 6, 7) </b>
+버그로 인한 수정할 때 주석을 추가 하자. <b> (Best Practices for writing code comments 규칙 8) </b>
 변수 명이나 메서드 명을 명확히 한다면 주석을 작성하는 일이 줄어 들 것 같다...!
 :::
 

posts/ddd/ddd-core-concept.mdx

@@ -162,10 +162,9 @@ DDD 의 적용 흐름 사이클은 애자일 방법론과 매우 밀접하게 
 ---
 
 :::success
-<b>정리</b><br />
-DDD 는 복잡한 도메인을 코드로 명확하게 표현하기 위한 사고방식이다. <br />
-도메인 모델과 코드 모델의 일관성 유지, 불변식 보장, 행위 중심 모델링이 핵심이며,
-패턴을 무조건 따르기보단 <b>상황에 맞는 유연한 적용</b>이 중요하다. <br />
+<b>정리</b>
+DDD 는 복잡한 도메인을 코드로 명확하게 표현하기 위한 사고방식이다.
+도메인 모델과 코드 모델의 일관성 유지, 불변식 보장, 행위 중심 모델링이 핵심이며, 패턴을 무조건 따르기보단 <b>상황에 맞는 유연한 적용</b>이 중요하다.
 → 오버엔지니어링을 경계 해야 한다.
 :::
 

posts/ddd/ddd-fact-misunderstanding.mdx

@@ -237,13 +237,15 @@ DDD 의 철학은 **소프트웨어가 도메인을 정확하게 반영해야 
 
 <br />
 
+---
+
 :::success
-<b>정리</b><br />
-DDD 의 핵심 철학은 비즈니스 도메인을 깊게 이해하고 소프트웨어에 정확히 반영하는 것이다. <br />
-DDD 는 모든 프로젝트에 적용해야만 하는 것은 아니고, 비즈니스 복잡성에 따라 적절히 활용하는 것이다. <br />
-핵심 도메인에 집중하고, 변화에 유연하게 대응할 수 있도록 설계하는 것이 철학이라고 볼 수 있다. <br />
-DDD 를 적용한다면 모든 문제를 해결할 수 있다는 것은 잘못됐다. 왜냐면 DDD 는 철학과 사상에 가깝기 때문이다. <br />
-도메인 전문가와 개발자가 끊임 없이 협력 유비쿼터스 언어로 소통하고 발전해나가는 것이 중요하다. <br />
+<b>정리</b>
+DDD 의 핵심 철학은 비즈니스 도메인을 깊게 이해하고 소프트웨어에 정확히 반영하는 것이다.
+DDD 는 모든 프로젝트에 적용해야만 하는 것은 아니고, 비즈니스 복잡성에 따라 적절히 활용하는 것이다.
+핵심 도메인에 집중하고, 변화에 유연하게 대응할 수 있도록 설계하는 것이 철학이라고 볼 수 있다.
+DDD 를 적용한다면 모든 문제를 해결할 수 있다는 것은 잘못됐다. 왜냐면 DDD 는 철학과 사상에 가깝기 때문이다.
+도메인 전문가와 개발자가 끊임 없이 협력 유비쿼터스 언어로 소통하고 발전해나가는 것이 중요하다.
 :::
 
 ---

posts/java/try-with-resources.mdx

@@ -180,10 +180,12 @@ Closeable : AutoCloseable 의 하위 인터페이스로 주로 I/O 클래스에
 
 <br />
 
+---
+
 :::success
-<b>정리</b><br />
-try-with-resources 를 이용하면 AutoCloseable 인터페이스를 구현한 자원들은 try() 구문에서 자동으로 close() 된다. <br />
-finally 블록 없이 간결한 코드를 작성할 수 있고, 리소스 누출 가능성을 줄일 수 있다. <br />
+<b>정리</b>
+try-with-resources 를 이용하면 AutoCloseable 인터페이스를 구현한 자원들은 try() 구문에서 자동으로 close() 된다.
+finally 블록 없이 간결한 코드를 작성할 수 있고, 리소스 누출 가능성을 줄일 수 있다.
 :::
 
 

posts/spring/jpa-determine-entity-is-new.mdx

@@ -172,11 +172,13 @@ Database 에는 해당 ID 가 존재하지 않지만, 신규 Entity 임에도 
 
 <br/><br/>
 
+---
+
 :::success
-<b>정리</b><br />
-Spring Data JPA 는 내부적으로 isNew() 를 통해서 신규 Entity 여부를 판단한다. <br />
-ID 는 존재하지만 실제 DB 에 없는 경우 SELECT + UPDATE 후 merge 를 하므로 정합성이 떨어질 수 있고, 비효율적이다. <br />
-ID 를 직접 설정했을 경우는 Persistable + isNew() 로 명시하는 것이 필요하다. <br />
+<b>정리</b>
+Spring Data JPA 는 내부적으로 isNew() 를 통해서 신규 Entity 여부를 판단한다.
+ID 는 존재하지만 실제 DB 에 없는 경우 SELECT + UPDATE 후 merge 를 하므로 정합성이 떨어질 수 있고, 비효율적이다.
+ID 를 직접 설정했을 경우는 Persistable + isNew() 로 명시하는 것이 필요하다.
 :::