사용자 도구

사이트 도구


root

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판 양쪽 다음 판
root [2017/09/26 08:24]
kwon37xi
root [2017/09/26 08:24]
kwon37xi [나]
줄 22: 줄 22:
 로버트 C 마틴 소프트웨어 개발의 지혜 원칙, 디자인 패턴, 실천방법 한국어판 서문 로버트 C 마틴 소프트웨어 개발의 지혜 원칙, 디자인 패턴, 실천방법 한국어판 서문
 > 패턴은 문제에 대한 '해결책'이다. 이 해결책들은 특정 상황에서는 적절하지만, 그 외의 상황에서는 그렇지 못하다. 이점도 있지만, 그에 따라 치루어야할 비용도 있다. 패턴은 수백 명의 많은 소프트웨어 설계자들이 몇 년에 걸쳐 축적해온 지식이지만, 이 지식은 여러분 각자의 지성에 의해 적용되어야 한다. 패턴은 좋은 것도 나쁜 것도 아니다. 단지 존재할 따름이다. 어떤 패턴을, 언제 사용할지를 결정하기 위해서는 좀 더 주의를 기울여야 한다. > 패턴은 문제에 대한 '해결책'이다. 이 해결책들은 특정 상황에서는 적절하지만, 그 외의 상황에서는 그렇지 못하다. 이점도 있지만, 그에 따라 치루어야할 비용도 있다. 패턴은 수백 명의 많은 소프트웨어 설계자들이 몇 년에 걸쳐 축적해온 지식이지만, 이 지식은 여러분 각자의 지성에 의해 적용되어야 한다. 패턴은 좋은 것도 나쁜 것도 아니다. 단지 존재할 따름이다. 어떤 패턴을, 언제 사용할지를 결정하기 위해서는 좀 더 주의를 기울여야 한다.
-> 방식은 고품질의 소프트웨어 생산을 돕는 '행동 양식'이다 팀 버들이 팀원 서로에게, 그리고 업무에 대해, 또 그들이 만든 코드에 대해, 어떻게 행동해야 하는지를 나타낸다. 이런 방식은 많은 팀에서 시도되어 왔고, 이런 방식을 통해 많은 이점을 얻을 수 있다는 것이 분명해졌다. 그렇지만 모든 팀에서 이 방식을 채택할 수는 없을 것이다. 각 팀은 먼저 이런 방식을 시도해보고 유익한지 여부는 각자가 판단해야 한다.+> 방식은 고품질의 소프트웨어 생산을 돕는 '행동 양식'이다 팀 버들이 팀원 서로에게, 그리고 업무에 대해, 또 그들이 만든 코드에 대해, 어떻게 행동해야 하는지를 나타낸다. 이런 방식은 많은 팀에서 시도되어 왔고, 이런 방식을 통해 많은 이점을 얻을 수 있다는 것이 분명해졌다. 그렇지만 모든 팀에서 이 방식을 채택할 수는 없을 것이다. 각 팀은 먼저 이런 방식을 시도해보고 유익한지 여부는 각자가 판단해야 한다.
  
 [[http://www.mimul.com/pebble/default/2014/02/04/1391490935022.html|[번역] 좋은 엔지니어와 나쁜 엔지니어의 리더십]] [[http://engineering.foursquare.com/2014/01/30/good-tech-lead-bad-tech-lead/|영문]] [[http://www.mimul.com/pebble/default/2014/02/04/1391490935022.html|[번역] 좋은 엔지니어와 나쁜 엔지니어의 리더십]] [[http://engineering.foursquare.com/2014/01/30/good-tech-lead-bad-tech-lead/|영문]]
root.txt · 마지막으로 수정됨: 2022/06/27 15:24 저자 kwon37xi