11月換了新工作，剛入職就被委以重任，要用四周不到的時間開發乙個專案並上線。專案的功能並不複雜，只是要使用公司內部封裝的框架開發，他們稱之為外掛程式開發，因為以前沒有使用過這種技術，完全不知如何下手，並且也沒有詳細的官方文件，僅有乙份不是很完善的文件，沒辦法，只能硬著頭皮看，看同事開發的外掛程式，看完後，自己照著模仿。
我先是熟悉平台的開發模式，然後將技術難點列舉出來，乙個乙個做測試案例，做技術可行性測試，先把比較難實現的點搞清楚，做個demo，有乙個實時更新的頁面做測試時搞了好久也沒做出案例，部門也沒人做過，沒辦法，時間太趕，先做其他的。
事實證明我的整體思路沒錯，因為前期把技術難點都解決了，在實際開發過程中，除了實時重新整理基本沒遇到過什麼問題，比較順利。
等到把基礎功能都完成後，偶然看別人的外掛程式的時候，突然想起實時重新整理的實現思路，然後就慢慢實現了出來。
專案的難點就是實時重新整理頁面，使用的技術也最為複雜，當初做可行性測試的時候，雖然沒能整個實現出來，但是也實現了一部分，然後在最後的實現中也用到了當初的那些，可以說實時重新整理頁面用到了前期開發中的很多技術，所以說，遇到較難實現的技術點，可以先做其他的，也許在做其他的過程中就找到了實現方法，就算沒找到，也會收穫一些可能在後期會用到的技術。
總結：在專案著手開發前，應先進行技術可行性測試，把技術難點都走通，這樣開發進度才可以把控，不然萬一遇到某個難點，幾天搞不出來，就會影響專案的開發進度，把技術難點走通後可以做到心中有譜，不然，真的不知道某個點上會卡多久。
遇到較難解決的問題，可以先暫時放下，去解決其他問題，在解決其他問題的過程中可能就找到解決這個難點的方法了，因為專案的功能模組不是孤立的，乙個複雜問題也不是孤立的，解決了基礎問題，其他難點可能就會更容易解決一些。
專案上線後的專案總結
某公司oa 專案上線後的自我總結 專案中的不足 1 沒有再進一步明確合同簽訂時的合同範圍，例如合同中說明了有 30個審批流程，結果做到了 36個。2 沒有嚴格的簽訂專案章程和專案範圍說明書 需要進一步強調明確章程和範圍 導致真正需求產生變更時，沒有特別嚴格的依據支撐增加費用。3 工作安排分配不合理，...
execute immediate的使用技巧
使用技巧 1.execute immediate將不會提交乙個dml事務執行，應該顯式提交 假如通過execute immediate處理dml命令，那麼在完成以前需要顯式提交或者作為execute immediate自己的一部分.假如通過execute immediate處理ddl命令,它提交所有...
專案上線前的準備
如果做乙個全新的tob端的一複雜系統，在人員及時間充足的情況下，你會做那些準備工作和安排確保專案準時上線 確認會議人數 確認會議成員 參加需求評審 討論專案的樣式和需求 準備測試用例 準備測試機型 測試多久 安排時間 系統的相容性 規範藉口 測試人員測試前提前熟悉系統的功能 需求 模組等 制定方案準...