2024-11-07_멘토링6회차 노트

[tttghost]

오후 11:13 2024-11-06

리마인드 차원
효과적인 멘토링방법

개인프로젝트를 하면서 이야기

작은것을 해보고 판단해보자

절반은 한 것 같다.

심화할 방법을

할 마음이 있다 없다 를

한달에서 한달 반치를 해보는 쪽

여러 방법 멘토링의 다양한 방법

1. 프로젝트를 하는게 아니라 책읽고 의견교환

강하게 해야한다는 의지
프로젝트를 다시 해서 이슈를 만들고 해야 하는것

약간의 강제성을 목표를 어느정도 잡아주시는 형태
그것을 먼저 이렇게 해야한다는 것은 숙제한다는 느낌이 발생할 수 있음
다음 이야기 할 때 까지 이런것을 좀 해보겠다.
기간에 대한 작업량의 할당이 약간의 강제성

조금하고 피드백 조금하고 피드백
2주치만 해보자
2주짜리 프로젝트

짧은 목표

조금씩 했을때에는 그만두고 싶은 마음이 그나마 덜 듬

2주치의 목표

특정 기법에 너무 매몰되지 말아라

진단사항
필요하지않은과도한코드
필요하지않은지네릭
싱글톤으로 시작되는 상태값들
이런 것들을 개선 해야 하는데...

최종적으로는 코드 리뷰보다는 설계리뷰쪽으로 가야한다.
소프트웨어책의 좋은 책들은 10에9은 설계
테스트코드 신간으로
실무로 통하는 클린코드 2달밖에 안된 신간책 읽고 계씬다
설계내용을 상당히 많이 언급한다.
마무리하는 유지보수 가독성이 좋고 테스트가 가능한 코드가 클린코드다.
이미 만들어진 코드에 대한 문제점만 발견했지 개선점에 대해 이야기를 못했다.

2달전의 상태에서 시작을 해야한다.

코딩을잘하는방법쉬운거에서어려운거

1. 아무것도없는것에서새로만드는거
2. 만들어져있는거 리팩터링
3. 이미 잘 돌고있는 코드 뭘바꿔야 좀더 좋아지는지를 판단하는것

개선점에 대해 가이드라인을 따주심
갑자기 코드를 훅 들이밀지는 않는다.
어떻게 설계가 들어갈거고 어떻게 바뀔거고를 공유

하는김에 동시에 하면 좋겠다는 생각이 방금 들음
설계쪽 부분 테스트코드쪽 부분도 알려주시면서 하면 좋을 듯

설계를 짜고 조금더 디테일하게 짜고 테스트코드를 짜고 그다음 PR을 올리고

뭘 개발할지를 이야기하고 코드만 짜도 된다 이건 회사의 입장

더 좋은 방법에 대해 자기 스스로 연마 후 품질로 보답하는게 좋은 엔지니어의 입장

이런것들이 빠질때마다 품질을 책임질 수 있는 것이 하나씩 빠진다고 봐야 함.

PR을 하는 이유?
나중에 이사람이 짠 코드를 볼 시간을 미리미리 30분 1시간씩 받아서 미리미리 알게 되는..

업보관련 이야기가 나오는 책
클린코더
소프트웨어장인

테스트코드 속는셈 치고 만들어보자 -> 그 만드는 방법? 단위설정? -> 단위테스트?? 메소드의 기능 단위
단위테스트: 최소단위의 테스트, 메소드 단위>
모듈테스트:여러개의 메소드를 모아서 어떤 기능을 한다 가 컴포넌트테스트or모듈테스트(로그인정도) >
통합테스트: 사용자가 쓰는 방식대로 만드는 것

처음테스트코드짤때 드신 생각
이걸 내가 왜 짜야하지?라는생각
이게 기능이 도는데 이걸 왜 짜야하지 라는 생각? -> 7~8년차때에 그 테스트코드를

디버그랑 테스트코드랑 다른점?
디버그는 런타임에 판단하는것이고 테스트코드는

인터페이스 대로 테스트코드가 나와야 한다 -?> 설계를 안하면 못하는것들이 많아짐
설계를 안해서 그런다.
객체지향이나 디자인패턴은 엄두도 못냄
설계를 안하면 지자인패턴이 안나온다.

디자인패턴만 가지고

설계 관련된 책을 보며꺠우치는게 좋다. -> 구름잡는 이야기만 한다.

클린코드라는 책을 보는게 더 좋다.
안읽어보고 내가 하자는 대로 해 라는것은 안좋다. 읽어보고 이야기 하는게 좋다.

그릇을 키우자.

설계는 배워서 할수 있는게 아니다. 코딩 짜듯 하는게 아니라, 무엇이 필요하다 무엇이 만들어야 한다 라는 생각을 하고 인터페이스의 정의

디자인패턴 시작방법
어떤문제가 있고 이때 이런 패턴을 썼다는 걸 이해해야함, 코드를 보는게 아니다.

11개의 알고리즘패턴이 있듯
디자인패턴은 23개가 정형화되어있음

인터페이스를 1개라도 뽑아서 설계를 해야하는것을

훈련방법도 있습니다.

구현하는쪽을 생각하지말고
필요로 하는쪽을 생각하는게 설계

시키는 쪽의 입장의 관점 즉 함수의 내용

여태까지
객체지향의 사실과 오해

인터페이스를 바라보고 호출하는 것을 해야 설계를 할 수 있다!!!!

설계가 어떤관점에서 필요하냐
이 관점에선 인터페이스가 필요하다.
디자인패턴은 다 인터페이스에서 시작한다.
기능에 대한 정의
호출하는 사람의 관점 == 안에 내용이 어떻은 내가 원하는 결과를 동작해줘

설계리뷰를 올바르게 한다면
코드리뷰를 하는 부하가 상당히 줄어듬

설계랑 테스트코드
기존코드에 대한 개선

당장 안되더라도 조급해 하지 말아봅시다.

멘토님의 예제는 8년차쯤에 테스트코드를 해보려고 했는데 테스트코드의 의미를 알게된건 그 후로부터 몇년뒤에

내일이나 모래정도까지 2주치의 분량을 디스커션에 남겨라.