Dev Book

· Dev Book
주석을 추가하는 이유? 우리의 코드 품질이 나쁘기 때문이다! 주석이 없이도 충분한 설명이 되는 코드가 좋은 코드이다. 주석은 코드와 다르게 한번 작성하고 나면 방치될 수 있다. 처음에는 코드를 잘 설명했지만 시간이 지날수록 거짓된 정보를 제공할 가능성이 있다. 좋은 주석이란? 구현에 대한 정보를 제공 : 정규표현식의 경우에는 한번에 이해하기 어렵다. 주석으로 자세히 설명을 달아주자 의도와 중요성을 설명하는 주석 TODO , FIXME TODO는 미래에 작성해야 하는 코드에 대한 설명을 적는다. FIXME는 문제가 되지만 당장은 고치지 않는 코드를 적는다. 📚 JavaDocs 현업에서 타 부서에게 코드를 보여준다면 JavaDocs로 자세한 설명을 달아놓는것이 좋다.
· Dev Book
나쁜 코드와 좋은 코드란? 🚫 나쁜 코드의 특징 필수적인 로직 외의 코드들이 추가되어서 성능이 저하된다. 제 3자가 볼때 사용 용도, 의미를 알 수 없는 모호한 표현(네이밍) 중복으로 인한 코드의 재활용성 저하 😊 깨끗한 코드의 특징 성능이 보장되는 코드 가독성이 좋은 코드, 즉 잘 쓴 문장처럼 술술 읽히는 코드 중복을 최대한 줄여서 코드의 재활용성을 극대화한 코드 한가지 기능에 집중하는 코드(SOLID의 SRP 원칙) 보이스카우트 룰 내가 코드를 건드리기 전보다 더욱 깨끗한 상태로 만들어야 한다. 네이밍을 잘 하기 String a; int b; public void printMyData(String a, int b) { System.out.println("my name is " + a + " and m..
· Dev Book
5장은 객체지향 설계에 있어서 메세지의 중요성과 책임의 자율성을 강조한다. 손님이 바리스타에게 커피를 주문하는 과정을 협력의 예시로 들어보자. 이 협력에서는 '커피를 만들어라' 라는 말이 메세지가 된다. 저자는 객체 지향 설계가 이 메세지를 정하는 것으로부터 시작되어야 한다고 말한다. 메세지의 송/수신자의 관점에서 수신자인 바리스타는 오직 '커피를 만들어라' 라는 메세지가 수신될때만 행동을 하게 된다. 인터페이스 이번장에서는 인터페이스의 개념이 등장한다. 인터페이스는 객체들이 협력하는 통로가 되어준다. 실생활의 예시 중 노트북을 예시로 들었을때 우리는 키보드에 타자를 침으로써 노트북과 의사소통 한다. 책에서 소개하는 인터페이스의 특징을 살펴보자. 인터페이스의 사용법을 익히기만 하면 내부 구조나 동작 방식..
· Dev Book
4장은 이기적이고 합리적이라 가정된 인간도 타인과의 협력의 관점에서는 행동 양식이 달라질 수 있다는 이야기로 시작된다. 객체지향의 세상에서도 이 원리는 똑같이 적용될 수 있다. 우리는 객체 하나하나의 독립성에 집중할 것이 아니라 객체들간의 협력에 초점을 맞춰야 한다. 협력은 객체들이 요청과 응답의 메세지를 주고 받는 과정에서 일어난다. 응답을 해주어야 하는 메세지의 수신자는 자신이 해결하지 못하는 작업을 능력이 있는 다른 객체에게 요청한다. 객체들끼리 유기적으로 요청과 응답의 연쇄작용이 일어나고 이를 협력이라고 할 수 있다. 4장에서는 재판 과정을 예시로 든다. 재판장은 재판을 진행해야 한다는 책임이 있고, 토끼는 증인을 출석시켜야할 책임이 있으며 증인은 거짓없이 증언을 해야할 책임이 있다. 각자의 책임..
Jemlog
'Dev Book' 카테고리의 글 목록 (2 Page)