오픈 소스 ECM과 상호 작용하려면 새로운 프레임 워크의 설계 및 개발을 시작해야합니다. 이는 웹 사이트 개발자가이 ECM과 상호 작용하는 데 도움이되는 사용자 정의 데이터 모델을 포함하므로 노드 조작의 세부 사항 및 기타 하위 레벨 세부 사항에 신경 쓸 필요가 없습니다. 그것은 개발할 클래스와 메소드의 무리 일뿐입니다.

프로젝트의 조직 및 관리 방법에 대한 의문이 있습니다. 이러한 종류의 프로젝트를 개발할 때 따라야 할 일반적인 규칙, 팁, 모범 사례 또는 명심해야 할 것이 있습니까?

프레임 워크 또는 라이브러리 개발과 응용 프로그램 사이에 약간의 차이가 있다고 확신합니다.

먼저 프레임 워크 폐기물 증후군을 피하기위한 두 가지 규칙이 있습니다.

• 기존 요구 사항이 없어 내 필요의 80 %를 커버하고 지난 20 %에 맞게 확장 가능
• 다른 응용 프로그램에서 다시 사용할 것이라는 거의 확실성

당신이 그들을 통과 한 후 이것을 확인하십시오 :

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

1) 기능은 작업 코드에서 추출 된 경우에만 프레임 워크에 추가해야합니다. 다시 말해, 멋진 새 아이디어를 멋진 새 프레임 워크에 추가하기 전에 실제 실제 응용 프로그램에서 실제로 가치를 추가하고 반복을 줄이는 지 확인하십시오.

2) 문서, 문서, 문서.

3) 문서, 문서, 문서.

고통스러운 경험과 많은 노력이이 조언으로 이어집니다. 작동하는 소프트웨어에서 프레임 워크를 추출하거나 리팩토링합니다. 나중에 프레임 워크를 추출하려고하지만 프레임 워크를 먼저 빌드하지는 않는다는 점을 염두에두고 해당 소프트웨어를 빌드하십시오.

나는 Framework Design Guidelines 책을 제안 할 것이다 . 몇 살이지만 원칙은 그대로입니다. 그것은 많은 패턴을 가지고 있으며 프레임 워크를 만들 때 결정을 내리는 이유를 설명합니다.

1) 처음부터 좋은 컨벤션을 고수하고, 매우 구체적인 컨벤션을 문서화했는지 확인하십시오. 최상의 프레임 워크는 내부적으로 일관성이 있습니다.

2) 좋은 코드 주석부터 가장 중요한 기능이 요구하고 생산하는 것을 설명하는 것에 이르기까지 모든 것이 문서화되어 있는지 확인하십시오. 매우 단순 해 보이지만 누군가가 14 시간 연속 사용하면 단지 필요한 그 한 가지는 바로 그때.

3) 프레임 워크가 달성하고자하는 목표, 현실적인 목표 및 전반적인 우선 순위를 포함하여 프로젝트 개요를 작성하십시오.

4) 사람들이 사용할 수있게된다면, 어떤 형태의 지원 프로세스 / 버그 추적이 있는지 확인하십시오. 버그가있을 것입니다. 우리 모두에게 발생하지만, 오프에서 관리 할 수 ​​있다면 인생을 더 편하게 해줄 것입니다.

대체로 모든 응용 프로그램을 구축하는 비슷한 접근 방식이지만 개발자는 사용자보다 훨씬 까다 롭고 최상의 프레임 워크는 우리가 선택할 수 있고 이해하고 싸울 필요가없는 프레임 워크입니다.

나는 많은 이야기에 동의하지 않으며 더 이상 언급되지 않았다고 생각하므로 처음부터 시작할 것입니다.

민첩한 방법론

프레임 워크 개발 과정에서 민첩한 방법론을 채택하여 변화에 적응하고로드 블록에 신속하게 대응하며 기능적이고 품질이 우수한 최종 제품을 보장 할 수 있습니다. 애자일 방법론은 "Agile Manifesto"에 따르면 다음과 같은 우선 순위를 정합니다.

프로세스 및 도구를 통한 개인 및 상호 작용 포괄적 인 문서를 통한
소프트웨어 작업 계약 협상을 통한 고객 협업 계획 에 따라 변경 에 응답

맞습니다. 나는 기능이 문서보다 중요하다고 말했다. "Agile Manifesto"는 오른쪽 우선 순위가 여전히 중요하지만 왼쪽보다 우선 순위가 낮다는 점을 언급합니다.

통신

프레임 워크를 만드는 사람은 누구나 알아야합니다.

1. 사용 방법 : 대상 응용 프로그램
2. 해결하려는 문제 : 대상 문제
3. 사용 대상 : 대상 고객

예를 들어, 회사에서 ASP .NET을 사용하여 최종 응용 프로그램을 개발하려는 경우 프로그래머에게 위의 내용을 알리지 않고 "이 프레임 워크를 만들도록"하는 것은 어리석은 일입니다. 프로그래머가 대상 응용 프로그램을 모른다면 웹 지향적이지 않을 수 있습니다. 문제를 알지 못하면 다른 목적으로 프레임 워크를 만들 수 있습니다. 청중을 모른다면 C ++로 프레임 워크를 프로그래밍 할 수 있습니다. 이러한 상황은 결과 프레임 워크를 쓸모 없게 만듭니다.

스타일

말할 필요도없이, 프로그래밍 스타일 / 포맷을 설정하고이를 고수하십시오.

E

1. 모듈성 : 문자 적으로가 아니라 프로그래밍 방식으로 코드를 재사용하십시오.
2. 효율성 : 코드는 재사용하기위한 것입니다. 속도 저하는 배가됩니다.
3. 유지 관리 성 : 해당 프로그램을 수정하지 않고도 프레임 워크를 편집하여 여러 프로그램을 업데이트 할 수 있습니다.
4. 유용성 : 응용 프로그램이 실제로 농구대를 뛰어 넘지 않고 프레임 워크를 사용할 수 있습니까?
5. 실용성 : 휠을 다시 만들지 않아도 휠을 재발 명하지 마십시오. 프레임 워크는 다른 프레임 워크에 의존 할 수 있습니다.
6. 중복성 : 예외 / 오류를 포착합니다. 어디에나. 처리하십시오. 어디에나. 오류가 있음을 알더라도 오류를 처리하기 위해 로컬 범위의 코드를 신뢰하지 마십시오.

프레임 워크 또는 라이브러리 개발과 응용 프로그램 사이에 약간의 차이가 있다고 확신합니다.

개발 과정은 본질적으로 동일합니다. 가장 큰 차이점은 일반적으로 프로젝트 범위 및 정의 측면에서 발견되지만 차이점은 마케팅 및 배포 문제와 관련이 있습니다. 응용 프로그램은 프레임 워크 또는 라이브러리를 포함하거나 사용할 수 있으며 프레임 워크는 라이브러리 모음 일 수 있습니다.

프로젝트의 조직 및 관리 방법에 대한 의문이 있습니다. 이러한 종류의 프로젝트를 개발할 때 따라야 할 일반적인 규칙, 팁, 모범 사례 또는 명심해야 할 것이 있습니까?

프로젝트 구성 및 관리는 모든 개발 프로젝트에서 동일합니다. 다시 한 번 범위에 해당합니다. 그러나 프레임 워크 작성과 관련하여 달성하려는 대상에 대해 매우 명확한 비전을 갖고 API의 프리젠 테이션 측면에서 일관성을 유지하기 위해 프레임 워크의 공용 인터페이스에 엄격한 설계 규칙을 적용해야합니다. 모든 개발자가 자신의 작업을 수행하도록 허용하면 복잡한 혼란과 매우 우아한 API 디자인이 생깁니다.

이 책 자체가 .NET 기반 프레임 워크 개발을 목표로하고 있음에도 불구하고 프레임 워크 디자인 가이드 라인 을 읽어야한다는 Ryan Hayes의 권고 에 이어 두 번째로 , 일반적인 조언은 사용하도록 선택한 특정 구현 기술에 관계없이 적용 할 수 있기 때문입니다.

경험을 바탕으로 가장 단순한 공용 인터페이스를 먼저 구현 한 다음 나중에 더 큰 제어 및 깊이를 제공하도록 확장하여 고전적인 YAGNI 원칙을 고수하는 것이 좋습니다. 그러나 유용한 이름을 사용하여 메서드 또는 클래스가 확장되는 이유를주의 깊게 살펴보십시오. 메소드 이름에 "Ex"또는 기타 유사한 접미사를 추가하거나 확장 된 인터페이스 정의에 숫자를 추가 한 적이 없습니다. 기능을 차별화하면 인터페이스 / 메소드 이름이 더 명확 해지며 혼란스럽고 혼동되지 않아야합니다.