vault backup: 2024-08-14 12:23:50

Seongil-Shin · Aug 14, 2024 · a81d456 · a81d456
1 parent 8bb8293
commit a81d456
Show file tree

Hide file tree

Showing 3 changed files with 27 additions and 5 deletions.
diff --git a/_posts/blog/posts/실용주의프로그래머/2024-08-02-실용주의프로그래머 5장 구부러지거나 부러지거나.md b/_posts/blog/posts/실용주의프로그래머/2024-08-02-실용주의프로그래머 5장 구부러지거나 부러지거나.md
@@ -310,7 +310,7 @@ class AccountForAdmin extends Account  with AccountValidations, AccountAdminVali
 
 **여담**
 
-실무를 경험해본 결과 서비스형 설정이 확실히 좋았다. 이러한 값들은 빌드가 필요없이 바로 참조가 되어 이슈가 발생했을 경우 곧바로 대응을 할 수가 있기 때문이다. (가이드를 제대로 남긴다면 개발자한테까지 연락이 안오고 기획자가 알아서 수정도 할 수 있다. 개발자는 그동안 꿀잠을 잘 수 있다.)
+실무를 경험해본 결과 서비스형 설정이 확실히 좋았다. 이러한 값들은 빌드가 필요없이 바로 참조가 되어 이슈가 발생했을 경우 곧바로 대응을 할 수가 있기 때문이다. 
 
 물론 스프링에서 properties 파일과 같은 정적 설정도 장점이 있다. 설정 정보의 성격에 따라 적절히 분리해서 관리하면 될 거 같다. 
 - 정적 설정 : 자주 변경되지 않지만 애플리케이션에 거쳐 많이 사용되거나 외부로 뺄 필요가 있어보이는 값들. 급하게 변경하지 않아도 이슈가 없는 값들

diff --git a/_posts/blog/posts/실용주의프로그래머/2024-08-07-실용주의프로그래머 8장 프로젝트 전에.md b/_posts/blog/posts/실용주의프로그래머/2024-08-07-실용주의프로그래머 8장 프로젝트 전에.md
@@ -44,7 +44,7 @@ tags:
 
 ### 지나치게 자세한 명세
 
-요구사항을 만들 때는 추상적으로 작성하는 적이 좋다. 모호하게 적으라는 것이 아니라, 의미론적 불변식을 요구사항으로 잘 갈무리하고, 구체적인 작업방식은 정책으로 문서화해야한다.
+요구사항을 만들 때는 추상적으로 작성하는 것이 좋다. 모호하게 적으라는 것이 아니라, 의미론적 불변식을 요구사항으로 잘 갈무리하고, 구체적인 작업방식은 정책으로 문서화해야한다.
 
 요구사항은 아키텍처나 설계가 아니며 필요를 표현하는 것이다
 
@@ -122,7 +122,7 @@ tags:
 
 애자일은 일하는 방식이지 우리 자신이 아니다. 애자일 선언에서 언급된 애자일의 가치는 아래와 같다.
 
-> 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 싰다. 이 과정에서 우리는 다음과 같은 가치들을 찾아냈다.
+> 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 과정에서 우리는 다음과 같은 가치들을 찾아냈다.
 > 
 > - 공정과 도구보다 개인과 상호작용
 > - 포괄적인 문서보다 작동하는 소프트웨어

diff --git a/_posts/blog/posts/실용주의프로그래머/2024-08-13-실용주의프로그래머 - 전체 후기.md b/_posts/blog/posts/실용주의프로그래머/2024-08-13-실용주의프로그래머 - 전체 후기.md
@@ -21,12 +21,34 @@ tags:
 - 어떤 변화를 만들고 싶으면 작은 성공을 먼저 보여줘라.  (Topic 4)
 - 당장의 일에만 정신을 쏟지말고 큰 그림을 기억하라
 - 피드백 주기를 만들어라
-	- 회귀 테스트, 의뢰인 피드백, 짧은 배포주기
+	- 회귀 테스트,  의뢰인 피드백, 짧은 배포주기
+	- 모호한 요구사항에 대해서도 여러번 질문을 하여 피드백받아 구체화하라
+	- 너무 먼 미래를 내다보지 말고 피드백을 받아라
 - 지식 포트폴리오를 만들어라 : 주기적인 투자, 리스크 관리, 다각화, 리밸런싱
 - 문서는 애초에 포함하고 나중에 집어넣으려고 하지 말라 (ex : swagger가 좋은 예시)
 - 변경하기 쉬운 설계를 하라
 	- DRY : 코드를 포함한 문서, 데이터, 주석, 개발자 간의 주석을 줄여라 (Topic 9)
-	- 직교성 : 코드 사이의 결합도를 줄여라. 전역 데이터도 결합이다.
+	- 직교성 : 코드 사이의 결합도를 줄여라. 전역 데이터도 결합이다. 데메테르 법칙(`.`은 하나만)
+		-  상속 대신 인터페이스, 위임, 믹스인을 사용하는 것이 결합도가 낫다.
+	- 프로그램을 데이터 변환 모델이라고 생각하라
 - PERT 기법 : 최상, 일반, 최악의 시나리오별로 예상되는 추정치를 전달하는 방법
 - 엔지니어링 일지를 적어라 : 디버깅 기록이나 엉뚱한 생각이나 어떤 것이든 기억할만한 무엇이든 적어도 됨
+- 있을 수 없는 일이 발생했다면 최대한 빨리 멈춰라. 빨리 멈추는게 계속 작동하는 것보다 좋다
+	- 있을 수 없는 일을 검사하기 위해 단정문을 사용할 수 있다. 단정문에 걸리면 최대한 빨리 멈춰라
+- 무언가 불안한 느낌이 들면, 왜 그런 느낌이 드는지 이유를 천천히 생각해보고, 테스트해봐라
+- 잘못된 가정으로 코딩을 하지마라. 가정을 세웠다면 그것을 증명하라
+- 속성 기반 테스트를 통해 가정과 예상치못한 상태를 검증할 수 있다.
+- 리팩터링은 일찍 자주 습관적으로 하라.
+- 테스트는 코드의 첫번째 사용자다. 테스트를 생각하는 것만으로도 큰 도움이 된다.
+- 이름을 지을땐 코드의 역할에 따라, 일관적으로 지어라. 
+- 어려운 문제를 맞이했을때, 불필요한 제약조건을 세우진 않았는지 생각하라
+- 어려운 문제를 맞이했을때, 잠시 숨을 돌리거나 고무오리 기법을 사용하는 것도 좋다
+- 일상적으로 반복되는 작업을 자동화하라
+- 특정한 방법론에 얽매이지말고, 팀에 잘 맞는 방법론의 좋은 점만 취하여라
+- 사용자가 기대하는 것이 무엇인지 계속 생각하라. 그것이 진짜 목표이다.
 
+
+
+- 하나의 메서드, 컴포넌트를 작성한 이후에는 어떻게 테스트할지를 생각해보자
+- 중요한 메서드, 컴포넌트에는 테스트를 추가하자 (속성기반 테스트, 단위테스트 등)
+- 반복되는 작업이 보이면 자동화하자