[로또 미션] 회고 : 수동적인 객체수동적인 객체는 항상 잘못된 것인가? 로또 시스템을 설계하는 과정에서 로또 객체는 스스로 당첨 여부를 판단해야 하는가? 라는 고민을 하게 되었다. 처음에는 현실 세계의 로또 티켓을 떠올mak-ing.tistory.com [출석 미션] 회고 : TDD를 미워합니다TDD는 직관적이고 이상적인 사이클을 따른다.RED: 실패하는 테스트를 먼저 작성한다.GREEN: 테스트를 통과할 최소한의 프로덕션 코드를 작성한다.REFACTOR: 코드를 리팩토링하여 개선한다. 먼저 확실mak-ing.tistory.com [블랙잭 미션] 회고 : Ace, Hit, SRPACE  블랙잭에서 ACE 카드는 특별한 존재다. 상황에 따라 1점 혹은 11점으로 점수가 달라질 수 있기 때문이다. ACE ..

미션 시작 당일 아침에 체스가 아닌 장기로 변경됐다!    객체 객체지향이란 무엇일까? 단순히는 객체를 중심으로 문제를 해결하는 방식이라고 말할 수 있다. 그렇다면 여기서 말하는 '객체'란 무엇을 의미할까? 흔히 객체는 상태와 행동을 가진 존재라고 설명되지만, 나는 조금 더 넓은 시각에서 접근하고자 한다.객체란 책임을 다하는 존재라고 생각한다. 문제를 해결하기 위해 객체들은 서로 협력하며, 이 협력 속에서 각 객체는 자신에게 주어진 역할을 수행한다. 이 역할을 수행하려면 객체는 반드시 책임을 다해야 한다. 이런 관점에서 객체는 단지 상태(데이터)와 행동(메서드)을 묶어둔 것 이상의 의미를 가진다.한 걸음 더 나아가 '상태가 없는 객체'라는 개념을 생각해 볼 수 있다. 상태가 없다는 것은 내부적으로 데이터..

TDD는 직관적이고 이상적인 사이클을 따른다.RED: 실패하는 테스트를 먼저 작성한다.GREEN: 테스트를 통과할 최소한의 프로덕션 코드를 작성한다.REFACTOR: 코드를 리팩토링하여 개선한다. 먼저 확실히 짚고 넘어가자면, 테스트는 중요하다. 나는 테스트를 사랑한다.테스트는 리팩토링할 때 자신감을 주고, 프로그램의 신뢰성을 확보하는 핵심 수단이다. 또한 코드의 동작을 명확히 전달하는 문서 역할도 한다. 테스트 작성에 최선을 다해야 하는 것은 분명 옳다. 그러나 TDD(Test-Driven Development) 방식에 대해서는 신중한 입장이다.작은 단위에 지나치게 집중할 가능성 TDD는 작은 단위에 집중하게 만든다. 하나의 테스트를 먼저 작성하고, 이를 통과하도록 만드는 최소한의 프로덕션 코드를 추가..

[백준 31809] malware 박멸하기 : https://www.acmicpc.net/problem/31809문제 조건시간을 신경쓸 필요가 없어보인다. 하루에 박멸 이후 감염이 차례로 진행된다고 이해할 수 있다. 따라서 자신에게 진입 간선이 존재한다면 박멸 이후 감염이 이뤄지므로 아무런 일도 일어나지 않는다. 위에서 말했던 것에 대한 예시를 확인할 수 있다. 진입 간선이 존재한다면, 박멸 이후 감염된다.주기(P)와 C의 크기가 다른 것이 처음 문제를 읽을 때 조금 헷갈렸다.  문제 해결 방법 문제의 핵심은 현재 박멸이 진행되는 컴퓨터(노드)에 진입하는 간선(즉, 외부에서 감염될 가능성)이 있다면, 해당 컴퓨터는 다시 감염될 수 있어 즉시 처리할 수 없다는 점이다.따라서 진입 간선이 없는 노드를 우선적..

플랫폼 독립성 소프트웨어는 발전할수록 더 많은 환경에서 실행할 수 있는 유연성을 필요로 한다. 그러나 과거에는 운영체제(OS)나 하드웨어(CPU)에 따라 실행 방식이 달라지는 문제가 있었다. 이를 해결하기 위해 JVM(Java Virtual Machine)이 등장했다. JVM이 무엇이며, 어떻게 자바 코드가 플랫폼 독립성을 가질 수 있는지 이해하기 위해, 먼저 기존의 실행 방식이 가졌던 한계를 살펴보자.  어셈블리어특정 하드웨어에 종속된 실행 방식  +------------------+ | x86 CPU (Intel) | +------------------+ | +----------------------..

반 년간의 데브코스를 마쳤다데브코스를 시작할 때, 나는 내가 경험해보지 못한 것이 나의 부족함이라고 정의했고, 그것을 채우는 것을 목표로 삼았다. 그러나 내가 이해했다고 여겼던 것들을 다시 되짚는 과정에서 오히려 더 깊은 통찰을 얻었다. 단순히 유행하는 기술을 익히는 데 그치지 않고, 스스로를 객관적으로 바라보며 부족한 점을 채워나가는 과정에서 진정한 성장이 이루어진다는 것을.특히 가장 큰 변화는 단순히 구현하는 것에 머물지 않고, '왜 이렇게 해야 하는가'라는 질문을 끊임없이 던지게 되었다는 점이다. 이 관점은 코드 레벨에 그치지 않고, 비즈니스와 도메인 관련 기획까지 확장되었다. 기술적 결정이 비즈니스 요구사항과 도메인의 특성을 어떻게 반영해야 하는지 고민하게 되었다는 점에서, 단순히 개발을 넘어 더..