이전

리뷰 (3)

한줄평
평점 분포
  • 리뷰 총점10 0%
  • 리뷰 총점8 100%
  • 리뷰 총점6 0%
  • 리뷰 총점4 0%
  • 리뷰 총점2 0%
연령대별 평균 점수
  • 10대 0.0
  • 20대 0.0
  • 30대 0.0
  • 40대 7.0
  • 50대 8.0
리뷰 총점 종이책
소프트웨어 설계는 이 책으로~~~
"소프트웨어 설계는 이 책으로~~~" 내용보기
소프트웨어를 개발하기 위해서는 요구사항분석, 설계, 코딩, 테스트 단계가 제대로 이루어져야 한다. 하지만 현실은 항상 시간에 쫓기기 때문에 대분의 개발자들은 요구사항을 듣고 바로 코딩을 하거나 간단히 설계를 한 후 코딩을 들어가게 된다. 이러한 과정에서 요구사항의 잘못된 분석으로 인해 완성 직전의 프로그램을 다시 작성하거나 설계가 잘못되어 다시 재작성하는 단계를 거치
"소프트웨어 설계는 이 책으로~~~" 내용보기
소프트웨어를 개발하기 위해서는 요구사항분석, 설계, 코딩, 테스트 단계가 제대로 이루어져야 한다. 하지만 현실은 항상 시간에 쫓기기 때문에 대분의 개발자들은 요구사항을 듣고 바로 코딩을 하거나 간단히 설계를 한 후 코딩을 들어가게 된다. 이러한 과정에서 요구사항의 잘못된 분석으로 인해 완성 직전의 프로그램을 다시 작성하거나 설계가 잘못되어 다시 재작성하는 단계를 거치면서 시간은 자꾸 개발자의 숨통을 조이게 된다.

일단 코딩을 하고 수정하는 작업을 하는 잘못된 개발 악순환이 현재 많은 프로그래머들 사이에서 행해지고 있는 것이다. 이러한 잘못된 개발 습관이 현재에 생긴 것은 분명 아니며 오랜 시간동안 내려온 악습이라는 것을 생각하면 빨리 고치고 더 나은 방법으로 프로그램을 개발할 수 있도록 어떤 조치를 해야 한다. 이러한 오랜 시간의 프로그래머들의 요구에 위해 OOP(Object Oriented Programming) 가 등장하게 되었다. OOP는 소프트웨어를 요구한 사용자를 위한 기술이 아닌 프로그래머가 프로그램을 좀 더 빠르게 효율적으로 개발 및 유지보수할 수 있도록 하기 위해 고안된 기술이다. 그래서 많은 개발자들이 절차형 방식에서 OOP 방식으로 프로그램 언어를 바꾸고 개발 방식을 바꾸어 소프트웨어 개발 시간을 단축하고 고품질의 소프트웨어를 만들려고 하였다.

하지만 OOP 로 프로그램을 하게 되면 무조건적으로 프로그램 개발이 향상될 거라 믿는 바람에 실제 소프트웨어 품질은 더 낮아지거나 이전과 비슷한 수준을 겨우 유지하는 정도였다.

소프트웨어 개발을 효율적으로 하기 위해서는 어떤 것이 필요한 것일까? 요즘 유행하는 객체지향방식의 프로그램 언어을 사용하면 개발시간이 단축되고 양질의 제품을 만들 수 있을까? 아니면 이 언어를 활용할 수 있는 좋은 개발툴을 구입하면 되는 것일까?

소프트웨어 개발에 있어서 가장 중요한 것은 프로그램 언어나 개발 툴등이 아니다. 소프트웨어를 구축하기 위한 일련의 준비과정을 제대로 진행했을때 비로서 양질의 소프트웨어가 개발될 수 있다. 그렇다면 이 일련의 과정은 무엇일까?

제대로 된, 시간을 단축할 수 있고, 요구사항이 변경되더라도 재빠르게 수정할 수 있는 프로그램을 작성하고 싶은데 어떻게 어디서 부터 시작해야 할까?

많은 분들이 제대로 된 프로그램을 작성하고 싶어한다. 그래서 유행하는 디자인 패턴, UML, 리팩토링등에 대한 책을 구입해서 읽어보지만 여전히 난해하고 왜 이러한 것을 적용해야 하고 어떻게 사용해야 하는 지에 대해서 막연하기만 하다. 하지만 이제 걱정할 필요가 없을 것 같다. 왜냐하면 "소프트웨어 설계 테크닉" 이라는 책이 판매되고 있기 때문이다. 이 책은 비록 많은 설계 기술에 대해서 깊이 있기 얘기하고 있지는 않지만 왜 해야 하는 지에 대해서는 확실히 잘 말하고 있다. 설계란 무엇이고 왜 해야하는 지에 대해서 그리고 어떻게 해야하는 지에 대한 물음을 가지고 있는 개발자라면 이 책은 반드시 도움이 될 것이다.

좀 더 나은 소프트웨어 개발을 하고 싶은 분은 반드시 이 책을 읽어보고 UML, 리팩토링, 디자인 패턴에 대한 전문 서적을 보면 빠르게 소프트웨어 설계에 대해서 익힐 수 있을 것이다.
k*****6 2004.06.09. 신고 공감 10 댓글 0
리뷰 총점 종이책
이제 소프트웨어 설계가 두렵지 않아
"이제 소프트웨어 설계가 두렵지 않아" 내용보기
언제까지 코더로 프로그래밍을 할 수 있을까? 회사를 다니면서 이런 회의가 들었다. 나이가 들면 다른 사람들처럼 영업을 해야 하나? 아니면 프로그램 전체 설계를 담당할 수 있는 고급 소프트웨어 설계자가 되야 하나? 그래도 돈을 많이 받을 수 있는 설계자가 낫겠지. 그래서 나는 이 책을 선택했다. 이 책의 내용도 마음에 들었다. 내용 뿐 만이 아니라 구성도 마음에 들었다
"이제 소프트웨어 설계가 두렵지 않아" 내용보기
 

언제까지 코더로 프로그래밍을 할 수 있을까? 회사를 다니면서 이런 회의가 들었다.

나이가 들면 다른 사람들처럼 영업을 해야 하나? 아니면 프로그램 전체 설계를 담당할 수 있는 고급 소프트웨어 설계자가 되야 하나?

그래도 돈을 많이 받을 수 있는 설계자가 낫겠지. 그래서 나는 이 책을 선택했다.

이 책의 내용도 마음에 들었다. 내용 뿐 만이 아니라 구성도 마음에 들었다.

첫 번째 이야기는 나에게 많은 것을 공감하게 해주었다. 나도 이 책에서처럼 당했으니깐 말이다.  그때에는 이랬다가 저랬다가 하는 갑(프로그램 개발 일을 맡기려는 사람)이 정말 싫었다. 이렇게 하면 저렇게 고쳐 달라  저렇게 하면 다시 이렇게 고쳐 달라고 하는…

그런데 이 책을 보니 그 사람들이 잘못한 것이 아니었다. 설계를 하는 것에는 그만한 노하우가 있었던 것이다.

그냥 무턱대로 설계를 해버리면 안 된다는 것을 책을 펼쳐서 조금 안 있어서 깨달았다.


이 책에서 나오는 데이터 플로 다이어그램의 예를 보면서 기존에 했던 업무를 따라 그려보았다. 그 때 이렇게 했다면 시행착오를 줄일 수 있었을 텐데 하는 한탄의 한숨이 튀어나오기도 했다.

그리고 ER 모델링도 해보았다. 직접 프로그램을 구해서 그려보고 잘못된 부분은 고쳐보기도 해 보았다.

처음에는 접해보지 못한 것들은 실수도 했지만 나중에는 깨끗하게 구현이 되었다.

신기했다. 

책에서 UML이라는 것이 있어서 이 책을 보고 또 다른 UML 책을 구해서 병행해서

공부도 했다. UML도 공부해 보니 재미있었다.


그리고 지금 프로그램 추세가 OOP로 가기 때문에 책에 있는 OOP부분도 중점적으로 시간을 할애해서 공부했다.

개념만 잡으면 쉬운 내용들이라 어렵지 않았다.

지금은 설계를 하는데 어려울 것이 없다

p********p 2009.04.30. 신고 공감 0 댓글 0
리뷰 총점 종이책
이미 Refactoring이나 GOF를 봤다면 내용이...
"이미 Refactoring이나 GOF를 봤다면 내용이..." 내용보기
여러 책 소개 페이지에서 많이 언급이 되어 내용에 대한 offline확인 없이 구매를 하게되었습니다 .이미 fowler의 refactoring이나 GOF의 design patterns, 기타 다른 패턴 서적을 본지라 그 다지 새로 배울 건 없었습니다. 게다가 robert.c.martin 씨의 UML책을 본 뒤인지라 (저도 미니멀리즘에 호감이있어서 그런지) 그가 말했던 미니멀리즘과 대치되는 내용이(UML 사용이 설계에 무조
"이미 Refactoring이나 GOF를 봤다면 내용이..." 내용보기
여러 책 소개 페이지에서 많이 언급이 되어 내용에 대한 offline확인 없이 구매를 하게되었습니다 .이미 fowler의 refactoring이나 GOF의 design patterns, 기타 다른 패턴 서적을 본지라 그 다지 새로 배울 건 없었습니다. 게다가 robert.c.martin 씨의 UML책을 본 뒤인지라 (저도 미니멀리즘에 호감이있어서 그런지) 그가 말했던 미니멀리즘과 대치되는 내용이(UML 사용이 설계에 무조건 있어야 되는것처럼 느껴지는...등등의 기타 내용) 좀 있는지라 좀 불편했습니다. 뭐...후반부에 현장주의의 장점을 얘기하는 걸 보면 꼭 저자의 주장이 형식에 얼 매인 건은 아닌듯 해보이지만.... 여튼 이미 리팩토링이나 패턴을 보신분들에게는 비추이고요. 그것들에 대한 사용 동기를 느끼고 싶은 분이 잠시 읽어볼 정도라고 보입니다. 분석 부분만 빼면 "자바 디자인 패턴과 리팩토링" 이라는 책과 좀 비슷하다는 느낌이라고나 할까요... 뭐 책 제목의 "아무도 가르쳐 주지 않았던" 보다도 리팩토링이나 패턴에 대해 "아무에게도 어느책으로도 배워본 적이 없던" 독자가 책을 정독이 아닌 통독으로 읽어보면 좋을듯합니다. 패턴관련 내용의 아티클을 읽다가 본 내용입니다만 GOF책에 있는 클래스 다이어그램 부분 조차 그 UML표현에 집중하지 말라고 하더군요. 어떤어떤 패턴 그 아이디어에 집중해야 된다는 것이죠. 어떤 다른 방법으로도 디자인을 할 수 있다고요. 그런데 시중의 몇몇 책들에서는 (특히 일본 저자쪽) 패턴은 이런 클래스 다이어그램이다 라고 못 박는 경향이 있는데 좋지 않은 듯합니다. 이책에서도 그런 같은 경향을 보이고 있습니다. 관심있는 분은 http://perl.plover.com/yak/design/ 아티클을 읽어보세요 :)
k*****0 2004.11.01. 신고 공감 0 댓글 2