Merge branch 'main' into 챕터7_2/변수미

챕터_4/상범.md

@@ -0,0 +1,9 @@
+## 안티 패턴
+
+안티 패턴은 겉으로만 해결책처럼 생긴 패턴
+
+안티 패턴을 이해하는 것은 디자인 패턴을 이해하는 것 만큼 중요함. 왜냐하면 익숙하지 않은 개발자가 프로젝트에 맞지않는 디자인 패턴을 도입하고 유지보수가 매우 어려워질 수 있기 때문
+
+그래서 안티 패턴을 반면교사로 활용하기 위해 문서화하여 기록하는 것도 좋음
+
+> 전 팀에서 tanstack query를 사용하고 있었고, useQuery의 반환값을 전역데이터로 set하여 사용하는 안티패턴을 사용하고 있었기에 안티패턴인 이유를 말씀드렸지만 무논리 우격다짐 + 고지식 이슈로 인해 설득 포기했던게 생각이 나네요

챕터_4/서준환.md

@@ -0,0 +1,9 @@
+# 4장 안티 패턴
+
+겉으로 보기에 해결책처럼 생긴 패턴으로 실제로는 *잘못된* 해결책인 것이다.
+
+안티 패턴은 결국 반면교사로 활용하기 위해 문서화하여 기록해야 하는 나쁜 디자인 패턴이다.
+
+> 어 이 패턴 여기에 사용하기엔 안 좋은 패턴인데 이 사람이 사용하네? <- 바로 1on1 ㄱㄱ
+
+> 지금 느끼기엔 모든 것이 다 경험인 것 같다. 

챕터_4/신승준.md

@@ -0,0 +1,9 @@
+# 안티 패턴
+
+안티 패턴은 잘못된 패턴이다.
+
+안티 패턴이라는 것을 인지할 수 있다면, 잘못된 패턴 도입을 피할 수 있다.
+
+가끔 신속한 구현을 위해 임시방편을 선택하곤 한다. 임시방편은 영구적으로 이어지는 경향이 있으며 이는 결국 기술 부채가 된다.
+
+> 저의 경우, React에서 컴포넌트를 잘 나누지 않았던 것이 안티 패턴이었던 것 같아요. '그냥 한 파일에서 다 파악 가능하도록 하자'라는 생각이었는데요, 나중에 다시 보니까 그 컴포넌트가 어디까지 동작하는지 파악하기 힘들더라구요. 요즘엔 적절히... 나누고 있습니다.

챕터_4/오혜성.md

@@ -0,0 +1,16 @@
+# 안티 패턴
+
+- 겉으로만 해결책처럼 생긴 패턴이 안티 패턴
+- 좋고 나쁨은 상황에 따라 결정되며, 소위 완벽한 설계도 잘못된 상황에서 사용된다면 안티 패턴이 될 수 있음
+
+> 경험이 부족해서인지, 코드리뷰 단계에서는 설득력이 있다고, 괜찮다고 생각되지만 막상 유지보수할 때면 지옥같은 경우가 종종 있었음
+>
+> 일반적인 '상황'을 예상할 수 있는 경험이나 도메인 지식이 있으면 괜찮을까 싶기도
+
+## 자바스크립트의 안티 패턴
+
+- document.write
+  - 처음 봄
+  - mdn에서도 사용하지 않는게 좋다고 하네요
+  - https://developer.mozilla.org/en-US/docs/Web/API/Document/write
+

챕터_4/우창완.md

@@ -0,0 +1,10 @@
+# 4장 안티패턴 
+
+안티패턴을 적절히 아는 것은 중요하다. 안티패턴을 아는 것만으로, 이게 왜 안티패턴인지 인지하는 것만으로 함정을 적절히 피해갈 수 있는 것 같다.
+
+또, 코드 리뷰를 하다 보면 뭔가 이상한 것 같은데.. 왜 이상한 것인지 설명을 하기 힘들 때가 있는데, 잘 알아두면 코드리뷰도 원활히 진행가능!
+
+
+
+
+