스마트스타일

5.0~5.2 .ts = 타입 파일 tsconfig.json: 타입스크립트 설정파일 설정 json키 설명 include = 어떤 부분을 컴파일할것인지 compileroptions = 컴파일러 옵션 설정 outDir= 아웃될 폴더 이름값 설정 target= 컴파일된 파일은 어떤 버전의 언어로 설정이 될지 선택 lib=ts를 작성할때 몇버전의 js를 사용할것인지, node서버를 하는지 브라우져를 코딩하는 것인지 설정

public으로 사용하면서 값은 노출하지만, 값에 새값을 덮어쓰는 것을 방지하기 위해, readonly사용 특정값만 올 수 있도록 설정도 가능 Team의 값으로는 'read', 'blue', 'yellow'만 올 수 있다 인터페이스 인터페이스는 오로지 오브젝트의 모양을 정해주기 위해 사용한다. 차이점 type키워드는 인터페이스에 비하여 더 활용성이 높다. 인터페이스키워드는 오로지 객체의 모양을 설명하는데에만 사용됨(좋아보이지 않다고 생각) 상속을 받을 수 있으며, 클래스와 유사한 문법 형태를 보임 객체지향이나 상속을 좋아한다면 익숙하게 사용가능한 장점이 있다. 인터페이는 type형과는 달리, 여러번 선언하여, 중첩구조로 사용하는 것이 가능하다. 인터페이스를 상속할때 implements로 상속이 가능하다...

abstract (추상 클래스) 추상클래스는 상속을 내려줄떄만 쓰고, 인스턴트를 직접 생성할 수 없다. private는 자바스크립트에는 적용되지 않고, 나를 지켜주기위해 오직 타입스크립트에만 있다.

1.call signatures 타입스크립트 함수위에 마우스를 올려두면, 설명 나오는것이 call signatures 함수의 타입과 함수의 반환타입이 아니라, 인자의 타입과 리턴의 타입을 알려준다 call signatures를 먼저 만들어 놓고, 함수에 대입하여 js와 비슷하게 사용할 수 있다. 2.다형성 2-1오버로딩 오버로딩은 콜시그니쳐를 더 정석적으로 만드는 방법으로, 여러 콜 시그니쳐를 가질 수 있음, 3.제네릭 콜시그니쳐를 직접 정의하기보다는, 함수 사용형태를 보고 오버로딩을 자동으로 하게 사용하는 방법을 제네릭이라고한다(근데 이렇게 막 다 사용할 수 있게 해줄거면, any타입을 쓰는거나, js를 쓰는거나 다를게 없는데 뭐가 좋다는건지) any와 같다고 생각했지만, any와는 다르게, 내가 인자..

#2 [2022 UPDATE] OVERVIEW OF TYPESCRIPT 강의요약 1.타입 선언 변수에 타입을 미리 선언해주는 것과는 다르게, 타입자체를 선언한다. 그 타입을 다른 타입선언에 재 사용 가능하다. 2.함수 파라미터 타입선언 함수에 input되는 파라미터의 타입을 선언한다 3.함수 리턴값 타입 선언 또한 함수가 반환하는 값의 형식 또한 타입을 선언할 수 있다. (리턴값의 타입을 선언하는 것은 좀 신선하다고 생각했다) 4.readonly기능으로 변하지 않는 값으로 만들기 자바스크립트 특성상 뭔가 고정되는 것은 오히려 별로라고 생각하지만, 가끔 꼭 이게 필요할것 같은 순간이 있을 것 같다. 5.배열의 index별 타입선언 어떻게 사용할지 생각은 안되지만, 꽤 좋은 기능인 것 같다. 가끔 함수내에서..

기존부터 쭉 진행해 오고 있는 스터디에서 새롭게 강의를 수강하는 시간을 갖기로 했다. 노마더코더님이 만드신 타입스크립트로 블록체인 만들기 강좌를 8/28부터 매주 수강하기로 하였다. 요즘 스터디에서 프로젝트를 진행하는 것에 어느정도 마음이 해이해진 부분도 있었고, 여러모로 타입스크립트의 필요성을 느끼고 있던터라 여러모로 좋은 기회가 된 것 같다. Typescript로 블록체인 만들기강좌를 8/28일 1.1~1.5강까지 수강하였다. 인트로 부분이라 코드적인 내용보다는 왜 타입을 해야할까하는 이야기였다. 평소 많이 듣는 이야기라서 타입이 왜 필요한지에 대해 어느정도 들어서 알고 있었는데, 인트로 강좌를 통해서 정확하게 어떤 이유인지 확신하게된것 같다. 타입을 사용하는 이유는 단하나, 타입에 대한 안정성을 얻..

10월 중순까지 첫번째 프로젝트를 급히 마무리하고, 주말 2틀쉬고 바로 4주 finalproject를 시작하였다. 코드스테이츠에서 조언 해 주기를 SR에 투자하는 시간에 7~10일정도 사용해도 좋다는 얘기가 있었다. 하지만 firstproject때 너무나 시간 부족 경험을 했어서, 코드치는 시간을 최대한 확보하고 싶었기에 7~10일은 너무 길다고 생각하였다. SR을 아무리 잘했어도, 어느정도 방향이나 내용이 수정될 수 밖에 없다고 생각했기 때문이다. 그래서 시간을 조금이라도 확보하기위해 주말에 2틀 푹쉬기로 하고, 대신 각자 아이디어를 생각해서 프로젝트 첫날에 만나자고 했던 기억이 난다. 처음에 나는 SR에 사용되는 시간은 3~4일정도만 사용하길 바랐는데, 팀원 모두가 SR을 7일주일정도 하고싶다고 해서..

1.데이터와 기능을 하나의 단위로 묶는것 -자동차의 데이터와 기능을 Car라는 함수에 하나로 만들었다. function Car(name,color){ this.name=name; this.color=color; //데이터을 정의 } Car.prototype.drive=function(){ //기능을 정의 console.log(this.name+ '가 운행 됩니다.') } 2.구현은 숨기고, 동작은 노출시키는 것(은닉화) -위에서 짠 코드는 설계한대로 name과 color의 데이터에만 접근할 수 있으며 drive메소드만 사용할 수 있다. 사용만 할 수 있을 분 내부 설계가 어떻게 되어 있는지 알 수 없다. 3.느슨한결합 코드 실행 순서에 따라 코드를 작성하는 것이 아닌 코드가 상징하는 실제 모습과 닮게 코..

10월중순 드디어 기다리고 기다리던 firstProject를 진행하게 되었다. 보통 프로젝트를 하기전 프로젝트팀을 미리 구성하는게 일반적인데, 나는 팀을 딱히 정하지 않았다. 프로젝트 진행 전 각종 스프린트들에서 만난 페어분들께 은근 프로젝트팀 제의를 몇개 받긴 했지만, 무슨 자신감인지, 그냥 팀프로젝트를 무작위로 하기로 마음먹었었다. 프로젝트의 퀄리티를 올리기위해서라도, 장기적으로는 포트폴리오에 사용하려면 프로젝트 팀을 미리 아는사람과 구성하는게 무조건 맞는다는것을 머리는 알고 있는데, 그냥 사전팀 구성없이 가겠다고 어느정도 마음이 결정했던 것 같다. 먼가 무조건 대책없이 그렇게 한 것은 아니다. 그래서 그 당시 왜 그랬나?를 지금 한번 떠올려 보면 여러 페어 프로그래밍을 해오면서 여러분들을 만났는데 ..

함수를 선언식으로 만들어 오다가, 어떨때는 표현식으로 된 함수를 복사해서 가져와서 치다보면서 "아 지금 좋은 코드를 쓰고 있지는 않다"는 생각을 하면서도 이미 혼용된 함수 선언 방식을 프로젝트 내에서 전부 바꿀 수 없기 때문에 그냥 사용하곤 했다. 그렇게 코드를 치다가 내가 지금 치고있는 코드가 좋은 코드일까? 라는 생각을 했었다. 요즘 협업프로젝트중 1개를 리팩터 하며 지내고 있는데, 문뜩 좋은 코드란 무엇일까? 라는 의문을 품었고, 오늘 블로그에 정리할 것이다. 일단 내가 지금 생각하는 좋은 코드란? 이렇다. -일관성 있는 코드 -변수명만 읽어도 그 의미를 어느정도 짐작하기 좋은 코드(함수이름이나, 변수) -함수가 2번이상 사용되어야 하는경우 재사용되도록 밖으로 나와 있는 코드 -함수 설계시 입력값만..