Street Coder
농담이 많아서 재미있게 읽고 있습니다.
제가 모르는 C#과 .NET을 기반으로 하는 점은 아쉽지만..

책 소개 문구입니다.

[마감일 vs 코드 품질, 무엇을 우선시할 것인가?]

프로그래밍 세계의 이상과 현실 속에서
살아남기 위해 필요한 ‘길거리 지식’을 배우자!

컴퓨터 과학 이론, 알고리즘, 데이터 구조, 테스트, 코드 최적화, 리팩터링 등 코딩할 때 적용해야 하는 다양한 이론이 있다. 하지만 현실은 마감일에 쫓겨 작업의 우선순위를 정하고, 어떤 규칙을 어겨야 할지를 빠르게 결정을 내려야 하는 상황에 내몰리곤 한다. 이때 우리에게 필요한 것은 무엇이 가장 중요한지 알아차릴 수 있는 ‘길거리 지식’이다. 어떤 규칙을 깨야 하고, 어떻게 깰 수 있는지, 무엇을 우선시해야 하는지를 알고 있어야 한다. 이 책은 추상적인 이론이나 상아탑의 이데올로기처럼 뜬구름 잡는 이야기가 아닌 독학으로 마이크로소프트 엔지니어가 되기까지의 경험을 바탕으로 한 실용적인 팁과 노하우를 담고 있다.

굉장히 중요한 질문이란 생각이 들어서 고민을 저도 좀 했습니다.
일단 가장 기본적인 것은 남들은 어떻게 코드를 짜는지에 대해서 좀 더 알아보고 읽을 필요가 있다는 생각이 들어서입니다.
기존에 제가 코드를 계속 짜면서 똑같은 것들만 짜다가 디자인 패턴을 공부하면서 다른 사람이 잘 만든 코드를 보고 따라하면 더 빠른 개선이 된다고 느끼게 됐거든요.
그래서 오픈소스를 읽어보려했는데, 이건 어떻게 해야하는지 너무 거대해서 아직 힘들다는 생각이 들더라구요

그러면 조금 더 작은 단위에서 좋은 코드를 읽어보자, 그런데 이번에 디자인 패턴을 봤으니 이걸 다른 방향에서 봐보는 것도 좋되 다른 관점에서 좋은 코드를 읽어보면 좋지 않을까? 이런 생각에 책을 찾게 됐습니다.

이 질문을 받게 된 것 자체가 그런데 가장 큰 수확이었던 것 같네요, 감사합니다

어떤 최적화된 방향이 있는 것은 아니니 이것 저것 읽어 나가며 그 해답을 찾아가실 것이라 생각하지만, 시작하는 단계에서 이정표 정도는 세워주는 역할이 되었으면 했습니다. 무엇을 해야할까 라고 고민하기 이전에 왜 해야할까 라는 고민을 먼저 해보면 좋겠습니다.
개발자라는 직업은 여러가지를 많이 알고 있어야 하는 것도 맞지만, 결국에는 쓸 줄 알아야 합니다. 해서 코드를 작성하는 것을 소홀히 하지 마시고, 계속 써보세요. 쓰다보면 조금씩 알게 됩니다. 왜 수많은 코드들이 실제로 책에서 제안하는 형식대로 작성하지 못했는지. 하지만, 책에서 얘기하고자 하는 의도를 어떻게 잘 표현하려고 노력했는지요. 그리고 이건 다양한 방법론 관련 책들을 읽어본 제 개인적인 견해인데, 객체지향적인 코드를 잘 작성하려면 어떻게 해야하는가에 대해서 얘기하고 있음을 알아가실 것이라 생각합니다.
해서, 책을 읽으며 지식을 쌓아가고, 코드를 작성하며 표현력을 길러보고, 다시 책을 읽으며 지식을 쌓아가고 좋은 순환을 만드시기를 바랍니다.

저 같은 경우는... 음... 무슨 책을 추천해야할까...... 잘 모르겠지만 많이 유명한 블로그 글 하나 링크걸어두겠습니다.
자바스크립트는 왜 프로토타입을 선택했을까
https://medium.com/@limsungmook/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%8A%94-%EC%99%9C-%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85%EC%9D%84-%EC%84%A0%ED%83%9D%ED%96%88%EC%9D%84%EA%B9%8C-997f985adb42

그리고 (백엔드 개발자를 지향하신다면) http / network / database 관련 전공 공부 많이 하시면 좋겠습니다. 그리고 kubernetes / 몇가지 db (sql, mongo, redis, hbase등) 좀 다뤄보시면 좋을 것 같습니다.
마지막으로 기술을 선택할 때 이 기술이 왜 선택되었는지에 대해서 고민하는 훈련을 해보시면 좋겠습니다. 그런 의미에서 언어의 발전사에 대해서 적혀있는 폴리글랏 프로그래밍 (https://product.kyobobook.co.kr/detail/S000001057511) 가볍게 읽기 좋은 것 같습니다.

좋은 말씀 감사드립니다.

요 근래 열심히 해야한다는 생각에 책도 많이 보고, 코드도 많이 쓰고 있었지만 말씀하신 방향성에 대한 고민은 모자라지 않았나 하는 머리를 한 대 맞은 듯한 질문이었어서 크게 고민하게 됐습니다.

여러 방향을 고민했지만 당장의 현실적인 구직 문제도 있고 제가 백엔드 자체를 꽤나 좋아해서 백엔드 개발자로 방향을 고정하고 공부를 진행하려합니다.

현재 그래서 토이 프로젝트로 선택한 것도 그래서 말씀하신 기술들을 이것저것 써먹기 좋아보인다 생각해서 채팅 어플리케이션 작성이었거든요. 목표로 하는 것은 sql, mongo, redis, go, azure 활용하는 것인데 조만간 채팅 부분 작성하기 시작하면 더 재밌어지지 않을까 싶네요. 이제 갓 기초적인 api 서버단을 배포할 수 있는 형태로까지만 작성하는데 완성한 상태입니다.

이런 코드를 작성할 때 요 근래 읽은 책들에서 배운 지식들을 말씀하신대로 잘 지키고 있는지 피드백하는 시간들을 가지면서 선순환을 만들도록 노력하도록 하겠습니다.

추천해주신 글을 읽으니 말씀하신 '왜 이 기술이 선택되었는지에 대한 고민을 하는 훈련을 해보시라'는 이야기를 하시는지도 알 것 같네요. 다른 언어에서는 class를 통해 상속하는 것을 왜 굳이 prototype이라 명명하는가를 플라톤의 이데아와 비트겐슈타인의 '전형적인 예시'를 통한 설명으로 이야기하니 굉장히 흥미로운 글이었습니다. 자바스크립트를 이해한다면 조금 더 재밌게 읽었을텐데 아쉽네요.

추천해주신 책 역시도 시간내어 읽어보도록 하겠습니다.

책도 책이고 제가 굉장히 오랜 시간이 지나서야 깨달을 수 있었을 법한, 혹은 도달하지 못해 괴로웠을 핵심적인 질문을 들을 수 있어 너무 감사합니다.

벡터 db가 뭔가 하고 찾아보니 이게 자료 구조 vector가 아니라 좌표의 개념으로 vector인 모양이군요. 얼핏 들었을 때는 단순하게 hash table의 계층이 여러 개인 것과 뭐가 다른건지 잘 이해가 안되는데 좀 더 찾아봐야겠네요.

마침 지금 읽고 있는 책이 데이터 중심 어플리케이션 설계라서 그런지 어줍잖게 알아먹을것도 같고, 아닌 것도 같고 재밌네요ㅋㅋ. 면접관 분하고 프리 인터뷰하는 과정에서 최근 인상 깊게 읽은 책 추천 받아서 읽고 있는 중입니다. graph db도 막 봤는데 여태까지 제가 아는 알고리즘 레벨의 graph edge는 weight 밖에 없었는데 edge에다가 label을 붙인다는 개념이 되게 재미있더라구요.

추천해주신 폴리플랏 프로그래머도 재밌게 읽었습니다. 어떤 의미로는 여러가지 db를 사용할 줄 알게 되는 것도 폴리플랏 프로그래머에서 이야기하는 바와 동일하네요. 기초적인 구조적인 한계 때문에 결국에는 다른 기술들이 대두하고, 이를 여러가지로 다룰 줄 알아야하는 것 같은 것이요

덕분에 즐겁게 많이 배웠습니다. 좋은 이야기 감사드립니다