반응형 기록 및 문서화20 [퇴사한 이형] 1년을 10번 사는 사람 vs 10년을 1번 사는 사람 https://www.youtube.com/watch?v=B-4OZwnNwJg 사명선언서 작성 Tips 모델을 따라하자. 미래의 구체적인 상황을 그리면서 작성하자 내 삶의 히스토리를 입체적으로 보고, 기여 포인트를 찾자. 한 줄 이라도 적어보고, 매년 업데이트 하자. 다양한 사람을 만나고 영향을 받아야 한다. 우선순위와 가치를 따지자. 선택의 기준이 있는 사람이 되자. 나는 뭘 하고 싶을까? 나는 뭘 하면 즐거운가? 무언가 만들어내는 것, 문제를 해결하는 것을 좋아한다. 완전하게 아는것을 좋아하는 것 같다. 다양한 것들을, 모든것을 알고싶어하는 욕심이 있다. 사람은 모든걸 알수 없고 완전하게 아는것은 더 힘들다. 나의 경력은 깊게 안다기보다 넓게 아는 사람이 됐다고 생각한다. 문제를 해결하는 능력은 있다.. 2023. 5. 1. [퇴사한 이형] 회사에서 친하게 지내야 되는 사람 https://www.youtube.com/watch?v=LfmUPnkal6w 회사 내 절친이 있는게 좋다. 어떤 사람과 절친이 되면 좋을까? 1. 자기 주관이 있는 사람 - lifestyle 일치 - 내 기준, 가치관이 일치 - 기준 자체가 없는 사람은 영향받고 바뀔 수 있다 2. 회사에 긍정적인 사람 - 회사에 냉소적인 사람 피해라(불평불만러, 뒷담러). 건설적 비판(더 나은 발전)과는 다름 3. 배울게 있는 사람 - 실력 + 인격적 성숙(사람을 경험해봐야 알게됨) - 이런 사람은 도와주고/도움 요청하면 좋다 - 어떻게 친해지나? 성과를 내는 순간 절친이 됨 2023. 4. 29. 오늘도 개발자가 안된다고 말했다 - Part 1 가깝고도 먼 개발자 보호되어 있는 글 입니다. 2022. 4. 18. 스프링 핵심 원리 - 기본편 보호되어 있는 글 입니다. 2022. 3. 14. 객체지향의 사실과 오해 6장 객체 지도 고객의 도메인과 프로그램, 설계를 일치시킴으로써 얻을 수있는 효과 고객의 도메인이 변경됐을때 == 요구사항이 변경됐을때 도메인과 대응되는 설계, 코드가 존재하면 해당 부분만 수정하면 되는? 수정 대상이 명확해진다? 설계와 구현의 변동 관리가 쉽다 나머지 절반을 읽었다. 도메인 + 유스케이스 하나하나 개념들이 합쳐지면서 큰 그림이 보이는거 같다. 도메인 모델과 유스케이스의 각각의 역할을 설명해줘서 좋았다. 문서의 변화로부터 코드의 변화가 생길수도 있지만. 코드의 변화로부터 문서의 변화가 생길수도 있다. 생길수도있다? 자연스럽게 변화가 흘러가고 동기화가 된다. 2022. 1. 6. 객체지향의 사실과 오해 5장 책임과 메시지 지금까지 책을 읽으면서 제일 주옥같은 이야기가 많이 나왔다고 생각한다. 5장이 좀 길어서 아직 전부를 읽지는 못했다. 다 읽고나면 여기다가 추가로 작성할 예정 책임이 설계의 품질을 좌우한다. 너무 구체적이거나, 책임이 분할되어있으면 운신의 폭이 줄어든다. 너무 추상적인 책임은 정확히 뭘 하는지가 알수가 없다. 좋은 책임이란? 어떻게 가 아니라 무엇을 해야하는지 설명하는 것 어떻게 책임지냐가 있으면 너무 구체적임에 다가가는 것이다. 메서드는 어떻게가 들어있는 단어다. 생각해보면 method는 한글로 하면 방법으로 해석된다. 펑션이랑 메서드가 어떤 차이가 있는지 구분이 간다. Function은 기능 Method는 방법 클래스에 있는 기능을 Method라고 한다 그럼 인터페이스에 적힌건 Method라고 안하나.. 2021. 12. 23. 이전 1 2 3 4 다음 반응형