Week 4 - 역량강화 3주차 😣

---

감기 몸살 때문에, 지난 주 금요일에 결석에 주말에 공부도 별로 하지 못해서 너무 스트레스 받았다 😑 앞으로 환절기에 일교차도 심한데다가 아침에 일어나는 것도 너무 힘들고, 일을 미루지말고 빨리 마무리해서 일찍 자고 몸 관리를 잘해야겠다. ㅜ_ㅜ 😂

📝 교양강화

[애자일 마스터]

---

지금까지는 애자일이 무엇인지, 애자일 프로젝트는 어떻게 진행되는 지? 중요한 것이 무엇인지 파악해 보았다면,
이번 주 애자일 마스터 9장 ~ 12장에서는 " 어떻게 소프트웨어로 구현할 것인지 " 에 대해서 알아보는 시간이었다.

9. 이터레이션을 이용해 어떻게 일을 처리하는가 ?

우리는 이터레이션을 통해 고객에게 매 주(매 이터레이션)마다 가치를 전달해야 한다.

매주 가치를 전달하는 방법

1. 가볍지만 정확하고 필요한 정보를 제때 제공할 수 있는 분석
2. 개발에 관련된 실천법은 반드시 실행되어야 함
3. 테스트는 개발 과정 중에 빈틈없이 이루어져야 함

1. 가볍지만 정확하고 필요한 정보를 제때 제공할 수 있는 분석

   • 얼마나 상세하게 해야 할 것이냐가 아닌, 팀과 프로젝트의 종류에 따라 적합한 분석(적당한 분석)을 해야하고
   • 사용자 스토리에 따라 깊이 있는 분석을 사용자 스토리 개발 직전에 해야 한다. (적시 분석)
   
   

2. 개발에 관련된 실천법은 반드시 실행되어야 함

   • 순서도, 페르소나를 이용하여 고객의 요구를 충족할 수 있도록 이해하는 것이 중요.
   • 자동화 테스트, 설계를 지속적으로 개선, 코드를 지속적으로 통합.

3. 테스트는 개발 과정 중에 빈틈없이 이루어져야 함

   • 매 이터레이션마다 테스트를 통해 잘 작동하는 소프트웨어를 고객에게 전달한다.
   • 보통 제품을 출시하기 이전에 사용자 인수 테스트를 진행하게 되는데, 이러한 사용자 인수 테스트마저 필요하지 않을 정도로
     테스트를 더 자주, 지속적으로 시행하도록 하자.

10. 이터레이션의 작용, 회의와 소통 방법

• SPM - 다음 이터레이션을 준비하는 회의

• 쇼케이스 - 지난 이터레이션 작업했던 내용을 고객에게 피드백을 얻는 자리.

• IPM - 다음 이터레이션 작업을 위해 계획을 세우는 회의

• 회고 - 짧은 시간 동안 팀이 정기적으로 모여서 잘하고 있는 것은 무엇인지, 그렇지 못한 것은 무엇인지에 초점을 맞춰 이야기 하는 것.

• 일일 스탠드업 - 지난 작업의 결과, 오늘 할 일, 공유사항을 공유하며 팀원들과 논의하는 자리.

이러한 5가지 방법들을 팀과 프로젝트의 종류에 따라 적절하게 사용하여 적절한 방법으로 일하는 것이 좋다.

11. 작업환경 갖추는 법

• 인셉션 덱 - 고객이 누구인지, 프로젝트에서 성취하는 바가 무엇인지 등을 나타내는 질문과 그에 대한 답

• 릴리스 상황판 - 스토리가 완성되었는지, 남아있는 스토리는 무엇인지

• 스토리 보드 - 개발 현황(만들어진 기능들과 완성된 기능) 제시

• 번다운 차트 - 팀의 생산성을 수치로 제공하고 현실적인 프로젝트 기간 제시

이러한 4가지 도구들을 이용해 작업환경을 갖췄을 때, 이해관계자들에게 적절한 기대치를 갖게 해주고 현실을 직시하는데 결정적인 역할을 할 것!

12. 단위테스트

💡 작은 메서드 단계의 테스트.

• 개발자들이 소프트웨어를 변경할 때, 자신들의 의도와 맞게 고쳐졌는 지 확인하기 위해 사용한다.

• 결과가 기대하는 대로 나오는 지 확인하고 싶을때 사용하도록 하자.

  • 자동화되어 실행하기 쉬운 단위 테스트의 가치는 헤아릴 수 없을 만큼 좋을 것이다.

• 비즈니스 로직에서부터 고객의 정보가 데이터베이스에 잘 저장되고 있는지 확인하는 기능 등 애플리케이션 전체를 아우르는 테스트.

• 피드백을 즉각적으로 준다.

  • 새로 추가된 코드가 틀린 것인지, 조금이라도 변화가 있을 때마다 즉각적으로 확인할 수 있다.

• 회귀테스트 비용을 낮춰준다.

• 디버깅 시간을 획기적으로 줄여준다.

  • 코드를 한 줄, 한 줄 읽는 디버깅보다 단위테스트를 통해서 정확히 시스템의 어느 부분에 문제가 발생하였는 지 알아낼 수 있다.

• 우리가 자신있게 배치할 수 있게 해준다.

  • 자동화된 테스트가 든든히 받쳐주고 있다면, 모든 것이 완벽하다고 보장하지는 못하더라도, 우리가 생각하기 힘든 복잡한 부분을 테스트 할 여력을 우리에게 준다.

느낀점

---

이번 애자일 마스터 발표 범위를 읽고 정리하게 되면서, 앞으로 팀 프로젝트에 있어 어떤 식으로 작업을 하면 좋을 지, 팀원들 간 소통은 어떻게 진행하면 좋은 지에 대해서 생각해보게 되었고, 어떻게 프로젝트를 계획하고 구현할 지 참고할 수 있었던 시간이었다.

매 번 느끼지만, 애자일 마스터 를 읽게 되면서, 애자일에 대해서 배우고, 내가 직접 과거에 경험했던 것이 애자일 사례라는 것, 앞으로 프로젝트에 어떻게 적용하면 좋을 지, 프로젝트 중 어려운 상황을 겪게 되면 어떻게 대처하면 될 지 등등 많은 것을 배울 수 있는 시간이었다.

📝 전공강화

[코틀린 완벽 가이드]

---

이번 전공강화 발표 주제로 우리 팀이 정리하게 된 주제는 크게 제네릭 , 애너테이션과 리플렉션 , 위임 이었다.

나는 제네릭 의 정리와 발표를 맡게 되었던 점도 있고, 그동안 제네릭에 대한 개념이 애매했던 부분도 있어서
제네릭 에 대해서 정리했던 부분들을 작성해보고자 한다.

그리고 ViewModel 에서 자주 쓰게 되는 위임 부분도 정리를 해보는 것도 좋겠다는 생각이 든다.

제네릭의 불변성

val str : String = ""
val any : Any = str

Any 는 최상위타입이므로, String 타입의 변수 str 을 담을 수 있다.

public inline fun <T> MutableList( ... ): MutableList<T> { ... }

val strs: MutableList<String> = mutableListOf()
val anys: MutableList<Any> = strs   // Error : Type mismatched.

하지만, 이와 같은 제네릭의 클래스나 인터페이스에서는 타입의 super , sub 타입 관계를 만족하지 않는다.
MutableList<Any> 가 MutableList<String> 을 담을 수 없다.
이러한 것이 제네릭의 불변성이다.

자바 와일드카드

위와 같은 제네릭의 불변성으로부터 고안된 자바 와일드카드<?>, 코틀린에서는 스타 프로젝션<*> 으로 사용한다.

void printCollection(Collection<?> c) {
    for (Object e : c) {
        System.out.println(e);
    }
}

printCollection 은 컬렉션을 출력하는 함수.

Collection 의 요소들의 타입이 ? 와일드카드로 되어있어 정확히 무슨 타입인지는 유추할 수 없지만,
자바에서는 최상위 타입인 Object 타입의 변수에 담을 수 있어, 출력하는데에 컴파일 에러가 발생하지 않는다.

@Test
void genericTest() {
    Collection<?> c = new ArrayList<String>();
    c.add(new Object()); // Error : Type mismatched.
}

하지만, 다음과 같은 코드에서는 문제가 발생한다.

위에서 말한 것과 같이, Collection 의 요소들은 타입이 확정되지 않았다.

따라서 특정해서 Object타입의 객체를 담을 때, 타입이 일치하지 않는 경우의 수를 컴파일러가 예측한 것이다.

상한 경계 와일드 카드

// Java
interface Collection<T> ... {
  void addAll(Collection<? extends T> items);
}

• 와일드카드 ? 의 최상위 타입을 T로 한정한 것이다.

  • T 이거나 T 의 자손 타입

• Collection 의 아이템을 하나 꺼낸다고 가정하자. (read)

  • 아이템은 T이거나 T sub type 이므로, T 라는 타입 변수에 아이템을 담았을 때 읽을 수 있다.

• Collection 에 아이템을 추가한다고 가정하자. (write)

  • 아이템이 ? 와일드 카드이므로, 정확히 어떤 타입인지 알아야하거나 ? 의 sub type 일 때 더할 수 있다.
  • T 타입을 추가할 수 있다고 오해할 수 있지만, ? 가 정확히 T 이라면 추가할 수 있겠지만, 그 와일드카드의 타입을 정확히 확정할 수 없고 알고보니 와일드카드가 T sub type 이라면 추가할 수 없다는 것이다.
  • 따라서 추가할(write) 수 없다.

• read - only

• 코틀린에서는 <out T> 와 같다.

하한 경계 와일드 카드

interface Collection<T> ... {
  void addAll(Collection<? super T> items);
}

• 와일드카드 ? 의 최하위 타입을 T로 한정한 것이다.

  • T 이거나 T 의 조상(super) 타입

• Collection 의 아이템을 하나 꺼낸다고 가정하자. (read)

  • 아이템은 T이거나 T super type 이므로, T 라는 타입 변수에 아이템을 담을 수 없다.

• Collection 에 아이템을 추가한다고 가정하자. (write)

  • 아이템이 ? 와일드 카드이므로, 정확히 어떤 타입인지 알아야하거나 ? 의 sub type 일 때 더할 수 있다.
  • T 타입을 추가할 수 있다. 이유는, 와일드카드의 최하위 타입이 T라는 것이므로, 무조건 T를 담을 수 있다는 것이다.
  • ? 가 T 타입 변수를 박싱할 수 있다.
  • 따라서 추가할(write) 수 있다.

• write - only

• 코틀린에서는 <in T> 와 같다.

스타 프로젝션

• <*>
• Java의 와일드카드인 <?> 에 대응. Unknown Type
• 일반적으로 Kotlin의 <out Any?> 와 동일하게 동작.
  • Java의 와일드카드 : Object or Object sub type
  • Kotlin : Any or Any sub type → <out Any?>

// <out Any?>와 같은 동작.
val anyList : List<*> = listOf(1,2,3)

fun printValues(values: ArrayList<*>) {
    for (value in values) {
        println(value)
    }
    values[0] = values[1] // Error : Type mismatched.
}

List 의 요소가 스타 프로젝션 * 이므로, Any 이거나 Any sub type 이라는 것인데
요소들의 정확한 타입을 알 수 없어서 for문의 마지막 줄에 컴파일 에러가 발생하는 것.

프로퍼티 위임

대표적으로 프로퍼티 위임이 자주 쓰이기 때문에 정리하고자 한다.

프로퍼티 위임

• 특정 객체에 대한 프로퍼티의 set과 get 메서드의 호출을 위임 가능
• getValue(), setValue() 메서드 필요
  • 읽기 전용일 경우(val) : getValue()
  • 읽기/쓰기 가능일 경우(var) : getValue(), setValue()
• by 키워드를 이용하여 위임할 객체를 프로퍼티 뒤에 명시

일반적인 위임 프로퍼티 구조

// 위임 관례를 따르는 클래스는 getValue, setValue 메소드를 제공해야함
class Delegate {
    // getValue는 게터를 구현하는 로직을 담음
    operator fun getValue(...) { ... }
    // setValue는 세터를 구현하는 로직을 담음
    operator fun setValue(...) { ... }
}

class Foo {
    // by 키워드는 프로퍼티와 위임 객체를 연결
    var p: Type **by** Delegate()
}

Foo 클래스의 p프로퍼티는 Getter , Setter 의 구현을 다른 Delegate 객체에게 위임한다.
Delegate 클래스의 인스턴스를 위임 객체로 사용한다는 것이다.

대표적으로 ViewModel을 생성할 때 쓰인다.

예제 코드를 살펴보자.

private val viewModel: HomeViewModel by viewModels { ViewModelFactory(requireContext()) }

viewModel 이라는 프로퍼티의 생성을 viewModels 에게 위임하는 것이다.

파라미터로 ViewModel 생성 코드를 전달한다.

class ViewModelFactory(private val context: Context ): ViewModelProvider.Factory {

    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        ...
    }
}

Udemy 온라인 강의

---

이번 주, 배웠던 내용에서 가장 중요하다고 생각했던 부분은 앞으로 프로젝트를 진행하면서 주로 사용하게 될 Json Object 를 처리하는 Gson 과 앱 아키텍처 구조 및 ViewModel , LiveData , Repository 구조인 것 같다.

학습일지에는 작성하면 내용이 길어질 것 같아 개인적으로 블로그에 내용을 정리해보려고 한다.

앞으로 제작하게 될 안드로이드 앱 아키텍처 구조 는 Google 공식문서의 앱 아키텍처 가이드를 참조하여 작성해보았고, 나머지도 블로그에 작성하며 정리해가며 한 번 더 학습을 진행해보고자 한다.

아무래도 강의에서는 빨리 빨리 넘어가는 느낌도 있고, 한 번 더 정리하면서 완전히 체화시키도록 하려고 한다.

마무리

---

점점, 시간이 지날 수록 개발 역량을 강화해야 한다는 생각이 든다.
계속해서 역량 강화 기간을 거듭하며 시간을 효율적으로 사용하는 것에서는 나아지고 있지만, 나태해지는 것도 있기 때문에 속도가 나지 않는 것 같다... ㅠ 좀 더 각성해야겠다는 생각이 든다 💪💪

그리고 이번 팀 프로젝트 회고를 통해서 다른 팀들에 비해서 문서화가 잘 진행이 되지 않았고, 레퍼런스 사전 조사 등, 작은 회의 및 사소한 대화내용까지 포함하여 기록해야 할만한 것들을 선별하여 좀 더 기록에 습관을 들여야겠다는 생각이 들었다.

그리고 이번 주에는 프로젝트에서 자신감을 얻기 위해서도 있고, 아직 프로젝트를 개발할 역량이 부족하다고 생각하여 프로젝트를 진행할 때 문제 없도록 전공강의 위주로 시간을 사용했다.

---

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

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

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