프래그먼트

• 이러한 프래그먼트 트랜잭션 관리
• 😭

  여러 개의 프래그먼트를 하나의 액티비티에 결합하여 창이 여러 개인 UI를 빌드할 수 있으며, 하나의 프래그먼트를 여러 액티비티에서 재사용할 수 있습니다

  프래그먼트는 항상 액티비티 내에서 호스팅되어야 하며 해당 프래그먼트의 수명 주기는 호스트 액티비티의 수명 주기에 직접적으로 영향을 받습니다. 예를 들어 액티비티가 일시정지되는 경우, 그 안의 모든 프래그먼트도 일시정지되며 액티비티가 소멸되면 모든 프래그먼트도 마찬가지로 소멸됩니다.

개발자도 정량적인 성과 측정이 가능할까?

• 참고: 개발자도 정량적인 성과 측정이 가능할까?
• 성과 지표를 내는 것이 어렵다고 생각하는 편이다
• 그럼에도 가능하다면?
  • 개인 보다는 팀
• 하지만 정확한 측정을 할 수 없다
• 그렇기에 신뢰 기반이 동작한다

반복

• 상대가 축하하고 있는 걸 봤다. 그들에게 말해주고 싶었다. 축하하는 동안 여전히 내가 싸우고 있었다는 사실을
• 이 문장이 와닿았는데
• 얼마 후 같은 사람이 같은 상황에서 똑같은 상황을 마주했다
• 잊지 않았어야하는 사실을 잊어버렸기 때문에
• 반복된다

react-native-builder-bob

• react-native-builder-bob
• 콜스택에서 RN 라이브러리, 모듈 cli로 뚝딱 해주는 오픈소스
• kotlin + swift 메뉴를 보고 혹해서 fabric으로도 제공해주나 봤지만
• 역시나 안된다는 사실 😆
• (세상에) 아니 근데
  • RN@0.73 부터 안드는 kotlin인거야!?!
  • 🚂

bun vs node

• 개인적으로 가장 관심 가는 이슈 아닐까
• 근데 또 문득 ㅋㅋㅋㅋ
• lint랑 test만 bun으로 돌려도 우리 프로젝트가 빨라진 개발 경험을 주지 않을까???
  • 🤔 근데 ts 읽을 수 있는건가?
  • 돌려보니 어느정도 되는듯하지만
    • warn: moduleSuffixes is not supported yet
    • RN 플랫폼 파일을 위해 사용하고 있는 이것을 아직 읽지 못한다
  • 이 옵션을 제외한 비교라서 정확할 수 없지만
    • bun 55초
    • yarn 125초
    • 정말 두배정도 차이난다
    • 완료 되지 않고 중간에 튕기는건가?

문제 해결

• 협업을 잘하는 개발자가 되어보자 - 프로그래머가 아니라 문제 해결사가 되자!

• 막연히 협업을 잘해야된다더라 보다는 개발자가 왜 협업을 잘 해야하는지, 그리고 어떻게 협업을 바라봐야 하는지

  • 구현을 잘하는 것이 개발을 잘하는 것 < 구현을 잘 하면서도 높은 품질의 코드를 계속 유지할 수 있도록 하는 것
  • 프로젝트의 규모가 커져도 일정한 퍼포먼스를 낼 수 있도록 좋은 구조를 유지하고 테스트 가능하게 코드를 작성하면서 코드 품질을 항상 신경을 쓰고자 하는것
  • 이것들을 지키려다보면 요구사항의 구현, 품질, 일정의 압박에 쫒기게 됨

• 시장은 일반적인 개발자의 생각보다는 고품질의 코드를 중요하게 생각하지 않는다

  우리가 어플리케이션이나 서비스들을 선택을 하는 이유는 코드를 잘 만들었기 때문이지 않습니다. 심지어 개발자들조차 코드가 공개되어 있는 오픈 소스의 라이브러리를 선택할 때 코드를 열어보고 좋은 코드 품질을 가지고 있기 때문에 선택하지 않습니다. 나에게 그 라이브러리가 얼마나 필요하고 유용하게 만들어졌는지에 따라서 선택을 하게 됩니다.

• 코드의 가치는 코드 자체가 아니라 그 코드로 어떤 가치를 만들어내느냐 하는 것

  • 결국 개발을 통해서 무엇을 만들었고 그게 얼마나 큰 가치를 만들어 냈는가
  • 코드를 작성하지 않더라도 더 나은 가치, 문제를 해결해냈다면 좋은 것이다

• 점점 더 큰 가치를 추구하다보면 결국 비즈니스가 커짐에 따라 코드의 복잡도가 올라가고 품질을 높여야만 한다

  • 비즈니스 복잡도와 함께 올라가는 챌린지
  • 레벨업

• 그러나 비즈니스 가치와 개발자 가치의 충돌이 발생

  • ex) A라는 비즈니스 요구사항에 대해 코드의 품질, 안정성을 높이기 위한 가치 충돌
  • 오늘도 개발자가 안된다라고 했다

• 돈을 벌지를 못했는데 코드를 잘 작성했고 구조를 잘 만들었다고만 해서 고성과로 평가를 해주지는 않습니다

  • 슬픈 사실
  • 비즈니스 가치를 올리기 위한 협업이 필요한 순간
  • 요구사항, 일정, 품질 삼각형의 조율
  • 내가 만든 가치를 더 올릴 수 있도록 나를 도와줄 사람이 필요하고, 나 역시 그들을 도와서 비즈니스의 가치를 구현하고 만들어 낼 수 있어야 합니다

• 내가 만드는 비즈니스의 가치를 높이기 위해 나와 함께 하는 사람을 도와주고 도움을 받고 문제를 해결하는 모든 과정 또한 개발입니다

  • 코드를 작성하지 않았더라도 문제 해결을 통해 가치를 높이는 일이라면 이 또한 얼마나 아름다운가

• 결국 모두가 비즈니스 가치를 높이기 위한 목표를 가지고

  • 현재 마주하고 있는 문제를 해결 하기 위함
  • 같은 문제를 각자의 전문성으로 각자의 시각으로 바라보게 되면 신기하게도 문제를 풀 수 있는 방법을 새로운 방법을 찾게 된다

• 성장을 하다 보면 가치관도 사고도 함께 성장합니다

• 나에게 질문하고 요청하는 것이 부담스럽지 않았으면 좋겠다

모든 것은 문제 해결을 위함

• 참고: 상위 1% 엔지니어의 7가지 간단한 습관
• 위의 내용과 같은 목적으로
• 모든 것은 문제 해결을 위함
  • 엔지니어링은 문제를 해결하는 것
  • 코드를 작성하는 즐거움은 있지만...
  • 문제를 해결하기 위한 코드를 작성하는 것에 의미가 있다
  • 일관된 스타일 가이드를 사용하면 팀과 코드베이스 모두 더 쉽게 확장할 수 있음
  • 새로운 관점은 종종 코드를 더 명확하게 만들거나 이전에는 생각하지 못했던 새로운 접근 방식을 제공하는 데 도움이 될 수 있음
• 가장 어려워 보이는 것
  • 적어도 한 가지 분야에 대한 깊은 도메인 지식을 가짐
  • 자신을 자주 그리고 적절하게 마케팅함