TeddyYeung Docs
Yeung's Docs
Yeung's DocsYeung's Docs
Yeung's Docs
Yeung's DocsYeung's Docs
  • Welcome
  • 내가 회사에서 배운 100가지
  • Leadership Playbook
    • 마인드셋
      • 진정한 리더십이란 무엇인가: 타이틀이 아닌 따르는 사람들
      • 한비자와 리더쉽
      • 지식과 신뢰, 나를 성장시키는 복리의 힘
    • 실천사항 (Action)
      • 부드럽고 명확하게 잘못을 지적하는 5단계
      • 리더가 된다면
      • 선수를 코치하지 마라, 팀을 코치하라
  • 커뮤니케이션
    • 실천사항 (Action)
    • 협상의 기술 [Never Split the Difference: Negotiating As If Your Life Depended On It]
      • 전술적 공감 (Tactical Empathy)
      • 교정 질문 (Calibrated Questions)
  • Android 공부
    • JetPack 컴포넌트
      • JetPack Compose
      • Understand Composable Functions
      • Understand State in Compose
      • Understand state hoisting in Compose
      • Kotlin의 Property Delegation과 Compose의 remember 함수 이해하기
      • Add a ViewModel to a Composable
    • 안드로이드 지식
      • What type of files does the Android Runtime (ART) execute?
      • Android SDK와 주요 도구들
      • Gradle, Version Catalog 소개
      • Maven 과 의존성
      • 람다 - 함수형 인터페이스(SAM 인터페이스)
      • Android에서 인텐트를 활용한 앱 간 통신
      • Android Kotlin에서 Retrofit을 활용한 네트워크 통신
      • 코루틴 개념 및 사용
      • Vector Drawable
  • Linux
    • 플러터에서 Shell Script로 Fastlane 두 개를 병렬 실행하는 방법
  • 알고리즘 & 자료구조
  • Computer Science
  • KeyWords
  • 네트워크 & 보안
    • 보안
      • 데이터 암호화 방식
      • 인증 보안 시나리오
  • 클린코드
    • 좋은 코드
      • [OOP] Flaw: Digging into Collaborators
      • [개발 원칙] 제로 오버헤드 원칙(Zero Overhead Principle)
      • [개발 원칙] 보이 스카우트 규칙(Boy Scout Rule)
      • Writing Testable Code by Miško Hevery
      • 좋은 코드의 기준 - 토스
    • 객체지향 원칙
      • [객체지향 원칙] 묻지 말고 말하라 TDA 원칙(Tell, Don’t Ask Principle)
      • [객체지향 원칙] 헐리우드 원칙(Hollywood Principle)
      • [객체지향 원칙] 명시적 의존성 원칙(Explicit Dependencies Principle)
      • [OOP] Flaw: Digging into Collaborators
    • 객체지향 생활체조 원칙 (Object Calisthenics)
      • 규칙 1 : 한 메서드에 오직 한 단계의 들여쓰기만 한다. (Only one level of indentation in a method)
      • 규칙 2 : else 예약어 금지 (Don't Use the ELSE Keyword)
      • 규칙 3 : 원시값과 문자열의 포장 (Wrap All Primitives And Strings)
      • 규칙 4: 일급 콜렉션 사용 (First Class Collection)
      • 규칙 5 : 한 줄에 한 점만 사용 (One Dot Per Line)
      • 규칙 6 : 축약 금지 (Don't Abbreviate)
      • 규칙 7 : 모든 엔티티를 작게 유지 (Keep All Entities Small)
      • 규칙 8 : 3개 이상의 인스턴스 변수를 가진 클래스를 사용하지 않는다. (No classed with more than two instance variables)
      • 규칙 9 : getter/setter/프로퍼티를 사용하지 않는다. (No Getters/Setters/Properties)
  • DDD 아키텍처
    • Value Objects (VO) 값 객체
    • 일급 컬렉션과 애그리게이트
    • DDD 플러터 코드 예제
  • CI/CD
    • Fastlane
      • [Fastlane] Fastfile 에서 Ruby 파일(functions.rb) 공유하는 방법
      • Fastlane 설치 및 환경 구성 가이드 (rbenv, Ruby, Bundler)
    • Aws
      • Mac mini -> Aws Ec2 인스턴스에 gitlab runner 설치
  • etc
    • 기술블로그 모음
  • 디자인 패턴
    • Abstract Factory Design Pattern
    • 함수형 프로그래밍
      • OOP vs 함수형 프로그래밍: 멀티스레딩환경에서Race Condition 비교
      • 함수형 프로그래밍 간단 예제
      • Railway-Oriented Programming (ROP)
      • Closure
  • 알아두기
    • 프로젝트에서 알게 된 상식
      • Homebrew로 설치한 Java, JAVA_HOME 설정 방법 차이점
      • GRPC
      • CPU 아키텍처에 따른 도커
  • 문제 해결 스킬
    • 맥킨지(Mckinsey)의 문제 해결 프로세스 7단계
  • Xcode & IOS
    • CocoaPods 기본 명령어 정리
    • CI/ CD Cache 를 통한 빌드 속도 개선
    • Xcode
      • Xcode 증분빌드
      • Xcode 동작원리
      • DerivedData
  • 아키텍처
    • 클린아키텍처
  • Flutter
    • 상태관리
      • Redux vs Bloc 상태 관리 패러다임 비교
    • Race Condition in Dart
    • RxDart - Handling Multiple Responses for the Same Event in a Single Bloc
    • flutter Rendering Mechanism
  • 디자인 UX / UI
    • 디자인 시스템
    • Figma Token to Code Generation
  • 모바일 개발
    • 딥링크 이해하기
Powered by GitBook
On this page
  1. 문제 해결 스킬

맥킨지(Mckinsey)의 문제 해결 프로세스 7단계

PreviousCPU 아키텍처에 따른 도커NextCocoaPods 기본 명령어 정리

Last updated 1 month ago