반응형 전체 글 70 [경제공부/신사임당] 김영익 교수 편 대폭락 전에 나타나는 징조들 https://www.youtube.com/watch?v=cvyAW-UOfG0 출처: 유투브 신사임당 현재 자영업, 영세업자의 상황은 나쁘고, 대기업의 경우 사상 최대의 실적을 내고 있음. GDP도 V자 회복으로 경제 상황이 좋음 전세계적으로 가계부채가 빠르게 늘어나고 있다. (2008년 금융위기, 현재는 코로나 상황 등으로 인해) 지금까지는 지역적으로 위기가 왔지만, 지금은 주식/채권/부동산 모두 거품일 확률이 높다. 한번 해소가 되고 넘어가야하는데, 교수님의 경우 이 시점을 내년 하반기 쯤으로 예측 (과거 데이터 기반 교수님의 자료) 경제 하강 리스크수준이 점점 높아지고 있음 가장 선행되는 지표: 장단기 금리 차 경기가 좋아지면 -> 장기금리 > 단기금리 이익 축소, 장기.. 2021. 8. 21. [Effective Kotlin] Item 10: Write unit tests Intro 코드를 더 안전하게 만드는 궁극적인 방법: 다양한 종류의 테스트를 사용하는 것 일반적인 테스트: 사용자 관점에서 애플리케이션이 올바르게 작동하는지 확인 애플리케이션 외부에서 올바르게 작동하는 것이 목표 충분한 수의 tester를 처리 개발자에게 유용하지만 불충분함 => 단위테스트가 필요한 이유 시스템의 구체적인 element들의 올바른 작동을 보장하지 못함 개발 중에 더 빠른 피드백을 제공하지 못함 단위 테스트 (Unit test) 구현된 elements의 작동방식에 대해서 빠른 피드백을 제공하기 때문에 개발중에 유용함 테스트는 누적되므로 regression에 있어서도 쉽게 확인 가능 수동으로 테스트하기 어려운 사례도 확인가능*TDD(Test Driven Development)방식에서는 단위테.. 2021. 8. 12. [Test - Spock + Kotlin] Mocking 실패 문제 Spring Boot + Spock Framework + Kotlin 조합으로 UnitTest 코드를 작성하다 문제를 마주하게 되었다. 이 문제는 재직중인 회사에서 tc를 작성하던 중 발생한 문제로, 소스코드를 그대로 담을 수 없어 최대한 비슷한 코드를 따로 작성해보았다. 결론부터 말하자면, 나와같은 환경, 상황이 발생한다면 Spock Framework를 사용하여 test를 진행하기 어려울 것 같다 ㅠㅠ 일단 문제가 발생한 코드는 아래와 같다. class HelloTest extends Specification { HelloDao helloDaoMock HelloService helloService def setup() { helloDaoMock = Mock(HelloDao) //문제 발생 helloSe.. 2021. 7. 14. [오브젝트] 14장. 일관성 있는 협력 일관성 없는 코드의 문제점 1. 개념적으로 연관되어있는 코드에 대해 서로 다른 구현 방식을 채택할수록 설계의 일관성이 무너지게 됨 2. 코드를 이해하기 어려움: 한가지를 이해했다고 다른 한가지를 이해하는 것이 아님 결론은 유사한 기능을 서로 다른 방식으로 구현 해서는 안 된다는 것이다. 일관성 없는 설계와 마주한 개발자는 여러 가지 해결 방법 중에서 현재의 요구사항을 해결하기에 가장 적절한 방법을 찾아야 하는 부담을 안게 된다. 유사한 기능은 유사한 방식으로 구현해야 한다. 객체 지향에서 기능을 구현하는 유일한 방법은 객체 사이의 협력을 만드는 것 뿐이므로 유지보수 가능한 시스템을 구축하는 첫걸음은 협력을 일관성 있게 만드는 것이다. 설계에 일관성 부여하기 일관성 있는 설계를 만드는 데 가장 훌륭한 조언.. 2021. 7. 14. [오브젝트] 10장. 상속과 코드 재사용 상속과 중복 코드 DRY 원칙 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을 만한 표현 양식을 가져야 한다. DRY(Don't Repeat Yourself)는 '반복하지 마라'라는 뜻 중복 코드는 변경을 방해 코드를 수정하는 데 필요한 노력을 몇 배로 증가 시킴 중복 여부를 판단하는 기준은 변경 → 요구사항이 변경 됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복 중복과 변경 중복코드는 새로운 중복코드를 부르고, 버그 발생가능성도 높아짐 (아주아주 문제가 많다 이마리야) 민첩하게 변경하기 위해서는 중복코드를 추가하는 대신 제거해야한다. 중복을 제거하는 방법 중 하나: 클래스를 하나로 합쳐 타입코드를 추가해 로직 분기 → 단점: 낮은 응집도와 높은 결합도를 갖게됨 상속을 이용해서.. 2021. 6. 4. [오브젝트] 9장 유연한 설계 01. 개방-폐쇄 원칙 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 여기서 키워드는 '확장'과 '수정'이다. 이 둘은 순서대로 애플리케이션의 '동작'과 '코드'의 관점을 반영 확장에 대해 열려 있다: 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다. 수정에 대해 닫혀 있다. 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다. 컴파일 의존성을 고정시키고 런타임 의존성을 변경하라 의존성 관점에서 개방-폐쇄 원칙을 따르는 설계란, 컴파일타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조를 의미 컴파일 의존성: 코드.. 2021. 6. 3. 이전 1 ··· 4 5 6 7 8 9 10 ··· 12 다음 반응형
