프로그래머스 시작이 좋아 🔥
오늘 프로그래머스 데브코스 풀 스택 과정의 OT가 있었다. 10시에 시작을 했고 정확히 60명의 동기분들과 운영을 도와주시는 운영진분들 3분이 계셨다. 그리고 추가적으로 해당 데브코스에서 교육을 해주실 강사분들도 와주셨다. 여기서 놀랐던 부분은 OT임에도 모든 강사분들이 참여해주셔서 앞으로 어떻게 강의를 진행하고 간략한 강의 진행 방식을 소개해주셨다는 점이다.
프로그래머스의 데브코스에 대한 강사진분들의 열정과 관심을 확인할 수 있었고 수강생으로서도 믿음이 갔다. 그리고 짧지만 이확영 CTO님의 좋은 개발자라는 주제의 강의도 들어볼 수 있었다. 평소 스스로 학습을 하다보니 정말 잘하시는 분들의 조언이나 강의를 들어볼 기회가 많이 없었다. 그런데 참 가려운 곳을 긁은 것처럼 오히려 빨리 앞으로의 교육 시간들이 나에게 다가와 주길 바라는 느낌이었다.
2월 쯤엔 아니려나 ㅎㅎ
너무나 기대가 되는 과정이고 꼭 성장할 수 있을 거 같은 느낌이 든다. 또 동기 분들도 Slack에서 간략한 인사를 나누었는데 느낌이 굉장히 좋다. 함께 성장하고 또 배울 수 있을 거 같다.
이확영 CTO님: 좋은 개발자란 ?
CTO님이 생각하시는 좋은 개발자에 대한 강의를 해주셨다. 실제 현업에서 일을 하고 있지는 않지만 프로필만 봐도 굉장한 분이라는 걸 느낄 수 있었다. 그럼 이러한 높은 수준의 개발자분이 생각하시는 좋은 개발자는 무엇일까?
- 문제정의와 해결을 잘하는 개발자.
이확영 CTO님은 이런 말씀을 하셨다. 결국 코딩도 AI가 하는 시대가 올 것이고 지금 많이 그러하다. 그럼 결국 AI가 할 수 없는 분야인 문제를 정의하고 해결할 수 있는 솔루션을 AI를 통해 구할 수 있어야 한다. 문제를 맞딱드렸을 때 문제를 잘 해결할 수 있는지에 대한 훈련을 하는 것이 중요할 거 같다.
프로젝트를 하더라도 문제를 맞딱드렸을 때 핵심 문제가 무엇인지를 파악하고 이를 해결하는 방법을 논리적으로 생각하는 연습을 해야겠다.
- 이해하기 쉬운 코드를 작성하는 개발자
사실 이해하기 쉬운 코드를 항상 작성하려 하지만 이건 객관성이 부족하다. 왜냐면 스스로 코드를 치고 또 내가 보기때문이다. 이번 데브코스를 통해 다른 분들의 코드를 잘 살펴보고 나 역시 나의 코드를 다른 분들께 보여줄 때 이게 복잡하게 보이지 않는지 또, 다른 분은 어떻게 쉽게 코드를 작성했고 변수를 어떻게 명명하셨는지를 잘 파악하자.
- 소통과 협업을 잘하는 개발자
소통과 협업을 잘한다는 증명으로 나는 동호회활동을 늘 앞세워 자기소개서에 채워넣었다. 그런데 흠 물론 동호회 활동이 다른 사람들과의 소통하는 능력에 도움이 되는 건 인정할 수 있다. 그런데 개발적인 측면에서의 부족함을 항상 느꼈었는데 이번 데브코스를 통해 내가 개발자로서 어떤 소통을 할 수 있고 협업의 상황에서 어떻게 대처할 수 있는지를 파악하고 이를 성장할 수 있도록 해야겠다.
- 끊임없이 개선을 하는 개발자
필자는 사실 이 데브코스를 듣는 이유 중 하나가 나의 개인 프로젝트를 개선함에 있어서다. 왜냐하면 필자의 프로젝트 역시 ReactJS, node.js를 사용했고 이를 개선하고자 하는 의지를 가지고 있다. 이번 데브코스에서 ReactTS를 배우고 node.js를 통한 백엔드 작업을 학습해 전체적인 웹 서비스의 질을 향상할 수 있을 것이라 판단하였다. 그런데 CTO님의 말씀을 듣고 다시 한번 프로그래머스 데브코스에 지원하길 잘했다는 생각이 들었다. 더욱 개선하고 고도화하는데 노력하는 개발자가 되어야겠다.
프로젝트의 관리
프로젝트를 어떻게 관리해야하는지에 대한 강의가 이어졌다. 프로젝트를 관리하는 방법중 한 가지를 배울 수 있었다. 바로 README.md 파일이다.
필자는 README.md 파일을 단순하게 완성 프로젝트에 대한 설명서가 아닌 구현중인 프로젝트의 현황을 더욱 표시하면 좋다는 말씀을 해주셨다.
README 단순 설명서가 아닌 프로젝트의 발자취 ❗️
README파일을 그 동안은 단순 프로젝트 설명서로 사용을 했다면 앞으로는 프로젝트의 발자취를 남길 수 있다면 더 좋을 것이라는 확신이 들었다.
여기 발자취에는 다음과 같은 것들이 들어가면 더 좋다.
구현된 주요기능
구현 현황
해결해야하는 문제등
MarkDown ❓
MarkDown문법을 주로 Gitgub의 README파일을 작성할 때 사용했었는데 이를 정확하게 짚고 넘어간 적은 없었다. 참고로 README.md에서의 md는 m(ark)d(own)의 약자였다..!!!
그럼 MarkDown의 역할은 ??
그냥 text파일로 README 파일을 작성해도 괜찮다. 하지만 이는 가독성이 떨어지게 된다.
Markdown의 최대 장점은 글자+가독성(꾸밈)이 가능하다는 점이다.
즉 "Markdown은 가시적으로 가독성이 좋게 만들어주는 웹기술이다."
웹에 적용되는 text꾸미기이다.
MarkDown을 사용하면 일반 text가 웹에서 예쁘게 변경될 수 있다.
버전 관리
버전이란 무엇일까 우리는 게임을 할 때도 사실 버전들이 모두 존재한다. 3버전, 3.2버전, 6버전 등 버전별 차이점은 분명한 수정사항이 있다는 점이다.
즉 버전은 유의미한 수정이 있어야한다.
그럼 버전을 관리한다는 것은 ?? => 유의미한 수정을 관리한다는점
버전관리=수정사항관리
이 뿐아니다. 기본적으론 수정사항을 관리한다는 공통점이 있지만 이로서 파생되어 오는 특징이 있다.
- 수정사항관리
- 백업
- 협업
자 수정사항을 관리해주다보니 백업이 가능하다. 만약 v4=>v6로 업그레이드 한 버전을 출시했다고 가정해보자. 그러다가 사용자가 v4를 더원하게 된다면 버전관리 툴을 사용해 v4에 대한 서비스를 지속할 수 있는 것이다.
또, 수정사항을 다른 개발자가 볼 수 있다면 어떻게될까? 함께 수정이 가능해지고 또 다른 분들의 수정사항을 나의 코드에 합쳐 더 큰 프로젝트가 가능할 수 있다.
아마 다음 시간엔 이 버전관리툴인 Git을 더 자세히 알아보게 될 것 같다!
중요한건
Git=> 버전관리툴
버전관리는 수정사항을 관리해준다.
오늘은 비교적 간단한 사항을 배웠지만 점차 이러한 템포를 끌어올려 스프린트를 진행할 거 같다. 그때까지 지치지 않고 꾸준히 성장해보자 화이팅 🔥
