CodeGym University
학습
강좌
과제
설문조사 및 퀴즈
게임
도움말
학습 재촉 스케줄
커뮤니티
사용자
포럼
채팅
기사
성공 사례
활동
리뷰
구독
옅은 색 테마
레슨
리뷰
회사 소개
시작
학습 시작
지금 학습을 시작하십시오
탐구 맵
레슨
모든 탐구
모든 레벨
좋은 소프트웨어 아키텍처의 기준
모듈 3
레벨 14,
레슨 3
능률 숙련된 프로그래머는 좋은 아키텍처와 나쁜 아키텍처를 쉽게 구분할 수 있지만 몇 마디로 설명하라는 요청을 받으면 그렇게 할 수 없을 것입니다. 좋은 아키텍처에 대한 단일 기준이나 단일 정의는 없습니다. 그러나 잘 생각해보면 좋은 아키텍처가 만족해야 할 여러 기준을 쓸 수 있다. 좋은 아키텍처는 무엇보다도 프로그램 개발 및 유지 관리 프로세스를 더 간단하고 효율적으로 만드는 논리적 아키텍처입니다. 프로그램의 아키텍처가 양호하
잘못된 소프트웨어 아키텍처에 대한 기준
모듈 3
레벨 14,
레슨 4
나쁜 디자인의 기준 인생은 매우 간단하게 작동합니다. 종종 똑똑해지기 위해 어리석은 일을 할 필요가 없습니다. 이는 소프트웨어 개발에도 적용됩니다. 대부분의 경우 어떤 일을 잘하기 위해서는 나쁘게만 하지 않으면 됩니다. 대부분의 프로그래머는 잘못 설계된 시스템 부분에 대한 경험이 있습니다. 그러나 더 슬프게도 대부분의 여러분은 자신이 그러한 시스템의 저자라는 사실을 깨닫는 슬픈 경험을 할 것입니다. 우리는 최고를 원했지만 언제
모듈식 소프트웨어 아키텍처
모듈 3
레벨 14,
레슨 5
6.1 분해 다양한 기준에도 불구하고 대형 시스템 개발의 주요 과제는 시스템의 복잡성을 줄이는 것 입니다 . 복잡성을 줄이기 위해 부품으로 나누는 것 외에는 아직 발명되지 않았습니다. 때로는 단순함을 위해 이것을 "분할 정복"의 원칙이라고 부르지만 소프트웨어 설계자의 관점에서 우리는 계층 적 분해 에 대해 이야기하고 있습니다 . 복잡한 시스템은 소수의 단순한 하위 시스템으로 구축되어야 하며, 각 하위 시스템은 더 작은 부분으로
올바른 소프트웨어 분해
모듈 3
레벨 14,
레슨 6
계층적 분해 응용 프로그램에 대한 클래스 작성을 즉시 시작해서는 안됩니다. 먼저 설계해야 합니다. 디자인은 사려 깊은 아키텍처로 끝나야 합니다. 그리고 이 아키텍처를 얻으려면 시스템을 지속적으로 분해해야 합니다. 분해는 계층적으로 수행되어야 합니다. 먼저 시스템은 가장 일반적인 형태로 작동을 설명하는 대형 기능 모듈/하위 시스템으로 나뉩니다. 그런 다음 결과 모듈을 더 자세히 분석하고 하위 모듈 또는 개체로 나눕니다. 객체를
소프트웨어 모듈 간의 연결을 해제하는 방법
모듈 3
레벨 14,
레슨 7
8.1 분해가 전부다 명확성을 위해 설명할 주요 사항을 설명하는 좋은 기사 "객체 지향 시스템의 분리"의 그림입니다. 아직도 애플리케이션 아키텍처 설계가 쉽다고 생각하시나요? 8.2 인터페이스, 구현 숨기기 시스템의 결합을 줄이기 위한 주요 원칙은 OOP의 원칙과 그 뒤에 있는 Encapsulation + Abstraction + Polymorphism의 원칙입니다. 그 이유는 다음과 같습니다. 모듈은 서로에 대해 "블랙 박스
종속성 역전
모듈 3
레벨 14,
레슨 8
9.1 종속성 역전 new Thread().start()서버 애플리케이션에서는 ?를 통해 스트림을 만들 수 없다고 말한 적이 있습니다. 컨테이너만 스레드를 생성해야 합니다. 우리는 이제 이 아이디어를 더욱 발전시킬 것입니다. 또한 모든 객체는 컨테이너에 의해서만 생성되어야 합니다 . 물론 모든 개체에 대해 말하는 것이 아니라 소위 비즈니스 개체에 대해 말하는 것입니다. 그것들은 종종 빈(bin)이라고도 합니다. 이 접근 방식의
소프트웨어 모듈을 연결하는 다른 방법
모듈 3
레벨 14,
레슨 9
직접적인 종속성을 메시징으로 대체 때때로 모듈은 일부 이벤트/변경 사항이 발생했음을 다른 사람들에게 알리기만 하면 되며 나중에 이 정보에 어떤 일이 발생하는지는 중요하지 않습니다. 이 경우 모듈은 "서로에 대해 알" 필요가 전혀 없습니다. 즉, 직접 링크를 포함하고 직접 상호 작용하지만 메시지 (메시지) 또는 이벤트 (이벤트)를 교환하는 것으로 충분합니다. 때로는 메시징을 통한 모듈 통신이 직접 종속성보다 훨씬 약한 것처럼 보
소프트웨어 수명 주기
모듈 3
레벨 15,
레슨 0
소프트웨어 제품의 수명 주기 단계 고품질 소프트웨어를 개발하려면 자격을 갖춘 팀, 작업 흐름 계획, 고객 기대치에 대한 제품 준수, 기한 준수 등 여러 요소가 필요합니다. 1. 요구사항 분석 이 단계는 가장 중요한 단계 중 하나로 간주될 수 있습니다. 프로젝트의 성공은 그것에 달려 있습니다. 그것은 모두 프로젝트 목표의 형성으로 시작됩니다. 그런 다음 완료해야 할 작업 목록과 향후 소프트웨어의 범위가 표시됩니다. 그 후 프로젝
폭포수 - 폭포수 모델
모듈 3
레벨 15,
레슨 1
캐스케이드 모델 장치 Waterfall이라고도 하는 Waterfall 모델은 소프트웨어 개발에 대한 가장 잘 알려진 접근 방식 중 하나입니다. 모델의 저자는 Winston Royce입니다. 1970년에 그는 장단점을 자세히 설명하는 기사에서 자신의 혁신의 본질을 설명했습니다. 같은 곳에서 그는 이 모델을 반복 모델로 정제할 수 있는 방법을 설명했습니다. 처음에는 폭포수 모델에서 개발 단계가 다음 순서로 진행됩니다. 요구 사항의
애자일 개발 방법론 - 애자일
모듈 3
레벨 15,
레슨 2
애자일 모델 Flexible(Agile) 방법론은 워크플로를 여러 개의 작은 주기로 이동하여 소프트웨어 개발의 위험을 줄이는 데 도움이 됩니다. 이러한 주기를 반복이라고 하며 일반적으로 2~3주 동안 지속됩니다. 반복은 각각의 기능을 향상시키는 작업으로 구성된 작은 소프트웨어 프로젝트와 같습니다. 여기에는 계획 작성, 요구 사항 평가, 프로젝트 동의, 코드 작성, 테스트 및 기술 문서 작성이 포함됩니다. 완전한 소프트웨어 릴리
스크럼 소개
모듈 3
레벨 15,
레슨 3
스크럼의 역사 1970년 Winston Royce의 "대형 소프트웨어 시스템 개발 관리" 보고서가 발표된 이후 많은 사람들이 Waterfall 개발 모델의 단점을 제거할 수 있는 방법론을 찾으려고 노력했습니다. "폭포"에 대한 대안은 지금 논의할 스크럼 방법이었습니다. 스크럼은 1986년 Takeuchi와 Nonaki의 저서 The New Rules for New Product Development에서 이름을 얻었습니다. 이
스크럼 작업
모듈 3
레벨 15,
레슨 4
사용자 스토리 사용자 스토리는 개발 중인 소프트웨어에 대한 요구 사항을 설명하는 효과적인 방법입니다. 이러한 이야기에는 소프트웨어 사용자를 대신하여 간략한 조언이 포함되어 있습니다. Scrum 방법론에서 목표 설정은 일반적으로 고객 또는 소프트웨어 소유자의 특권이므로 개발 프로세스에 영향을 미치는 주요 방법으로 간주됩니다. 각 사용자 스토리에는 텍스트의 양과 프레젠테이션의 복잡성에 제한이 있습니다. 역사는 대부분 작은 시트에
더 보기
1
...
30
31
32
33
34
35
Please enable JavaScript to continue using this application.