은닉을 향한 자바스크립트의 여정

클래스 필드 스펙 Stage3까지 올랐다고한다. 곧 Stage4가 표준 스펙이 될거라는데??

타입스크립트 3.8부터 private를 지원, 공부 중에 잠깐 확인한 적이 있었다.

 

  • 표준 스펙이 될 것이다.

    • 스펙이 업데이트될 수 있다.

  • private와 같은 키워드를 사용하지 않고 #을 사용한다.

    • 키워드가 아닌 프리픽스

  • public과 다르게 클래스의 필드 선언을 통해서만 만들 수 있다.

    • 동적으로 객체에 추가할 수 없다.

  • 메서드에는 제한적이며 메서드 선언으로 사용 불가

    • 함수 표현식으로 정의

  • 객체 초기화 구문은 계산된 속성명(computed property name)을 사용할 수 없다.

  • 모든 private 필드는 소속된 클래스에 고유한 스코프를 갖는다.

    • getter 함수를 만들어서 public하게 노출해서 값에 접근 할 수 있다.

    • private를 정의한 클래스를 제외하고 어디에서든 접근이 불가능하다.

 

자바스크립트는 private 속성을 지원하지 않아서 코드를 짤 때 private하게 하기 위해 꼼수를 사용해왔다.

보통 클로저를 통해 캡슐화, 은닉화를 통해 private하게 만들었고,

그렇지 않고서는 언더스코어(_) 프리픽스를 통해 컨벤션으로 이것은 private야라고 해서 쓰기도 했다.


하지만 이게 컨벤션일뿐 모르는 사람이 그냥 외부에서 접근했을때에는 그냥 public이다.

그 후에는 JSDoc을 통해 @private를 표현했다고 한다. 

언더스코어보다 훨씬 명시적이로 문서도 자동화가 되니 자연스럽게 언더스코어의 사용은 줄었고,

글쓴이도 컨벤션에서 제하는것에 찬성했다고 한다. 

나도 글을 보니 사용을 지양하는 것이 좋겠다고 생각했다.

 

원본 글에서 가져온 코드다.
es6를 사용하지 못하는 프로젝트에서 캡슐화 시켜서 private하게 코딩할 때 모듈 패턴을 사용하는데,

이것도 생성자의 인스턴스 컨텍스트별로 private하게 하지 못하기 때문에 도움이 되지 않는다.

function SomeModule() {
  const privateProp = 'dont touch this';
  const publicProp = 'you can touch this';

  _doSomethingWithPrivateProp = () => { ... }

  const publicMethod = () => {
    _doSomethingWithPrivateProp();
    // ...
  }

  return {
    publicProp,
    publicMethod
  }   
}

- 코드 출처 원본 글

 

아래는 symbol에 대해 공부 의지를 불태워 줄 좋은 자료의 코드이다.

es6에서는 더 멋진 꼼수로 private하게 만들 수 있다는 예시라고 하는데, 

(하지만 이제 private를 정식으로 지원한다고 하니까.)

다음에 공부하게 참고해야지.!!

const privateMethodName = Symbol();
const privatePropName = Symbol();

class SomeClass {
  [privatePropName] = 'dont touch this';;
  publicProp = 'you can touch this';

  [privateMethodName]() {
    console.log('private method');
  }

  publicMethod() {
    this[privateMethodName](this[privatePropName]);
  }
}

- 코드 출처 원본 글

 


원본, 코드 출처

https://meetup.toast.com/posts/228

JSON.stringify () 기능

JSON.stringify를 간단히 JSON문자열로 변환할때만 사용할 때 썼었는데, 몰랐던 기능들이 있습니다.

 

 

1. 찾고자하는 키 값을 두번째 인수에 넣어 전달하면 원하는 키의 배열만 리턴받을 수 있다.

{"id":"0001","type":"donut","name":"Cake","ppu":0.55,"batters":{"batter":[{"id":"1001","type":"Regular"},{"id":"1002","type":"Chocolate"},{"id":"1003","type":"Blueberry"},{"id":"1004","type":"Devil’s Food"}]},"topping":[{"id":"5001","type":"None"},{"id":"5002","type":"Glazed"},{"id":"5005","type":"Sugar"},{"id":"5007","type":"Powdered Sugar"},{"id":"5006","type":"Chocolate with Sprinkles"},{"id":"5003","type":"Chocolate"},{"id":"5004","type":"Maple"}]}

console.log(JSON.stringify(product,['name']);

// RESULT
{"name" : "Cake"}

 

 

2. 두번째 인수에 함수를 넣어 원하는 값을 리턴 받을 수 있다.

undefined일 경우에는 리턴되지 않는다.

const user = {
	"name" : "Prateek Singh",
	"age" : 26
}

JSON.stringfy(user, (key, value) => {     
	if(typeof value == 'string'){
        return undefined;
    }
    return value;
});

// RESULT
{ "age": 26}

 

 

3. 세번째 인수가 '숫자'일 경우 문자열의 간격을 제어할 수 있다.

4. 세번째 인수가 '문자'일 경우 공백 대신 문자를 삽입할 수 있다.

 

 

5. toJson

키값에 따라 객체를 바로 리턴하지 않고 메서드를 통해 원하는 키 값을 합쳐서 반환할 수 있다.

const user = {
	firstName : "Prateek",
    lastName : "Singh",
    age : 26,
    toJSON() {
    	return {
        	fullName: `${this.firstName} + ${this.lastName}`
        };
	}
}

console.log(JSON.stringify(user));

// RESULT
"{ "fullName" : "Prateek Singh"}"

 


원본, 코드 출처

https://medium.com/javascript-in-plain-english/5-secret-features-of-json-stringify-c699340f9f27

 

하루에 1000번 배포하는 조직되기

 

잦은 배포는 많은 비즈니스 충족을 뜻하고 사용자에게 더 많은 가치를 빠르게 전달할 수 있다는 것을 의미하며 
빠른 성장과 높은 가치를 인정받게될 수 있다.
실제로 유명한 스타트업, 테크 기업들은 하루 1000번 이상의 크고 작은 배포가 이루어지고 있다고한다.

 

gitflow

하나의 repository에서 메인테이너들이 동시에 작업할 경우 큰 장점이 있는 모델
총 5가지의 브랜치로 이루어져있다.
- master, release, develop, hotfixes, feature

 

흐름

- develop에서 feature 브랜치를 생성, feature에서 개발 -> develop에 병합
- develop에서 release 브랜치 생성, release에서 배포에 핃요한 문서 작업 혹은 버그 수정 등을 진행
- release 준비가 완료되면 release 브랜치를 master와 develop에 병합

 


잦은 배포에서 더이상 git-flow를 따를 필요가 없다.
브랜치를 생성하고 병합하고의 절차가 너무 많았기 떄문에 복잡한 프로세스를 줄일 필요가 있다고 생각했으며
여러명이 동시 작업 후 배포를 진행했을 경우 특정 기능에 장애가 나면 tag기반으로 롤백할 때 전체를 할 수 밖에 없는 상황이 있었기에 배포 정책을 수정할 필요를 느꼈다고한다.
따라서 최소한의 브랜치를 생성하여 작업을 하게되었다고하는데,
master만이 존재하며 작업 시 master에서 브랜치를 생성 (브랜치 네이밍은 명확히) 후 작업하고 master에 병합
(안전하지 않아보인다면 원본 글을 읽고오세요, 병합 전 절차들이 있습니다.)

 

- 병합할때는 squash and merge 방식을 사용한다고한다.

- 브랜치의 모든 커밋을 squash하여 하나의 커밋으로 만들고 이 브랜치를 병합한다.
- 병합을 요청하는 단위는 배포가능한 단위여야하고 작을 수록 좋다.

- git flow와 가장 큰 차이는 master에 병합될때마다 커밋들을 배포하지 않고 여러 커밋을 모아서 배포
  ㄴ 사이드이펙트나 커뮤니케이션의 비용문제로 빠르게 배포하는 것을 권장
  ㄴ 여러 기차가 정차해 있다가 출발하는 모양과 비슷하다고 해서 commit-Train based deployment라고 한다.

 

그 아래 배포 툴에관한 내용 잘 몰라서 읽고 넘어가자

 


결론은 ... 
하루에 1000번의 배포를 할 수 있는가?
모니터링 툴과 장애 대응 프로세스, 조직의 비즈니스 역량이 있어야 가능하며 판단할 수 있는 지표가 될 수 있다.

 


 

원본 글

https://blog.banksalad.com/tech/become-an-organization-that-deploys-1000-times-a-day/

개발자도 알면 좋은 UI 디자인

 

토이프로젝트에서 종종 개발욕구가 사라지는 경우가 있는데,

개발을 하면서 디자인에서 많은 시간을 쏟게되는 경우인 것 같습니다.

그럼에도 디자인이 똥망일때 진짜 개발욕구가 사라집니다..

세세하게 설명해주는 부분들을 개선할 수 있을 것 같아서 좋은 글이라고 생각합니다.

메모해뒀다가 바로 프로젝트에 적용해야겠습니다.

 

  • 목업, 와이어 프레임

  • 구체적인것은 뒤로 미뤄라

    • 먼저 빨리 만들어라

  • 컨셉을 정하라

    • 폰트

      • 클래식 serif

      • 통통 생동감 sans serif

      • 중립 sans serif

  • 일관된 UI

  • 디자인을 시스템화

    • 소모적인 고민들의 선택지를 제한하라

    • 테마 선별

      • 폰트 두께, 폰트 크기, 라인 높이, 색상 값, 마진, 패딩, 너비, 높이, 박스 쉐도우, 테두리 반경, 테두리 두께, 투명도, 아이콘 크기 등


참고
개발자도 알면 좋은 UI 디자인
https://joshua1988.github.io/web-development/design/ui-for-developers/
참고자료로 명시되어있는 사이트
https://refactoringui.com/book/

 

+ Recent posts