Backend/책 정리
-
내 코드가 그렇게 이상한가요?Backend/책 정리 2024. 6. 6. 20:07
시작에 앞서...예전에 블로그에 클린 코드나 이팩티브 자바를 읽고 정리하는 내용을 올렸었는데, 관련된 정리 내용은 다른 블로그에도 너무 많은것 같아서 앞으로는 책 정리 내용을 블로그에 올리지는 않을 예정입니다.사실 그전에도 책은 꾸준히 읽고 있었는데 블로그에 정리는 하지 않았고 대신 개인 노트 앱에 정리하고 github에 올리는 방식으로 변경하고 여기 블로그에는 책에 대한 리뷰만 작성하려고 합니다. 내용 정리에 대한 깃허브는 아래 링크를 통해 볼 수 있습니다. 기술 책 정리 github repository](https://github.com/jin-mook/TechBookSummaries\)) 이번 글은 최근에 다 읽었던 '내 코드가 그렇게 이상한가요' 라는 책에 대한 리뷰입니다. 챕터별 리뷰 지금까..
-
클린 코드를 마무리 하며...Backend/책 정리 2023. 5. 18. 02:54
클린 코드 책을 드디어 모두 읽었다. 물론 부록 내용은 조금 남긴 했지만 그래도 기본적인 내용은 다 읽었다는 점에서 결국 어떤 일을 마무리 지었다고 생각하기 때문에 다행이라는 느낌을 받고 있다 책 자체는 읽는데 엄청 어려운 느낌은 아니었다. 하지만 좀 더 빨리 읽어야 하지 않았을까 라는 생각은 많이 든다... 책을 읽으며 정말 많은 생각을 하게 되었는데 가장 중요하게 가져야 할 마음이 결국 좋은 코드란 끝없는 리팩터링 끝에 나온다는 것이다. 저자도 얘기하듯이 단 한번에 깨끗하고 구조가 잘 잡힌 코드를 작성하는 것은 불가능하다. 중간에 저자가 리팩터링 하는 과정에 대한 내용이 있는데 처음 코드는 굉장히 아쉬운 부분이 많지만 이를 꾸준한 리팩터링을 통해 좋은 코드로 발전시켜가는 것을 확인하며 많은 것을 느낀..
-
객체 참조를 해제하라Backend/책 정리 2023. 5. 17. 23:25
이번주부터 이펙티브 자바 스터디를 진행하며 정리한 내용을 적어보려 합니다. 클린코드 책의 경우는 매 챕터마다 정리를 진행했는데 이펙티브 자바는 그보다는 내가 맡은 아이템을 좀 더 집중해서 읽으며 괜찮은 내용이 있으면 정리하는 식으로 앞으로 글을 작성하도록 하겠습니다. 이번 글에서는 아이템 7번 다 쓴 객체 참조를 해제하라는 파트입니다. 지금까지 개발하면서 메모리까지 생각하며 개발을 한 경험이 없다보니 이번 아이템을 읽으며 좀 더 신중하게 개발을 해야겠다는 생각을 많이 했습니다. 즉, C, C++이 아닌 가비지 컬렉터를 갖춘 언어라 할지라도 메모리 관리에 신경쓰도록 하는 습관을 갖는것이 좋아보입니다. 아래 예제를 살펴보겠습니다. 아래 코드는 Stack 자료구조를 간단하게 구현한 클래스 입니다. 이 코드에는..
-
Clean Code 12 ~ 13 장Backend/책 정리 2023. 4. 4. 02:19
12장 - 창발성 가장 먼저 창발이라는 단어의 뜻부터 알아보자 위키백과에 나온 창발이라는 단어의 정의는 다음과 같습니다. 창발 (創發)또는 떠오름 현상은 하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상이다. 또한 불시에 솟아나는 특성을 창발성(영어: emergent property) 또는 이머전스(영어: emergence)라고도 부른다. 자기조직화 현상, 복잡계 과학과 관련이 깊다. 개인적으로 이해한 창발적 설계를 통해 깔금한 코드를 구현한다는 의미는 저자가 제시한 단순한 설계 규칙(하위 계층)을 통해 돌연히 출현하는 현상 즉, 소프트웨어 설계 품질을 높이는 방법에 대한 글이라는 주제로 12장을 이해했습니다. 컨트 벡이 제시한 단순한 서례 네 가..
-
Clean Code 9 ~ 11 장Backend/책 정리 2023. 3. 28. 03:05
9장 - 단위 테스트 TDD 법칙 세 가지 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 유지하기 지저분한 테스트 코드를 내놓으나 테스트를 안 하나 오십보 백보라는, 아니 오히려 더 못한다는 사실을 인지해야 한다. 문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는 데 있다. 테스트 코드는 실제 코드 못지 않게 중요하며, 실제 코드 못지 않게 깨끗하게 짜야 한다. - 테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라도, 설..
-
Clean Code 7~8 장Backend/책 정리 2023. 3. 21. 00:41
7장 - 오류 처리 오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다. 해당 챕터에서는 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지를 소개하고 있다. 1. 오류 코드보다 예외를 사용하라 오류가 발생하면 예외를 던지는 편이 낫다. 그러면 코드가 더 깔끔해진다. 2. Try-Catch-Finally 문부터 작성하라 try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다. 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. public List retrieveSe..
-
Clean Code 5~6 장Backend/책 정리 2023. 3. 10. 02:54
5장 - 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 작성해야 한다. 형식을 맞추는 목적 코드 형식은 너무나도 중요하다!!! - 하지만 융통성 없이 맹목적으로 따르면 안 된다. 코드 형식은 의사소통의 일환이다. - 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. - 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확정성에 계속 영향을 미친다. - 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 그렇다면 원활한 소통을 장려하는 코드 형식은 무엇일까?? 적절한 행 길이를 유지하라 5..
-
Clean Code 3~4장Backend/책 정리 2023. 3. 7. 03:09
3장 - 함수 프로그래밍 초창기에는 시스템을 루틴과 하위 루틴으로 나눴는다, 포트란과 PL/1 시절에는 시스템을 프로그램, 하위 프로그램, 함수로 나눴다. 지금은 함수만 살아남았고 어떤 프로그램이든 가장 기본적인 단위가 함수라고 할 수 있다. 3장에서는 함수를 잘 만드는 법을 소개해주고 있다. 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까, 함수에 어떤 속성을 부여해야 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까. 이에 대해 지금부터 하나하나 소개하도록 하겠다. 1. 작게 만들어라! 함수를 만드는 첫째 규칙은 작게!다 함수를 만드는 두번째 규칙도 더 작게!다 함수는 100줄을 넘어서는 안 된다. 아니, 20줄도 길다 2. 블록과 들여쓰기 if 문 / else 문 / while ..