본문 바로가기

책

 (76)
5. 영웅, 선의 그리고 프로페셔널리즘 💡 해당 책은 수필 느낌의 성격이 강하며 챕터 하나의 분량이 약 30페이지로 상당히 짧습니다. 그렇기에 포스팅이 다소 짧을 수 있습니다. 아래는 제가 책을 읽으며 가슴에 와닿은 내용들입니다. 우리는 전혀 프로답지 못했다. 한번도 '아니오'라고 말하지 않았기 때문이다. '아니오'라고 말하는 방법 배우기 이러한 상황에서, 시도해보겠다고 하거나 영웅이 되겠다는 생각을 해서는 절대 안 된다. 우리가 영웅이 될 수 있다는 망상에 사로잡혀 프로페셔널하게 행동하지 못했다. 우리는 '아니오'라고 말할 수 있어야 했다. 프로답게 행동하기 불명확하거나 불편한 사실들, 걱정되는 사항들을 최대한 이른 시점에 문제제기해야 한다. 열심히만 하면 갑자기 불가능하던 일이 가능해지고 전부 완료할 수 있다는 것인가? ... 그렇지 않다..
4. 소프트웨어 장인의 태도 💡 해당 책은 수필 느낌의 성격이 강하며 챕터 하나의 분량이 약 30페이지로 상당히 짧습니다. 그렇기에 포스팅이 다소 짧을 수 있습니다. 아래는 제가 책을 읽으며 가슴에 와닿은 내용들입니다. 오래전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다. 내 커리어의 주인은 누구인가 소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 끊임없는 자기계발 특정 주제나 기술을 깊이 이애해야 할 때는 책만한 것이 없다. 커리어를 위해서라면 개념이나 행동양식에 대한 책들에 더 관심을 두는 것이 좋다. 모든 소프트웨어 개발자는 경험 수준과 관계없이 블로그가 있어야 한다고 본다. 경험과..
3. 소프트웨어 장인정신 💡 해당 책은 수필 느낌의 성격이 강하며 챕터 하나의 분량이 약 30페이지로 상당히 짧습니다. 그렇기에 포스팅이 다소 짧을 수 있습니다. 아래는 제가 책을 읽으며 가슴에 와닿은 내용들입니다. 좀더 주관적인 정의 소프트웨어 장인정신은 마스터가 되어가는 긴 여정이다. 소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구과 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다. 공예, 사업, 엔지니어링, 과학 또는 예술 스프트웨어 장인정신은 시켜야만 일하는 역량 미달의 노동자가 아니라 소프트웨어 프로페셔널의 수준을 높여, 프로의 모습으로 일하는 소프트 웨어를 개발자를..
2. 애자일 💡 해당 책은 수필 느낌의 성격이 강하며 챕터 하나의 분량이 약 30페이지로 상당히 짧습니다. 그렇기에 포스팅이 다소 짧을 수 있습니다. 아래는 제가 책을 읽으며 가슴에 와닿은 내용들입니다. 절차적인 관점에서의 애자일 원칙 올바른 목표를 향해 진행 중인지를 확인할 수 있다. 기술적인 관점에서의 애자일 원칙 목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게 한다. 애자일을 따른다는 것 애자일 방법론들은 모두 빠르고 짧은 피드백 루프에 대한 것이다. 애자일은 문제 자체를 해결해주지는 않는다. 애자일은 문제를 드러나게 한다. 애자일 행오버 유즈 케이스는 사용자 스토리로 대체되었고... 애자일을 도입하여 모든 절차를 뒤바꾸는 궁금적인 목적은 소프트웨어에 대한 투자 대비 이득을 키우기 위해서다. 애자일..
1. 21세기의 소프트웨어 개발 💡 해당 책은 수필 느낌의 성격이 강하며 챕터 하나의 분량이 약 30페이지로 상당히 짧습니다. 그렇기에 포스팅이 다소 짧을 수 있습니다. 아래는 제가 책을 읽으며 가슴에 와닿은 내용들입니다. 커리어 패스를 정할 때는 내가 열정이 있는 것, 진정 즐겁게 할 수 있는 것을 따라야 한다는 것이다. 고참 개발자 같은 경험을 10년 동안 열 번 반복하는 것과, 10년 동안 매년 서로 다른 경험을 하는 것 사이에는 어마어마한 차이가 있다.
07 함께 모으기 책에서 언급한 내용들을 한데 모으며 이러한 것들을 배웠고 또 어떻게 써먹을 수 있는지 알려주는 챕터였습니다. 총정리를 하는 성격이 강했기에 새롭게 배운 내용들이 적습니다. 그렇기에 포스팅의 길이가 다소 짧을수 있습니다. 객체지향 설계 안에 존재하는 세 가지 상호 연관된 관점에 관해 설명한다. 파울러는 세가지 관점을 각각 개념 관점, 명세 관점, 구현 관점이라고 부른다. ... 개념 관점에서 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현하다. ... 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심이다. ... 명세 관점에 이르면 사용자의 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨진다. 명세 관점은 도메이느이 개념이 아니라 실제로 소프트웨어 안에서 살아 ..
06 객체지도 설계를 할 때 기능을 중심으로 설계를 하는 것이 아닌 구조를 중심으로 설계를 하라는 말이 와닿았습니다. 구조 중심으로 설계를 하며 객체간 메시지를 주고받는 것이 핵심인듯 합니다. 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더범용적이고 이해하기 쉬우며 변경에 안정적이라는 것이다. ... 객체지향은 자주 변경되는 기능이 아니라 안정적인 구조를 기반으로 시스템을 구조화한다. 기능이 아닌 구조를, 변경에 유연한 구조를 설계하는 것이 중요하다는 생각이 들었습니다. 기능 설계 대 구조 설계 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다. ... 전통적인 기능 분해는 자주 변경되는 기능을 중심으로 설계한 후 구조가 기능에 따..
부록B 타입 계층의 구현 이전에 나온 타입, 클래스, 상속에 대하여 다시 한번 짚고 넘어가는 파트였습니다. 클래스를 이용한 타입계층의구현 타입을 구현할 수 있는 다양한 방법이 존재하는 손간부터는 클래스와 타입은 갈라지기 시작한다. ... 상속은 자식 클래스를 부모 클래스의 구현에 강하게 결합시키기 때문에 구체 클래스를 상속받는 것은 피해야 한다. 가급적 추상 클래스를 상속받거나 인터페이스를 구현하는 방법을 사용하기 바란다. 타입!=클래스이며 클래스는 타입을 구현하기 위한 방법이라는 것을 다시 한번 마음에 새겨넣었습니다. 인터페이스를 이용한 타입 계층 구현 인터페이스를 이용해 타입을 정의하고 클래스를 이용해 객체를 구현하면 클래스 상속을 사용하지 않고도 타입 계층을 구현할 수 있다는 사실이다. ... 타입은 동일한 퍼블릭 인터페이..
부록A 계약에 의한 설계 해당 내용은 오브젝트 책의 마지막에 있는 부록입니다. 그리고 부록의 사전적인 의미는 다음과 같습니다. "본문 뒤에 참고 자료로 덧붙이는 내용." 그러나 저는 인터페이스를 이용해서 설계를 하는 방법 나아가 "계약에 의한 설계를 하는 방법"이 궁금하였기에 부록에 대해 읽어보았습니다. 해당 내용을 올바르게 이해하지는 못하였는듯 하나 제가 감명깊게 읽은 내용들을 정리하고자 하였습니다. 우리에게 필요한 것은 명령의 부수효과를 쉽고 명확하게 표현할 수 있는 커뮤니케이션 수단이다. 이 시점이 되면 계약에 의한 설계가 주는 혜택으로 눈을 돌릴 때가 된 것이다. ... 계약에 의한 설계는 클래스의 부수효과를 명시적으로 문서화하고 명확하게 커뮤니케이션할 수 있을뿐만 아니라 실행 가능한 검증 도구로써 사용할 수 있다. 계약..
15 디자인 패턴과 프레임워크 15장은 오브젝트 책의 마지막 챕터로 지금까지 배운 객체지향의 개념을 바탕으로 디자인 패턴과 프레임워크에 대해 이야기하고 있습니다. 특히 이번장에서 저는 프레임 워크에 정의에 대해 새로 배웠으며 디자인 패턴의 종류가 아닌 정의에 대해 공부한 적은 처음이기에 어려웠지만 흥미롭게 읽었습니다. 이처럼 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법을 디자인 패턴이라고 부른다. ... 디자인 패턴이 설계를 재사용하기 위한 것이라면 프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다. 세부적인 내용에 들어가기전 디자인 패턴은 무엇인지 프레임워크가 무엇인지 짚어주는 부분입니다. 저는 이 부분을 읽기 이전까지 프레임워크는 제어의 역전이 적용된 코드라고 이해를 하고 있었지만..

티스토리툴바