[정리] 그냥 저냥 #위클리뉴스 #41

Java

• Jedis 보다 Lettuce 를 쓰자 : 이 부분에 있어서 동의하는 점이 많은게, Jedis는 일단 유지보수가 굉장히 느리고, 오픈소스이더라도 어떤 커미터들의 순환 구조가 있어야 하는데, 그게 좀 부족하지 않나 생각한다. 이슈에 대응도 느리고 해서 필요하다면, 프로젝트를 fork 해서 직접 수정해서 사용해야 하는 수준으로 업데이트 지원이 느리다. 그에 반해 Lettuce는 Spring project에서도 내부적으로 많이 사용하고 있고, 메모리 누수 이슈 문제도 빠른 업데이트로 대응 되고 문제점에 대해서 굉장히 빠르게 업데이트와 피드백을 준다.

• 자바의 GC 가비지 콜렉션 알고리즘 : Java의 GC의 방식들에 대해 요점만 잘 정리가 되어었다. 실제로 대부분의 웹 서버들은 G1 GC를 사용할 것 같은데, ElasticSearch에서는 G1 GC를 사용하면 제대로 효율이 나오지 않아, CMS GC를 사용한다고 본 것 같다. 그런데, 이제 ZGC가 나와서 JDK12를 사용할 때쯤에는 고려를 해볼 것 같다. 다른 분들은 어떤 옵션을 사용하는지 궁금하다.

• [Java/Algorithm] 자바 JVM에 대하여 : Java의 전반적인 내부 흐름을 설명하면서, JVM, JRE등 용어에 대해서도 상세하게 설명을 하고 있어서 재밌게 읽었다. 그리고, GC와 관련해서 정말 자세하게 설명을 하고 있는데, 생각보다 어려울 수 있으니 주의할 것!

• [IntelliJ] intellij 유용한 단축키 정리 - Heee's Development Blog : Java 개발을 하는 사람들은 보통 2가지의 IDE를 사용하는데, IntelliJ를 요즘은 좀 더 많이 사용하는 추세이다. 나도 사용중인데, 정말 편하고, 특히 git merge가 정말 좋다. (3 way diff를 제공하기 때문에 정말 좋습니다.) IntelliJ의 단축키를 소개하고 계신데, jojoldu님의 인프런 강의를 보시고 정리해두신 것이다. 해당 IDE를 잘 쓰고 싶다면, 인프런 강의를 직접 보는 것도 정말 좋겠다.

• Spring Security 아키텍쳐: 대부분 웹 개발을 하다 보면, 인증 관련해서 막막해질 떄가 오는데, 그럴 때, Srping Sercurity가 제일 강력하고 편하게 다가갈 수 있는 것 같고, 그럴때 필요한 내용이 바로 이 글이라고 생각 했다.

• [OKKYCON: 2018] 박재성 - 의식적인 연습으로 TDD, 리팩토링 연습하기 : 세미나 영상을 들으면서 느낀 점은 결국에는 작게 시작하라는 말이 참 와닿는다. TDD를 안하다가 실제로 업무에서 하려고 하면 막막할 때가 있긴 하다. 테스트를 빠르게 작성할 수 있도록 테스트 설정이 잘 되어 있어야 한다는 점도 항상 느끼는 바이다. 그리고, 책 소개가 나오는데, 클린 코드란 책을 아직 읽어보진 않았는데, E-book으로 사서 봐야겠다. 그리고, 소트웍스앤솔러지라는 책도 괜찮은 책인 것 같다. 그나저나, 켄트벡의 TDD 책도 절반 보다 말았는데, 다시 정독을 해야겠다.

• [OKKYCON: 2018] 정진욱 - 테스트하기 쉬운 코드로 개발하기: 테스트 하기 쉬운 코드와 테스트 하기 어려운 코드의 분리라는 중요한 포인트를 알게 되었다. 중요해보이지 않을 수 있지만, 결국 본질은 크게 다르지 않다는 것을 얻을 수 있었다. 부수효과를 없애는 방법도, 테스트 하기 쉽게 코드를 작성 하는 방법도 결국 한 가지의 목표를 통해 나타난 결과가 아닐까? 하는 생각을 하게 되었다. 테스트 하기 어려운 코드도 어렵다는 것이지, 불가능한 것은 아니다. 그리고 행위 테스트 vs 검증 테스트 둘 사이의 차이가 있다. 어떤 것을 우선 할지는 개개인의 방향에 따라 다를 것 같은데, Mockist vs Classicist 어떤 방향으로 갈지는 개인의 선택에 따라 좌우 될 것 같다.

Kube

• 쿠버네티스 시작하기 - 쿠버네티스란 무엇인가? : subicura님의 도커 관련 시리즈도 정말 재밌게 읽은 기억이 있고, 잘 정리를 해주셨는데, 이번에는 k8s의 시리즈를 시작 하셨다. 쿠버네티스가 어떻게 동작하는지? 어떠한 요소들이 있는지 정말 자세하게 설명하고 있다.

JavaScript

• 재사용 가능한 코드 개발: "재사용 코드 필요는 요구사항을 분석할 때 인지된다.", 재사용 코드는 인지가 되는 시점에 개발되지 않으면 중복 코드를 발생하게 된다.이 말이 가장 와닿는다. 결국에는 자신과의 싸움이다. 내가 이렇게 이번에는 넘어가고 다음에 리팩토링을 할 것인지? 아니면 재사용하도록 코드를 작성할지?의 갈림길에 놓이는 순간이 서비스를 하다보면 꼭 오긴 한다. 그럴때 어떻게 대처를 해야 프로가 되는 길일까? 고민이 생긴다.

• async await 정리: 비동기 프로그래밍을 우리가 흔히 아는 동기식 코드로 바꿔 준 녀석이 바로 async/await 아닐까 한다. 기존 Promise pattern의 한계를 바꿔 개발자들에게 편리한 비동기 프로그래밍을 할 수 있게 해주었다. 사용해본 적이 없다면, 어렵지도 않고, 쉽게 케이스별로 코드로 설명을 하는 이 글을 읽고 사용해 보는 것도 좋을 것 같다.

• [OKKYCON: 2018] 이혜승 - 테알못 신입은 어떻게 테스트를 시작했을까?: 확실히 중요한 부분은 테스트를 잘 작성해야 한다는 점이다. 이번에는 테스트 관련해서 세미나 영상을 많이 접했는데, 주요한 점은 단 하나이다. 결국에는 테스트를 위해서는 코드의 적절한 분리가 중요하고, 테스트 하기 쉬운 코드는 결국 읽기 좋은 코드가 된다는 점을 깨달았다. 그리고, 선순환의 습관화가 가장 중요하다!! 사실, 그게 TDD가 아닐까 한다. TDD에서 가장 중요한 점은 테스트와 개발자의 선순환 구조를 만드는 것을 습관으로 가지는 것이 아닐까 한다.

• Lodash-es vs individual Lodash utilities: Size comparison: 요즘 업무에서 사용하고자 하려고 하는데, 용량이 생각보다 중요하다. Production에서 Bundling size는 서비스 전반에 걸쳐서 영향을 준다. 그래서 특정 라이브러리를 사용하는데, 용량을 많이 차지 하면, 좋지 않다. 그래서 최근에 뜨는 것이 lodash-es 로 벤치마크를 보면, 사용하는 유틸이 많을 수록 훨씬 유리하다.

• The Correct Way to Import Lodash Libraries - A Benchmark : 위의 내용과 비슷하며, lodash babel plugin도 설명하고 있어서 lodash를 사용하신다면, 2개의 글을 읽어보시는 것을 추천 드린다.

• [좌충우돌] 앗! 리액트 + 하이차트로 차트를 그렸는데 차트가 갱신이 안되네!?: highcharts 를 많이 사용하는데, 요즘은 오픈소스 차트 라이브러리를 많이 사용하기도 한다. 그런데, React 환경에서 하이차트를 사용해야 한다면, 어떻게 해야 할까? 문제는 없을까? 그런 고민을 하던 와중에 차트 갱신 오류 문제를 겪었던 분이 경험기를 남겨주셨다.

Python

• 청년 고득녕 (2014~) : 네이버 블로그: 왜 파이썬을 해야 하는지 소개한다. 그런데, 이 글의 내용을 정말 쉽게 전체 받아들이면 위험하다. 결국에는 목적성이 있어야 하는 건데, 다 하니까 나도 해야지라고 생각하기엔 우리들의 시간은 집중력 있게 학습 하는 시간도 부족하다.

개발자에게 도움이 되는

• [번역] 빠른 개발을 위한 기술 - 1: 30분은 좋은정도지만, 2시간을 오롯이 집중하는건 아주 훌륭한 일입니다. 그 주에 따라 다르지만 저는 아마 매일 3~4시간정도 이런 시간을 가집니다.보통 오전 9시 30분부터 11시 30분까지 일이 잘 되더군요. 캘린더에 ‘집중 근무 시간’ 같은 일정을 등록해둘 수도 있습니다. 이런 생산성 관련한 글이 정말 좋다. 나도 항상 생각하는 거지만, 집중 하기가 어려운 환경에서 일을 하고 있다고 생각하는편인데, 그럼에도 우리는 집중력을 필요로 한다. 그런 관점에서 딥워크라는 책을 읽어보면 좋겠다 싶은 생각이 들었다. 그리고 내 개인적인 경험으로는 ASMR이라고 하는데, 핸드폰으로 자연관련 소리를 듣는게 집중력을 향상하는게 좋았다. 특히 Tide App이 좋았다.

• [번역] 빠른 개발을 위한 기술 - 2: 수 년 동안 모든 브랜치에서 셀프 코드 리뷰를 하면서 80%는 무언가 고쳐야 할 부분을 찾아냈습니다. 보통은 동료가 금새 찾아낼 법한 바보같은 실수인데, 만약 동료가 PR에 코멘트를 남기면 저는 그 부분을 읽고 고친 다음, ‘fixed’ 같은 커밋을 한 뒤 동료들에게 다시 브랜치를 리뷰할 상태가 되었다고 알려야 하죠. 이런 실수를 직접 찾게 되면 엄청난 양의 시간을 절약할 수 있습니다. 이러한 실수를 하지 않으면 좋겠지만, 생각보다 잦은 실수를 하는 때에는 내 경험상 휴식을 취하는 것도 좋았다. 나도 내일부터는 Self Review를 해야겠다. 특히 좋은 부분은 오랜 시간동안 매일 처음 한 시간은 읽기에 투자하면서, 제가 제일 헤메던 부분에 대한 글을 중심으로 읽고 있습니다. 보통 오전 7시에 일어난다 치면 오전 8시까지 읽습니다. 빠짐없이요. 이 방법을 강력히 추천합니다. 문제를 해결하는 속도가 점점 빨라지는 것을 느낄 것이며, 계속 읽는 한 그 흐름도 이어질 것입니다. 나도 항상 느끼는 부분이라 요새는 아침 일찍 일어나서 활동 하려는 노력을 하고 있다. 한 달 정도 지나면, 아침에 일어나서 30분 정도 스펙을 읽고, 운동을 하고자 마음 먹었다! 아직 6개월이 남았기 때문에, 신년 계획을 수립해볼까 한다.

• 주니어의 짝코딩 경험기: 짝코딩에서는 가장 중요한 부분이 바로 이 부분이 아닐까 한다. "오랜 시간 집중 할 수 없을 수 있으니, 서로 상태를 체크해야 한다는 점이다." 지속적인 상태 체크로 짝코딩의 효율성을 증대하는 것은 가장 중요하다고 생각하는데, 나도 훗날 어느 정도의 실력이 쌓여 있을 때, 신입 개발자가 온다면, 한 달 정도는 짝코딩을 해보고 싶다. (물론, 상대가 싫어할 수도 있다는 점은 고려 해야 할 점이다.)

• How to use redis well: Redis를 실제로 자체 구축해서 사용할 일이 거의 없을 수 있는데, AWS에서는 사실 쉽게 지원이 가능하기 때문이다. 실제로 구축해서 사용시에는 어떻게 구조를 가져갈 것인지? 부터가 정말 어렵다. 클러스터를 사용할지? Master-Slave 구조를 사용할지? 그런데, 강대명님 자료를 잘 찾아보면 유용한 자료가 참 많다. 그런데, Redis를 사용하기 위해서 사용하는 Client가 필요로한데, Redis v4.0을 jedis는 여전히 지원을 못하고 있다. lettuce는 Spring에서도 많이 사용하고 있기에 보장이 되고, 업데이트가 굉장히 빠르다.