이해한 내용을 설명할 수 있도록 한다.
가끔 이해한 부분이 있다면 설명을 할수 없더라도 그냥 사용할수 있으면되지 식으로 넘어가는 경우가 있었는데 개발실력 향상에 도움이 되지 않았음을 인지했다.
알고 있던 내용도 소홀히 듣지 않으려고 노력한다.
이미 알고 있던 내용에도 충분히 더 좋은 내용이 있을수 있기때문에 항상 새로운 마음가짐으로 임해야 함을 인지했다.
어려운 문제라도 계속 고민해보고 계속 해결해보려고 노력한다.
당장 해결할 수 없을 것 같은 문제여도 계속 고민해보려고 매달리고 시도하는것 자체부터가 이미 개발인것이다. 고민을 덜려고 쉬운 방법을 선택하려고 한다면 개발을 소홀히 하는것이다.
Depth가 깊다 : 이해할 수 없을만큼 복잡하고 난잡한 구조의 코드 (ex 중첩반복문)
더미데이터 : 본격적으로 개발을 시작하기전에 테스트하는 용도의 데이터, 확인용도로만 사용하도록 한다.
흐름이 없는 주먹구구식 개발을 하고있다는 피드백을 받았다.
이말을 들어서 너무 다행이라는 생각이 들었다. 내가 어떤코드를 짜고있는지
그 코드가 효율적인지 비효율적인지조차 알지 못하고 계속 개발을 진행한다면
겉잡을수없이 코드가 어려워지고 비효율적으로 변할것이다. 하지만 정말 안될때는
구현이라도 먼저 해보려고하는게 좋을것이다. 그뒤에 추가적인 리팩토링 또는 재작성을 통해서 비효율적이었던 코드와 다시 작성했을때 더나아진 코드를 같이 보면서 양면을 볼수있게된다.
나만의 코드로 이해하기
나는 내가 당장 사용할 수 있다면 굳이 내식의 코드로 작성하지 않아도 괜찮다는 조금 안일한 생각을 가졌던것같다. 하지만 정말 오만한 생각이라고 느꼈다
세상에 분석해야 할 코드는 넘쳐나고 새로운 코드는 앞으로도 얼마나 많이 나올지도 모르는 마당에 그런 코드들을 모두 다 갖다쓰는 방식으로만 작성한다면
내가 어떤 코드를 갖다쓰고있는지, 그 코드를 왜 사용하고있는지 이해할수 없을것이다.
가독성 향상
개발자도 컴퓨터 언어를 사용하는 한명의 작가 라고 생각한다. 왜냐면 글의 흐름이 논리정연해야하고 문맥과 어울리지 않는 코드는 작성하지 않으려고 노력하기 때문이다. 사용하기 좋은 코드라는 건 결국 사용자에게도 그 이점을 같이 전달한다고 생각한다. 그게 바로 가독성 인것같다.
피드백을 받았을 때 정확히 이해하고 사용해보기
아무리 잘나고 멋진 사람이 피드백을 주더라도 결국 본인이 직접 행하지 않으면 그 피드백은 지나가는 한마디가 될뿐이라는 생각이 들었다. 피드백을 아무리 열심히 들어도 나는 기록만 해뒀을 뿐 진행하고 있던걸 마저 진행한후에 피드백 받은 사항을 수정하는 식으로 했었는데 어느정도 병행할 필요가 있다는걸 느꼈다.
시간은 유한하고 내가 해야할 일은 앞으로도 무한하다. 효율적으로 잘 분배해서
내가 지금 하고있는 일과 앞으로 진행해야 할일(피드백)을 병행할 수 있어야겠다
