I'll be back!

一個強壯的prpc系統(tǒng)很關(guān)鍵的一點就是看代碼的重用性，為了滿足特定需求且僅滿足該需求的功能模塊是脆弱的，必須在設(shè)計之初就必須充分考慮到需求的變更，最大幅度擴大該模塊的運用場景。
以創(chuàng)建組織地點下拉選擇框(選擇地域信息)為例子，脆弱的做法就是直接在property內(nèi)對下拉選擇框的值進行配置(Name, Value)。而一個好的做法就是創(chuàng)建一套對應(yīng)的field value。 當然這個例子并不適用于那些特定模塊的下拉選擇框，
再舉一個例子，我們在制作一個篩選用戶的html property的時候，好的設(shè)計應(yīng)該把篩選用戶的條件作為parameter設(shè)在里面，例如OrgFilter, DivFilter,UntFilter,LocFilter等等。
如果項目在提交到客戶之前就本項進行"Health"檢測的話，可以讓BA在原來的BRD基礎(chǔ)上進行一定幅度合理的變更，然后有開發(fā)人員評估系統(tǒng)變更所需要的開發(fā)時間，由此來判斷該系統(tǒng)代碼是否擁有足夠的靈活性(當然這個評判標準是一個經(jīng)驗值)。

我覺得題目開的很宏大，支持一下！！
但真正要提出一個標準來，是有相當?shù)慕?jīng)驗來作基礎(chǔ)，并且要經(jīng)過很多驗證。我們可以從小的地方開始作：分享一些怎么作可以使prpc application 更加健康的case。
這樣一來可以積累很多人的經(jīng)驗，二來可以使我們分享這些經(jīng)驗當工作中遇到問題時提供借鑒。

這個題目很好,不過就算是Pega公司本身也很難給一個滿意的答復(fù)。
個人感覺，PRPC的開發(fā)不適合規(guī)模型的外包開發(fā)，只適合緊湊的精英型開發(fā)。而所謂開發(fā)，其實大部分的工作就是在分析和設(shè)計，而實際的代碼工作量不會多到哪里去；相反一個系統(tǒng)如果沒有很好的規(guī)劃和設(shè)計而匆忙開發(fā)，那么最終的結(jié)果將是很鬧心的。

如果長期規(guī)?；约暗退刭|(zhì)的開發(fā)人員維持低效的開發(fā)，有可能最終產(chǎn)生大量的rule，這些rule的特點往往是高度冗余，通用性差，難以統(tǒng)一維護。
PRPC目前的一個很大問題就是對十萬數(shù)量級以上的rule management很差。到這種程度上ruleset這個東西就顯得很力不從心了。
所以我同意樓上的觀點。