Підвищення продуктивності розробників за допомогою платформи ArcGIS?

Ми невелика команда розробників .NET. Ми маємо достатньо досвіду роботи з ГІС, і ніхто з нас не новачок у розробці програмного забезпечення / баз даних або системного адміністрування. Ми маємо технічні ступені та багаторічний досвід галузі. Ми відвідували саміти Esri Developer.

Технологія 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. Створіть сценарії встановлення, щоб ви могли відтворити всю систему з нуля, не покладаючись на пам'ять та ручні процеси. Віртуальні машини ідеально підходять для цього.
• Якнайбільше зберігайте чисті .NET та DLL з специфічним кодом ESRI
• Ви можете почати намагатися робити більше "важких підйомів / обробки" в базі даних, наприклад безпосередньо в SQL Server 2008 за допомогою нових класів геометрії та географії

Зв'язок

• Опублікуйте невловимі помилки на GIS SE / StackOverflow, і якщо ви знайдете рішення надсилайте і їх, я знайшов попередні відповіді, які я написав сам під час пошуку тієї самої помилки, про яку я зовсім забув про 6 місяців пізніше ..
• Ведіть нотатки та в ідеалі дозволяйте їх шукати в команді іншими. Я спробував вікі, але відсутність вставлення зображень була достатньою перешкодою, щоб перешкодити мені це робити регулярно. Зараз я використовую Microsoft OneNote, який ідеально підходить для відстеження помилок, URL-адрес, скріншотів. Це може бути також спільним.
• Щоб отримати детальніші технічні підходи, розмістіть їх у блозі. Схоже, набагато менше обміну деталями у світі ESRI, можливо, через страх, що інші скористаються комерційними перевагами, проте гідний блог - це хороша реклама для послуг вашої компанії

Я боюся, що з цього питання не вийде багато хороших відповідей. Але це добре ... продуктивність ESRI продуктів вже давно хвилює мене.

Мій коментар вище - це запит на потребу в продуктах ESRI або ви можете перейти на інший стек технологій. Якщо ви розробляєте продукти ESRI для інтеграції із системами ESRI, щоб звернутися до користувачів ESRI, то вам застряг баз коду ESRI, який був перенесений або перетворений під сучасні розробки та користувацькі платформи.

Хтось із ESRI, будь ласка, виправте мене, якщо я не прав. Більшість бібліотек .NET. ESRI є обгортками для об’єктів COM, з яких є накладні витрати та пропонують неоднозначні в кращому випадку повідомлення про помилки та обробку. Розуміння базових об’єктів COM та залучення їх до вашої кодової бази допоможуть вам краще розробити код відповідно до їх роботи. Цей один факт допомагає мені збільшити продуктивність у моїх сценаріях Python в 10 разів. Те, що колись займало 40 хвилин, зараз займає 4, і трохи налаштуючись, тепер знижується до 2,5 хвилин!

Я чула гарні речі з ArcGIS 10, але не затримуйте дихання.

Якщо ви використовуєте продукти ESRI, щоб забезпечити рішення ГІС у вашому програмному забезпеченні, тоді перейдіть до одного з багатьох проектів з відкритим кодом, який пропонується, і надрукуйте звідти. @capdragon пропонує один такий набір додатків, який забезпечить вам велику кількість гнучкості та масштабованості за допомогою команди підтримки однодумців-розробників у хмарі, яка допоможе вам у цьому.

Розробка з продуктами ESRI - це гра розуму з неоднозначністю, незрозумілими хаками та неузгодженістю основних гравців, якщо ви намагаєтесь зробити щось інноваційне і поза стандартною процедурою операції ESRI.

Я хочу, щоб хтось довів мене неправильно!

На мій досвід роботи з ESRI, чим далі ви можете піти від ArcObjects, тим більше шансів на успіх. На практиці це означає, що якщо ви можете використовувати новіші API REST, щоб робити те, що ви робите, ви завжди повинні отримувати доступ до ArcGIS таким чином.

Вони, схоже, навчилися чомусь із загальної невдачі, якою став веб-ADF в Java / .net, а API REST значно спрощені та мають порівняно чудовий досвід роботи просто без великої суєти. Найпростіший спосіб отримати доступ до API REST - це якщо ви працюєте в Javascript / Flex / Silverlight, оскільки ESRI надає бібліотеки для тих, хто досить гарний, але це просто стандартний інтерфейс REST, і ви можете поговорити з ним майже з усім.

Є речі, які ви не можете зробити так, але я не можу наголосити достатньо, наскільки приємніше працювати з тоді майже будь-чим іншим у стеці ESRI. Коли вам доведеться працювати з ArcObjects (або з ArnetObjects, оброблений .net), все, що ви дійсно можете зробити, - це створити надзвичайно гарну документацію у своєму коді та молитися, щоб вони не зламали речі в наступному патчі (що, мабуть, буде, знаючи їх ).

Будьте в курсі технічного обслуговування. Єдине, що більш засмучує, ніж намагатися з'ясувати проблему з кодом, - це намагатися вирішити її без допомоги людей, які написали код. І ви не отримаєте жодної допомоги від ESRI, якщо у вас не буде укладеної з ними угоди про технічне обслуговування. (Ви можете отримати допомогу на цьому веб-сайті або на форумах ESRI, але це далеко не розмова з ними безпосередньо.)

Будьте в курсі службових пакетів та патчів. Ви не гарантовані , не мають ні одного проблем , якщо ви робите, але ви можете сміливо відповісти: «Так,» відповідаючи на питання підтримки , якщо у вас є остання версія / встановлені оновлення.

Додавайте свої обхідні шляхи громаді (блоги, питання тут тощо). Якщо б достатньо людей це зробило, я думаю, що відбудуться дві речі: один, більше розробників знає про проблеми і матиме шанс боротися з ними швидше, а два - проблеми вирішаться швидше ESRI (нічого подібного до збільшення) скляна, щоб мурахи рухалися, є?).

Я також розробник ESRI, який щодня бореться з цим продуктом. У мене немає підтримки з технічного обслуговування, тому я не отримую багато відгуків від розробників.

Це насправді дуже дратується, коли щось "просто не працює" (на відміну від IJW - це просто працює), незалежно від того, наскільки ви намагаєтеся.

Що я намагаюсь виграти бій:

• Задайте питання (багато)
• Прочитайте посилання SDK на ArcObjects (багато - знову і знову)
• Експериментуйте з різними налаштуваннями

Найкоротший шлях до результату - це запитати когось, у кого вже була така ж проблема, тож, якщо хтось потрапив у цю проблему і знайшов виправлення, він, швидше за все, вам скаже.

Документація хороша, але бракує опису основних елементів та важливих деталей - тому поверніться до 1.

Експериментація також працює. Створіть консольну програму та випробовуйте її. Рамки тестування блоків можуть допомогти вам зробити все, що знаходиться в IDE, але протестувати різні сценарії.

Найбільш гнучка або дивна бібліотеки ESRI - це база даних Geodatabase і може давати химерні результати, залежно від умов, тому спробуйте її засвоїти.

Спробуйте скористатися PostGIS> GeoServer> OpenLayers. Подивіться, як це працює для вашої команди.