11/8 TIL | 아샬님의 강의를 듣고.

이 사진 뭔가 색감이 예쁘게 잘 나온 거 같으다 :)

어제오늘 아샬님이 1기분들의 포트폴리오 코드 리뷰 겸 리팩터링을 해주시러 코딩 도장에 오셨다. 오셔서 엄청나게 좋은 말씀을 많이 해주고 가셨는데.. 기억이 조금이라도 더 생생할 때 한번 정리해보고자 한다.

---

1. 기능에는 가치를 드러내야 한다.
단순히 기능만 나열하면 안 된다. 이 기능을 통해 사용자에게 어떤 것을 제공할 수 있는지, 또 사용자는 이 기능을 통해 어떤 것을 얻을 수 있는지에 대한 가치가 명확해야 한다.(As-I-So 기법 활용) 기능은 영원하지만 화면은 일시적이다. 화면에 집착하지 말자. 

2. 규칙을 만들게 되면 우연에 따라가게 된다.
프로그래밍에는 정답이 없다. 이 경우에는 이 설계가 맞고, 저 경우에는 저 설계가 맞다. 근데 규칙을 만들어 버리면 설계에 대한 고민이 전혀 진행되지 않게 되고, 그냥 관습적으로 작성하게 된다. 이는 프로그래밍에 있어서 절대적으로 지양해야 한다. 끊임없이 고민하고 또 고민하자.

3. 당시에 최선인 것을 하면 된다.
분명 지금 내가 짜는 코드는 더 나은 방법이 존재한다. 하지만 그걸 내가 지금 해낼 여력이 없다면 그 순간 최선의 결과물을 내면 된다. 우선 완성을 하고 점진적으로 더 나은 방법으로 개선하면 된다. 일단 내가 지금 할 수 있는 최선을 다 하자.

4. 사용자 스토리를 계속 발전시켜 나가야 한다.
기획 단계에서 완벽하게 기획한 후, 개발로 넘어가는 경우는 거의 드물다. 맨 처음부터 완벽한 기획을 만들고 개발로 넘어가려고 하면 너무 힘들뿐더러 시간도 많이 소요된다. 처음에는 간단하게 시작해 개발하면서 사용자 스토리를 계속 추가해나가자.

5. 설계, 기능 구현, 기획이 동시에 진행되어야 한다.
앞서 말했던 4번의 내용에 이어 말하자면, 설계와 기능 구현, 기획은 동시에 애자일하게 진행되어야 한다(폭포수 X). 기획이든 기능 구현이든 어느 부분이 이상하다 생각되면 다시 돌아갈 수 있어야 한다. 이때 폭포수 방식으로 작업을 했다면 다시 돌아가는 것이 불가능하다. 때문에 동시에 진행되어야 한다.

6. 머리 아프게 고민해야 성장한다.
자신이 고민하여 해결한 것이 아닌 다른 사람의 도움으로 쉽게 해결한 것들은 결국 나의 것이 아니다. 내 머리가 쥐가 날 정도로 고민해서 내놓은 결론이야 말로 자신을 진정으로 성장하게 한다. 다만 쥐가 날 정도로 고민해서 나지 않는 결론이라면 어느 정도 고민하고 바로 도움을 요청하자.

7. 내가 구현한 기능에 대한 근거가 명확해야 한다.
내가 구현한 기능들은 내가 만든 것이니 왜 이렇게 만들었는지에 대한 이야기를 명쾌하게 전달할 수 있어야 한다. 예를 들어 면접에서 나의 포트폴리오를 보고 왜 Vue가 아닌 React를 사용했나요?라는 질문을 받았다고 가정해보자. 이때 '많이들 그렇게 하니까~'라는 대답이 아닌 'React는 이러이러한 장점을 가지고 있고, 이러이러한 단점을 가지고 있는데, 내 프로젝트 환경에서는 이러이러한 부분에 React가 더 적합하여 사용하였다'라는 식으로 명확하게 근거를 전달할 수 있어야 한다.

---

이밖에도 실제 라이브 코딩을 하시면서 더 Java와 소프트웨어 공학의 깊은 지식들을 나눠주셨는데, 내가 아직 그 정도의 깊이가 없어 모두 소화하지 못하는 것이 아쉬울 뿐이었다. 완전 초반 TIL인 8월 14일에 작성했던 <이젠 컴퓨터 덕후가 되어보는 거야>에서도 말했었지만 아샬님은 정말이지 엄청난 컴퓨터 덕후이신 것 같다. 하나의 질문을 해도 그에 대한 답변이 엄청나게 많이 돌아와 마치 먹어도 먹어도 줄지 않는 마법의 주먹밥통 같았달까... 나도 끊임없이 정진해서 이런 좋은 지식들을 더 잘 소화할 수 있게 그릇을 키워 깊이 있고 좋은 아키텍처를 설계하는 개발자가 되고 싶다. 그러기 위해선 오늘도 주어진 것을 열심히 하자. 그러다 보면 언젠가 그 어디쯤에 도달하지 않을까? 파이팅이다!💪