반응형
Jake Seo
제이크서 위키 블로그
Jake Seo
전체 방문자
오늘
어제
  • 분류 전체보기 (715)
    • 일상, 일기 (0)
    • 백준 문제풀이 (1)
    • 릿코드 문제풀이 (2)
    • 알고리즘 이론 (10)
      • 기본 이론 (2)
      • 배열과 문자열 (8)
    • 데이터베이스 (15)
      • Planet Scale (1)
      • MSSQL (9)
      • 디비 기본 개념 (1)
      • SQLite 직접 만들어보기 (4)
    • 보안 (7)
    • 설계 (1)
    • 네트워크 (17)
      • HTTP (9)
      • OSI Layers (5)
    • 회고 (31)
      • 연간 회고 (2)
      • 주간 회고 (29)
    • 인프라 (52)
      • 도커 (12)
      • AWS (9)
      • 용어 (21)
      • 웹 성능 (1)
      • 대규모 서비스를 지탱하는 기술 (9)
    • 깃 (7)
    • 빌드 도구 (7)
      • 메이븐 (6)
      • 그레이들 (0)
    • Java (135)
      • 이펙티브 자바 (73)
      • 자바 API (4)
      • 자바 잡지식 (30)
      • 자바 디자인 패턴 (21)
      • 톰캣 (Tomcat) (7)
    • 프레임워크 (64)
      • next.js (14)
      • 스프링 프레임워크 (28)
      • 토비의 스프링 (6)
      • 스프링 부트 (3)
      • JPA (Java Persistence API) (5)
      • Nest.js (8)
    • 프론트엔드 (48)
      • 다크모드 (1)
      • 노드 패키지 관리 매니저 (3)
      • CSS (19)
      • Web API (11)
      • tailwind-css (1)
      • React (5)
      • React 새 공식문서 요약 (1)
      • HTML (Markup Language) (5)
    • 자바스크립트 (108)
      • 모던 자바스크립트 (31)
      • 개념 (31)
      • 정규표현식 (5)
      • 코드 스니펫 (1)
      • 라이브러리 (6)
      • 인터뷰 (24)
      • 웹개발자를 위한 자바스크립트의 모든 것 (6)
      • 팁 (2)
    • Typescript (49)
    • 리눅스와 유닉스 (10)
    • Computer Science (1)
      • Compiler (1)
    • IDE (3)
      • VSCODE (1)
      • IntelliJ (2)
    • 세미나 & 컨퍼런스 (1)
    • 용어 (개발용어) (16)
      • 함수형 프로그래밍 용어들 (1)
    • ORM (2)
      • Prisma (2)
    • NODEJS (2)
    • cypress (1)
    • 리액트 네이티브 (React Native) (31)
    • 러스트 (Rust) (15)
    • 코틀린 (Kotlin) (4)
      • 자바에서 코틀린으로 (4)
    • 정규표현식 (3)
    • 구글 애널리틱스 (GA) (1)
    • SEO (2)
    • UML (2)
    • 맛탐험 (2)
    • 리팩토링 (1)
    • 서평 (2)
    • 소프트웨어 공학 (18)
      • 테스팅 (16)
      • 개발 프로세스 (1)
    • 교육학 (1)
    • 삶의 지혜, 통찰 (1)
    • Chat GPT (2)
    • 쉘스크립트 (1)
    • 컴파일 (2)
    • Dart (12)
    • 코드팩토리의 플러터 프로그래밍 (4)
    • 플러터 (17)
    • 안드로이드 스튜디오 (1)
    • 윈도우즈 (1)
    • 잡다한 백엔드 지식 (1)
    • 디자인 패턴 (1)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

인기 글

태그

  • 서버리스 컴퓨팅
  • bean Validation
  • serverless computing
  • item8
  • 객체복사
  • pnpm
  • 슬로우 쿼리
  • 러스트
  • MSSQL
  • item7
  • 느린 쿼리
  • 추상 팩터리 패턴
  • 외래키 제약조건
  • 팩터리 메서드 패턴
  • 메이븐 골
  • rust
  • Pre-rendering
  • 자바스크립트
  • 작업기억공간
  • 메이븐 페이즈
  • 이펙티브 자바
  • Javadoc 자바독 자바주석 주석 Comment
  • 자바스크립트 인터뷰
  • 싱글턴
  • 이펙티브 자바 item9
  • 참조 해제
  • 디자인패턴
  • 싱글톤 패턴
  • 스프링 검증
  • prerendering
  • 자바 검증
  • next js app
  • 이펙티브자바
  • Java
  • 프로그래머의 뇌
  • 메이븐 라이프사이클
  • 빈 검증
  • 자바스크립트 면접
  • 자료구조
  • item9
  • 자바 디자인패턴
  • NEXT JS
  • 플라이웨이트패턴
  • 싱글톤
  • 자바
  • 토비의 스프링
  • Next.js
  • try-with-resources
  • 알고리즘
  • 도커공식문서

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
Jake Seo

제이크서 위키 블로그

설계

일론머스크의 설계 5단계 법칙

2022. 5. 7. 16:28

https://www.youtube.com/watch?v=t705r8ICkRw&t=831s

1. Make the requirements less dumb. Requirements are always dumb and lacking. It is especially dangerous if a smart person made the requirements, as they might not be questioned enough. Everyone is wrong some of the time. All requirements and constraint must be linked to a person who takes responsibility for the requirement (not a department). You must always be able to track down the author and someone who will defend it.
  -> 1단계: 요구사항을 덜 멍청하게 만들어라. 특히 똑똑한 사람들이 만든 요구사항이라면, 충분히 질문받지 못했기에 더 위험하다. 모든 사람은 때때로 틀린다.  모든 요구사항과 제약은 요구사항을 책임지는 (한 부서가 아니라) 한 사람에게 연결되어야 한다. 항상 작성자를 추적할 수 있어야 하고, 왜 그렇게 작성했는지 방어할 수 있는 사람을 찾아야 한다.

2. Try very hard to delete the part or process. If you are not occasionally adding things back in you are not deleting enough. There is a strong bias towards "let's add this in case we need it", but you can make just in case arguments for so many things. When doing something difficult you need to run tight margins. Because if you don't run tight margins you won't have a chance of achieving your goals. You can't hedge your bets
 -> 2단계: 일부 혹은 프로세스를 지우도록 열심히 시도하라. 가끔 무언가를 다시 추가하는 일이 일어나지 않는다면, 당신은 충분히 지우고 있지 않은 것이다. "필요할 때를 대비해 추가해보자" 라는 강한 성향이 있지만, '만일'이라는 이유로 너무 많은 것들을 추가할 수 있다. 어려운 일을 할 때는 아슬아슬하게 진행하게 될것이다. 아슬아슬하게 진행하지 않는다면, 목표를 달성할 기회가 없을 것이기 때문이다. 양쪽 모두에 배팅할 수는 없다.

3. Simplify or optimize
-> 3단계: 간소화하고 최적화하라. 그러나 반드시 3단계여야 한다. 가끔 똑똑한 엔지니어들은 존재않는 것이 나은것을 최적화한다.

4. Accelerate cycle time. You are moving too slowly. Move faster. Don't work on going faster before you have worked on the previous 3 steps.
 -> 4단계: 사이클을 빠르게 돌려라. 더 빠르게 움직여라. 그러나 앞의 3단계를 진행하기 전에는 더 빠르게 진행하지 마라.

5. Automate. This is the final step for a reason.
  -> 5단계: 자동화하라. 이것이 마지막 단계인데는 이유가 있다.

반응형
저작자표시 (새창열림)
    Jake Seo
    Jake Seo
    ✔ 잘 보셨다면 광고 한번 클릭해주시면 큰 힘이 됩니다. ✔ 댓글로 틀린 부분을 지적해주시면 기분 나빠하지 않고 수정합니다. ✔ 많은 퇴고를 거친 글이 좋은 글이 된다고 생각합니다. ✔ 간결하고 명료하게 사람들을 이해 시키는 것을 목표로 합니다.

    티스토리툴바