개발 단상

기본

개발자의 기본은 어떤 것이 있을까

주호민의 위펄래쉬를 보면 정말로 기본이 안된 만화들이 나온다 주호민작가가 말하는 만화의 기본은 말풍선, 폰트, 정렬, 채색, 스토리텔링, 연출 등인데 가독성을 위한 부분이다. 어떤식으로 연출하느냐에 대한 세부가 아니고 독자가 알아볼 수 있나 없냐의 부분만 얘기해주는데 정말 응모자의 고유영역은 안건들이고 잘 설명한다 기존의 만화에서 사용되던 관용표현을 쓰는 것을 기반에 두지만 하나씩 변화하는 것을 좋게 보는 점도 있다. 말풍선의 위치는 독자들이 원래 읽는 방식대로 하는 걸로 하는게 맞고 바뀌면 안좋다는 부분 공감. 독자의 시점에서 어떻게 보는지를 생각한다.

개발자의 기본은 어떤 것이 있을까 개발단. 개발된 프로그램의 독자는 유저 코드단. 코드의 독자는 개발자 개발자들이 공통으로 생각하는대로 코드를 짜면 코드 이해하기 좋을 것이다

기본이란 무엇인가

대학 커리큘럼? 사람들이 자주 쓰는 것들? 제작자의 가이드? 기술의 기반과 역사? 의도 혼합된 개념을 이루는 단일 개념

프로운동선수는 프로데뷔무대에서 기라성같은 선수들과 비슷한 퀄리티를 가진 채로 무대에 선다

개발자는?

가방의 본질은 수납

수납하기 위해 만들어졌다

개발자는? 컴퓨터는? 컴퓨터는 계산을 위해 만들어졌다. 인간이 귀찮게 안해도 되도록 개발자는 소프트웨어를 만드는 사람 인간이 귀찮게 안해도 되도록 컴퓨터가 일하도록 만드는 프로그램을 만드는 사람 소프트웨어란

처음 만들어진 소프트웨어는 수학문제를 풀기위한 것 문서 작업용으로 많이 쓰였었고 지금은 여러 물리적 공간을 연결해서 접근이 쉽게 해준다(배민, 우버) 공간, 시간의 제약을 줄이는 것에 뛰어나다(인터넷 예약) 계산을 빨리 해준다(머신러닝)

중요할 때 이상동작 하지 않는 신뢰성, 안정성 고장나면 바로 교체할 수 있는 모듈화 망치에 고무를 둘러서 사용성을 증가시키는 것

피드백을 해달라고 할 때 해줄 수 있는 여유

주니어가 도메인에 대한 정보, 업무 노하우, 관련지식, 여태의 경험을 공유해달라고 할 때 딱 정리해서 알려줄 수 있도록 하면 좋겠다

개발자는 이직을 하면 그 빈자리가 큰 구멍이 될까 아니면 누군가 대체할 수 있을까

내가 없으면 안돌아가도 문제고 누구나 나를 대체할 수 있어도 문제다

사람이 100% 대체되는 것은 불가능 하지만.

Geeknews에서 나를 대체 가능하게끔 일을 하자는 글을 봤는데 아주 마음에 들었다. 내 지식을 문서화하고, 내 경험을 다른 사람과 나눔으로써 나에게도 객관적인 지식이 쌓이고, 회사에도 객관적인 지식이 쌓인다는 태도였다.

• https://news.hada.io/topic?id=4442&utm_source=weekly&utm_medium=email&utm_campaign=202125

작업 하다가 쉬고 싶을 때 집중력이 높은 상태에서 깨지는 것이 안좋지만,

고장 난 테스트를 작성해서 다시 돌아 왔을 때 시작지점이 되게 할 수 있겠다

데이터 엔지니어도 재밌겠다

데이터 관련 작업을 취미로 해보자

데이터는 계속 쌓이는 거라서 데이터 없는 작업을 해볼까 생각해봤지만 수파리를 내가 의미있게 생각한다면 처음의 쌓는 과정이 필요한 것은 거부할 수 없다. 즉, 데이터는 필요하다. 그리고 그 쌓은 데이터를 파하는 작업도 할 수 있으니 데이터 관련 작업은 재밌는 작업이 될 것이다. 쌓아두는 것보다 나눠주는 것을 더 좋아하려고 했으나 나눠주려면 쌓아야 하는 것도 있다. 쌓는 그 자체가 목적이 아니라 그 다음을 위해 쌓아야 한다.

정보를 기반으로 가설을 세우고, 검증하고. 피드백을 혼자서 만들어 낼 수 있다?

개발 대회 입상

경력 개발자는 대학생들 대회에서 입상을 할 수 있을까? 글쎄, 입상을 한 사람은 입사 후에도 개발을 잘할까? 글쎄, 근데 그럼에도 한 영역에서 자신만의 접근법을 가지고 훌륭한 결과물을 만들어냈으면 그 접근하는 능력으로 개발도 잘 할 수 있다.

블록체인 회사에 들어가서 일을 하게 되면

관리보다 코어 프로그램을 발전시키기 위한 개발을 하게 될텐데 내가 아는 지식으로 기존의 프로그램보다 더 나은 알고리즘을 만들 수 있을까? 수학적인 지식 없이? 블록체인에서 자원을 얻어가는 것만을 방지하기 위해(자발적인 참여를 위해) 코인같은 보상이 나오게 되었는데 보상 대신 다른 방법이 없을까?

30살까지 프로그래머로서 달성하고 싶은 것들

오타니의 8개 구단 드래프트 1순위와 같은 추상레벨로

• 나는 오타니 만다라트에서 구체적이고 명확한 목표에 끌렸었다 논리력, 연상력, 기초, 깊이를 어떤 목표설정을 할 수 있을까

프로그래머의 가치를 소프트웨어의 가치와 접목시킬 수 있을까

개발자는 멋진 직업이다

코드를 어떻게 짜면 좋을지에 대한 추상적인 탐구로 코드의 질을 높일 수 있다 하지만 실제 코드를 짜면서 그것이 모두 되지 않는다는 것 또한 실전에서 바로 느낄 수 있다 이상적인 그림도 크게 그릴 수 있고 현실적인 경험도 할 수 있는, 책을 통해 발전 가능하지만 책에만 갇혀있지 않는 실존적인 직업임이 멋지다.

다른 개발자의 후기나 경험담이 인터넷에 자료가 많다 나도 잘 공유해야지

음악이나 수영 등 각 분야에서

잘못 습관을 들인 경력자보다 생초짜를 새로 가르치는게 쉽다고 한다. 나는 야생의 개발자에 속하는데 잘못된 습관 때문에 다른 사람에게 피해를 안줬으면 좋겠다

개발자가 게임의 테마와 진행방식, 어떤 점에 중점을 줄지 생각하지 않고 기획자가 하게 된다

그러면 개발자의 역할은 무엇일까 개발과 기획을 나누는게 맞을까, 큰 서비스를 할 때는 나뉘게 되겠지만 개발자가 기획을 하지 못하는 것은 아니다 엔지니어의 영역

구현하려는 것을 깔끔하게 구현하기 - 여기서 개발자의 의견이 더해질수는 있지만 메인은 아니다 구현한 것이 오류를 일으키지 않게 하기

사람과 기계를 연결하는 일 기계 - 컴퓨터 - OS - 작업환경 사람이 할 수 있는 것을 쉽게 하게 해주는 일 사람이 할 수 없는 것을 하게 해주는 일

주고 싶은 가치는 따로 있을 것 같다 사람의 편의, 효율을 늘리는 것 효율을 크게 늘릴수록 좋은 소프트웨어인가?

전체 소프트웨어 레벨에서는 효율성 증가를 목적으로 두고 각 소프트웨어는 각 기계처럼 각자의 목표가 있겠다 하나의 소프트웨어는 하나의 기계와 같다 식기세척기는 식기를 잘 세척하는 것이 목표다 앨런튜링 리누스토발즈 리차드스톨먼

소프트웨어는 커널, OS, 프로그래밍 언어, 화면에 종속된다 + 네트워크 + 사용하는 서비스 + api

Is developer an engineer?

Creator#예술가와 엔지니어의 차이

• 실제 문제를 해결해야 한다

구글 엔지니어가 일하는 법 이라는 책에 우리는 software engineer라고 이야기하고 있다. 그리고 이건 개발을 포함하는 큰 범주의 개념이라고 이야기한다.

한 곳만 깊게 파는 개발자와 넓고 얕게 파는 개발자에 대하여

예술적으로 소프트웨어를 만들고 싶은 개발자와 공학적으로 소프트웨어를 만드는 개발자

스페셜리스트, 제네럴리스트

한 도메인에 오래 있어서 전문가가 되는거라면 나는 전문가가 안되겠다. 한 분야의 스페셜리스트보다는 제네럴리스트가 되겠다. 예전부터 스페셜리스트, 제네럴리스트에 대한 얘기는 있었는데 도메인에 묶인 전문가의 얘기를 듣고 그럴싸하게 생각해버렸다

어디에 둬도 애매한 사람이 아니라 어디에 둬도 잘하는 사람이 되야겠다

넓게 두루두루 하려는 개발자 vs 한 곳만 깊게 파는 개발자

백엔드도 제대로 못하면서 이것 저것 다 하려고 한다 vs 여러 분야를 다 내가 신경쓰고 싶다 풀스택 개발자를 말도 안되는 것이라고 한다 백엔드와 프론트엔드만 하는 사람들보다 못하는 이도 저도 안되는 사람이라고 한다 엉성하다고 한다 기획자와 개발자를 나눔으로써 더 큰 소프트웨어가 된단다 좁은 곳에 집중해야 깊게 팔 수 있단다

개발자가 제품에도 신경을 써야 한다 코딩만 하면 안된다고 한다

그러면 기획자와 개발자는 나눠도 되고 코딩과 일련의 작업은 나누면 안되는 것인가? 그럴리가 없다

T자 커리어가 개발자들 사이에서 나오고 있다. 깊이 하나를 박아놓고 양 옆도 넓히는 것 좁고 깊은 것이 효율적이라는 일련의 공감대가 있기 때문에 이런 이야기가 나온 것이겠지 좁게 깊게 파되, 넓이도 가져갈 수 있는 방법은?

좁은 영역이라는 것의 경계는? 글씨를 잘 써서 글씨만 대신 써주는 사람이 있다고 한다 사람은 경계가 없고 모두 개별적으로 인식해야 할 것 같다

말을 아끼는 것이 좋다고 생각했었는데 자기 어필은 해야 할 것 같다 아는 것을 떠벌리고 싶진 않은데 내가 할 수 있는 것은 알려야 한다

원하는 것이 있을 때 정확히 원하는 것을 얻지 못할 때 타협하는 것이 도망치는 것이 아니라 쫓을 수 없는 완벽이라는 지향점을 놓아주는 것이어야 한다.

현재에 충실하되, 미래를 대비

다음 세대는 모두가 프로그래밍을 할 수 있는 세대가 될 것이다.

그렇다면 직업적 프로그래머와 그들과의 차이점은 무엇이 될 수 있을까 원하는 프로그램을 구상하고 구현하는 것은 코딩교육과 노코드 프레임워크로 어느정도 구현할 수 있을 것이다 (물론 더 나은 교육이 나올 수 있지만) 대규모 엔터프라이즈는 개개인이 접근할 수 없으니 이 영역만 남게 될까? 퀄리티의 차이를 논할 수는 없을 것이다. 프레임워크가 발전하면서 오히려 더 깔끔한 코드가 나올 수도 있기 때문에.

프로그래머라고 이야기하면 수학 잘한다고 생각하는 경우가 있는데

수학은 전혀 못하지만 컴퓨터를 좋아하면 프로그래머가 될 수 있는 것 같다 컴퓨터에서 뭔가를 내가 만들어 동작시킨다는 것이 재밌기 때문이다

페어 프로그래밍

• 짝 코딩을 하면 딴짓을 못하기 때문에 하루 8시간 중 7시간을 코딩과 업무 분석에 집중할 수 있었다.
• 핵심은 쉬지 않고 계속 말을 하는 것. 심지어int i = 0이런 걸 쓸 때에도 계속 말하는 것이 핵심이다.
• 그냥 코딩만 해서는 의도 전달 효율이 매우 낮다. 말하면서 타이핑해야 하고 설명하면서 코딩해야 한다.
• 짝에게 계속 생각을 노출해야 한다.

이미 나와있는 기술은 써먹으면 된다

• 근데 FC의 기술은 분석하고자 한다
• 분류가 다른가? FC를 분석하려는 목적, 종착지는 어디인가
• 써먹기 위해 분석이 필요한데, 이 FC 분석은 클론코딩을 하고 거기에 개선을 하기 위해서였다

리눅스라는 운영체제가 공개되어 있는 상황에서

os를 바닥부터 만들필요없이 원하는 부분만 바꿔서 자신의 시스템에 도입하면 된다
os 에서 한단계 추상화가 생긴것이다
리눅스를 쓰고 싶지 않아하는 사람들도 있을 것이기에 리눅스를 보고 그것과 다른 무엇인가를 만들 수 있다
그렇다고 해도 그것은 리눅스가 공개되어있기에 가능한 것이다
이렇게 한 분야의 추상화 단계를 높이는 작업물을 만들어낸다면 세상의 발전에 기여하는 것이 되는 것 같다

개발자는 다른사람이 읽기 쉽도록 코드를 짜야하고

비슷한 컨벤션 속에서 산다
같아지기 위해 노력하는 것처럼도 느껴진다
나만의 개성과 느낌을 살리려면 어떤 포인트를 살릴 수 있을까
기술직은 예술적이면 안되나?
art of programming 의 목차를 보자 목차만 봤을 때는 컴공입문공학서적같다 해커와 화가나 임백준님의 글을 다시 보자 #behavior

소프트웨어는 객체로 이루어진다

소프트웨어는 객체로 남아있어도 되는 것인가? 객체가 주체가 되려면 어떻게 해야하나. 인공지능을 가지고 스스로 뭔가를 하면 주체가 되겠지..

같이 일하고 싶은 개발자

• 사람을 잘 이해하는 개발자
• 배움을 계속 하는 사람
• 대화가 잘되는 사람
• 문제해결을 잘하는 사람
• 긍정적인 사람(건강한 사람)
• 다른 영역도 잘 이해하는 사람
• 읽기 좋은 코드를 쓰는 사람
• 서비스에 애착이 있는 사람
• 코드에 이유가 있는 사람

같이 일하고 싶은 개발자

예) 신뢰를 잃지 않기 나를 신뢰하는 거래처를 스무 군데 이상 발굴한다 고객이 평가하는 신용 평가에서 A 등급을 획득한다 주어진 업무를 데드라인 1시간 전까지 마무리한다, 미팅 시간 10분 전에 참석한다

지배가치 : 같이 일하고 싶은 개발자 장기 목표 : 중간 목표 : 세분화 : 일을 하기 전 계획을 세우고 일을 하고 나서 돌아보는 작업을 꼭 하고 싶다 -> 캘린더에 작업을 작성하고 -> 작업 내용을 공유한다 근데 업무가 딱 끝나는 경우는 없고 여러번 봐야한다

코드 줄 수가 적을수록 관리할 포인트가 줄어든다

1000페이지의 코드보다는 100페이지의 코드가 관리하기 쉽다 하지만 압축적이고 은밀한 코드를 남발하는 것보다는 풀어 쓰는 편이 낫다 추상화를 잘 쓰면 좋지만 난독화가 되지 않아야 한다 의미가 감추어지면 안된다 추상화 속에 전제조건이나 종속성이 숨을 수 있겠다 테스트코드를 먼저 적고 테스트 코드만 통과할 정도의 함수만 작성하고 문제가 생기면 추가하는 방식으로 한다

다양하지만 넘치지 않는 함수

다양한 케이스를 커버할 정도로 추상화시켜야 하지만 요구받지 않은 사항까지 예상해서 만들면 안된다

한 함수가 여러 상황은 커버하지만 당장은 필요없는 함수는 만들 필요 없다라고 하면 좀 쉽네

제네릭 프로그래밍과 정적 타입 언어가 동적 언어와 비슷한 걸 하려는 것 같다

세부적인 개발

예를들어 ejs에서 html로 렌더링 하는 방법 같은 것은 아주 구체적인 부분이지만 딱 그 영역에만 쓰이고, 기억에서도 금방 사라진다. 그래서 구체적인 개발은 하다보면 되는거고 구조를 생각하는게 더 낫겠다고 생각해서 지금의 공부를 하게 되었는데,

이는 경험을 무시하는 것이 되었다. 경험이라는 것이 그 분야를 익히는데에 성장을 많이 시켜주는데 세부적인 것은 까먹더라도 뭔가 남는다.

한 곳을 깊게 파면 경험이 남는다 근데 그 경험을 잘 남기는 방법도 생각해야겠다. 그냥 구현에 급급하면 경험마저 날아간다.

작업 처리라는게 이전에 8시간 만에 되었다고 다음에도 8시간에 되는 것이 아니다

7시간 동안 생각하다가 1시간만에 구현되도 8시간이고, 1시간 생각 후 2시간 동안 구현하다가 망해서 다시 3시간 생각하고 3시간 구현을 다시 해야 할 수도 있다.

업무에 분명히 데드라인이 있으면 해결의지가 강해져서 완수될 가능성은 높아지지만 안풀려서 데드라인 앞에서 급하게 정리한다고 적당히 수습해야 할 때도 있다

적당히 수습을 잘하는 것이 능력일까? 데드라인을 잘 설정하는 것이 능력일까? 둘 다 능력이 아니고 맞춰나가는 것이다.

마무리는 없으니 짧은 단계를 순환시켜서 계속 발전시키는 방향으로 가면 좋겠다

공수에 맞추지 말고 사이클 마감 시간의 기준으로 설정하면 되겠다 8시간 공수면 한 사이클에 끝날수도 있고 3 사이클을 돌릴 수도 있고.

일정 산출 기준을 이전 작업으로 잡고 할 수도, 내 기준으로 할 수도.

피드백 소프트웨어

api 서버에서는 원하는 요청에 대해 기대하는 결과값을 설정해두고, 피드백 소프트웨어에서 확인하여 원하는 결과값이 안나오면 조절해주는 방식을 구현해보자

월간윤종신

나만의 소프트웨어도 월(년)마다 내도록 계획하고만 있다

프로그래머의 취미를 프로그래밍으로 하는 것에 대하여

프로그래머는 개발하는 것을 재밌어 해서 일 외에도 개인적으로 프로젝트를 하곤 한다

신입으로 들어갔을 때 회사의 스택에 빨리 적응하기 위해 집에서 공부를 하는 경우도 있다

하루의 대부분을 하나의 작업을 계속 하는 것이 다소 답답하게 느껴진다 공간의 분리처럼 일과 생활의 분리, 관심사의 분리가 가져오는 장점이 있을 것이고, 하나에만 집중함으로써 깊게 파고드는 것의 장점도 있을 것이다

좋아하면 하게되고 하다보면 새로운 것을 알게되고, 더 깊게 알게 되고, 알게 된 것들을 내 방식대로 바꿔보기도 하고, 새로운 것을 만들어 보기도 한다

퇴근 후에 개발을 하지 않아도 모든 경험이 개발과 연관될 수 있으니까 쫓길 필요 없다. 단지 생각난 것을 개발로 바로 나타내고 싶을 때 바로 접근할 수 있도록 해야겠다

삶과 개발이 나란히 있는 삶이 되어, 무엇을 하든 상관 없어지는 경지가 되면 좋겠다

단순한 것을 연결하는 것이 우아하다

유닉스의 철학처럼 단순한 것들을 연결(파이프)하여 복잡한 것을 구현하는게 우아하다 특정한 상황을 위한 복잡한 것을 만들어내는 것은 우아하지 않다 그래서 코드짤때 너무 한 작업이 커지면 찝찝해졌던 것이다.

데이터베이스 정규화

검색이 쉽도록 정규화를 하는 방식이 정리되어있는 컨벤션이 있다

어떻게 하면 서비스하기 좋은 소스를 작성할 수 있을까

npm 에 올라가 있는 라이브러리들을 참고해서 사용하기 좋은 코드형태가 있을지 확인해봐야겠다 종류가 다양하게 있을 것이긴 하다

• golang 라이브러리 참고
• axios

키네시스

• 파티션은 나누고 청크를 천개로 하면 좋을까?
• 지금 입력 실패하면 재시도 하나?
• 근데 처음에 시도했던게 파티션을 나눈 건데, 이건 on demand의 용량을 초과해서 그런가? 각 메시지의 크기가 커서 그런가?
• 키네시스가 입력받을 수 있을 때 입력하게 할 수 있을까?
• 업데이트 실패 시 다시 시도할 수 있는 상황
• 발송완료 상태로 업데이트가 안됐으면 다시 검색할 때 걸리나?

개발

가려움을 해결한 방법 1

프로그램이 세이프티하게 돌아갈 수 있느냐에 대한 확신이 없었다 분명히 동작을 하다가 안전하지 않은 상황이 닥칠 것 같다는 불안감이 있었다 그리고 프로그램이 깔끔하게 잘 짜졌다는 생각이 전혀 들지 않았다 이런 문제들이 계속 나를 압박하고 있을 때… 리팩토링을 다시 생각하게 되었고, 안전에 대한 부분은 문제가 될만한 부분들을 예측해서 에러가 발생하게 되면 초기상태로 최대한 돌리는 방식으로 프로그램을 수정하기로 했다. 일단 해야될 것들을 다 작성한 후, 리팩토링을 지속적으로 해서 더 나은 프로그램을 만들어야 한다 한번에 작성되는 프로그램은 없는 것 같다 기존 프로그램은 동작 중 에러가 발생할 경우 초기상태로 되돌리는 코드가 있었으며, 동작 전에도 위치를 확인함으로써 제품의 불량이 나는 것을 최우선적으로 막은 것 같다 이를 계속 신경써야 하고, 리팩토링도 열심히 해야한다.

develop

• 어떻게 구동되는지
• 어떻게 효율화할건지
• 어떻게 보기 좋게할건지
• 어떻게 피드백이 잘 되게 할건지

개발을 하는 경우

일단 재밌어 보이면 해보는 경우 목차화를 해서 전체 흐름을 잡고 해보는 경우 해야할 목표가 있어서 그것을 해야할 경우 문제해결을 위해 문제정의를 하고 처리하는 경우

Safety programming

• Inner network only is safe? Every service has lots problem
• And it has used to user and responsive complain
• After that. Service is better than previous one.
• How to make program to same as it.
• Only accept have a certificate paper user system. Is it security?

Coding

테스트 케이스를 처음부터 최대한 적으려다 포모도로 프로젝트가 망했다.

필요한 기능을 확인하는 용도로 먼저 쓰고, 살을 붙여 나가는 방식으로 하자

함수는 하나의 동작 클래스는 하나의 변경 이유를 가진 객체 폴더는 하나의 의미 프로젝트는 하나의 목표

글쓰기

프로그래밍과 글쓰기의 상관관계

코드를 읽는 것은 책을 읽는 것과 비슷한 것 같다. 한 줄 씩 읽다보면 내용이 보인다 그런데 요즘의 프로그래밍 흐름은 책 읽는 방식과 달라지고 있다. 함수형 프로그래밍의 대두와 객체지향형 프로그램에서 부터 시작된 코드의 클래스화, 모듈화, 소형화가 코드의 가독성을 좋게 해주고 유지보수에 이점이 있다고 받아들여지고 있다

프로그래밍을 문학적으로 표현하면 위험하다 평소에 사람들이 느끼지만 언어로 표현하지 못했던 것을 작가의 특별한 언어로 그것을 떠올리게 해주는 것이 내가 좋아하는 문학적 표현인데, 이런 문학적 표현이라면 코드를 읽으면 뭔지 느낄 수 있어서 괜찮겠다 싶기도 하다. 이 문학적 표현은 현학적 표현은 아니니까

이걸 생각하다보니 예술, 문학이 관찰과 발견의 기능을 할 때가 좋은 것 같다. 예술의 목적이 이것뿐인건 아니지만 일단 이런 발견의 순간은 대체로 짜릿했던 것 같다.

Refactoring is like a revision

program is different with journaling

program haven't finish, journaling is. so program is need refactoring anytime. it is no defeat. it is strength.

코드는 절차지향에서 객체지향으로 오면서 책과 쓰이는 방식이 달라졌지만

읽기 좋아야 한다는 점은 여전히 중요한 가치다

읽기 좋은 코드는 책처럼 쓰여진 코드가 아닐까 객체화 된 코드를 어떻게 책처럼 읽히도록 할 수 있을까

코드는 파일, 폴더, 프로젝트의 구조로 되어있다 참조해야 되는 객체가 있는 파일은 같은 폴더에 있을 수도, 외부에 있을 수도 있다

인쇄를 통해 정보를 많은 사람이 전달 받을 수 있게 됐다

그리고 웹을 통해 더 많은 전달

문맥

문맥을 알아야 내용을 잘 이해하는 것은 코드나, 언어나 마찬가지인데, 어떻게 하면 문맥을 잘 공유할 수 있을까?

글쓰기 가이드

개발자를 위한 글쓰기 가이드 목차 체크리스트로 활용

명확성 간결성 일관성

독자를 정한다
깊이 조절
어조 분위기
주제
문서의 종류

퇴고의 끝, 출판의 시작

창작을 할 때도 퇴고를 하다가 계속 할 수는 없고 출판을 해야하는 순간이 있다 하루키는 출판이 되면 이제 더 바꾸고 싶어도 독자에게 넘긴다고 한다

개발할 때도 설계 단계에서 처음에 생각난 것에서 살을 붙이는 것을 전제로 하더라도 처음 생각난걸로 바로 시작하기 보다 설계를 좀 더 다듬고 시작하려고 한다 근데 아무리 좋은 설계도 수정할 부분이 생기기 마련이라 애자일이 요즘 방식으로 쓰이고 있다. 그렇다고 최초 설계를 짧게 가져가고 바로 시작하는 것도 다소 아쉬운 부분이 있는데, 최초 설계의 기간을 어느정도로 잡는게 좋을까 하다보면 좋은게 생각날 수 있음은 분명하지만, 방향설정은 필요한가 이번 개발에서 메시지, 메시지 히스토리를 구상한 것 자체가 의미 있는 것이었나, 그 세부 컬럼도 오래 생각한 것이 도움이 되었나? 얼마나 생각하고 시작해야 하나

생각은 하루를 넘기지 않는게 좋지 않을까

하루가 중요한건 아니긴 함

쭉 나열해서 일어날 상황을 그려보는 작업은 필요할 듯

개발하면서 생길 수 있는 미래를 구축하는 문학

짜여진 틀에 맞추는 것에 대한

의문문으로 책을 전체로 해서

억지인 부분이 있지만 그래도 내가 꺼내놓지 못할 것들을 꺼내도록 도와주는 장치로 틀을 이용하는 점을 부각 틀이 책에서 목차의 역할이라고 볼 수도 있다 목차를 상정해놓고 글을 쓰면 흐름이 잡힐 수 있다 정해진 내용만 쓰는게 아니라, 이렇게 정해놓지 않았으면 꺼내지 못했을 이야기를 꺼낼 수 있도록 끌어내주는 역할

기획과 개발에 대해 이런식으로 스토리텔링하는 것들은 있었다 #todo

Regacy

기존 리소스 활용 최대화

프로젝트 관리 툴 있다 고객 관리 대시보드 있다 회사 직원 관리 대시보드 있다 깃헙 관리 대시보드 있다 프로젝트들을 관리하는 대시보드도 있다

프로젝트를 하면서 쌓인 리소스를 활용하고 싶다 메타 프로젝트 관리 툴도 분명 있을 것이다 근데 없다. 잘 안찾아진다 소스코드도 활용하고, 서비스로 만들어진 것도 다시 활용할 수 있고 기존 서비스에 접근해서 쓸 수도 있고 간단한 함수를 가져와서 쓸 수도 있고 설정파일 가져와 쓸 수 있고 컨테이너 이미지 가져와 쓸 수 있고

레거시의 가치, 소중함과 한계

개발자는 방금 작성한 코드도 모두 레거시로 느껴진다

기존의 프로그램을 개선하는 것보다 아예 새로 짜는 것을 좋아한다 하지만 새로 짜는 것이 기존 코드를 넘어서기는 아주 힘든 일이 될 수도 있다 새로 짜는 것은 자기 마음껏 할 수 있는 부분이 늘지만 기존의 문제 해결을 모두 따라가야 하는 작업량의 압박도 있다. 모든 것을 새로 시작하는 것은 깔끔하고, 얽매는 것도 없어 마음이 편하다는 밝은 면이 있지만, 또 다른 레거시를 쌓는 작업이 될 수 있다.

레거시는 계속 쌓이게 되고, 그래서 처음부터 클린 코드를 염두에 두고 짜는 것이 좋은 소프트웨어를 위해서는 필요하다.

소프트웨어 개발에서 프로그래밍은 여러 축 중 한 축이고 코딩은 프로그래밍의 한 축이다 코딩이 프로그래밍의 전부는 아니지만 중요한 부분이고, 잘해야 되는 부분이다. 코더라고 비난하기도 하지만 코딩이라도 잘하는 사람이 더러운 코드를 짜는 아키텍처보다는 나을 수도 있겠다 코딩에만 몰두하고 디자인에는 신경 안쓰는 것도 문제지만 코드를 쉽게 생각하고, 코드도 못짜면서 다른 부분을 하려고 하냐고 하는 것은 개발에 대한 회의를 일으킨다

original program vs new program

어떤 것을 위해 프로그램이 만들어지면 그것에서 더 필요한 기능을 느끼고 새로 기능을 추가하여 프로그램을 만들어 기존 프로그램보다 매력적이게 된 프로그램이 있고 원래 프로그램이 믹강한 기술을 가지고 있어 새로 생긴 것들이 영향력을 못 일으키는 경우도 있다.

전자인 경우에서 새로운 기능을 가진 프로그램을 어떻게 찾고 어떻게 기능을 써볼 수 있을까? 계속 모니터링 할 수도 없는 노릇인데... 키워드로 알림을 만들어 놓아야 하려나

Regacy

기존양식 사용하는게 마음에 안드는 이유 내가 필요해서 만든 항목이 아니 와닿지 않는다

SWOT같은 분석 방법론이 마음에 안드는 이유 그 안에 들지 않은 더 중요한 내용을 놓치고 있는 것 같아서

공통 일일이 기억할만큼 통찰력 있는 내용이 아닌 것 같아서 #collection

생각난걸 바로 만들고 점점 개선시키려면

바로 만드는 것이 빨라야 한다 -> 템플릿 개선 -> 변화하기 쉬운 간단한 형태여야 한다

구글은 그들의 사이드 프로젝트를 어떻게 관리하나?

그냥 사람들 입소문으로 전달하나 레포지토리에 묶여있나 새로운 툴을 만들어서 관리하나

검색 시 너무 많은 데이터가 문제라면 필터를 많이 만들어서 노이즈를 제거하고 필터를 조금씩 푼다

적은 데이터라면 비슷한 영역을 캐치한다

쿠팡이 자체적으로 만든 서킷브레이커와 api gateway

직접 만든 사람들이 관리할 때는 잘 돌아가겠지만 사람이 바뀌면 기존 서비스보다 잘 돌아갈지는 의문이 든다 메뉴얼이나 구조가 잘 만들어져있으면 더 쉽게 관리가 되겠지만.

에러 감지 시스템에서 반복되는 오인식은 정인식이 되었을 때 무심코 넘기게 하는 사람이라서 생기는 문제가 있다 기계의 문제 + 사람의 문제이긴 하다

사람이 유연한 대처가 가능하지만 사람에게 어느 역할까지 맡겨야 좋을지는 모르겠다. 사람과 기계가 잘 상호작용이 이루어져야 할텐데

그동안의 리소스를 이용하는 것 vs 리소스와 별개로 새로운 것을 만드는 것

쌓고 쌓는 방식은 혼잡성을 증가시키고 옛날 것이 묻힌다

모듈 방식은 마이크로서비스. 이 또한 혼잡성을 증가시킨다

• 내가 kustomize를 안쓰고 싶어하는 이유가 기존의 리소스를 활용하지 않고 독자적인 것으로 만들어져서 너무 국소적이고, 나만 쓰게 될 것 같고, 새로운 것을 외워야하는 느낌이 들어서인데, 회사용 툴을 만들게 되면 이런 느낌을 주지 않을까

CRUD

기존에는 생성, 수정, 삭제, 조회 모두 API로 요청을 받아 처리하고 응답을 보내고 있었습니다. 하지만 분리를 하며 다음과 같은 이유로 조회를 제외한 나머지 동작들은 모두 이벤트로 동작하도록 수정했습니다.

• 조회 외에는 응답을 받을 필요가 없다.
• 조회 외에는 실시간으로 처리가 될 필요가 없다.
• 이벤트 방식으로 구현하면 외부 서비스의 의존성을 격리 시킬 수 있다. https://blog.dramancompany.com/2022/01/java-기반의-알림-서비스로-msa-전환기/

ETC

https://news.hada.io/topic?id=9723 소프트웨어 개발의 가장 어려운 점은 코딩이 아니라 요구사항

ai 가 잘 할 수 있는 것. 잘 모른다. 데이터로 할 수 있는 것. 많은 시간이 필요한 것?

세부적인 디테일이 아니라 큰 범위에서의 디테일도 있을 수 있다?

• 프로덕트 디자이너는 프로그램 내부를 알 필요 없이 자신이 아는 추상화된 부분에서 작업을 한다

소프트웨어에서는 한 동작을 바꿀 때 다른 동작이 영향을 적게 받게 하는 것이 좋다

어떻게 정보를 공유하고 확산하는 것이 효과적일까

건물 붕괴 사고 후 법이 개정되면 하도급 업체까지 그 정보를 다 알 수 있을까? 새로운 무엇인가가 나오면 그것에 대해 어떻게 알 수 있을까? 관리자가 따로 있다면 그 사람은 새로운 것을 계속 확인해야하니까 알 수 있다고 해도 일반 노동자들이 그 새로운 정보를 계속 확인하지는 않을 것 같다. 그렇다고 정부 사이트에 새로운 소식들을 계속 올린다면 정부페이지만 확인하면 된다는 인식을 가지고 확인할 수 있겠지만 정부 사이트에 올라오는 글들이 너무 많아지면 정작 자신에게 필요한 정보를 못 찾을 수도 있다.

why I choose this company

• vision can growth with me
• skill set is what I want to improve
  • large scale traffic
• industry is interest to me
• 내가 원하는 기술을 쓰는 회사
• 내가 해보고 싶은 것을 하는 회사
• 좋은 아이템과 좋은 사람을 가지고 있는 회사
• 좋은 사람은 공유하는 글, 채용 프로세스(사용하는 기술도 여기 있다)로 파악, 좋은 아이템은 회사 소개에 항상 있다
• 좋은 실적까지 있다면 금상첨화

Economics

what is the condition that selects the company state?

1. trendy
2. I want to challenge a pair programming
3. I want to manage a lot of people used service
4. I want to deploy for big traffic stream infra

• 회사가 가진 매력을 알고 싶다
• 같이 일할 팀원들이 어떻게 일하는지 알고 싶다
• 회사의 분위기

이 회사에서 할 수 있는 것

일을 처리하는 능력 (계획 실행 확인) 주변사람의 장점을 파악해서 그 장점을 내 습관으로 만들고 안좋은 점은 피하는 삶을 산다

존경할만한 사람이 있는 회사에 취직해라

• 지금 직장은 존경하고 배울것이 많은 회사이다. 형들과 얘기를 많이 하면서 많은 것을 가져와야겠다. 배울 수 있는 것들을 최대한 이끌어 내야 한다.

• 회사의 지식과 정보를 다 데이터화 시켜놓자

• 홍보는 제품을 소개하면서 회사도 소개시켜야 한다

• 글을 볼 때 글을 쓴 사람을 알게 되면 내용에 더 집중하게 된다