Simple is IT, 누구나 보고 누구나 깨닫는 IT

https://medium.com/@jung23e/%EB%82%98%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%84-%EB%91%90%EB%A0%A4%EC%9B%8C%ED%96%88%EB%8A%94%EA%B0%80-d8bc49f87da3

https://medium.com/@jung23e/%EB%8F%84%EC%A0%84%EC%9D%80-%EC%97%B0%EA%B2%B0%EB%90%9C%EB%8B%A4-5%EB%85%84%EC%B0%A8-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%ED%8E%B8-f26edb188a9f 도전은 연결된다. — 5년차 소프트웨어 엔지니어편Intro: 문제 해결은 도전에서 시작된다medium.com

Life Cycle(블로그보단 아래 위키의 가독성이 더 좋다. 추천한다)https://currenjin.github.io/wiki/spring-bean/#life-cycle Spring Bean currenjin.github.ioBean이라는 녀석은 어떤 타이밍에 생성되고, 또 소멸될까?순서크게 다음과 같은 순서를 갖는다.생성자 호출 (Bean 인스턴스 생성)의존성 주입 (Properties 세팅)@PostConstruct 메서드 실행afterPropertiesSet() 메서드 실행@PreDestroy 메서드 실행destroy() 메서드 실행순서만 봐서는 와닿지 않을 것이다. 아래와 같은 예제를 생각해보자.@Servicepublic class UserService { private final User..

이 광대한 코스모스의 시작은 어디이며, 끝은 어디인가. 우리가 바라보는 시선은 시작으로 향할 것인가.시간이 지나고, 우리의 끝은 이 거대한 서사의 시작에 한 번이라도 닿았을까.

이 책의 682(마지막)페이지를 넘긴 후에는 두 가지의 질문만이 머릿속에 맴돈다.나는 지금까지 어떻게 살아왔는가? 그리고 또 어떻게 살아갈 것인가? 벌써 몇 번째 정독하는 건지 모를. 이번에 가장 기억에 남는 키워드는 바로 ‘핵전쟁’이다. 누군가가 나에게 ‘핵전쟁은 비극인가?’라는 질문을 한다면 나는 확신을 담아 대답할 수 있다. “절대 비극이다.” 핵전쟁에 사용되는 핵무기는 도대체 왜 탄생하게 됐을까? 개인의 생존 위협과 분노에 ‘살인’과 같은 상황이 펼쳐지듯, 국가의 생존 위협과 분노에 ‘전쟁’이라는 상황이 수없이 발생해왔다. 나는 ‘심리적 관점에서 전쟁은 살인과 같다’는 칼 세이건의 말에 전적으로 동의한다. 2차 세계대전이 한창일 때, 추축국 독일은 핵무기 제작에 돌입했었으며, 연합국 미국이 이를 ..

LinkFixture Monkey를 적용해보자지루함을 편함으로 바꿔주는 Fixture Monkey에 대한 문서이다.Problem테스트를 작성하며 각자 느끼는 고충이 있을 것이다. 그 중 많은 사람들이 테스트를 위한 셋업 코드를 작성하며 많은 시간을 소요하고, 지루함을 느끼곤 한다. TDD의 저자 켄트벡은 두려움이 지루함으로 변할 때까지 테스트를 작성하라고 하지만, 나는 더 나아가 반복되는 지루함은 반드시 자동화해야 한다고 생각한다.테스트 코드를 작성하는 우리의 두려움은 지루함으로 바뀌었으니, 이 지루함의 반복됨을 편함으로 바꿀 수는 없을까?Fixture MonkeyFixture Monkey는 이런 고민을 해결해준다. 이 라이브러리를 사용하면,테스트 데이터 생성을 자동화하여 시간을 아낄 수 있다.다양한 시..

밥 아저씨가 생각하는 테스트 주도 개발TDD의 세 가지 법칙실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.확신FitNesse의 코드는 6만 4천 줄인데, 그중 2만 8천 줄은 테스트 코드다.어떤 부분이라도 바꾸게 되면 별 생각 없이 단위 테스트 코드를 돌리는데, 통과하면 내가 만든 변경이 다른 부분을 망가뜨리지 않았다고 거의 확신할 수 있다.용기믿음직한 테스트 묶음이 있으면 변경에 대한 두려움이 모두 사라진다. 나쁜 코드가 보이면 그저 그 자리를 깨끗이 치우면 된다.문서화세 가지 법칙에 따라 만든 각 단위 테스트는 코드로 만든 에제이며 시..

태도, 원칙, 그리고 행동내가 바라는 개발자의 태도우리는 목적을 함께하는 사람이다.개발자가 할 수 있는 일은 무엇일까? 소프트웨어를 다루는 프로그램을 만들거나, 기존 프로그램을 개선하는 것이 주된 일일 것이다.작은 조직에서는 서로의 일이 가까이 있기 때문에 목적을 함께하는 느낌이 강하고, 어떤 일을 진행함에 있어서도 서로 노력할 것이다. 하지만 조직의 규모가 커지면 서로의 일을 멀리서 바라보게 되고, 다양한 이해관계가 생기며 그 목적을 인지하기도, 함께한다고 생각하기도 어려워진다.그러나 나는 조직이 크든 작든 바라보는 목적이 같아야 한다고 생각한다. 개발자는 서로의 다른 목적을 충족시키기 위해 개발하는 것이 아니라, 함께 목적을 이루기 위해 개발하는 것이다. 그 목적에 다가가기 위해 각자가 가장 잘하는 ..