ArcGIS 플랫폼으로 개발자 생산성이 향상됩니까?

우리는 소규모 .NET 개발자 팀입니다. 우리는 충분한 GIS 경험이 있으며 소프트웨어 / 데이터베이스 개발 또는 시스템 관리에 익숙하지 않은 사람은 없습니다. 우리는 기술 학위와 수년간의 업계 경험이 있습니다. Esri 개발자 서밋에 참석했습니다.

Esri의 기술 (주로 ArcGIS Server, ArcSDE 및 ArcObjects)은 우리가 개발하는 모든 소프트웨어에서 작지만 필요한 역할을합니다. 기술 스택에서 ESRI의 소수 상태에도 불구하고, 우리는 어려운 버그를 해결하고, 임시 해결책을 만들고, 모호한 오류 메시지를 해독하고, 성능 문제를 추적하고, 프로세스를 재활용하는 데 많은 시간을 소비합니다.

일반적으로 우리의 문제는 실제 버그, 잘못된 예외 처리, 설계 / 건축 결정 제한, 문서 부족, 불안정성 또는 그 조합으로 인해 발생합니다. (여기서 ESRI 스택에 대해 말하고 있습니다.)

프로젝트 관리자의 관점에서 저는 팀 생산성에 대해 매우 우려하고 있습니다. 시간이 많이 걸립니다. 우리는 ESRI 스택의 모든 특유성을 배울 시간이 없지만 여전히 일을해야합니다. (그것과 함께 살 수없고 그것 없이는 살 수 없습니다.)

ESRI를 통해 개발자 생산성을 향상시키기위한 실용적인 제안은 무엇입니까?

대체 기술 스택에 대한 제안을 찾고 있지 않습니다.

성능을 위해서는 이 기사 에서 언급 한 것처럼 C ++ 프록시 코드를 ArcObjects에 작성하는 것이 가장 좋은 해결책 인 것 같습니다 . ESRI는 COM interop을 많이 사용하지 않으면 6 배의 성능 향상을 제공합니다.

ESRI는 또한 암호화 된 COM 오류 메시지 처리에 대한 제안 / 모범 사례 와 HRESULT 오류 코드에 대한 설명을 제공 합니다.

이러한 많은 구성 문제 외에도 Windows 관련 문제가 있으므로 Windows 서버 관리, IIS, Windows 서비스, Windows 이벤트 로그, 레지스트리, 등록 된 COM 개체 등에 대한 모든 지식이 도움이됩니다.

이 기사 외에도 유용한 일반적인 개발 방법이 많이 있습니다.

소프트웨어 개발 접근법

• 지리적 데이터 (WMS, WFS, ArcGIS REST 서비스) 모두에 대해 가능한 한 웹 서비스를 사용하십시오. 이렇게 분리하면 디버깅 및 유지 관리가 쉬워집니다.
• 가능한 경우 Windows 설치를 정리하기 위해 시스템을 설치하십시오. 메모리 및 수동 프로세스에 의존하지 않고 전체 시스템을 처음부터 다시 작성할 수 있도록 설치 스크립트를 작성하십시오. 가상 머신은 이에 적합합니다.
• ESRI 특정 코드를 사용하여 순수한 .NET 및 DLL을 가능한 한 많이 유지하십시오.
• 새로운 지오메트리 및 지리 클래스를 사용하여 SQL Server 2008에서 직접 데이터베이스에서 더 "무거운 리프팅 / 처리"를 시도 할 수 있습니다.

통신

• 찾기 어려운 버그를 GIS SE / StackOverflow에 게시하고 해결책을 게시하면 6 개월 후에 완전히 잊어 버린 동일한 버그를 찾는 동안 내가 작성한 이전 답변을 찾았습니다.
• 메모를 작성하고 팀의 다른 사용자가 검색 할 수 있도록하는 것이 이상적입니다. 나는 위키를 시도했지만 이미지 붙여 넣기가 부족하여 정기적으로 방해하지 않아도됩니다. 나는 현재 오류, URL, 스크린 샷을 추적하는 데 완벽한 Microsoft OneNote를 사용하고 있습니다. 공유 할 수도 있습니다.
• 보다 자세한 기술 접근 ​​방식은 블로그에 게시하십시오. ESRI 세계에서 다른 사람들이 상업적 이점을 취하는 것에 대한 두려움 때문에 세부 정보를 공유하는 것이 훨씬 적지 만 괜찮은 블로그는 회사 서비스에 대한 좋은 광고입니다.

나는이 질문에서 많은 좋은 답변이 나오지 않을 것을 두려워한다. 그러나 ESRI 제품의 성능은 한동안 내 관심사였습니다.

위의 의견은 ESRI 제품의 필요성을 묻거나 다른 기술 스택으로 마이그레이션 할 수 있습니다. ESRI 시스템과 통합하여 ESRI 사용자에게 어필하기 위해 ESRI 제품으로 개발하는 경우 최신 개발 및 사용자 플랫폼에 맞게 포팅되거나 왜곡 된 ESRI 코드베이스가 붙어 있습니다.

ESRI의 일부는 내가 틀렸다면 수정하십시오. 대부분의 ESRI .NET 라이브러리는 COM 객체에 대한 래퍼이며 액세스하기에 오버 헤드가 있으며 최상의 오류 보고서 및 처리에서 모호합니다. 기본 COM 개체와 코드 기반에 대한 이해를 이해하면 작업에 맞게 코드를 더 잘 설계 할 수 있습니다. 이 사실은 Python 스크립트의 성능을 10 배 향상시키는 데 도움이됩니다. 한 번 40 분이 걸렸던 것은 이제 4 분이 걸리고 약간의 조정으로 이제 2.5 분으로 줄었습니다!

ArcGIS 10으로 좋은 소식을 들었지만 숨을 참지 마십시오.

ESRI 제품을 사용하여 소프트웨어 내에서 GIS 솔루션을 제공하는 경우 제공되는 많은 오픈 소스 프로젝트 중 하나에 연결하여 빌드하십시오. @capdragon은 클라우드에서 같은 생각을 가진 개발자들로 구성된 지원 팀을 통해 많은 유연성과 확장 성을 제공하는 응용 프로그램 세트를 제공합니다.

ESRI 제품을 사용한 개발은 ESRI 표준 운영 절차 이외의 혁신적인 작업을 수행하려는 경우 모호함, 모호한 해킹 및 불일치가있는 마인드 게임입니다.

나는 누군가가 나를 잘못 증명하기를 원한다!

ESRI를 사용한 경험에서 ArcObjects에서 멀어 질수록 성공할 가능성이 높습니다. 실제로, 최신 REST API를 사용하여 수행중인 작업을 수행 할 수있는 경우 항상 ArcGIS에 액세스해야합니다.

Java / .net의 웹 ADF 인 전체 실패에서 무언가를 배운 것으로 보이며 REST API는 훨씬 단순화되었으며 많은 번거 로움없이 작업 할 때 비교적 훌륭한 실적을 가지고 있습니다. REST API에 액세스하는 가장 간단한 방법은 ESRI가 꽤 좋은 라이브러리를 제공하기 때문에 Javascript / Flex / Silverlight에서 작업하는 경우 표준 REST 인터페이스 일 뿐이며 거의 모든 항목과 대화 할 수 있습니다.

그렇게 할 수없는 것들이 있지만 ESRI 스택의 거의 모든 다른 것들과 함께 작동하는 것이 얼마나 좋은지 강조 할 수 없습니다. ArcObjects (또는 .net 래핑 된 ArcObjects)로 작업해야 할 때 실제로 할 수있는 일은 코드에서 매우 훌륭한 문서를 작성하고 다음 패치에서 내용을 깨뜨리지 않기를기도하는 것입니다. ).

지원 유지 보수를 최신 상태로 유지하십시오. 코드 문제를 파악하는 것보다 더 실망스러운 것은 코드를 작성한 사람들의 도움없이 코드를 알아내는 것입니다. ESRI와 유지 관리 계약이 없으면 ESRI로부터 도움을받지 못할 것입니다. (이 사이트 나 ESRI 포럼에서 도움을받을 수도 있지만 직접 대화하는 것은 그리 큰 도움이되지 않습니다.)

서비스 팩 및 패치를 유지하십시오. 당신은 없다 보장하지 않는 더 당신이 경우에 문제를,하지만 당신은 안전하게 최신 버전이있는 경우 지원에 의해 물었을 때 "예"/ 업데이트가 설치, 응답 할 수 있습니다.

해결 방법을 커뮤니티 (블로그, 질문 등)에 제공하십시오. 충분한 사람들이 그렇게한다면 두 가지 일이 일어날 것이라고 생각합니다. 하나, 더 많은 개발자가 문제를 인식하고 더 빨리 해결할 수있는 기회가 있고 두 개는 ESRI에 의해 문제가 더 빨리 해결 될 것입니다. 개미가 움직이게하는 유리가 있습니까?)

또한 매일이 제품과 끊임없이 싸우는 ESRI 개발자입니다. 유지 관리 지원이 없으므로 개발자의 의견이 많지 않습니다.

아무리 노력해도 상관없이 "JJ가 작동하지 않을 때"(IJW와 반대로 작동하는 경우) 정말 실망 스럽습니다.

내가 싸움에서이기려고하는 것 :

• 질문 (많이)
• ArcObjects SDK 참조 읽기 (많은 이상)
• 다른 설정으로 실험

결과에 대한 최단 경로는 이미 같은 문제가있는 사람에게 물어 보는 것입니다. 따라서 누군가 문제를 일으켜 해결을 찾은 경우 가장 가능성이 높습니다.

설명서는 훌륭하지만 핵심 요소 설명과 중요한 세부 정보가 부족하므로 1로 돌아가십시오.

실험도 가능합니다. 콘솔 프로그램을 작성하고 테스트하십시오. 단위 테스팅 프레임 워크는 IDE 내부의 모든 작업을 수행하는 데 도움이되지만 다른 시나리오를 테스트 할 수 있습니다.

가장 버그가 많거나 이상한 ESRI 라이브러리는 Geodatabase이며 조건에 따라 기괴한 결과를 줄 수 있으므로 마스터하십시오.

PostGIS> GeoServer> OpenLayers를 사용해보십시오. 그것이 팀에 어떻게 작동하는지보십시오.