Conversation
|
|
||
| ``` | ||
| 논의 주제) | ||
| 과연 주석은 필요악일까? |
There was a problem hiding this comment.
저도 책이나 읽거나 리더들에게 가이드를 받았었습니다.
주석이 필요 없을 만큼 간결하고 깔금하게 코드를 작성하면
주석은 필요 없다고 생각은 합니다만
구현과 관련된 히스토리나 관련 도메인 지식의 경우는 필요하지 않을까
생각을 합니다. 나중에 돌아왔을 때 왜 이렇게 짰는지 기억이 안나더라구요ㅠㅠ
그렇다면 작성된 코드가 잘 못 된것이겟죠 ㅠㅠ
| ``` | ||
| 의견) | ||
| 나도 역시 저자와 마찬가지로 주석으로 처리된 코드를 보면 뭔가 의미가 있을 거라고 생각하는 것 같다. | ||
| 앞으로 코드를 주석 처리 할 게 아니라 그냥 지워야 겠다. | ||
| ``` |
There was a problem hiding this comment.
다른 사람과 함께 개발을 할 때
제가 작성한 것이 아니라면 찝찝하더라구요.
앞으로는 깃 로그를 확인 후
제가 작성한 것이라면 지우고
아니라면 확인해서 지우는 쪽으로
해야겠어요.
하지만 다른 사람이 히스토리용
참고용, 기타 등등 이유를 말하고
보존하는 경우는 어떻게 해야할까요?
| 논의내용) | ||
| 리팩터링과 연결지어서 생각해 보면 좋을 것 같다. | ||
| 라인이 길면 분리를 하는게 좋을 것 같고 | ||
| 개념 분리를 위해 라인이나 공백을 잘 활용해서 넣어 주면 될 것 같다. | ||
|
|
||
| 만약 IDE에서 정해준 규칙 혹은 쓰고 있는 언어의 표준 규칙이 아닌 형식을 쓰는게 있다면 논의해 보면 좋을 듯. | ||
|
|
||
| 나의 경우는 형식을 만들어서 쓰는 경우는 거의 없고 | ||
| IDE, 쓰는 언어가 가장 많이 사용하는 형식에 맞춰서 쓰는 편이다. | ||
| ``` |
There was a problem hiding this comment.
최근에 작업을 할 때는
airbnb 에서 공개한 규칙을 적용을 했어요.
규칙이 상세하고 엄청 많고
개발하면서 불필요하다고 생각하는 규칙은
팀원과 논의해서 비활성화 하는 방식으로 규칙을 정했어요.
| 객체지향에 대한 기본적인 개념을 조금이나마 다시 이해하는 챕터인 것 같다. | ||
| 객체에 대해 뭔가 내부 자료를 set, get 하는 메서드 외에 로직을 처리하는 메서드로 객체를 바라본 적이 있는지 생각해 보면 좋을 듯. | ||
|
|
||
| 나의 경우는 그게 잘 안되는 것 같다. | ||
| 자료를 숨기고 로직을 처리하도록 메서드를 노출시키는 것이 당연한데도 | ||
| 그렇지 않은 클래스들이 있는 것 보면 생각을 조금 덜 하는 것 같다. | ||
| 또, spring boot에서는 DTO를 약간 강제하는 것도 있기에 | ||
| 거기에 로직을 처리하는 메서드를 추가한 적도 있는데 | ||
| 앞으로는 잡종을 만들지 않기 위해 넣지 않는 방향으로 해야 겠다는 생각도 했다. |
There was a problem hiding this comment.
지금 것 프론트 개발 할 때는 객체지향을 생각하면서 개발을 하진 않은 것 같아요
| ctxt가 객체라면 뭔가를 하라고 말해야지 속을 드러내라고 말하면 안 된다. | ||
|
|
||
| ``` | ||
| 의견) 조영호의 오브젝트에서 객체에 메시지를 전달하라는 뜻과 비슷하다는 걸 느낀다. |
There was a problem hiding this comment.
http://www.yes24.com/Product/Goods/74219491
국내에서 객체지향 얘기할 때 한번 쯤 얘기해볼 수 있는 좋은 책입니다.
챕터별 md 파일 처음에 논의 주제를 달아 봤습니다.