우아한 테크코스는 배달의민족 운영사인 우아한형제들에서 운영하는 개발자 교육 프로그램으로, 프리코스는 우아한 테크코스의 본과정에 대한 맛보기이자 합격자를 추려 내기 위한 4주간의 평가 과정을 의미 합니다.
우아한 테크코스의 합격 여부를 떠나서, 4주간의 프리코스 기간만큼은 어떻게 해야 클린코드를 작성할 수 있을지 깊이 고민하는 시간을 가질 계획 입니다.
우아한 테크코스에서는 지원자들 간 소통을 위해 슬랙을 사용합니다.
슬랙에 남겨진 많은글을 읽으며 내가 놓쳤던 부분과 내 코드의 개선점을 발견하였고, 많은 사람들이 협력 함으로써 얻는 집단지성의 가치를 알게 되었습니다.
다음주차에는 코드리뷰가 가능한 프리코스 커뮤니티가 만들어진다고 하는데, 커뮤니티에 적극적으로 참여하여 많은것을 배워갈 계획입니다.
조부용 코치님이 공유한 질문을 잘하는 개발자에 대한 글을 읽어 보았습니다.
지금 생긴 이슈가 무엇이며, 나는 어떠한 상태이고, 어디까지 시도해 보았는지 구체적으로 하는것이 좋은 질문 입니다.
앞으로 질문할 일이 생기면 상대방이 질문의 의도를 잘 파악하여 좋은 답변을 줄 수 있도록 구체적으로 질문을 해야함을 깨닫게 되었습니다.
참고 : https://jbee.io/essay/good_questionor/#%EB%A7%88%EB%AC%B4%EB%A6%AC
1주차 미션을 완료하는데에 하루도 쉬지않고 꼬박 7일이 걸렸습니다.
시간대비 빠른 성장을 하고있는 기분이 들어 뿌듯합니다.
앞으로의 미션을 시간내에 좋은 퀄리티로 완수할수 있을지 걱정이 되는 동시에, 앞으로의 프리코스 기간동안 얼마나 성장할 수 있을지 기대가 됩니다.
제시한 요구사항을 만족하는 메소드 7개를 구현해야 합니다.
구현한 내용은 Git Hub에 업로드 했습니다.
위의 테스트 코드를 돌리는데, UnsupportedOperationException 에러가 발생했습니다.
all mutating methods throw UnsupportedOperationException
에러가 발생한 지점을 확인해 보니, List.of으로 생성한 인자에서 리스트의 요소를 변경하는 메소드를 호출하면 에러가 발생하는 것을 알게 되었고, List.of로 생성한 데이터는 직접 수정하지 않는 방식으로 문제를 해결했습니다.
이번 에러를 통해 List.of()로 생성한 리스트는 요소를 변경하지 못하는 것을 알게 되었습니다.
참고 : https://sas-study.tistory.com/413
람다식 안에서 사용하려는 외부 지역 변수는 final 이거나 effectively final 이어야 한다는 에러가 발생했습니다.
effectively final : 초기화 된 이후 값이 한번도 변경되지 않았음을 의미 합니다.
매개변수 money는 초기화 된 이후 값이 변경되었는지 보장받을 수 없어서 effectively final이 아니기 때문에, 에러가 발생 했습니다.
forEach와 람다식 대신 for문을 사용하는 방식으로 문제를 해결 했습니다.
이번 에러를 통해 effectively final이 무엇인지, 람다식 안에서는 왜 final 혹은 effectively final 변수를 사용해야 하는지 알게되었습니다.
참고 : https://coder-in-war.tistory.com/entry/Java-25-lambda%EC%99%80-effectively-final
자바 8버전 부터 Lamda식과 Stream API가 추가 되었습니다.
메서드를 하나의 식으로 표현하는 방식으로 코드의 가독성을 높일 수 있습니다.
컬렉션을 반복적으로 처리할 수있는 여러 API를 지원하여 코드의 가독성을 높일 수 있습니다.
스트림과 람다식 사용 전
스트림과 람다식 사용 후
Lamda식과 Stream API를 이용하여 간결한 코드를 작성할 수 있게 되었습니다.
참고 : https://mangkyu.tistory.com/112
메소드 참조는 람다식이 단 하나의 메소드만을 호출하는 경우에 해당 람다 표현식에서 불필요한 매개변수를 제거해주는 문법 입니다.
메소드 참조 사용 전
메소드 참조 사용 후
메소드 참조를 이용해 간결한 코드를 작성할 수 있게 되었습니다.
참조 : http://www.tcpschool.com/java/java_lambda_reference
주석 없이 코드만으로 의도와 목적을 명확히 알 수 있도록 네이밍 규칙을 준수하려 노력했습니다.
참고 : https://naver.github.io/hackday-conventions-java/#method-lower-camelcase
하나의 메소드가 하나의 기능만 수행할 수 있도록 어떻게 메소드를 잘 분리할지 고민 했습니다.
메소드 분리 전
메소드 분리 후
메소드를 잘 쪼갬으로써 재사용성이 높아졌고, 메소드의 이름만 보아도 어떤 기능을 하는지 알 수 있게되어 가독성이 좋은 코드가 완성되었습니다.
참고 : https://mrbinggrae.tistory.com/164
메모리를 효율적으로 사용하고, 실행속도를 높이기 위해 자료구조 사용법을 익힐 필요가 있습니다.
클린코드 측면에서도, 어떠한 자료구조를 적재적소에 사용함으로써 간결한 코드를 만들 수 있을지 고민했습니다.
저도 예전에 effectively final 관련한 문제 겪었었는데 같은 고민을 했던사람을 보니 반갑네요😀
잘보고갑니다!