실제 제출했던 코드는 여기 있습니다 제출했던 소감문을 바탕으로 적었습니다 이번주 목표 1번만 완벽하게 만들자 1~3주차 까지는 그냥 코드를 많이 짜봐야 될 것 같다는 불안감이 있었기에 많이 짜려고만 했던 것 같습니다 실제로 2, 3주차는 다시 만들어보자는 생각을 가지고 총 3번씩 같은 코드를 작성했기에 여러 요구사항들 중 놓쳤던 부분이 있던 점이 아쉬웠습니다 꼭 프리코스만이 아니더라도 조금 안 좋은 코드임에도 요구사항을 완벽하게 지켜주는 쪽이 더 좋은 개발자라는 생각이 코수타를 통해서 들게 되었습니다 지금까지의 방식과는 거의 반대되는 느낌이라서 이 부분을 내려놓는 과정을 거쳤습니다 같은 문제를 여러번 푸는 것도 많이 배울 수 있었지만, 생각이 굳어버리는 과정이 있었습니다 그래서 하지 않았던 한 번의 코드..
우아한테크코스를 하면서 정말 많은 변화가 있었고 배우고 있습니다 실제 제출했던 소감문을 바탕으로 작성되었습니다 실제로 작성했던 코드는 여기에서 확인하실 수 있습니다 알게 되었던 점 1. 기능 목록은 진행 순서와 관계가 없다 2. 변경을 고려해서 추상화 해야 한다 3. 주석을 다는 작업이 생각보다 커다란 효용을 준다 4. 코드에 제약을 걸 수록 좋은 코드가 나온다 5. 모든 코드를 테스트 할 필요는 없다 1. 기능 목록은 진행 순서와 관계가 없다 1주차에는 진행 순서를 그대로 기능 목록으로 작성하려고 했었는데 그 순서대로 커밋을 하려니 진짜 너무너무 힘들고, 작성하기가 힘들었었던 경험이 있습니다 2주차 문제를 3번째로 새롭게 작성할 때 기능 목록과 진행 순서를 분리하고, 기능 목록을 작성하기 시작했는데 그..
이 글에는 문제에 대해서만 딱딱하게 적혀있습니다 개인 복습용 노트 느낌으로 작성한 것이기 때문에 큰 도움이 되지 않을 수도 있습니다 2주차를 통해서 얻을 수 있었던 것 1. 전체 프로그래밍 과정의 프로세스에 대한 정립 전체 흐름 작성 흐름 속에서 생길 수 있는 모든 개념 작성 개념들에 대해서 단위 테스트를 작성함 2. 추상화를 통한 테스트 가능한 코드들 출력같은 경우 바로 System.out.println을 통해 출력하게 된다면 이 부분을 테스트 하기 정말 어려움 중간에 객체가 하나 있고, 그 객체에 제대로 값이 전달되는 것만 확인한다면 그 자체로 충분할 수 있음 3. 중간 구현체를 두는 상황에서의 인터페이스의 유효성 중간 구현체는 당연하지만 실제 클래스가 되었을 경우 너무 강하게 결합되어서 추후 분리가..
좋아하는 책 제목이 생각에 관한 생각인데, 내용적인 것 보다는 제목이 기억에 많이 남았었습니다 프로젝트에 대한 계획이 아니라 프로젝트를 설계하는 그 일반적인 과정을 고려하는 과정을 좋아합니다 완성까지는 하지 않더라도 대충 프로세스를 이해할 수 있을 정도까지는 작성해보았습니다 간단한 목표이자 설계 과정 특정 프로젝트가 아닌, 프리코스 프로젝트를 만들 때 필요한 것들을 적고자 합니다 정말 좋은 문제를 미리 해보면서 참여했을 때의 느낌을 잃어버리기 싫어서 완성까지는 가지는 않았습니다 프로젝트의 빡빡한 제약조건을 고려해보고 각 프로젝트를 통해 얻게 하고자 하는 것이 무엇일지 고민해보았습니다 좋은 프로젝트란 무엇인가? 1. 다른 사람이 알아보기 쉬운 프로젝트 이 조건을 정말 세심하게 쪼개두었습니다 1. 커밋메시지..
