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

코드의 변질 - 레거시 코드는 왜 늘 개떡같을까?

• 글의 마지막이 인상적인 문구가 있는데, 정말 많은 공감을 한다. 레거시 코드는 왜 항상 변경이 어려울까?라는 고민을 해 보았다면, 많은 공감을 받을 수 있는 글이다.

개발자가 안된다고 했을때의 진짜 이유 - dobiho on HCI

• 이 분이 생각하신 개발자가 "안 된다"라고 말하는 이유 3가지에 대해 정리 해 주셨는데, 내가 생각 하는 부분과 약간의 차이가 있다.
• "할 줄 모른다"의 경우는 사실, 대부분 그냥 말 하는 경우가 없다. 할 수는 있지만, 어떤 부작용이 생김에 대해 말하는 개발자가 많다. 그러나, 대개 기획 쪽에서 다른 곳은 이렇게 하는데, 왜 여기는 안되나요? 라고 묻는 사람들이 굉장히 많다. 이런 상황에 있어서는 예의의 문제이다. 내가 할 줄 몰라도 문제지만, 그렇게 서로 말하는 순간 사람과 사람간의 문제가 발생 한다. 그리고 할 줄 모를 수도 있다. 서로 인정을 해야 한다. 좋은 예시는 전문가를 데려 오는 방법이다. 해법은 많다.
• "시간이 부족하다"의 경우는 항상 사람을 붙인다고 해결 되는 문제는 아니다. 그리고 더군다나 처음 스펙 리뷰 단계에서 이러한 스펙이 필요로 하니 미리 언급을 해주어야 개발자들의 충격 완화가 덜 하다. 이는 애초에 커뮤니케이션 미스라고 생각 하는 편이다. 갑자기 고사양의 스펙을 들고 와서 해달라고 하면, 개발자들은 마법사가 아니다. 사람을 더 붙여서 해결 할 수 있는 일이 있고, 오히려 더 붙으면 생산성이 떨어지는 경우가 있다. 고로, 사람을 더 붙인다고 모든 일의 만능이 아니다. 그렇게 생각 하는 관리자, 기획자, PM이 있다면 그 팀에서는 일 하기 어렵다.
• "하기 싫다"의 경우는 대부분 개발자들이 이 작업을 왜 해야 하는지? 설득이 부족한 경우라고 생각 하는 편이다. "지표 상으로 이게 필요하다. 내가 보기엔 이게 더 좋다."라는 니즈가 있을 수 있는데, 개발자들은 이해하기 어려울 때가 있다. 스펙에 대한 명확함이 부족도 이유가 된다. 그럴 때 "하기 싫다" 그렇기 때문에, 어떠한 설득력은 개발자도, 기획자도, PM도 필요로 하다. 업무에 대한 설득력이 떨어지는데, 일의 완성이 글로벌한 품질을 가지기는 어렵다.

카카오페이지 글로벌 웹 개발 후기

• 인도네시아 서비스를 개발하면서 겪은 후기담인데, 겪었던 이슈나 사용 했던 기술 스택이 잘 정리 되어 있다.

[번역] 개발 배우기가 정말 어려운 이유

• 이 글을 통해 왜 개발은 배우기가 어려운지? 자세하게 알 수 있다. 물론, 요즘 코딩 열풍이다 싶을 정도로, 패스트캠퍼스, Java 교육으로 워낙 유명한 비트교육센터, 클래스101등과 같은 코딩 교육을 온/오프라인으로 하는 곳이 많고, 뭐 하면 연봉 5천 무슨 엔지니어는 연봉 7천이다 라는 자극적인 글, 유투브 홍보 영상들을 보고, 많은 사람들이 또는 어떤 동기에 의해 개발자를 하려고 하는데, 생각보다 쉽지 않다. 클론 코딩은 단순히 그냥 클론 코딩으로 생각해야 한다. 내가 인스타그램 클론 코딩 했다고 해서 인스타그램에 취직 할 수 있는 것은 아니다. 단적으로 확실한 니즈가 있는 사람, 어떤 호기심을 꾸준히 관리 할 수 있는 사람이 개발을 배우면 적합한 생각을 많이 하는 편이다. 어설픈 개발 익히기를 통해 다 할 수 있는 영역이 아니다. 시작은 좋다. 하지만, 시작을 했다면, 글에서 정말 자세하게 소개하는 지루한 영역도 지나고, 꾸준하게 익힐 수 있는 능력을 잘 키우는 것이 정말 중요하다.

With Great Tech Comes Great Responsiblity

• 모질라 재단에서 기술 산업의 윤리 문제에 대한 PDF를 무료로 배포하고 있다. 11페이지 정도라 그렇게 많은 분량은 아니라서 시간 날 때 읽어보면 좋겠다.

Introduction

• Bash shell에 대한 정리가 정말 잘 되어 있는 글이다. 사실 맥과 리눅스를 쓰다 보면 Bash shell, Bash script를 통해 편리한 작업을 한 번에 해결 할 수 있는 경우가 많다. 그래서 공부를 틈틈히 하면 정말 좋다고 생각 하는 편이다. (물론, 쉘 스크립트의 달인이 될 필요는 없다.)

블로그 새단장 후기

• 블로그를 정말 깔끔하게 만드셨는데, 만드시면서 고려한 요소들을 소개 하고 있다. 생각해보니 나는 Styled-component를 써보지도 않았는데, emotion, TailwindCSS을 적용 하셨다. 개인 프로젝트에서 써봐야 뭘 알텐데, 사실 CSS를 직접 작업 하지 않기 때문에 개인 프로젝트에서 쓰기도 좀 모호하다. 개발보다 CSS에 더 공을 들여야 하는 경우가 훨씬 많았다. 그럼에도 올해는 좀 도전 해봐야 하는 영역이라 생각 한다.

Introduction | Remote Work 2020

• 원격 근무에 대한 내용이 총집합 되어 있는 글인데, 원격 근무에 대한 설문조사 결과도 포함 되어 있고, 원격 근무가 잘 맞는 사람이면, 사무실에 가서 일 하는 것이 원격 근무 하기 전보다 더 어려울 수 있겠다는 생각을 하게 되었다. 특히, 생각보다 "커피숍에서 일을 많이 안하는 구나"를 또 알게 되었다.

HTTPS에 대해 알아야 할 것들 | Mimul Tech log

• 점점, 모던 브라우저들이 HTTPS 사용을 강제 하려고 하는 움직임(크롬의 경우 안전/비안전 표시)이 많은데, 관련해서 잘 정리 되어 있는데, 특히, 라이브러리들의 버그들과 해결 방법들도 잘 정리 되어 있어서 참고하기 좋다.

Browse good first issues to start contributing to open source

• 대다수의 개발자들이 오픈 소스 프로젝트에 어떻게 기여 하면 좋을지? 고민이 많은데 첫번째 이슈를 시작하는 좋은 방법에 대해 소개를 하는 글이다. 요즘 오픈 소스 프로젝트들에 보면 good first issue가 라벨링 되어 있다. 특히, 오픈 소스 프로젝트의 기여자들이 이전에 작업 했던 이슈들을 잘 살펴 보는 것도 좋은 가이드가 될 것 같다.

JavaScript

You Must Understand These 14 JavaSript Functions

• 유용한 JavaScript의 함수를 직접 구현 하면서 이해 할 수 있게 코드와 실제 예시를 통해 설명 하는 좋은 글이다. 직접 함수 하나 하나 입력 해보고, 어떻게 구동 하는지? 원리를 이해 하면 실력에 좋은 도움이 되지 않을까? 하는 글이다.

Tool

Kubernetes 커맨드 라인 툴

• 쿠버네티스를 쓰다 보면, 명령어를 자주 입력 해주어야 하는데, 이런 방식을 적용하면, 생산성이 올라 가기 때문에 자동 완성이나, 다른 콘솔 모니터링 도구들을 쓰는 건 정말 편리하다. 물론, 회사에서 쓸 수 있을지는? 고민을 좀 해 봐야겠다.

Roam: Why I Love It and How I Use It - Nat Eliason

• Roam 이라는 노트 어플리케이션인데, 왜 좋은지? 소개 하는 글이다. 참, 신기하게 노트들의 네트워킹 구조를 만들고 그 구조를 레이아웃으로 볼 수 있다는 점이 다른 노트 앱들과는 다른 점 같다. (약간, RDBMS의 테이블 구조라고 할까..)

Mirage JS * An API mocking library for frontend developers

• API mocking 라이브러리인데, 굉장히 유용하다는 생각을 하게 되었다. 사용할 일이 생기면 꼭 써 봐야겠다.

Working with Vim

• vim 튜토리얼에 대한 글인데, 사실 영어라 온전히 이해하기가 쉽지는 않지만 따라 하는 느낌으로 읽으면 도움이 많이 된다.

일반적인

아마존에서 고객평가 최고상 받은 '일기장'

• 습관 일기장을 통해 아마존에서 엄청난 성장을 하고 있는 제품이 있는데, 6가지의 일기장을 판매 한다고 한다. 사실 계기는 아무래도 대표의 습관 만들기에서 회사 창업까지 오게 되었다고 한다. 번역된 일기장이 한국에서도 출시 되면 좋겠다. (내가 영어로 쓸 순 없으니까..)