super.init(version=4) 후기

소개

DevFest, Studyjam, WTM << 다양한 행사가 있다.

안드로이드 주니어, 시작점에 서기까지 : 임준섭

소제목 : 취업준비기에 대한 회고록

다소 뻔한 이야기 ex).. 클론코딩, 프로젝트 완료 없음

• 실패에 안주하지 말고 준비하고 또 준비하자.
• 똑똑하게 공부해야한다. 자신의 처한 상황에 맞추어 능동적으로 공부하자.
• 자기객관화, 비판적 사고 자신이 하고 있는 작업이 옳게 가고 있는가 확인이 필요

How to ?

• 자신이 원하는 도메인에 맞는 회사에 지원하자.
  • 기업이 사용하는 기술에 맞추어 포트폴리오 작성
  • 이 기술을 사용하는 이유?,
    • 단점과 장점, 이 기술 전의 기술 등등 파고 들어가자. (Keyword)
    • 스터디, 자신이 아는것을 남에게 설명하는 것이 중요하다.
    • 꾸준히.. 자존감 상승!

궁금한 점

이러한 문제점을 알고 깨달음을 얻는데 까지 가장 큰 요인은 ?

API 통신, Retrofit 대신 Ktor 어떠신가요? : 유광무

• Retrofit
  • 설명.
    • JVM 위에서 돌아간다. 멀티 플랫폼 환경에서 적합하지 않음.
• Ktor
  • 설명..
    • kotlin 100%, 멀티플랫폼 적합

WHY Ktor ?

• Retrofit2 과 비교해 무척 간단하게 데이터를 가져올 수 있다.
• Retrofit2 과 비교해 data class 에 @seri .. annotation 을 추가해야 한다.
  • json(). xml() 등 함수가 있는 것으로 원하는 형식을 가져올 수 있다.
• Retorift2 과 비교해 Interface(Service) 를 만들 필요가 없다.
• Retrofit2 과 비교해 response 필드가 일부 null 일 경우 정상적으로 실행된다. ktor 에서는 에러가 난다. (무결성)
  • ex) id = “null" retrofit : 성공 ktor : error
• Ktor 에서는 Serialization 필터링이 가능하다.
  • isLenient, ignoreUnknownKeys ..
• Retrofit2 과 비교해 Ktor 은 Header 을 따로 인터셉터 오버라이딩 안해도 사용이 가능하다.
  • header(“ “, “ “)
• Retroft2 과 비교해 Ktor 은 간단히 Mock 을 만들어 test 가 가능하다.

궁금한점

• Retorift2 과 비교해 Ktor 이 가지고 있는 단점은?
  • 정형화된 패턴이 필요하다.
    • 발표자분의 회사에서는 적극적으로 사용
  • 사용성이 너무 무분별해 의존성 역전 관계가 일어날 수있다.
  • 회사에서 사용했을 때 고려해야할 점
    • 1. 테스트 를 일일히 해야한다.
    • 계기가 있어야한다, 버전에 따라 바뀌는게 많다. (비용 상승0)

선언형 UI가 대세임을 “선언”합니다 : 이현우

Compose 왜 사용해야 할까?

• 개발자 휴먼 에러 가능성 내려가고, 효율성은 올라간다.

개념

• Recomposition
  • RN (Redux?)
  • 뜻 : 데이터가 바뀌는 과정
  • @Stable << 컴파일러 에게 리컴포지션이 많이 된다는 것을 알림 ?
  • @Imuutable ?
  • State Hoistiong ?
• Side Effect ?
  • UI 렌더링 과 서버 통신은 어떤식으로 처리 ?
  • UI 관련된거 아니면 Side Effect
  • 화면이 내려갈 때의 액션을 지정할 수 있음 << 예시??
    • LaunchedEffect : 처음 호출할 때 ?
      • 처음 화면을 호출할 때 : init
        • activity : onCreate(), viewModel: init()
    • DisposableEffect
• 결론
  • F(STATE) = UI

지라 자동화 어디까지 가능할까요? : 이하나

WHY 자동화 ?

• 개발의 생산성을 위해

How ?

• 필요한점 : 충분한 권환 필요, 무엇을 자동화?, 뜻이 같은 팀원
• JQL & smart value, Jira authmation, github Octokit & AWS Lambda, Slack Webhook << 이 것으로 자동화 가능.
• 기능
  • 이슈 상태 변경
    • 티켓 생성 → branch 생성
    • pr merge → 티켓 상태 변경
    • Jira 에서 branch 를 만듦으로 추척이 가능한게 아닌, 번호로 트리거함.
  • 알림
    • 알림
      • ?? (놓침)
• 이미 있는 자동화 Plugin
  • What
  • Hpw

장 단점

• 장점
  • 반복작업 줄어듦.
  • 커뮤니케이션 비용 줄어듦
• 단점
  • 충분한 테스트가 필요, 비용 상승 및 위험부담이 크다.
  • 충분한 논의가 필요.
• 어려웠던 점
  • 기본 베이스는 문서가 잘 되어 있지만, 기능 추가/수정 할 때 러닝커브가 있음.

궁금한 점

• QA 관점 vs 개발자 관점
  • 둘다 사용 가능.
• 베포메일 자동화도 가능하나요 ?
  • 발표자분의 회사는 Slack 으로 알림.
  • 가능하다
• 실제로 적용하는 것을 알려주셨으면 좋겠다 (실습)
  • 설명만 들어서는 잘 체감이 안된다.

질의응답

• Q : 테스트 했나요?
• A : 했어요.
• Q : 컨플릭 어떻게 해결했나요?
• A : 손으로 일일이.. 했어요.
• Q : 오토매틱 사용할 때, 실 환경이랑 다르면 어떡하나요?
• A : 감사 log ? 로 확인할 수 있다.
• Q : 적용하는 데 까지 얼마나 걸렸나요?
• A : 한, 두 달 정도. 안정화는 2주
• Q : 비용이 얼마나 드나요?, 적용하는데 까지 생산성이 어떻게 바뀌었나요?
• A : 적용 어렵지 않음, 업무 외적으로도 적용함

개발자의 글쓰기 Design Document 작성기 : 정세희

• Design Document == 개발 설계

단계

• Context and Scope
  • 배경 (문제 정의, 설계 목적 등등)
• Actual Design
  • 설계, 설계 분석, 설계 실패 해결 등등
• Review
  • 다른 팀원분들게 리뷰
    • 고려할점
      • 독자를 고려
      • 구현이 아닌 설계, 뼈대륾 만드는 게 중요, 코드 최대한 x, 이해하기 쉽게

단계 개선

• Context and Scope
  • 어려울 것 같은 용어는 미리 설명하자.
  • 코드 보단 최대한 문장으로 작성하자. << 개발 외적의 업무도 이해해야함.
• Actual Design
  • 다이어그램, 플로우 차트. 시퀀스 다이어그램 등을 이용

결론

• 남에게 이해해야함.
• 피드백 수월
• 문서와 코드의 간격이 줄어듦

질의응답

Q : 문서와 다르게 개발할 경우 어떻게 해결하나요?

A : 문서를 수정하고, 애초에 리뷰를 다 같이 하기 때문에 그럴일이 없다.

Q : 얼마나 시간이 걸리는지, 일정 산정에 Design Document 가 포함되는지

A : 대략 1주일, 일정 산정에 포함.

Q : 결함 발행 시, 새로운 문서를 만든가?, 아니면 코드레벨에서 수정하는가

A : 핫픽스 진행 시 코드레벨 에서 선 수정 후 문서 를 갱신

궁금한 점

• Design Document 에 과몰입하면 일정에 맞추기 어렵지 않을까?
  • 개발 후의 피드백 보단 설계에 피드백에 일정에 더 효율적으로 관리할 수 있다.
• 신입한테도 이 작업을 시키나요?
• Design Document 에 일정이 너무 딜레이 되면 어떻게 하나요?
  • 문서를 작성하지 않는다?
  • 시니어 분이 작성한다 ?

인생게임 ver.모바일 개발자

인생 스토리..

필기.. 필기

회고록..

• 장점을 극대화 하자, 단점 보완
• 불확실 한 것을 모두 막을 수 없다. 잘 대비하자.