웹 사이트 서버와 모바일 앱 API 서버는 기술적인 부분에서 비슷한 부분이 많지만 앱 API 서버라는 특성 때문에 조금 신경 써야할 부분도 있기에 API 디자인 시 참고할 만한 내용들을 찾아보고 정리한 내용이다. API 서버는 한번 API가 클라이언트에게 나가고 나면 변경하기가 힘들다.웹 사이트는 클라이언트 코드와 서버 코드 모두 웹 서버에서 제공하기 때문에 두 부분을 동시에 변경하는 것이 가능하지만, 앱 같은 경우에는 일반적으로 앱 스토어를 통해서 배포되기 때문에 동시에 변경할 수도 없고 사용자가 업데이트 하지 않으면 계속해서 구 버전을 사용할 수도 있다. 앱을 업데이트하지 않으면 사용할 수 없도록 강제 업데이트하는 방법이 있긴 하지만 되도록이면 피해야 한다. REST를 준수하는 것은 좋지만 그것을 목..

클린 코드 책으로 유명한 로버트 마틴의 책 클린 코더에 대한 독서 노트이다.최근 클린 아키텍처라는 책도 나오면서 클린 트릴로지?(클린 코드, 클린 코더, 클린 아키텍처)가 완성되는 듯하다. 소프트웨어는 너무 복잡해서 오류가 생길 수 밖에 없다. 안타깝지만 너무 복잡하다는 이유로 책임이 사라지진 않는다. 완벽하지 않다는 사실에 책임을 져야한다. 완벽한 소프트웨어를 만드는 것이 사실상 불가능하다는 것이지 완벽하지 않아도 괜찮다는 뜻은 아니다. 경력을 쌓아가면서 오류를 만드는 비율을 0에 가깝게 만들어야 한다. 코드에 결함이 있는걸 알면서도 QA에게 코드를 보내는 일은 매우 프로답지 못한 행동이다.반성하게 되는 부분이다.. 제대로 작동하는지 아닌지 알아야 한다. 알려면 어떻게 해야할까? 테스트하고 또 테스트하..

클린 코드 책에서 기억할만하거나 인상 깊었던 내용을 발췌한 내용임 클린 코드에 대한 정의 비야네스트롭스트룹 논리가 간단해야 버그가 숨어들지 못한다. 깨끗한 코드는 한가지를 제대로 한다. 그래디 부치 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다. 함수 작게 만들어라! 가로 150자 이하 세로 20줄도 길다! 들여쓰기가 2단을 넘어서는 안된다 한가지만 해라! 함수당 추상화 수준은 하나로! 플래그 인수는 추하다 한수가 한꺼번에 여러가지를 한다는걸 그대놓고 공표하는 셈임 명령과 조회를 분리하라! 함수는 객체 상태 변경 아니면 객체 정보 반환 둘 중 하나를해야 혼란이 없다. 형식 맞추기 서로 밀접한 개념은 세로로 가까이 둬야 한다. 변수는 사용 위치에 최대..

XML의 DTD나 스키마와 유사하게 json에도 스키마에 대한 표준적인 부분이 존재하고 있는데요(http://json-schema.org/), 스키마 포맷도 json 포맷입니다. { "contentsId": "123456", "title": "꽹과리", "metadata": [ { "propertyName": "category", "propertyContent": "타악기" }, { "propertyName": "category", "propertyContent": "동양악기" } ] } 위의 예제 데이터에 대한 스키마를 작성하면 다음과 같이 작성할 수 있습니다. 스키마 포맷{ "type": "object", // 루트 타입은 객체 "properties": { // 속성 정의 "contentsId": {..

크지 않은 json 데이터를 파싱할 때는 한번에 파싱해도 메모리 사용량이 많지 않지만,파싱해야할 json 데이터가 굉장히 크다면 메모리 사용량이 많기 때문에 주의가 필요한 부분입니다. 참고삼아 제 로컬 PC에서 jackson 라이브러리로 json 파일을 객체로 파싱하는 로직을 실행해서 visualvm으로 확인해본 결과는 다음과 같았습니다.약 300 KB 파일을 한번에 객체로 파싱 : 약 60 MB 힙메모리 사용약 50 MB 파일을 한번에 객체로 파싱 : 약 150 MB 힙메모리 사용약 150 MB 파일을 한번에 객체로 파싱 : 약 750 MB 힙메모리 사용 jackson 사용 예제streaming api는 json 데이터를 다음과 같은 토큰 단위로 읽어서 처리합니다.객체의 시작 ( { ), 끝 ( } )..

클린 코드 - 2장 의미 있는 이름 - 의도를 분명히 밝혀라 - 좋은 이름을 지으려면 시간이 걸리지만 그로 인해 절약하는 시간이 훨씬 더 많다. - 이름을 통해 존재 이유, 수행 기능, 사용 방법에 대한 답을 해야 한다. - 그릇된 정보를 피하라 - 나름대로 절리 쓰이는 의미 있는 단어를 다른 의미로 사용하면 안된다. - 실제 List가 아니라면 accountList라는 식으로 네이밍하지 않는다. accountGroup, bunchOfAccounts, Accounts 식으로 네이밍한다. - 혼동할 수 있기 때문에 서로 흡사한 이름을 사용하지 않는다. - 의미 있게 구분하라 - 연속된 숫자를 덧붙이거나 특별한 정보를 주지 못하는 Info, Data, variable 같은 단어를 추가하는 방식은 적절하지 않..