뻔뻔한블로그

Topic 15 추정

기억할 내용

- 추정하는 법을 배우고 측정 능력을 계발하여 ~ 직관적으로 이것이 가능한지 판단할 수 있게 된다. 94p
- 얼마나 정확해야 충분히 정확한가? ~ 무언가를 끝내는 데 근무일 기준으로 약 130일 동안 일해야 한다고 말하면 드는 사람은 실제 소요 기간이 추정과 상당히 비슷하리라 기대할 것이다. 하지만 "아, 대략 6달 정도 걸리겠군요"라고 말하면 지금부터 5~7달 사이 언젠가쯤 끝날 것 이라 여길 것이다. 두 숫자는 같은 기간을 이야기하지만 '130일'은 실제 여러분의 느낌보다 더 정확도가 높으이라는 인상을 풍길 수 있다. 95p
- 추정치는 어디에서 나오는가?
1. 그 일을 해본 사람에게 물어보라
2. 무엇을 묻고 있는지 이해하라
3. 시스템의 모델을 만들어라 ( 기본적인 것만 갖춘 개략적인 모델을 만들어 보라, 조직이 개발하는 동안 사용할 발판, 밑그림이 될것이다.) 97p
4.모델을 컴포넌트로 나눠라
5. 각 매개 변수에 값을 할당하라 (결과에 가장 큰 영향을 미치는 매개 변수를 찾아서 이 매개 변수의 값을 최대한 정확하게 산출해 내는 것이다.) 98p
6. 여러분의 추정 실력을 기록하라 (나중에 이 값이 실제 결과에 얼마나 가까웠는지를 평가해 보면 정말 좋을 것 이다.)
- 프로젝트 일 추정하기
1. 미사일에 페인트 칠하기(숫자 하나로 대답해야만 하는 상황이 아니라면 숫자 하나가 아니라 여러가지 시나리오로 추정한다.)
2. 코끼리 먹기(단계를 작은 단위로 나누어 점증적으로 )
- 계산한 추정치를 기록으로 남겨라. 그리고 각 추정치가 얼마나 정확했는지 기록으로 남겨라. 오차가 50%이상이라면 잘못된 추정치를 내게 된 원인이 무엇인지 찾아보라
 

느낀 점

 실제로 작업을 할때는 일정을 추정하기가 쉽지 않았다. 작업을 진행하다가 예상치못한 요인 코드뿐만 아니라 외부 요인까지..내기 해보진 않은 일이라면 더더욱 어려웠다. 여기서 제시한 방법을 활용하며 일정산정 방법을 가다듬고 결과에 따라 정확도가 얼마나 떨어지는지 점검해보는 연습을 해야겠다. (뭐든지 사실 생각만 하는 것보다는 실제로 적용해보아야 안다.)

Topic 13 프로토타입과 포스트잇

기억할 내용

-  프로토타입 ~ 위험 요소를 노출시킨 후, 이를 매우 저렴한 비용으로 바로잡을 기회를 얻는 것이다. 80p

-  프로토타입은 빠르게 개발할 수 있다.  ~ 여러분에게 당장 중요하지 않은 세부사항이라면 추후에 사용자에게 매우 중요해질지도 모르지만 일단 무시하면서 코딩할 수 있다.

- 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토 타입을 만들고 있는 게 맞는지 자문해 보라.

- 프로토 타입 대상은 ~ 증명되지 않았거나, 실험정이거나, 의심이 가는것, 마음이 편하지 않은 것 모두가 프로토타이핑의 대상이 될 수 있다. 81p

- 프로토타이핑의 가치는 생산한 코드에 있는것이 아니라 이를 통해 배우는 교훈에 있다.

- 아키텍처를 프로토타이핑할 때는 코드를 작성하지 않고 화이트보드, 포스트잇, 인덱스카드 등을 사용해도 된다. 83p

- 프로토타팁임을 모르는 사람에게는 오해를 살 정도로 매력적일 수도 있기 때문에 ~ 이 코드는 폐기할 것이고, 불완전하며, 완성할 수 없다는 사실을 분명히 주지시켜야 한다.

느낀 점

- 이책에서 말하는 예광탄, 프로토타입 각각 장단점이 있고, 요구되는 목적, 특성에 따라 선택이 필요하다. 나는 평소에 프로토타입이라고 생각했지만 예광탄에 가까운 작업을 선 작업을 했던 것 같다. 프로토타입은 없어질 코드이며, 코드는 남지 않고 작업하면서 이를 통해 배우는 교훈에 있다는 말이 포인트라고 생각했다. 

Topic 12 예광탄

기억할 내용

- 프로젝트를 개발할때는 ... 수 많은 미지의 것과 맞닥트리게 된다. 72p

- 어둠 속에서 빛을 내는 코드 : 탄환이 순식간에 목표물에 도달하기 때문에 기관총 사수는 즉각적인 피드백을 얻을 수 있다. 73p

- 요구 사항으로 부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무엇인가를 찾아야한다. 

- 예광탄은 한번 쓰고 버리는 코드를 만드는것이 아니다. 75p

- 모든 기능이 들어있지 않을 뿐 / 시스템을 구성하는 요소를 모두 연결해 놓은 후 목표물에 얼마나 근접했는지 확인할 수 있으며. 조정도 가능하다

- 변경 요청과 기능 추가 요청은 언제나 게속 들어오기 마련이다. 76p

- 예광탄 장점 : 1. 사용자가  뭔가 작동하는지 일찍 볼 수 있다. 2. 개발자가 들어가서 일할 수 있는 구조를 얻는다. 3. 통합 작업을 수행할 기반이 생긴다. 4.보여줄 것이 생긴다. 5.진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

- 예광탄 vs 프로토타입 : 예광탄은 기능은 없지만, 완결된 코드이며, 골격이다. 프로토타입은 예광탄을 발사전에 수행하는 정찰이나 정보 수집과 같다. 79p

느낀 점

이번 내용으로 예광탄은 프로젝트 작업을 시작할때 골격을 만드는 시스템구조와 같다고 느꼈다. 프로토타입과 혼동될 수 있지만. 이 둘은 다르며, 장단점을 가지고 있다. 나는 예광탄은 작업을 시작하면 꼭 필요한 작업이라고 생각이들었다. 먼저 골격을 만든 후 살을 (기능) 붙이는 방법이 여러모로 큰 장점을 가지고 있다고 생각했다.

Topic 11 가역성

기억할 내용

- 당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다. 66p

- DRY원칙, 결합도 줄이기, 외부 설정 사용하기를 따른다면 중요하면서도 되돌릴 수 결정의 수를 가능한 줄일 수 있을 것이다.

- 되돌릴 수 없는 결정을 줄여야 하는 까닭은 우리가 프로젝트 초기에 늘 최선의 결정을 내리지 못하기 때문이다. 68p (많은 외부요인)

- 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

- Tip18 최종 결정이란 없다. 69p

- 유연한 아키텍처 : 아키텍처, 배포, 외부 제품과의 통합 영역을 유지하는 데에도 관심을 기울일 필요가 있다.

- 누구도 어떤 미래가 펼쳐질지 알 수없다. 70p

느낀 점

프로젝트를 진행하다 보면 예상치 못하는 이슈가 생기기 마련이다. 단순히 코드설계에서만 생기는 것이 아닌, 외부요인들 언제 어디서나 나타나게 된다. 이번 주제에서는 이런 예상치 못한 일들이 생긴다면 그때 어떻게 효율적으로 복귀할 수 있을까, 그리고 왜 그렇게 해야만 하는가를 설명해 주는 내용이었다. 지금까지 거의 반복된 내용이라면 ETC, DRY원칙을 다시 한번 중요하다고 느꼈다. 

• 기억할 내용
  • '직교성' 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다.
  • 비직교적 예시 => 헬리콥터 조종
  • TIP.17 관련 없는 것들 간에 서로 영향이 없도록 하라
  • 직교성의 장점
    생산성 향상 => 자족적인 컴포넌트들을 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 쉽다.
    리스크 감소 => 위험의 크기를 감소시켜준다. (코드 격리, 테스트 용이 등)
    계층 구조적 설계는 모듈 간에 의존성이 폭증할 위험을 줄인다.
    '특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?'
    코딩 => 코드의 결합도를 줄여라, 전역 데이터를 피하라, 유사한 함수를 피하라
  •  자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라. 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라(리팩터링)
  • 단위 테스트를 빌드하고 실행하기 위해 어떤 작업이 필요한가? 나머지 시스템 중 상당 부분을 불러와야 하지는 않는가? 만약 그렇다면 모듈과 나머지 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻이다.
• 느낀 점
  • 이번 파트에서는 많은 부분에 공감이 됐다. 이미 작업이 끝난 코드에 새로운 기능이 추가될 때나 변경이 될 때 많은 부분을 고려하며 작업을 해야 했었던 경험, 특정 부분을 바꿨을 때 예상치 못한 다른 곳에서 문제가 발생했던 경험, 모듈, 컴포넌트화를 통해 직교성의 장점을 살리며 작업하도록 해야겠다.

문제

변수에 데이터를 추가 후 라이브 코딩을 통해 업데이트 과정을 거친 후 에디어틀 재시작하면 변수가 사라지는 이슈가 있다.

ex) MyInt3이라는 변수에 '500'을 셋팅

에디터 재시작

MyInt3가 사라짐

언리얼 에디터에서 라이브코딩을 하면 MyInt3변수는 복구되나 셋팅한 값이 사라짐.

해결방법

에디터를 닫고 빌드 후 다시 에디터 실행

Solution Explorer에서 Build로 처리

AutoPossessPlayer 설정을 Player0으로 셋팅

AutoPossessPlayer : 레벨이 시작될 때나 폰이 생성될 때, 자동으로 폰을 소유해야하는 플레이어 컨트롤러를 결정

갑자기 블루프린트 창에 아무것도 안뜨는 경우가 있었다. 당황스러운...

해결방법 : window -> class default -> 블루프린트 에디터열기!

안녕하세요.

불판코팅업체 이핌코팅을 소개해드립니다.

삼겹살 고깃집을 운영하는 삼촌에게도 추천해 드렸는데요

이전에 이용하던 재코팅 업체보다 이 핌코팅이 더 꼼꼼하게

코팅되고 더 오래 쓸 수 있다고 하시네요. 고기 굽는 품질도 더 좋아졌다고 합니다. 

고깃집, 또는 그릴석쇠, 타코야끼, 빵팬등 사용하며 가게를 운영하시는 사장님이라면 주목해 주세요!

불판은 맛있는 고기를 굽기 위한 중요한 장비입니다.

그러나 시간이 지남에 따라 불판 표면이 마모되고 부식될 수 있습니다.

이럴 때 이 핌 재코팅 서비스를 이용하면 불판을 새로 구입하지 않고 고기불판을 다시 새롭게 만들 수 있습니다.

이핌 코팅은 입고가 되면 많은 공정 작업이 들어가는데요

제품 입고 -> 열처리 1차 -> 쇼트 -> 열처리 2차 -> 코팅 1차 -> 열처리 3차 -> 코팅 2차 -> 코팅 3차 ->

열처리 4차 -> 코팅 4차 -> 열처리 5차 -> 마블코팅 5차 -> 열처리 6차 -> 포장+출고

저도 재코팅이 엄청 공수가 많이 들어가고 번거로운 작업인지 처음 알았습니다.!!

그리고 이핌 코팅은 서울,경기,인천 지역은 정규직원이 직접수거 및 무료 배송하고 있다고 합니다.

학교오븐팬 재코팅, 식판 연마도 이미 많은 학교에서 이 핌코팅을 이용하고 있다고 합니다!

현재 이핌코팅 첫 주문 10퍼센트 할인 및 무료코팅 이벤트

진행하고 있다고 하니 필요하신 사장님들은 이 핌 코팅 이용해 보세요!

https://smartstore.naver.com/coating_epim

불판, 그리드, 오븐팬, 그리들, 솥뚜껑 등 코팅 입히는 건 모두 가능하다고 합니다. 

• 기억할 내용
  • 효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다. 28p
  • 개발자로서 우리는 여러 입장에서 소통해야 한다.
  • 코드를 작성하는 것은 우리의 의도를 기계에게 전달하는 것이지만, 생각을 기록하여 다음 세대의 개발자들에게 전달하는 것이기도 하다.
  • 청중을 알라. 29p
    • 청중의 요구와 관심, 능력을 이해해야 한다. (어떤 난해한 기술의 장점에 대해 긴 독백을 읊조리는... 단 지껄임 일뿐. 짜증 나는 일이다)
    • 변경 사항을 청중에 따라 각각 다른 방법으로 제시할 수 있다.(ex 영업부, 마케팅, 유지보수팀)
  • 말하고 싶은 게 무언지 알라 30p
    • 말하고자 하는 것이 정확히 무엇인지 생각해 내는 것은 어려운 일이다.
    • 무엇을 말할지 미리 계획하라
  • 때를 골라라
    • 청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다.
  • 스타일을 골라라
  • 멋져 보이게 하라
  • 청중을 참여시켜라 ( 독자가 문서 초안에 참여하도록 하라) 32p
  • 경청하라
  • 응답하라 33p
  • 문서화 (노력을 중복으로 들이거나 시간을 낭비하지 말고 문서를 늘 손에 닿는 가까운 곳에 두면 된다.)
    • 기계적인 주석은 오히려 코드 유지 보수를 어렵게 만든다(모든 함수, 자료 구조, 타입 정의)
    • 어떻게 동작하는지는 코드가 이미 보여주고 있기 때문에 이런 주석은 사족이다.
    • 코드 주석은 프로젝트에서 쉽게 누락되는 다른 곳에서 문서화할 수 없는 부분을 문서화하기에 최적의 기회다.
• 느낀 점
  • 게임 클라이언트 개발자로서 여러 사람들과 소통하는 경우가 많다. 기획자, 아트, 서버 등등 다양한 사람들과 대화할 때 어떤 식으로 소통해야 하며, 또, 소통에는 문서화를 통해 어떻게 소통하는지도 알게 되었다. 어떻게 보면 뭐든 적극적으로 참여하는 마음이 중요해 보인다. 또 이 책에서는 이번 주제 마지막에서 온라인 의사소통에 예절도 가르쳐 준다.ㅎㅎ

• 기억할 내용
  • 지식에 대한 투자가 언제나 최고의 이윤을 낸다. -벤저민 플랭클린 19p
  • 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다.
  • 하지만 불행히도 이 자산은 '기한이 있는 자산' 이다. (빠르게 변화하는 기술 시장) 20p
  • 새로운 것을 배우는 능력은 가장 중요한 전략 자산이다.
  • 지식의 포트폴리오
    • 주기적인 투자 : 정기적으로 이용할 계획을 마련하라
    • 다각화 : 오늘 인기 있는 기술이 내일이면 거의 쓸모없어지거나 그 정도는 아니어도 수요가 없어지기도 한다.
    • 리스크 관리 : 달걀을 한 바구니에 담지 말라
    • 싸게사서 비싸게 팔기
    • 검토 및 재 조정
  • 목표
    • 매년 새로운 언어를 최소 하나는 배워라
    • 기술 서적을 한 달에 한 권씩 읽어라
    • 기술 서적이 아닌 책도 읽어라
    • 수업을 들어라
    • 다른 환경에서 실험해 보라 : 윈도우,리눅스.
    • 요즘 흐름을 놓치지 말라 : 다른 기술을 다루는 뉴스와 온라인 게시물을 읽어라
• 학습의 기회 : 답이 뭔지 전혀 알지 못할 땐 인정하고 거기서 멈추지 말라 24p
• 비판적 사고 : 읽거나 듣는 것에 대해 비판적으로 생각하는 것이다. 25p
  • 왜냐고 다섯 번 묻기
  • 누구에게 이익이 되나?
  • 어떤 맥락인가? (전제 조건은 무엇이고 그 결과의 장기, 단기적 여파는 무엇인가?)
  • 언제 혹은 어디서 효과가 있을까?
  • 왜 이것이 문제인가?

• 느낀 점
  • 지식의 포트폴리오를 쌓아야 한다. 언제 어떤 기술이 트렌드가 될지 모르고 당장 필요가 없어지는 기술이 있을 수 있다. 이것은 아무도 모르기에 항상 준비를 해야 한다. 이번 주제에서는 그것을 준비하는 과정, 방법들이 소개됐다. 당장 없어지고 유망하지 않다고, 가만히 있는 것보다는 그것들을 배우는 과정에서 성장한다는 것이다. 

• 기억할 내용
  • 우리는 종종 나아지게 하려다가 괜찮은 것마저 망친다. - 셰익스피어<리어왕> 15p
  • '적당히 괜찮은'이라는 표현은 너절하거나 형편없는 코드를 의미하지는 않는다. 16p
  • 타협 과정에서 사용자를 참여시켜라
    • 불가능한 시간약속을 하거나 데드라인에 맞추기 위해 기본적인 걸 빼 버리거나 하는 것 역시 똑같이 전문가 답지 못하다.17p
  • 오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다.
  • 사용자에게 뭔가 직접 만져 볼 수 있는 것을 일찍 주는것이 낫다.(피드백) 17p
  • 멈춰야 할 때를 알라
  • 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라
• 느낀 점
  • 나는 '적당히 괜찮은'이라는 표현을 보고 무슨 말인가 했다. 적당하게? 어느 정도의 적당함을 말하는 걸까. 완벽을 추구하며 작업을 하는 것이 맞지 않을까? 책에서는 완벽한 소프트웨어는 현실적으로 불가능하기에. 적당하게 단, 형편없는 코드는 아니란 말이었다. 그리고 제작 단계에서 필요한 사용자를 참여시켜 요구조건에 맞는 소프트웨어 사용하는 사람에게 정확한 요구 사항을 파악하여 품질을 결정해야 한다는 말도, 공감이 많이 됐다.

전쟁 직후 돌멩이 수프로 마을 사람들의 호기심으로 음식재료를 얻었다는 이야기처, 눈앞에 빤히 그려지는 시스템이 있어도 그 시스템이 옳다는 것을 알아도! 막상 일에 착수하려고 허락을 구하는 때부터, 복잡해지기 시작한다. 모든 사람이 각자 자신의 자원을 지키려고 할 것이다. 이걸'시작의 피로'라고도 부른다. ---

작업을 원활히 진행하기 위해서 이런 것들이 필요한 것들이라 생각한다. 빠르게 프로토타입을 보여준다 던 지, 너무 큰 요구를 하기보다는 간단 요구부터 요청한다던지 말이다. 또 이 책에서 말하기로는 돌멩이 수프하나만 바라보고 다른 것을 놓치게 되는 마을사람들의 행동에 대해서 얘기한다. 우리는 매일 이런 상황에 처해있다. 우리도 모르는 새 서서히 상황이 악화된다고, 너무 작아 알아채기 힘들 정도의 문제에서부터, 혹은 이 정도는 괜찮겠지라고 생각하며 넘기게 되는 것들이 나중에 쌓여서 프로젝트의 서서히, 하지만 가차 없이 구제불능인 상태가 되어 버린다. 이것을 개구리 수프라고 표현한다. 뜨거운 물에 개구리를 넣으면 바로 튀어 나가지만, 서서히 온도를 높이면 그것을 감지 못하는 것처럼. 원활한 일을 시작하기 위한 촉매의 돌멩이 수프인지, 나도 모르게 악화되는 개구리 수프인지!

큰 그림에 늘 주의를 기울이고 당장 하고 있는 일에만 정신을 쏟지 말고, 이것이 돌멩이 수프인지 개구리 수프인지 잘 판단해야 한다. 주변에서 무슨 일이 벌어지는 늘 살펴야겠다.

Topic 3 소프트웨어 엔트로피

소프트웨어의 무질서도가 증가할 때 우리는 이를 '소프트웨어의 부패'라고 한다. 

이를 보다 그 정적인 표현인 '기술 부채'라고 부르기도 한다. 은연중에 언제 가는 갚을 수 있다는 뉘앙스를 풍기면서 말이다. 하지만 아마 갚지는 않을 것이다.  미래에 시간을 당겨다 쓰는 느낌이랄까..? 

여기서 말하기를 소프트웨어가 부패하는 데에는  많은 요소가 관여되는데 가장 중요한 것은 프로젝트에서 발생하는 심리학적 혹은 문화적 요소라고 한다. 이 심리는 이미 쓰레기가 넘치는 코드에 내 쓰레기 하나 더 버리는 건 괜찮다는 생각을 갖기 쉽다는 내용이다. 결국 이런 부정적인 생각은 팀원들에게 퍼져 악순환이 된다.

말하기를 깨진 창문을 내버려 두지마라

나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라, 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라. 더 이상 손상을 예방하기 위해 "아직 구현되지 않았음"이라는 메시지라도 표현하자. 그 조치로 관리되고 있다는 것을 알리자. 

공감이 많이 됐다. 쉽고 빠르게 구현하기 위해 작성했던 코드들이 나중에 유지보수가 불가능한 코드가 되어 개선 작업이 힘들었던 경험. 이미 깔끔하지 않은 코드 위에 깔끔하지 않은 코드 한 줄 추가하기에는 쉽지만, 누가 봐도 잘 정돈된 코드 위에는 조금 더 신경 써서 코드를 작성하려 했던 경험.

우선, 망가트리지 말자

문제를 해결하기 위해 부가적인 피해를 일으키지 마라. 깨진 창문은 하나라도 충분하다.

정확한 확신 없이는 오히려 건들지 말자.

당장 부패한 코드를 작성하지 말자. 미래에도 바꾸지 않는다.

Topic 2 고양이가 내 소스 코드를 삼켰어요.

실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다. 

주제만 봐도 핑계를 대는 사람의 모습이 보인다. 그건 바로 책임감과 연결된다. 이번 주제에서는 실용주의 프로그래머라면 자신의 경력 개발, 자신의 학습 및 교육, 자신의 프로젝트, 자신의 일상업무에 대해서 책임을 지고, 자신의 실수나 무지도 주저 없이 인정한다. 책임을 지는 것은 프로그래밍에서 가장 즐거운 부분은 아니지만, 자주 일어나는 것이다. 잘 나가는 프로젝트에도 철저한 테스트, 훌륭한 문서화, 탄탄한 자동화 등에도 불구하고 뭔가 잘못되는 일이 있다. 예상치 못했던 기술적 문제가 발생한다. 이런 일이 일어나면 우리는 가능한 전문가답게 처리하려고 노력한다. 이는 정직하고 솔직해져야 한다는 것이다. 

이 내용을 읽고 내가 느꼈던 것은 주어진 일정 안에 기획된 내용을 개발하지 못했을 때, 팀장님에게 내가 어떤 식으로 얘기를 했었지? 한번 떠 올렸다. 말도 안 되는 핑계를 되지는 않았는지, 해결하지는 못했지만 적절한 대안은 제시했는지. 과연 팀장님이 보기에 전문가처럼 얘기를 했는지..

팀 내 신뢰

여러분의 팀이 여러분을 믿고 의할 수 있어야 한다. 여러분도 다른 팀원 누구에게나 편하게 의지할 수 있어야 한다. 팀원끼리 신뢰하지 않는다면? 서로 의지할 수 없는 관계가 형성된다. 그리고 이런 신뢰에 구멍이 뚫리면 원상복구가 힘들다.

나는 이런 부분에서 신뢰를 쉽게 깨지지 않을까 생각한다. 당연히 테스트해야 하는 것들, 너무 간단한 시퀀스에도 쉽게 나오는 버그, 귀찮다고 그냥 넘어가는 것들... 이것들부터 신뢰를 지키는 중요한 시작이라고 생각한다.

책임지기

책임은 최선을 다하는 것이 전부가 아니다. 통제할 수 없는 위험 요소가 있지 않은지 상황을 분석해야 한다. 결과에 대한 책임을 지기로 했다면 나중에 그 결과를 감당해야 한다. 실수를 저지르거나(누구나 실수를 한다) 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라. 다른 사람 혹은 무언가를 비난하거나 변명을 만들어 내지 말라. 모르면 모른다고 얘기하고 그지만 찾아본다고 얘기해 전문가답게 책임을 지는 모습을 보여주자

내가 맡은 업무가 있다면 책임지고 해결하자. 안좋은 결과가 일어났다면, 그 결과를 좋은 결과로 바꾸기 위해 노력해야 한다. 변명이나 비난은 아무 의미가 없고, 내가 해결하지 못한다고 판단되면 일찍이 도움을 요청하자

나는 첫 번째 회사에서 2년 정도 경력을 쌓고 현재 직장인 이곳으로 이직을 했다. 좋은 프로젝트를 개발부터 출시까지 했다. 지금도 많은 것들을 경험하면서 배우고 있다. 내가 이 책을 처음 읽게 된 계기는 당시 팀장님과 첫 면담에 이런저런 얘기를 주고받았고, 짧은 시간이었지만 정말 배울 점이 많다고 생각했다. 그리고, 서점에서 이 책을 사주셨다. 사실 나는 프로그래밍이란 책은 언어문법이나 패턴정도의 책들만 몇 권 봤었지, 이런 종류의 책은 처음이었다.

이 책을 처음 읽을때는 이해하지 못하는 부분이 많아, 그냥 가볍게 읽었었다. 그 당시에 내년에 다시 한번 읽어봐야겠다'라는 생각을 했고, 올해 이 책을 다시 읽기 시작했다.  확실히 작년에 읽었을때 느끼지 못했던 것들이 있었다. 물론 지금도 저자가 예시를 드는 내용이며, 용어며.. 생소하고 이해하지 못하는 게 많다. (그럼 1년, 2년 후에는 점차 이해하는 부분들이 많지 않을까?) 이번에는 책의 내용들을 체득화하기 위해 내용을 정리하고, 내 생각들을 포스팅을 해보고 싶었다.

Topic 1 당신의 인생이다.

당신의 인생이다. 당신의, 당신이 사는, 당신이 만드는 인생이 있다. 

첫 번째 주제부터 확 와닿았다. 이 책에서 말하는 '불만 많은 개발자'를 얘기가 나는데. 공감이 됐다. 대학교를 다닐 때나, 학원에 다니며 공부하고 있을 때 불만이 많은 친구들이 꼭 있었다... 책에서 말하기를 이런 사람들은 변화를 귀찮아 피하고, 내가 발전하지 못하는 이유를 회사가 교육을 시켜주지 않는다고 투덜댄다고 한다. 내가 느끼기에도 이런 사람들은 무슨 어떠한 상황이 주어져도 불만을 갖으며, 그 이유를 동료 탓, 회사 탓으로 핑계를 댄다. 원하는 게 있으면 요구를 하고 내가 바꿀 수 없는 상황이라면 차라리 회사를 옮기는 것이 맞다.(근데 아마 이것도 귀찮아할 것이다.)

+,-,*,/ 연산자 추가하기

PIN CONVERSIONS로  타입선택

Add pin으로 더하기 피연산자 추가

Add한거 출력해보기

VARIABLES -> '+'버튼으로 추가

Name : 언리얼 내부에서 사용하는 변수, 빠른 검색에 용이, 용량도 적다

Text : 다국어 변환할때 용이

Print Text

=>

Event BeginPlay : 게임이 시작하고 한번 실행

EventTick : 매 프레임 실행

주석기능 : 드래그하고 'C'

연결된 라인 정리 : 가운데 더블클릭, ctrl누르고 이동

정리 : 단축키 q

1. 데이터 추가 팝업

'Add'버튼을 누르면 AddGameResult()를 통해 팝업을 열어준다.

SaveGameResult : DB에 저장 작업

작업 결과

Add버튼을 통해 새로운 데이터를 추가한다.

새로 추가된 데이터가 db에도 잘 들어감

DB와 연결을 수월하게 하기 위한 EntityFramework 방식

1. DB 테이블 연동하기

appsettings.json파일에 기존에 있던 문자열을 지우고 연결할 연결 DB문자열을 넣어준다.

2. 유저 데이터 모델링

add-migration : 마이그레이션을 추가 한다.

3. DB 접근하기 위한 준비

DB를 참조하기 위한 RankingService를 생성

Startup에 새로 생성한 RankingService를 DependencyInjection 해준다.

4. 데이터 입력

일단 각각 더미로 데이터를 입력해준다.

5. 결과

JS 연동하기

1. JS파일 추가

s파일을 생성하고 2개의 함수를 만들었다. 단순히 "Hello World" 텍스트가 있는  윈도 창이 뜨는 함수와 이용자가 입력한 string을 리턴하는 함수

2. host에 추가하기

추가할 js파일을 연동하기 위한 작업

3. 레이저 파일 추가

@page "/JSInterop" : 페이지 라우팅

@inject IJSRuntime :. NET에서 JS를 호출하려면 IJSRuntime가 필요하다

button  2개 추가

@code 부분

4. 웹사이트 메뉴 추가

웹사이트에 새로 추가한 블레이저 파일을 연결 작업.

실행결과

1번째 버튼

2번째 버튼

c++의 templated나 c#의 generics같은 기능이라고 생각하면 된다.

@typeparam : 템플릿타입 컴포넌트를 만들기 위한 선언

RenderFragment : Header와 Row 타입을 템플릿으로 만들기 위한 타입

@Header : 아래 @code부분에 선언한 Header와 바인딩

@foreach ~ @Row : RenderFragment<Item> Row와 바인딩되었으며 어떤 식으로 작동될지 선언 부분이다.

템플릿 타입으로 만든 컴포넌트를 사용

실행 결과

컴포넌트 분리

저번 포스팅에 @code부분인 AddUser()와 KickUser()를 컴포넌트화 시키기 위해 새로운 Blazor파일을 생성해 분리하도록 해보자

ShowUser 블레이저 파일 생성

ShowUser.razor파일을 생성해 User.razor에있던 리스트 생성과 유저 추가, 삭제하는 함수들을 옮겼다.

설명

-<ShowUser></ShowUser> : 새로 생성한 ShowUser.razor를 사용하기 위한 처리

-<ShowUser User ="_users"> : ShowUser.razor의 User변수와 User.razor의 _user의 변수를 공유한다

-@ref ="_showUser" : 부모쪽에서 자식에 접근하는 방식(이 처리가 없으면 @code에 ShowUser는 null임)

CallbackTest="CallbackTestFunc" : 콜백을 사용할 때

[Parameter] : 를 통해  다른 블레이저 파일에서 접근 가능하도록 명시한다.

(블레이저에서는 Action보다는 EventCallback을 추천한다. StateHasChanged()가 없어도 리프래시 처리 )

"CallbackTest"문자가 보임 : 콜백 호출이 잘되고 있다

@code 부분

OnInitialized() : 웹이 시작할때 시작되는 함수 (유니티 awake()나 start()정도로 생각하면 될듯하다)

AddUser() : 리스트 요소 추가 함수

KickUser() : 리스트 요소 삭제 함수

웹코드 부분

"list-group"

- @foreach (var user in _users)<li>는 리스트갯수별로 추가해줘야 하지만 동적으로 추가,삭제 되기 때문에 foreach로 처리 되도록 한다.

- @onclick="(()=>KickUser(user))을 통해 리스트 요소옆에 해당 요소를 제거하는 버튼을 추가하는 내용이다

"container"

- <input class="form-control" placeholder="Add User" @bind-value="_inputName" : 처음에 뜨는 텍스트는 "Add User", "_inputName"을 바인딩 처리

- <button class="btn btn-primary" type="button" @onclick="AddUser">Add user</button> : AddUser를 실행처리

결과화면

step : 몇 단위로 증감시킬건지

bind-value : @code에있는 _value값을 처리

웹에서 표현되는 Value는 @code부분에 _value값을 보여주고 슬라이더로 _value값을 접근하여 변경할 수있다.

1. 

실행결과

Start TestAsync가 불리고 3초 뒤에 EndTestAsync가 불리고 바로 while start가 불렸다. 만약 TestAsync에서 매우 긴 시간 동안 대기가 걸리면 그 이후 코드들이 실행되지 않게 된다.

2.

실행결과

await를 사용하여 대기하지 않고 바로 다음 코드가 실행되도록 할 수 있다.

3. await 활용방법

https://docs.microsoft.com/ko-kr/dotnet/csharp/programming-guide/concepts/async/

eggs, eggs, toast는 각각 연관이 없는 동작이다. 그렇기에 await키워드를 통하여 동시에 작업이 가능하도록 할수 있다. 이 사진에 문제점은 3가지 작업 중 toast가 끝난 뒤에 juice작업과 "Breakfast is read!"가 출력되도록 되어있다. toast가 가장 먼저 끝난다는 전제가 있다는 것이다. (우리는 어떤 작업이 먼저 끝날 줄 모른다.)

whenAny

3가지 작업을 List로 만들어 while문을 통해 끝난 작업들을 표시해주는 방법이 있다.

인덱스 칼럼 순서에 따른 탐색 시간 비교해보기

0. 테이블생성

1. 정렬하기

1) ORDER BY EmployeeID, OrderDate;

EmployeeID로 정렬된 뒤에 OrderDate 순으로 정렬되어있다.

2) ORDER BY OrderDate, EmployeeID;

OrderDate , EmployeeID 순으로 정렬되어 있는 것을 알 수 있다.

2. 특정 조건으로 찾기

SELECT *
FROM TestOrders WITH(INDEX(idx_emp_ord))
WHERE EmployeeID = 1 AND OrderDate = CONVERT(DATETIME, '19970101');

SELECT *
FROM TestOrders WITH(INDEX(idx_ord_emp))
WHERE EmployeeID = 1 AND OrderDate = CONVERT(DATETIME, '19970101');

인덱스 조건이 다른 두 개 코드는 탐색 결과가 차이가 없는 걸 알 수 있다.

3. 범위 조건으로 찾기

범위가 늘어나면 점점 큰 차이가 나게 된다. idx_emp_ord로 정렬한 뒤에 OrderDate범위는 바로 접근할 수 있는 반면에 idx_ord_emp로 정렬된 두 번째는 OrderDate를 범위를 찾은 다음에 다시 EmployeeID를 찾아야 하기에 더 오랜 시간이 걸리게 된다.

=> Index(a,b,c)로 구성되었을때, 선행 between사용하면 후행은 인덱스 기능을 살싱하게 된다.

1. NonClustered 인덱스 추가

특징 : Clustered Index가 없으면 데이터는 Heap Table이라는 곳에서 저장하고 Heap RID를 통해 Heap Table에 접근해서 데이터를 추출한다.

2. Clustered 인덱스 추가

HEAP RID가 없어졌으며 UNIQUEFIRE(같은 OrderID를 식별도록)가 생성됐다.

특징: HeapTable이 없으며, Leaf Table에 실제 데이터가 있고, Clustered Index의 실제 키값을 가지고 있다.