Study19 [Clean-Code] Chapter. 17(G24~)~부록:동시성 Clean-Code_week7_yerimi11 (p.286~) G23: If/Else 혹은 Switch/Case 문보다 다형성을 사용하라 ‘switch 문 하나’ 규칙을 따른다. 즉， 선택 유형 하나에는 switch 문을 한 번만 사용한다. G24: 표준 표기법을 따르라 팀이 정한 표준은 팀원들 모두가 따라야 한다. 모두가 동의한 위치에 넣는다는 사실이 중요하다. G26: 정확하라 잠금과 트랜잭션 관리를 건너뛰는 행동은 아무리 잘봐줘도 게으름이다. G28: 조건을 캡슐화하라 가능하면 긍정 조건으로 표현하라 G30: 함수는 한 가지만 해야 한다 한 가지만 수행하는 좀 더 작은 함수 여렷으로 나눠야 마땅하다. G33: 경계 조건을 캡슐화하라 코드 여기저기에 +1이나 -1을 흩어놓지 않는다. 경계조건은 변수로.. 2023. 7. 20. [Clean-Code] Chapter. 15-17(~G23) Clean-Code_week6_yerimi11 (~p.285) 15. JUnit 들여다보기 의도를 명확히 표현하려면 조건문을 캡슐화해야 한다. 즉, 조건문을 메서드로 뽑아내 적절한 이름을 붙인다. if문은 긍정으로 만들어 조건문을 반전한다. 불필요한 if문을 제거한다. 코드를 리팩터링 하다보면 원래 했던 변경을 되돌리는 경우가 흔하다. 리팩터링은 코드가 어느 수준에 이를 때까지 수많은 시행착오를 반복하는 작업이기 때문이다. => 리팩토링 시 위의 내용들을 기억하면 좋을 것 같다. 또한 현재 업무 중 내가 개발한 코드를 리팩토링하는 과정에 있는데, 이전으로 돌아가는 경우가 잘못된 과정이 아님을 알고 여러 시도를 해봐야 겠는 생각이 든다. 16. SerialDAte 리팩터링 코드를 고칠 때마다 단위 테스트를.. 2023. 7. 12. [Clean-Code] Chapter. 14 Clean-Code_week5_yerimi11 점진적인 개선 자바는 정적타입 언어라서 타입 시스템을 만족하려면 많은 단어가 필요하다. -> (14-7 에러코드) 정말 귀찮고 복잡해보이는데 실제로 정말 이렇게 줄줄 쓰는지 대다수 신참 프로그래머는 이 충고를 충실히 따 르지 않는다. 그들은 무조건 돌아가는 프로그램을 목표로 잡는다. 일단 프로그램이 ‘돌아가면’ 다음 업무로 넘어간다. ‘돌아가는’ 프로그램은 그 상태가 어떻든 그대로 버려둔다. 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살행위라는 사실을 잘 안다. -> 반성. 실제로 시간분배를 어떻게 해야할지.. 어떻게들 하고 계신지 -> 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다. 설계와 구조를 개선할 시간이 없다고 .. 2023. 7. 11. [신입 개발자 기술 면접] 면접 직전 준비 방법 저는 매사에 밝고 긍정적인 편이지만, 한편으로는 두려움이 많고, 불안함 또한 꽤 많이 가지고있는 사람입니다. 잘하고 싶어질 때 특히나 더 그렇습니다. 누구나 그렇겠지만요. 이런 제 성격은 취준 과정 속의 제 모습들을 돌아봤을 때, 그런 불안함들을 발전의 발판으로 삼아 더욱 노력하기도 했지만, 힘든 마음에 주변사람에게 불완전한 모습을 보이기도 했습니다. (자아성찰할 때마다 괴롭습니다..) 취업을 준비하고, 인터뷰를 준비하는 과정 역시 그랬습니다. 이 정도면 신입지원자로서는 많이 준비했다 싶다가도, 아직 완벽하게 준비가 되지 않은 것 같아 포기하고 싶어지고, 나의 부족함이 드러나는 과정을 마주하고 싶지 않았습니다.. 어쩌면 완벽하고 싶어하는 모습이 있었던 것 같습니다. 하지만 본래 사람은 부족한 모습을 스스.. 2023. 7. 7. [Clean-Code] Chapter. 11-13 Clean-Code_week4_yerimi11 시스템 관심사 분리를 하지 않고 런타임 로직과 객체 생성 로직이 섞이는 경우, 단일 책임 원칙(Single Responsibility Principle)이 깨질 수 있다. 좋은 설계를 위해서는 객체 생성과 관련된 로직은 별도의 팩토리나 생성자 등의 메서드로 분리하여 단일 책임을 갖는 별도의 클래스로 위임하는 것이 좋다. 이를 통해 코드의 응집도를 높이고 유지보수성을 향상시킬 수 있다. 체계적이고 탄탄한 시스템을 만들고 싶다면 모듈성을 깨서는 절대로 안 된다. 객체를 생성하거나 의존성을 연결할 때도 마찬가지다. 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. 또한 주요 의존성을 해소하기 위한 방식, 즉 전반적이며 일관적인 방식도 필요하다. main(.. 2023. 6. 23. [Clean-Code] Chapter. 7-10 Clean-Code_week3_yerimi11 오류 처리 [Try-Catch-Finally 문부터 작성하라] try-catch 구조로 범위를 정의한 후 TDD를 사용해 필요한 나머지 논리를 추가한다. [미확인(unchecked) 예외를 사용하라] 지금은 안정적인 소프트웨어를 제작하는 요소로 확인된(checked) 예외가 반드시 필요하지는 않다는 사실이 분명해졌다. C#와 C++, 파이썬, 루비는 확인된 예외를 지원하지 않는다. 그럼에도 불구하고 해당 언어들은 안정적인 소프트웨어를 구현하기에 무리가 없다. 그러므로 확인된 오류가 치르는 비용에 상응하는 이익을 제공하는지 따져봐야 한다. 확인된 예외는 OCP(Open Closed Principle)를 위반한다. 메서드에서 확인된 예외를 던졌는데 catch 블.. 2023. 6. 22. 이전 1 2 3 4 다음
