最近，odps從簡單模型更新成開發/生成模式。差異比較大，特別對開發完成後的自測造成很大影響。將需要注意的點總結如下。
以下以btime_recommand專案為例，對應的預設開始模式專案為btime_recommand_dev.
（1）開發模式下，預設讀取和生成的都是開發環境下的表
因此，測試的時候，如果要讀正式的表，需要加上字首：btime_recommand。
正式合入**的時候，最好去掉這些字首。
（2）表的新建要保證在使用前建
發現，之前很多表是在臨時查詢裡建的。以後，這種方式不可取。開發模式下，預設表的新建在開發模式下的，正式沒有對應的表。
（3）函式呼叫
（4）本地udf函式測試
開發模式的表預設在recommand_dev專案中，因此工程需要加上recommand_dev專案才能同步到對應的表。
（5）新舊版工作流的問題
舊版工作流，如果當天流程有改動，第二天才能生效。**是立即生效。
新版工作流，流程、**都是當天生效。因此，最好將現在舊版的工作流都更新成新版，或者提前準備好舊版工作流改動帶來問題的解決方法。
（6）自測成功後，**提交注意點：
a.gitlab提交udf**
b.odps提交最新**編譯的package，並發布
c.odps檢視確認每個新增函式，並發布
d.odps提交sql**，模組屬性修改，並發布
Android APP開發自測點
功能完成後，自測時的檢查點 1.思考某些情況下，某個變數是否會造成空指標問題 2.把手機橫屏，檢查布局是否有bug 3.在不同解析度的機型上，檢查布局是否有bug 4.切換到英文等外文本型下，檢查外文是否能完整顯示 5.從低版本公升級上來，會不會有問題，比如可能會出現資料庫不相容的問題 6.按下ho...
開發自測模式實踐
背景 長期以來業務線測試有這種困擾 業務線傳統的專案流程把開發 測試兩個階段分得比較明顯，導致開發趕時間寫 提測階段測出一些低階bug 重新返工不僅測試時間延長，也導致開發 測試同學都累。在天彤的支援下，本人今年3月份來到c2b市場團隊輪崗開發，實踐了開發自測的專案模式。這是乙個新產品團隊，新模式比...
開發注意點
1.不要在mybatis的xml檔案裡map使用巢狀查詢，如 property inte ceinfo column inte ce code select selectbyinte cecode 可能會導致很嚴重的效能問題 2.定義固定的返回格式類 如 public class effect 3....