천객만래 [千客萬來] (It has an interminable succession of visitors)

도메인 주도 설계 핵심 - 핵심을 간추린 비즈니스 중심의 설계로 소프트웨어 개발 프로젝트 성공하기

반 버논 저/박현철, 전장호  | 에이콘출판사 | 2017년 09월 25일 | 원제 : Domain-Driven Design Distilled

 

책소개

도메인 주도 설계(DDD)를 프로젝트에 적용하고자 하는 개발자, 소프트웨어 아키텍트 또는 관리자가?DDD를 빠르게 배우고 적용할 수 있게 도와준다.?뿐만 아니라?좋은 소프트웨어를 만들기 위해 꼭 필요한 역할인 비즈니스 전문가와 플랫폼 기획자도?DDD를 이해하고 적극적으로 설계에 참여할 수 있게 해준다.

도메인 모델을 분리하고 명확한 경계 내에서 비즈니스 전문가와 개발자가 함께 공통적으로 사용할 수 있는 보편 언어를 개발하는 방법,?레거시 시스템을 다루기 위해 서브 도메인을 활용하는 방법과?여러 개의 분리된 컨텍스트의 통합을 위한 기술적 메커니즘까지 반드시 알아야 할 것들을 빠짐없이 다루고 있다.

다른 두꺼운?DDD?서적들이 바이블이라면,?이 책은 얇지만 꼭 필요한 핵심 개념과 함께 프로젝트 적용을 이해하기 쉬운 예제 흐름으로 설명한다.?따라서 DDD를 처음 접하는 사람부터 도메인 주도 설계 개념을 혼란스럽게 생각하는 사람들에게까지 도움이 되는 길잡이가 돼줄 것이다.

 

OOD -> MDD -> DDD 로 넘어오는 단계에서 요즘은 아키텍처 설계에 MSA + DDD, MSA + MDD 로 설계를 다수 하는 것으로 보인다.

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

 

델파이가 출시된 이후 25년간의 델파이 역사, 발전 과정 등을 돌아볼 수 있습니다.

델파이의 역사는 1983년 터보 파스칼 IDE부터 시작됩니다. 실제 '델파이'라는 이름으로 첫 선을 보인것은 1995년 RAD 개발환경을 갖추어 재탄생한 시점부터 입니다.

 

 

https://tech.devgear.co.kr/delphi_news/463165

Posted by 사용자 SB패밀리

댓글을 달아 주세요

매달 인터넷 여러 사이트에서 발생하는 키워드, 태그를 가지고 개발 언어 순위를 매기는 사이트입니다.

 

이번 달에는 Top 1의 순위 변동이 있네요.

C언어 우상향은 계속 되고 있습니다. 신기방기.

거기다가 Python의 약진은 계속됩니다. 구글 트렌드에서 확인해도 파이썬의 약진이 두드러지게 보이고 있습니다.

파이썬으로 영상처리 알고리즘 응용 앱이나 리소스 만들까 봅니다.

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

 

Github.com 을 많은 사람들이 사용하고 있습니다.

github은 점점 기능을 추가하고 개선을 하면서 여러가지 기능을 제공하고 있습니다.

거기에다 자동으로 버전업(형상관리)를 해주고 있으니 얼마나 편리한지 모르겠습니다.

간단한 text 파일 작성이라든가, markdown 파일 작성, 각종 소스관리가 무척 편리합니다.

그래서, github 이용자는 점점 늘어나고 있습니다.

github project 관리 기능

그런데, 단지 텍스트 파일이 아닌 다른 파일들 즉, 이미지나 특정 문서 포맷 파일, 다이어그램 파일 등을

업로드해서 저장하려고 하면 용량이 기하급수적으로 늘어납니다.

이럴 경우에는 내가 사용할 수 있는 용량이 얼마인지 점차 궁금해지고

구글링이나 다음에서 검색해서 찾아보게 되겠죠.

그래서 좀 알아봤습니다. github는 개인의 용량 관리를 어떻게 하고 있을까?

https://help.github.com/en/github/managing-large-files/what-is-my-disk-quota 

 위 사이트에 들어가서 확인해보면

Github에 업로드할수 있는 최대 용량은 단일 파일 100MB, repos(저장소) 용량 최대 100GB이다. 하지만 저장소 용량은 사실상 100GB를 채울수 없게 만들고, Github에서도 1GB 이하로 유지하기를 바라고 있다. 오늘은 왜 100GB를 채울수 없게 만드는지 알아볼 필요가 있습니다.

http://blog.naver.com/mirusu400/221782802220

 

Github의 최대 용량에 관해서

https://help.github.com/en/github/managing-large-files/what-is-my-disk-quota 우선 위 사이트에 들어가...

blog.naver.com

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

마이크로소프트 팀즈 vs 슬랙테그날러지즈 슬랙

 

현재 글로벌 메신저의 가장 사용자가 많은 커뮤니케이션 툴이 있다.

바로, Teams와 Slack이다.

그간 Slack의 사용자가 독보적이었는데 그 흐름이 바뀌고 있다.

아마도 전세계 커뮤니케이션툴 이용자는 MS의 주장처럼 올 해 초부터 팀즈가 될 것으로 보인다.

 

출처 : trends.google.com

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

파이썬 vs 자바 vs C++ vs 자바스크립트

 

C/C++ 계열의 언어가 여전히 강세다. 그리고 무엇보다 점점 더 거세지는 파이썬(Python)의 인기다. 

어딜가나 파이썬(Python)의 인기가 대단하다.

 

 

 

전세계(World)에서의 4가지 개발언어의 인기를 살펴보자.

 

한국(South Korea)에서의 4가지 개발언어의 인기를 살펴보자.

미국(USA)에서의 4가지 개발언어의 인기를 살펴보자.

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

마이크로소프트 팀즈 vs 슬랙

 

팀즈 하루 이용자 슬랙 넘어서다.

 

결국, 스마트 워치 시장을 애플이 먹 듯이 협업 툴 시장을 마이크로소프트가 삼키는 군요.

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

전세계 mybatis와 hibernate 점유율

동아시아를 제외하고 대부분 나라에서는 Hibernate를 압도적으로 많이 사용하고 있으며, Hibernate를 배우게 되면 Mybatis보다 코드가 더 간결하며, 더 객체 지향적이고 생산성이 매우 높다는 것을 장점으로 생각하게 됩니다.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

클라우드 선두업체 아마존, 블록체인 개발서비스 정식 출시 

https://news.v.daum.net/v/20190502173046670
#AWS #AMB #아마존 #AMAZON

 

클라우드 선두업체 아마존, 블록체인 개발서비스 정식 출시

(서울=뉴스1) 이수호 기자 = 전세계 1위 클라우드업체 아마존(AWS)이 기업용 블록체인 개발서비스 '아마존 매니지드 블록체인'을 정식 출시했다. 2일 아마존은 자사 홈페이지를 통해 아마존 매니지드 블록체인 서비스의 정식 버전을 공개하고 고객사 모집(미국 동부 대상)에 나선다고 밝혔다. 다만 한국 서비스 시기는 공개하지 않았다. 아마존 매니지드 블

news.v.daum.net

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

2019년 4월 인터넷에서 가장 인기 있는 프로그래밍 언어 순위는?

Top programming language ?

인터넷에서 인기있는 tag나 검색어를 바탕으로 한 것이라서 100% 신뢰라기 보다는 참고용.

Assembly language, Object-C, MATLAB의 약진이 돋보인다. Groovy 가 가장 많은 상승을...

reference : TIOBE index

Posted by 사용자 SB패밀리

댓글을 달아 주세요

RAD Studio에는 여러 라이센스 옵션이 있습니다.

  • 지명 사용자 라이센스 : 특정 개인에게 사용 권한을 부여 라이센스. 소프트웨어는 여러 대의 컴퓨터에 설치하여 사용할 수 있지만 동시에 사용할 수는 1 만입니다. 지명 사용자 라이센스를 여러 사용자가 공유하거나 양도 할 수 없습니다. 지명 사용자 라이센스를 사용하려면, EDN 계정 (E 메일 주소가 필요)를 작성해야합니다.
  • 네트워크 지명 (Network Named) 또는 네트워크 동시 (Network Concurrent) 라이센스 : 라이센스 서버 (Embarcadero License Server)에 의해 관리되는 라이센스. 네트워크 지명 사용자 라이센스는 조직의 사용자에게 할당하여 사용할 수 있습니다. 네트워크 동시 라이센스는 구입 한 라이센스 수 분의 조직의 불특정 다수가 동시에 사용할 수있는 라이센스입니다. 어떤 라이센스도 조직 내에 구축 된 라이센스 서버에 연결하는 네트워크 환경이 필요합니다.
  • Flexera FlexNet에 의해 관리되는 네트워크 라이센스 (일반 판매는하고 있지 않으므로 자세한 내용은 문의 바랍니다)
  • 아카데믹 라이센스 - 학생 개인의 학습을위한, 아카데믹 볼륨 라이선스 - 학교 교실 수업 교육을위한




RAD Studio 10.2 Tokyo는 다음 이전 버전의 라이센스를 사용할 수 있습니다.

  • Delphi 10.1 Berlin, Delphi 10 Seattle, Delphi XE8, Delphi XE7, Delphi XE6, Delphi XE5, Delphi XE4, Delphi XE3, Delphi XE2, Delphi XE, Delphi 2010 Delphi 2009, Delphi 2007, Delphi 7
  • C ++ Builder 10.1 Berlin, C ++ Builder 10 Seattle, C ++ Builder XE8, C ++ Builder XE7, C ++ Builder XE6, C ++ Builder XE5, C ++ Builder XE4, C ++ Builder XE3, C ++ Builder XE2, C ++ Builder XE, C ++ Builder 2010, C ++ Builder 2009, C ++ Builder 2007, C ++ Builder 6
  • HTML5 Builder XE3, RadPHP XE2, RadPHP XE

Posted by 사용자 SB패밀리

댓글을 달아 주세요

2018년 1월, 12월 프로그래밍 언어 인기도 순위


네덜란드 티오베(TIOBE) 회사가 매달 검색엔진 통계를 이용하여 발표하는 개발언어 인기도 순위


2018년12월



2018년 1월


1년 전 / 1개월 전 정보이지만 대략 트렌드 파악이 간다.

2019년 1월은 어떨지 조만간 확인하도록 하고

C#은 6위, DELPHI는 11위 정도를 유지하고 있구나.


https://www.tiobe.com/tiobe-index/

Posted by 사용자 SB패밀리

댓글을 달아 주세요

마이랩뷰 사이트 운영 종료 안내


안타깝게도 커뮤니티 사이트가 문을 닫네요.

제가 활동을 많이 한 건 아니지만 아쉽습니다.


사이트에 있는 강의 Q&A로 공부하고 미니프로젝트 진행해서 

나도 정보 및 팁 공유하자고 다짐만 했더니

시간이 지나가버리네요.


자세한 내용은 사이트로 접속해서 확인해 보시기 바랍니다.


이미지를 클릭하시면 이동합니다.



Posted by 사용자 SB패밀리

댓글을 달아 주세요

2017 가장 멋진 앱 개발 플랫폼 Top 10 - 엠바카데로 선정

10 Coolest App Development Platforms of 2017




오늘날 업무 관련 미팅이나 개인적으로 해야 할 일 등 거의 모든 활동을 보조하는 다양한 모바일 앱들이 있습니다.

스마트폰 자체적으로 제공하는 기능이 많아져 모바일 앱의 신기함이 다소 약화되기는 했습니다.

물론 모바일 앱 개발 시장이 포화 상태에 있다고 생각할 수도 있습니다.

하지만, 수많은 혁신을 거듭하는 전문가들은 기술의 속도, 보안, 유연성, 연결성을 놀라울 정도로 향상시킴으로써 그 가치를 더해주고 있습니다.


2017년, 가장 멋진 모바일 앱 개발 플랫폼은 무엇이었을까요?

 

1. Adobe Systems

 

2. Amazon

 

3. Appcelerator by Axway

 

4. Embarcadero (엠바카데로)

미국 텍사스 오스틴에 위치한 이 혁신적인 기업은 신속한 모바일 앱 개발 도구인 RAD스튜디오를 많은 다양한 기업들에게 제공하고 있습니다. RAD스튜디오를 이용해 모바일 앱 뿐만 아니라 주요 4대 플랫폼 윈도우/맥 OS/안드로이드/iOS 용 앱을 개발할 수 있습니다. 사용자들은 동일한 코드를 사용해 서로 다른 운영 체제에 적합한 애플리케이션을 만들 수 있습니다.

 

5. Kinvey

 

6. Kony

 

7. Mendix

 

8. Oracle

 

9. Pegasystems

 

10. Red Hat



출처 : 데브기어 https://readitquik.com/articles/data/10-coolest-app-development-platforms-of-2017/



Posted by 사용자 SB패밀리

댓글을 달아 주세요

2016년도 적용 SW기술자 평균임금 공표

출처: 한국소프트웨어산업협회(KOSA)






Posted by 사용자 SB패밀리

댓글을 달아 주세요

[링크] 볼랜드 관련 정보나 자료 링크 모음



제다이 JEDI
http://www.delphi-jedi.org



About.com 델파이
http://delphi.about.com



닥터밥 : 델파이, C++빌더, Kylix, C#Builder, Delphi for .NET
http://www.drbob42.com



소스포지 : 오픈소스 개발 웹사이트
http://www.sourceforge.net



코드기어 : 델파이,C++빌더,C#빌더,InterBase,JBuilder,Turbo,PHP
http://www.codegear.com/

Posted by 사용자 SB패밀리

댓글을 달아 주세요

201가지 소프트웨어 개발원칙



201가지 소프트웨어 개발원칙


일반원칙
1. 품질이 제일이다.
2. 품질의 정의는 보는 사람에 따라 다르다,
3. 생산성과 품질은 불가분의 관계이다.
4. 고품질의 소프트웨어를 개발할 수 있다.
5. 사후에 품질을 만들어 넣으려 하지 말라.
6. 성능보다 신뢰성이 더 중요하다.
7. 시제품을 고객에게 빨리 보여준다.
8. 고객이나 사용자와 충분히 협의한다.
9. 개발자와 고객에게 적합한 보상기준을 마련한다.
10. 처음 시도하는 것은 폐기할 작정으로 개발한다.
11. 적절한 유형의 시제품을 개발한다.
12. 적절한 기능을 시제품화 한다.
13. 일회용 시제품은 빨리 개발한다.
14. 시스템을 점증적으로 개발한다.
15. 보면 볼수록 더 많은 것을 원한다.
16. 개발중의 변경은 피할 수 없다.
17. 가능하면 개발하기 보다는 구매한다.
18. 사용자 매뉴얼이 간단하게 되도록 소프트웨어를 개발한다.
19. 아무리 복잡한 문제라도 해결책은 있다.
20. 가정한 것이 있으면 이를 기록한다.
21. 다른 단계에는 다른 언어를 사용한다.
22. 도구를 사용하기 전에 기법을 배운다.
23. 도구는 현실적으로 사용한다.
24. 소프트웨어 도구는 우수한 개발자에게만 제공한다.
25. CASE도구는 고가이다.
26. "Know-How"만큼 "Know-When"도 중요하다.
27. 목적을 달성하면 중단한다.
28. 정형적 방법을 알아야 한다.
29. 조직의 평판을 중시한다.
30. 대세를 따를 때는 주의해야 한다.
31. 기술을 무시하면 안된다.
32. 문서 표준을 사용한다.
33. 모든 문서에는 용어정의를 한다.
34. 모든 문서에는 색인을 부여한다.
35. 같은 개념에는 같은 명칭을 사용한다.
36. 연구결과의 기술이전은 즉시 되지 않는다.
37. 책임을 질 줄 알아야 한다.

요구공학 원칙
38. 요구사항이 불명확할수록 비용예측은 어렵다.
39. 요구사항을 기록하기 전에 문제를 확실하게 결정한다.
40. 지금 요구사항을 결정한다.
41. 요구명세상의 오류는 즉시 수정해야 한다.
42. 시제품으로 사용자 인터페이스 선정의 위험을 줄인다.
43. 요구사항 항목의 선정근거를 기록한다.
44. 최소 요구사항을 식별한다.
45. 요구사항을 검토한다.
46. 요구분석단계에서 설계하지 않는다.
47. 올바른 기법을 사용한다.
48. 여러 관점으로 요구사항을 분석한다.
49. 요구사항을 현명하게 조직화한다.
50. 요구사항의 우선순위를 정한다.
51. 간결하게 기록한다.
52. 모든 요구사항에 유일한 식별번호를 부여한다.
53. 요구사항의 모호성을 줄인다.
54. 자연어는 정형모델로 보완만 하고 대체하지는 말라.
55. 먼저 자연어로 기록하고 정형모델을 작성하라.
56. 요구명세서는 읽기 쉬워야 한다.
57. 신뢰성에 대하여 구체적으로 명시한다.
58. "수용 불가능한" 환경조건을 명시한다.
59. 미결정항목은 각주와 함께 작성한다.
60. 요구명세서를 데이터베이스에 저장한다.

설계 원칙
61. 요구사항에서 설계로의 전환은 어렵다.
62. 설계산출물에서 요구사항을 추적한다.
63. 대안을 평가한다.
64. 문서가 없는 설계는 설계가 아니다.
65. 캡슐화 한다.
66. 가능하면 재사용한다.
67. 단순하게 개발한다.
68. 특수한 경우를 많이 만들지 않는다.
69. 지적인 거리를 최소화 한다.
70. 설계를 지적 통제하에 둔다.
71. 개념적 무결성을 유지한다.
72. 개념적 오류는 문법적 오류보다 심각하다.
73. 결합도는 낮추고 응집도는 높인다.
74. 변경이 쉽게 설계한다.
75. 유지보수를 고려하여 설계한다.
76. 오류수정이 쉽게 설계한다.
77. 일반성을 띄게 소프트웨어를 개발한다.
78. 유연성 있게 소프트웨어를 개발한다.
79. 효율적인 알고리즘을 사용한다.
80. 사용자가 필요로 하는 모든 정보는 모듈명세서에 있다.
81. 설계는 다차원적이다.
82. 뛰어난 설계는 뛰어난 설계자가 한다.
83. 어플리케이션에 대해서 숙지한다.
84. 큰 투자 없이도 재사용할 수 있다.
85. 무효한 값을 입력하면 적절한 오류 메세지를 출력하도록 한다.
86. 소프트웨어 신뢰성은 중복성을 통해 얻을 수 있다.

코딩원칙
87. 트릭을 사용하지 않는다.
88. 광역변수를 사용하지 않는다.
89. 하향식으로 읽을 수 있도록 작성한다.
90. 부작용을 제거한다.
91. 의미 있는 명칭을 사용한다.
92. 사람을 위한 프로그램을 작성한다.
93. 최적의 자료구조를 사용한다.
94. 빨리 하기 보다는 올바르게 한다.
95. 코드를 완성하기 전에 주석을 작성한다.
96. 코딩을 시작하기 전에 문서화한다.
97. 모든 구성요소를 책상 위에서 실행시켜 본다.
98. 코드 검사를 실시한다.
99. 비구조적 언어도 사용할 수 있다.
100. 구조화된 코드가 반드시 좋은 코드는 아니다.
101. 너무 깊이 중첩 시키지 않는다.
102. 적절한 언어를 사용한다.
103. 프로그래밍 언어를 핑계 삼아서는 안된다.
104. 언어에 대한 지식은 중요하지 않다.
105. 프로그램의 체계를 정비한다.
106. 코딩을 너무 빨리 시작하지 말아라.

시험원칙
107. 시험에서 요구사항을 추적한다.
108. 시험하기 훨씬 이전에 시험을 계획한다.
109. 자신이 개발한 소프트웨어를 자신이 시험하지 않는다.
110. 자신이 개발한 소프트웨어의 시험계획은 남이 세운다.
111. 시험은 결함을 드러나게 할 뿐이다.
112. 오류의 많고 적음과 소프트웨어의 가치는 무관하다.
113. 오류를 찾아야 성공적인 시험이다.
114. 15% 모듈에서 50%의 오류가 발견된다.
115. 블랙박스시험과 화이트박스시험을 실시한다.
116. 시험사례에는 예상결과를 포함시킨다.
117. 무효한 값으로 시험한다.
118. 항상 스트레스 시험을 한다.
119. 빅뱅설을 적용하면 안된다.
120. McCabe의 복잡도 척도를 사용한다.
121. 효과적인 시험종료 척도를 사용한다.
122. 시험 적용범위를 효과적으로 활용한다.
123. 단위시험이 끝나기 전에 통합하지 않는다.
124. 소프트웨어에 특정한 시험용 코드를 내장시킨다.
125. 오류의 원인을 분석한다.
126. 오류를 개인적인 차원으로 생각하지 않는다.

관리원칙
127. 뛰어난 관리는 뛰어난 기술보다 중요하다.
128. 적절한 해결책을 이용한다.
129. 읽은 것을 모두 믿지 않는다.
130. 고객의 우선순위를 알아야 한다.
131. 사람이 성공의 열쇠이다.
132. 많은 사람보다는 소수정예요원이 더 낫다.
133. 부하 직원의 말을 경청한다.
134. 부하 직원을 신뢰해야 한다.
135. 항상 기대치를 높이 가진다.
136. 능숙한 의사소통 기술은 필수적이다.
137. 진심으로 부하직원을 위해준다.
138. 사람은 의외의 것으로 동기부여 받는다.
139. 사무실 분위기를 조용히 유지한다.
140. 인력과 시간은 대체할 수 없다.
141. 소프트웨어 개발자의 능력차이는 크다.
142. 원하는 목표로 최적화 할 수 있다.
143. 자료수집을 강요하면 안된다.
144. 코드 1줄 당 비용은 무시한다.
145. 완벽한 생산성 측정방법은 없다.
146. 비용산정 모델을 조정한다.
147. 일정은 현실적으로 계획한다.
148. 불가능한 것은 피한다.
149. 측정하기 전에 무엇을 측정할 지 알아야 한다.
150. 생산성 자료를 수집한다.
151. 팀의 생산성을 잊지 않는다.
152. 인월 당 행수(LOC/PM)은 언어와 관계없다.
153. 일정을 믿는다.
154. 정확하게 산정한 비용견적이라도 완전히 맞지는 않는다.
155. 일정을 정기적으로 재조정한다.
156. 약간 적은 견적을 항상 나쁘다고 할 수는 없다.
157. 자원을 적절히 할당한다.
158. 프로젝트를 치밀하게 계획한다.
159. 계획을 최신 버전으로 유지한다.
160. 잦은 계획변경의 파급효과에 주의한다.
161. 최상위 10개의 위험항목을 알아야 한다.
162. 직면한 위험을 이해한다.
163. 적절한 프로세스 모델을 사용한다.
164. 방법론이 당신을 구해주지는 못한다.
165. 기적적인 생산성 향상 비법은 없다.
166. 진척도의 의미를 정확히 알아야 한다.
167. 계획과의 차이만 관리한다.
168. 하드웨어에 과중한 부하를 주지 않는다.
169. 하드웨어의 발전에는 낙천적으로 대응한다.
170. 소프트웨어의 발전에는 비관적으로 대응한다.
171. 예상치 못한 사고로 인해 대혼란이 자주 초래된다.
172. 프로젝트의 사후 검토회를 실시한다.

제품보증 원칙
173. 제품보증 수준은 프로젝트에 맞게 조정한다.
174. 형상관리 절차를 조기에 확립한다.
175. 소프트웨어 프로세스에 SCM을 적용한다.
176. SCM은 프로젝트 관리에 독립적으로 조직화한다.
177. 개발과 제품보증업무 사이를 순환보직화 한다.
178. 모든 중간산출물에 명칭과 버전 번호를 부여한다.
179. 기준선을 통제한다.
180. 모든 것을 보존한다.
181. 모든 변경을 계속 추적한다.
182. 변경관리를 해야 한다.
183. 변경요청에 우선순위를 부여하고 일정계획을 세운다.
184. 대규모 개발에는 검증과 확인(V&V)을 적용한다.

진화원칙
185. 소프트웨어는 계속 변화한다.
186. 소프트웨어의 엔트로피는 증가한다.
187. 고장나지 않았으면 고치지 않는다.
188. 증상이 아닌 근본적인 문제를 수정한다.
189. 요구사항을 먼저 변경한다.
190. 릴리즈 전의 오류는 릴리즈 후의 오류의 원인이 된다.
191. 프로그램은 오래되면 될수록 유지보수하기 어려워진다.
192. 언어는 유지보수성에 영향을 미친다.
193. 때로는 처음부터 수정하는 방법이 좋다.
194. 최악의 구성요소는 처음부터 다시 개발한다.
195. 유지보수는 개발보다 많은 오류를 발생시킨다.
196. 변경한 후에는 반드시 회기 시험을 실시한다.
197. 변경사항이 간단하다고 방심하면 잘못 변경하게 된다.
198. 비구조적인 코드는 구조화해도 개선되지 않는다.
199. 최적화하기 전에 프로파일러를 사용한다.
200. 시스템에 친밀감을 갖는다.
201. 시스템은 환경변화에 따라 계속 변화한다.


출처 : '201가지 소프트웨어 개발원칙' 목차


Posted by 사용자 SB패밀리

댓글을 달아 주세요




ITO(IT Outsourcing)은 아웃소싱은 축적된 기술 및 시스템 운영 경험을 바탕으로 고객사를 위한 시스템의 기획 개발
운영 전략수립 BRP등 전반적인 정보시스템 서비스를 제공
합니다.


SI은 고객의 비즈니스 환경을 분석하여 사업목적에 적합하게 하드웨어, 소프트웨어, 네트워크를 유기적으로 통합시켜
정보기술을 효과적으로 사용할 수 있도록 시스템을 통합, 구축하는 서비스입니다.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

LabVIEW 정규교육 수강권 무료 제공 이벤트를 하네요.


우리는 LabVIEW 2014 업그레이드 CD를 벌써 받아서 이번 이벤트는 응모를 못할 것 같네요.


LabVIEW 2014로 업그레이드 해서 수백만원 상당의 정규교육을 무료로 들어보세요...


저도 몇 번 수강했는데 도움이 된 것 같아서 추천해 드립니다.



http://www.ni.com/korea




Posted by 사용자 SB패밀리

댓글을 달아 주세요

[개발/랩뷰] CLAD 한 번에 끝내기 1편




어쩌다 보니 랩뷰(LabVIEW)도 하게 되었고 제대로 업무에 활용을 못했지만
업무활용보다 먼저 LabVIEW 시험을 보게되었다.
프로젝트를 하나 끝내기를 했지만 코드가 엄청 많았다.
그런데. 랩뷰 강의를 core3 까지 듣게 되면 그 코드가 엄청줄어들게 될 꺼라는 생각이다.
앞으로 랩뷰로 업무에 바로 활용될 수 있도록 시간을 만들어서 프로그래밍을 할 예정이다.

테스트를 해볼 수 있는 프로젝트가 필요하다. 예전 프로젝트.

강의 들어보고 더욱 힘내자.



[개발/랩뷰] CLAD 한 번에 끝내기 2편


Posted by 사용자 SB패밀리

댓글을 달아 주세요