2020.10.25 진행된 행사 '여성 개발자 컨퍼런스 2020'에서 발표한 '또 하나의 개발자 취업기' 발표 슬라이드입니다. 서른살이 넘은 시점에 직물공예가에서 프런트엔드 개발자로 전직을 결심한 계기, 선택, 노력, 운과 환경에 관해 이야기합니다.
* 발표 스크립트를 같이 읽으면 슬라이드를 더 잘 이해할 수 있습니다. 링크 : https://docs.google.com/document/d/1foANTtkUBq58prRgSI2sSmJjfmfHwabLoxnfNB6wqJE/edit?usp=sharing
* 발표 영상이 여성개발자컨퍼런스 유튜브 채널에 올라와 있습니다. 링크 : https://youtu.be/GfOCrTarrsI
2020.10.25 진행된 행사 '여성 개발자 컨퍼런스 2020'에서 발표한 '또 하나의 개발자 취업기' 발표 슬라이드입니다. 서른살이 넘은 시점에 직물공예가에서 프런트엔드 개발자로 전직을 결심한 계기, 선택, 노력, 운과 환경에 관해 이야기합니다.
* 발표 스크립트를 같이 읽으면 슬라이드를 더 잘 이해할 수 있습니다. 링크 : https://docs.google.com/document/d/1foANTtkUBq58prRgSI2sSmJjfmfHwabLoxnfNB6wqJE/edit?usp=sharing
* 발표 영상이 여성개발자컨퍼런스 유튜브 채널에 올라와 있습니다. 링크 : https://youtu.be/GfOCrTarrsI
개발을 업으로 한다는 것. 즉 선수 개발자가 되려면 스스로 개발에 자신이 있어야 하고 동시에 남들에게도 인정받는 훌륭한 개발자여야 합니다. 자신있다는 것과 훌륭하다는 것은 어떤 차이가 있을까? 이 발표는 이제 개발에 입문하려는 사람들, 이제 뭐든 만들 수는 있을 것 같은 개발자들, 뭔가 개발 '꺼리'를 보면 솟아나는 열정에 가슴이 뛰는 개발자님들을 위하여 훌륭한 개발자가 되기 위한 마음가짐과 준비해야하는 것들에 대하여 이야기를 합니다.
아래의 9권 책 리뷰를 포함하고 있습니다.
리팩토링 코드 품질을 개선하는 객체지향 사고법
빅데이터의 충격 (거대한 데이터의 파도가 사업 전략을 바꾼다)
헤드 퍼스트 데이터 분석 (당신을 최고의 데이터 분석가로 이끌어줄 마법 같은 학습서)
왓슨 인간의 사고를 시작하다
소프트웨어 누가 이렇게 개떡같이 만든 거야
앱만장자 (부를 거머쥔 인디 개발자들의 성공 비법)
애자일 마스터 (프로젝트 인셉션 추정과 계획 그리고 실행)
읽기 좋은 코드가 좋은 코드다 (더 나은 코드를 작성하는 간단하고 실전적인 테크닉)
프로그래머, 열정을 말하다
객체지향에 관련해서, 가볍게 내용을 정리하였습니다.
참고서적 : 스프링 입문을 위한, 자바 객체 지향의 원리와 이해 김종민 지음
객체지향.
말은 참 어려운데. 프로그래밍 하면서 사람이 인식하는 사물 또는 실체를 하나하나 조합해서 프로그래밍 하자는 패러다임입니다.
쉽게, 객체를 가지고 놀자 이겁니다.
객체지향언어에서는
클래스(Class) 객체(Object)가 존재합니다.
클래스는 추상화 및 분류
객체는 실제를 의미합니다.
예) 사람클래스 -> 원빈 객체 / 동물 클래스 -> 고양이 객체
4대 특징
- 캡슐화
- 상속
- 추상화
- 다형성
객체지향 개념을 완벽히 이해하려면. 많이 공부해야 할거같습니다..ㅠㅠ
읽은 책은 "전문가를 위한 안드로이드 프로그래밍 : 그 한계를 넘어서" 이다.
이 책이 기존의 안드로이드 책과 다른점은. 기존의 책들이 튜토리얼, 초보자를 대상으로 만들어진 책이라면
이 책은 이미 안드로이드 어플리케이션을 몇 개 작성해보고 고급 API나 트릭을 알고자 하는 사람을 대상으로 한다.
기술서적으로 독후감을 쓰려니 막막하지만. 어렵게 생각하지 않고 이 책을 읽는다는 것이 현재 나의 환경(회사에서 일을하는)에서 어떤의미를 던지는 것일까? 생각해보니 두가지 측면에서 할 이야기가 생각났다.
한가지는 기술서적을 읽는 그 자체에 대한 생각이고 다른 하나는 주어진 프로젝트가 있는 상황에서 기술들의 나열을 보았을때 프로젝트에 어떻게 적용시킬까에 대한 생각이다.
개발을 업으로 한다는 것. 즉 선수 개발자가 되려면 스스로 개발에 자신이 있어야 하고 동시에 남들에게도 인정받는 훌륭한 개발자여야 합니다. 자신있다는 것과 훌륭하다는 것은 어떤 차이가 있을까? 이 발표는 이제 개발에 입문하려는 사람들, 이제 뭐든 만들 수는 있을 것 같은 개발자들, 뭔가 개발 '꺼리'를 보면 솟아나는 열정에 가슴이 뛰는 개발자님들을 위하여 훌륭한 개발자가 되기 위한 마음가짐과 준비해야하는 것들에 대하여 이야기를 합니다.
아래의 9권 책 리뷰를 포함하고 있습니다.
리팩토링 코드 품질을 개선하는 객체지향 사고법
빅데이터의 충격 (거대한 데이터의 파도가 사업 전략을 바꾼다)
헤드 퍼스트 데이터 분석 (당신을 최고의 데이터 분석가로 이끌어줄 마법 같은 학습서)
왓슨 인간의 사고를 시작하다
소프트웨어 누가 이렇게 개떡같이 만든 거야
앱만장자 (부를 거머쥔 인디 개발자들의 성공 비법)
애자일 마스터 (프로젝트 인셉션 추정과 계획 그리고 실행)
읽기 좋은 코드가 좋은 코드다 (더 나은 코드를 작성하는 간단하고 실전적인 테크닉)
프로그래머, 열정을 말하다
객체지향에 관련해서, 가볍게 내용을 정리하였습니다.
참고서적 : 스프링 입문을 위한, 자바 객체 지향의 원리와 이해 김종민 지음
객체지향.
말은 참 어려운데. 프로그래밍 하면서 사람이 인식하는 사물 또는 실체를 하나하나 조합해서 프로그래밍 하자는 패러다임입니다.
쉽게, 객체를 가지고 놀자 이겁니다.
객체지향언어에서는
클래스(Class) 객체(Object)가 존재합니다.
클래스는 추상화 및 분류
객체는 실제를 의미합니다.
예) 사람클래스 -> 원빈 객체 / 동물 클래스 -> 고양이 객체
4대 특징
- 캡슐화
- 상속
- 추상화
- 다형성
객체지향 개념을 완벽히 이해하려면. 많이 공부해야 할거같습니다..ㅠㅠ
읽은 책은 "전문가를 위한 안드로이드 프로그래밍 : 그 한계를 넘어서" 이다.
이 책이 기존의 안드로이드 책과 다른점은. 기존의 책들이 튜토리얼, 초보자를 대상으로 만들어진 책이라면
이 책은 이미 안드로이드 어플리케이션을 몇 개 작성해보고 고급 API나 트릭을 알고자 하는 사람을 대상으로 한다.
기술서적으로 독후감을 쓰려니 막막하지만. 어렵게 생각하지 않고 이 책을 읽는다는 것이 현재 나의 환경(회사에서 일을하는)에서 어떤의미를 던지는 것일까? 생각해보니 두가지 측면에서 할 이야기가 생각났다.
한가지는 기술서적을 읽는 그 자체에 대한 생각이고 다른 하나는 주어진 프로젝트가 있는 상황에서 기술들의 나열을 보았을때 프로젝트에 어떻게 적용시킬까에 대한 생각이다.
11. 기획자
역할: 신기능을 기획하기
개발자
역할: 기능을 개발하기
객체의 특징 3. 협력은 하되, 자신의 역할에만 집중한다
서로 내부 구조 모름. 공개된 메서드만 호출
가능
“requestPlans”만 있군..
12. 기획자 개발자
객체지향은 ‘단순한 클래스 잘 만들기’가 아니다
위 객체의 특징들을 어떻게 잘 살릴지 고민한 결과가
객체지향
1. 필요에 따라 적당한 상태와 행동을 구성하는 것
2. 객체 사이의 협력 관계를 구축하는 것
3. 각 객체가 가져야 할 역할과 책임을 적절히 부여하는 것
객체지향 설계의 핵심
13. 객체지향을
처음 본 나
근데 왜 이렇게 귀찮게
만들지? 그냥
전역에다가 대충 함수
만들어서 쓰면 되는거
아닌가...
14. 객체지향을
처음 본 나
근데 왜 이렇게 귀찮게
만들지? 그냥
전역에다가 대충 함수
만들어서 쓰면 되는거
아닌가...
그래서
전역에다가
마구잡이로
코드를
짜버린 나
플젝 사이즈 커지니까
뭐가 어디있는지도,
어디에 쓰이는지도
모르겠고… 다시
손대기도 부담스럽네;;
ㅅㄱ
15. 객체 & 객체지향을 이용하면 얻을 수 있는
이점은?!
역할, 책임, 협력으로 만들어진 지속가능한 코드 구조
수정하기 쉽고, 확장성 있고, 이해하기 쉬운….
아니 뭐… 어떻게?
16. 책임과 협력의 관계
개발자
무지성으로 코드짜기, 디버그하기, 테스트하기, 빌드하기 메서드를 제공한다면 기획자는...
어떤 협력이 필요한지 생각하지 않고, ‘개발자’라는 클래스를 구현한다면...
개발자가 할 수 있는 일..?
코드짜고, 테스트하고, 빌드하고…
이런 메서드를 클래스에 만들어두고 쓰게 하면
되겠지?
17. 책임과 협력의 관계
개발자
무지성으로 코드짜기, 디버그하기, 테스트하기, 빌드하기 메서드를 제공한다면 기획자는...
자신의 역할을 넘어 너무나 많은 것을 신경 써야 하는 기획자
협력 관계가 복잡해짐, 의존성 ON, God object ON
어떤 협력이 필요한지 생각하지 않고, ‘개발자’라는 클래스를 구현한다면...
개발자가 할 수 있는 일..?
코드짜고, 테스트하고, 빌드하고…
이런 메서드를 클래스에 만들어두고 쓰게 하면
되겠지?
기획자
내가 코드 짜라, 디버깅해라, 하나하나
다 말해줘야 하냐고~
18. 책임과 협력의 관계
기획자 개발자
명확한 책임이 깔끔한 협력을 만든다
너무 세세하지 않으면서, 너무 추상적이지도 않은 ‘적절한 책임’을 가지고
있어야 함
19. 책임과 협력의 관계
기획자 개발자
명확한 책임이 깔끔한 협력을 만든다
개발자는 ‘기획을 받아 원하는 것을 개발해내 전달하기’ 라는
책임을 가진다
기획자는 개발자의 해당 책임을 호출하고 기다리기만 하면 된다
= 기획자가 해야 하는 역할을 넘어서지 않아도 된다
협력 관계가 깔끔해진다
20. 협력은 어떻게 이루어질까
메시지를 전송하는 방법
(= 공개된 메서드를 호출하는 방식)
공개된…?
(“Developer는 이 메서드를 갖고 있구나?!” 라고 알 수
있는)
23. 추상화와 타입
기획
자
iOS 앱
개발자
개발자
얘는 개발자구나...
그러면 일단 누구든 간에
개발은 할 수 있겠군...
개발자.develop()
개발자라는 타입이란걸 알고 있으면
기획자는 복잡하게 생각할 필요 없이
“아! 얘는 개발은 할 수 있겠군!”
이라고 판단, .develop() 메서드를 호출할 수 있다
=> 추상화를 통해 깔끔해진 협력 관계
24. 추상화와 타입
기획
자
iOS 앱
개발자
개발자
얘는 개발자구나...
그러면 일단 누구든 간에
개발은 할 수 있겠군...
개발자.develop()
기획자는 해당 대상이 ‘개발자’라는 타입인 것만 신경
씀
이게 사실은 안드로이드여도, 서버여도, 웹이어도
상관없음
‘개발자’라는 역할을 수행하는 그 어떤 객체든
들어와서 붙을 수 있음
=> 역할을 통해 객체의 대체가능성
27. 인터페이스
Swift의 Protocol: JS, Kotlin의 interface와 같음
이 역할(타입)이 수행하기 적절한 책임을 넣어둔다
Developable에 부합하는 객체들은 부담없이
사용 가능
28. 책임을 수행하는 객체
메시지를 받은 객체는 그 메시지가 요구하는 결과를 내야 하는 책임이 있고,
그 책임을 다 하기 위해 자율적으로 메서드를 수행할 수 있다.
기획자
개발자
책임 부여
알아서 개발해서
결과물을 돌려주면
되겠군...
29. 자율적? 메서드 불러지면 수동적으로 움직이는건데 이게 왜 자율적이냐?
객체가 자유 의지를 가지고 있다는게 아니라…
어떤 결과를 내기 위해 내부에서 어떤 과정을 거칠지는 객체가 알아서 하라는 뜻
30. 캡슐화
기획
자
iOS 앱
개발자
개발자
Developable
개발자.develop() develop 해달래
내부에서 어떻게 작동하는지
모름
사실 알 필요도 없음
코드
짜기
테스트
하기
빌드하기
내부 메서드를 알아서 사용해
개발 책임을 수행
객체의 협력은 메시지로만, 그 이상의 간섭은 지양해야 함
내부(구현)와 외부(인터페이스)의 분리가 필요 -> 캡슐화
내부 로직 수정이 필요할 때도
외부에 나가는 결과값만 제대로 맞춰준다면
다른 객체에서는 수정된 부분을 신경 쓸 필요가 없어짐
31. 자율적인 책임이 중요한 이유
1. 협력을 단순하게 만드는데 도움을 줌
2. 캡슐화를 통해 외부와 내부를 확실히 분리하는데 도움을 줌
3. 내부 로직을 변경하더라도 외부, 다른 객체의 구현에 영향을 미치지 않도록 해줌
4. 코드를 읽을 때 객체의 역할을 쉽게 이해할 수 있게 해줌
32. 객체지향, 어떤 기법이 있을까
더 많긴 하지만, 두 가지만 살펴보자면...
1. 책임 주도 설계
2. 테스트 주도 개발
33. 책임 주도 설계, Responsibility Driven Design
● 시스템이 사용자에게 제공해야 하는 기능과 그 책임을 파악한다.
● 시스템의 책임을 더 작은 책임들로 분할한다.
● 분할된 책임을 잘 수행할 수 있을 적절한 역할(객체)를 찾아 책임을 할당한다.
● 객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체를
찾는다.
● 그 객체에도 새로운 책임을 할당함으로써 두 객체가 협력하게 한다.
단연 포인트는 책임의 분할과 할당이라고 생각한다
34. 테스트 주도 개발, Test Driven Development
처음엔 실패할 수 밖에 없는 테스트를 하나 만들어두고,
그걸 해결하기 위한 코드를 일단 짠 후,
리팩토링으로 정리하며 좋은 코드를 얻는 방식
35. 테스트 주도 개발, Test Driven Development
처음엔 실패할 수 밖에 없는 테스트를 하나 만들어두고,
그걸 해결하기 위한 코드를 일단 짠 후,
리팩토링으로 정리하며 좋은 코드를 얻는 방식
테스트는 단순 테스트가 아니라, 해당 객체가 어떤 책임을 해줄 것이라는 ‘기대’를 담고 있는 것
36. 결론: 왜 객체지향을 써야 하는가
읽기 좋고 이해하기 쉬운 코드 구조로 협업을 더 잘 하려고
적절하고 느슨한 객체 사이의 관계를 구축해 수정해도 부담 없는
코드를 만들려고
테스트를 좀 더 하기 좋게 하려고
37. 결론: 왜 객체지향을 써야 하는가
더 좋은 코드를 짜기 위해서
읽기 좋고 이해하기 쉬운 코드 구조로 협업을 더 잘 하려고
적절하고 느슨한 객체 사이의 관계를 구축해 수정해도 부담 없는
코드를 만들려고
테스트를 좀 더 하기 좋게 하려고