Week 3 - 역량강화 2주차 🤣

---

지난, 금요일 개인 프로젝트 발표 이후, 시간이 부족하여 팀 빌딩을 첫 날 진행하게되었다.
우리 안드로이드 팀과 백엔드 4분을 제외하고는 모두 사전에 연락하여 팀을 하기로 협의가 되었어서 조금 당황스러웠다 😅

하지만, 그래도 힙겹게(?) 결성된 우리 팀에서 열심히 하고자 한다. 우리 팀은 여행을 기록하는 서비스를 주제로 프로젝트를 진행하게 된다.
이번 주차도 마찬가지로, 지난 주에 하지 못했던 팀 빌딩 이후로, 교양강화, 전공강화 시간이 주어진다.

각 그룹마다 학습 후 발표를 진행하고, 대신 이번 주 부터는
개인 프로젝트 시간 -> 팀 프로젝트 시간으로 바뀌었다.

---

교양강화

교양강화 시간은 각 팀이 맡게 된 교재를 읽은 후, 발표를 통해 강의 후 질문을 하는 형식으로 진행이된다.

이번 교양강화 발표는 내가 맡게되었다.
이번 주차 안드로이드 그룹이 맡게 된 애자일 마스터의 발표 범위는 4, 5, 6, 7, 8장이다.
때문에 주말에 독서시간만 4~5시간 정도 할당하였고, 정리하는 시간까지 합쳐서 거의 10시간을 할당한 것 같다.
토요일 하루 놀았더니, 애자일 마스터 교양강화 발표 준비하느라 시간을 다 날렸다.

이번 애자일 마스터 발표 범위에서는 인셉션 덱의 10가지 질문을 어떻게 활용하는 지, 그에 대해서 어떤 이점을 얻을 수 있는 지를 설명하였고,

두꺼운 요구사항 문서를 작성하는 대신 사용자 스토리를 작성하는 이유, 좋은 사용자 스토리를 만족하는 요소, 사용자 스토리를 사용하면 가져다주는 이점, 사용자 스토리를 올바르게 작성하고, 구별하는 과정 등을 통해서 이렇게 완성된 마스터 스토리 리스트에 추정치를 측정하는 방법, 이러한 마스터 스토리 리스트와 이터레이션, 팀의 속도를 통한 번다운 차트, 번업 차트에 대한 설명들을 다루었다.

이번 교양강화 발표를 준비하면서, 이와 같은 내용들을 정리하게 되었는데, 이로써 느낀 점으로는 앞으로 우리가 진행할 팀 프로젝트에 있어서, 고객의 입장에서 어떻게 생각하고, 고객의 사용자 스토리를 어떻게 정의해야 할 지, 우리의 프로젝트를 어떻게 애자일처럼 변화시킬 지, 여러 시나리오에 따라 어떻게 대응하면 될 지를 적용해보면 어떨까라는 생각을 하였다.

---

전공강화

전공강화 시간은 각 팀이 맡게 된 교재를 학습 후, 발표를 통해 강의 후 질문을 하는 형식으로 진행이 된다.

이번 전공강화의 발표 범위에서 우리가 주로 발표할 주제로는 코틀린에서의 함수로 정하고, 발표를 준비하였다.

코틀린에서의 함수는 다음과 같은 특징이 있다.

Kotlin의 함수는 first class라는 것이다. -> 함수가 일등시민과 같다는 것.

• 클래스가 없이 함수로만 작성해도 실행이 가능.
• 함수를 다른 함수의 인자로 전달 가능
• 함수의 반환타입이 함수가 될 수 있음
• 함수를 함수타입의 변수에 저장 가능

이러한 주제로, 우리는 코틀린의 고차함수가 무엇인지 ? , 함수타입은 어떻게 정의하며 변수에 저장하는 지 ? , 그리고 스코프 함수는 무엇인지 ? , 확장함수라는 개념은 무엇인지 ? 를 도출하여 발표를 진행하였다.

아쉽게도 발표 날, 목 감기가 심해서 몸살도 있고, 열도 조금 나서 컨디션이 매우 안 좋아 출석을 하지 못하였지만, 우리 팀원들이 발표를 잘 진행해주었을 것이라 생각한다. ( 다행히 신속항원검사를 받았는데 코로나 음성이 나왔다. 다들 조심하세요.. ㅠ + 저번 주 금요일에도 받았는데 음성이라 진짜 코로나는 아닌 것 같아 다행이다. )

---

Scope Function

우리의 발표 범위는 대부분 다 아는 내용이었지만, 스코프 함수 부분이 개념이 좀 부족하였고, 어떤 차이가 있는 지 애매모호한 점들이 있었는데, 이번 발표를 준비하게 되면서 거의(?) 확실하게 이해하게 되었다.

apply , also , run , let , with 다음과 같은 scope 함수들이 있는데, 한 번 살펴보고 넘어가는 것이 좋아보인다.

apply/also

다음과 같이 묶은 이유는, apply 와 also 는 자기 자신(수신객체) 객체를 반환하는 성질이 있다.
예제를 살펴보자.

class Starters() {
    private var student = 18
    private val facilitator = 2
    private val manager = 1
}

val starters = Starters()

다음과 같은 Starters 클래스, 그리고 starters 라는 인스턴스가 있다.

apply

val cnt = starters.apply { 
	student = 18
    student + facilitator
}

println(cnt)

보통 람다식은 마지막 줄의 값을 반환하는 성질을 가졌으므로 cnt의 값은 20이라고 생각할 것이다.

틀렸다.

이 cnt의 값을 출력하게 되면 starters 라는 apply 앞에 오는 수신 객체의 힙 메모리 주소 값이 출력된다.
이유는, apply 는 수신객체의 필드를 this로 참조하는 성질이 있고, 이 람다식 안에서 this는 생략되며, 필드를 참조할 수 있다.
따라서, student라는 필드 값이 18인 자기 자신, 수신 객체 자체를 반환한다.

also

val cnt = starters.also { 
	it.student = 18
    it.student + it.facilitator
}

println(cnt)

이 코드도 마찬가지로, cnt라는 변수 이름에 낚일 수 있다. 하지만 이 또한 cnt값은 반환 받은 수신객체의 주소 값이 된다.
also는 수신 객체의 필드를 it으로 참조하는 성질이 있다.

apply와 also 의 특징을 살펴보자.

• 자기 자신인 수신 객체 반환
• apply 는 this 로 수신객체 참조가능, 생략 가능
• also 는 it으로 수신객체 참조가능.
• 객체를 생성 후, 필드 값을 초기화할 때 주로 사용한다.

---

run/let

run과 let을 묶은 이유는, 이들은 람다 식의 마지막 줄 값을 반환하는 성질이 있다.
반환할 값이 없다면, 마찬가지로, 수신객체의 필드 값을 참조하는 성질이 있다.
run은 this를 통해 참조하고, let 은 it을 통해 수신객체의 필드 값을 참조한다.

run

val cnt = starters.run {
	studnet = 18
    student + facilitator
}

println(cnt)

이 때, cnt의 값은 무엇일까 ?

20

그렇다. run에서는 마지막 줄 값이 반환된다고 하였다.
그리고 this를 통해 참조하므로, this는 생략이 가능하다. 따라서, 필드명만 작성하여도 참조가 가능하다.

let

val cnt = starters.let {
	it.studnet = 18
    it.student + it.facilitator
}

println(cnt)

let 또한 마찬가지이다. cnt의 값은

20

이다. it을 통해 필드를 참조하는 모습을 확인할 수 있다.

---

with

val cnt = with(starters) {
	student = 18
    student + facilitator
}

with 는 다음과 같이 사용한다.

수신객체를 with(수신객체) 형태로 사용한다.
수신객체의 필드를 참조할 때, it을 붙이지 않는 것을 보니, this를 통해 참조하는 것을 알 수 있고, 생략되었다고 볼 수 있다.

그리고 블럭의 마지막 값을 반환하는 성질이 있다.
cnt의 값은

20

이다.

여기서 중요한 부분이 있다.

with는 다른 apply, also , run , let 과는 다른 형식이고, ?. : safe call operator 를 사용하지 못한다는 성질이 있다.

따라서 수신객체가 nullable일 때는 with 를 통해 처리하지 못한다는 것이다.

수신 객체가 null 일 때는 null을 반환하며 ?: : elvis operator 를 사용해서 처리해줄 수 있다.

---

safe call operator 와 elvis operator를 사용한 예시.

apply/also

val nullableStarters = starters?.apply(or also) {
	student = 15
} ?: Starters()

run/let

val cnt = starters?.run(or let) {
	student + facilitator
} ?: run {
	println("Starters is null")
    null
}

with에서는 nullable 수신객체를 처리해주지 못한다.

---

팀 프로젝트

이번 주차 팀 프로젝트 시간에는 주제를 정하고, 각 팀원들의 역할 및 소개, 사용할 기술 스택 등 UML 다이어그램을 그리며 기획을 하는 주차이다.

이번 팀 프로젝트 기간에는 정말 정신없었던 것 같다.

주제를 정하고, IA(Information Architecture) , UseCase, Activity, Class Diagram , 화면 설계서 + 기능 명세서 까지 작성을 하였다.

작성하다가 알게되었는데, 프로젝트를 소개하고, 팀원들의 역할 그리고 사용할 기술 스택까지 정의해야 한다고 해서 부리나케 정리했던 기억이 있다.
위와 같은 산출물들을 작성하면서 많은 의견충돌이 있었다. 그래두 팀원들의 노력과 협조 덕에 시간 안에 산출물들을 완성하였다. ㅎㅎㅎ

사실 우리 팀장님이 디자이너와 다른 스택의 개발자들과 협업 경험이 있어서 다행인 것 같았다.
화면 설계서와 기능 명세서에 대한 이해도가 높으셨고, 화면 스케치 또한 엄청 열심히 그려주셨던 덕분에 프로젝트 팀원들이 프로젝트를 좀 더 체화(이해)하기 쉬웠고, 산출물들을 작성하는 데에 많은 시간을 단축시킨 것 같다.

금요일에는 지금까지 작성하였던 프로젝트 소개글, 팀원들 역할, 기술 스택 글, 위와 같은 산출물들을 바탕으로 발표하며 프로젝트를 소개하는 시간을 가졌다.
감기가 심해져서 가지 못하였는데, 나머지 팀원들끼리 잘 해주신 것 같다는 생각이 들었고, 팀원들끼리 기능 우선 순위를 정해주신 것도 잘 봤어요.. 감사합니다 ㅎㅎ..

---

마지막 한 마디

그리고 나머지 팀원분들끼리 KPT 방식으로 회고를 진행하신 것을 보았는데, 많이 공감이 되었다.
특히, 나의 자신감 부분이었다. 사실 지금까지 진행해왔던 프로젝트에서는 이렇게 체계적으로 진행해보지 못하였고,
같이 안드로이드 파트를 담당하게된 팀장님께서 솔직히 수준 높은 프로젝트들을 경험해보았고 너무 잘해보여서 기가 죽었던 부분이 있었다.
거기에다 아직 공부해야 될 부분도 너무 많았고, 민폐를 끼칠까 걱정이 앞섰던 것 같다. 이런 부분들을 다른 백엔드 팀원분들께서도 느끼고 계셨고, 팀장님도 느끼고 계셨다고 한다.

앞으로 프로젝트 진행하면서 민폐끼치지 않도록 공부를 열심히해서 이러한 걱정을 좀 덜고 자신감을 좀 회복하려고자 한다 ! ㅎㅎ
아자아자! 화이팅..

이거 학습일지 작성 마치고 진짜 공부해야지..

---

유데미 바로가기: https://bit.ly/3SFlXDy

유데미 STARTERS 취업 부트캠프 공식 블로그 보러가기: https://blog.naver.com/udemy-wjtb

💡 본 후기는 유데미-웅진씽크빅 취업 부트캠프 2기 - 프론트엔드&백엔드 과정 학습 일지 리뷰로 작성되었습니다.