사용자 정의 표현식(~/.hanspell-bad-expressions.json
)을 중심으로 “비주얼 스튜디오 코드 한스펠”의 설정 예시를 제공합니다.
맞춤법 검사를 한 번이라도 실행한 문서라면 수정할 때마다 사용자 정의 표현식이 자동으로 적용됩니다.
아래의 저의 ~/.hanspell-bad-expressions.json
파일입니다. 김정선 작가의 《내 문장이 그렇게 이상한가요?》에서 많이 가져왔습니다.
사용자 정의 표현식(~/.hanspell-bad-expressions.json
)을 중심으로 “비주얼 스튜디오 코드 한스펠”의 설정 예시를 제공합니다.
맞춤법 검사를 한 번이라도 실행한 문서라면 수정할 때마다 사용자 정의 표현식이 자동으로 적용됩니다.
아래의 저의 ~/.hanspell-bad-expressions.json
파일입니다. 김정선 작가의 《내 문장이 그렇게 이상한가요?》에서 많이 가져왔습니다.
#!/usr/bin/env node | |
/** | |
* @fileOverview Converts Tygem's GIB format to SGF. | |
*/ | |
// GIB format example. | |
// | |
// \HS | |
// ... |
소프트웨어 품질과 아키텍처의 연관성은 명확해 보인다. 특히 품질 속성 주도의 디자인Attribute-Driven Design이 지배적인 방법론인 것을 고려하면 거의 동의어로 느껴질 정도이다. 이런 이유로 소프트웨어 품질 향상을 위해 아키텍처 평가 방법론을 살펴보는 것도 뜻이 있다고 생각한다. 이 글은 이런 배경에서 쓰였고 따라서 세부 절차보다는 평가 방법론의 주요 개념을 살펴보는 데 집중한다.
일을 끝낸 뒤에 그 결과와 과정을 평가하는 것도 뜻이 있지만 되돌리는 비용이 큰 결정에 앞서 그 결정의 적합성을 검토하고 평가하는 것도 뜻이 크다. 이런 평가가 효율적으로 이루어진다면 시행착오로 인한 비용을 줄이고 그 결정에 근거해서 수행될 일의 질 또한 높여 줄 것은 분명하다. 따라서 많은 선택과 결정이 전체 프로세스 상의 한 지점에서 이루어졌다면, 직후에 양식을 갖추어 평가를 시도하는 것은 고려할 가치가 있다. 오늘 소개하고자 하는 ATAMArchitecture Tradeoff Analysis Method은 소프트웨어 시스템 아키텍처의 장단점을 분석하는 방법론으로써 이런 평가의 취지에 부합한다.