Simple

遇到一個神奇的問題，Javascript在client端產出的值正確(從F12開發者工具看JS跟HTML都正常)，結果丟回server端hiddenfield的值卻沒有傳回來。 「因為innerText是IE 8之前IE專用屬性」 參考資料：https://blog.kkbruce.net/2013/10/js-dom-edit-text-node-select-innerText-or-textContent.html 在做web應用系統的過程，常常會遇到這種類似的問題，也就是相容性的問題。 在早些日子瀏覽器開始百家爭鳴的時候，這種情況更難處理，Chrome、IE、Firefox、Safari，對於HTML格式的支援都不同，造成開發上常常要測試在不同瀏覽器上是否都可以正常使用。 現在有W3C制定一個標準的規範，但各家瀏覽器有沒有全部照著規範就不一定了；所以只是有改善這樣的情況，即使整個網站都是用標準的HTML語法，在各個瀏覽器顯示上還是有所差異。 要解決瀏覽器相容性的方法有滿多的，還沒有深入研究，就先點到為止了。

最近遇到一個需求是需要DB新增欄位 思考後發現有兩種做法 1. Alter Table ... ADD Column 2. create&drop重新建一個新的table：複製舊的資料表格式，並加入新的欄位，再將舊資料表的資料SELECT INTO至新的資料表，最後重新命名為原本的資料表名稱。 作法1的速度非常快，但是在SQL Server中，ALTER ADD的欄位是無法指定排序的，因此新加入的欄位一定會排在最後，我是認為在觀看上有點不便與醜陋。 由於兩種做法都可行，因此問了資深前輩，trade off的考量點應該要有哪些，得到一些原本沒想到的觀點，順便整理記錄一下。 1. 系統是否已經上線 已經上線的系統，如果採用方法2，風險會比較高，因為轉換資料的過程中會lock住資料，萬一資料量大的時候，需要的時間就很長，萬一有其他使用者需要使用，可能會導致連線逾時。 且轉換的過程中，萬一中途有些資料失敗了，會不知道斷在哪裡，造成資料的不一致；如果採用transcation，則會lock更多資料。 2. 造成的影響最小化 在擴充功能的時候，優先考量的一定是有沒有side effect，如果造成side effect會讓系統品質變得更難維護。而方法1跟2，基本上都不太會影響原本系統邏輯（如果當初寫在系統中的使用語法都有明確指定欄位，沒有使用select * from table的寫法），因此在變動所產生的影響最小化考量，1跟2是都可以採用的。 3. 資源耗用量 MS SQL server有提供的圖形化介面操作，可以移動欄位的順序，看起來非常的方便。但如果我們再進階一點去使用「產生指令碼」的功能，會發現 系統做的事情底層還是select into綁上交易的作法 ，只是沒讓我們看到而已，因此資料量愈大（上千萬筆），採用方法2所耗用的資源就愈多。 最終還是選擇的方法1的做法，因為影響最小，且系統已經上線使用。

紀錄一些關於測試的重要觀念。 1. 不要小看也不要忽略測試的工作，這是維持系統品質重要的一關。 2. 不要只看程式是否做了它該做的事，更要看看程式是否做了它不該做的事 （不要基於程式沒有錯誤的假設來做測試） 3. 不要丟棄這個程式使用過的測試個案 （日後要重測很方便，且有文件可以查是很重要的事情。 尤其是流動率高的時候 ） 4. 每個測試個案都必須定義所預期的輸出或結果 5. 設計測試個案時， 不合理、不被預期的輸入狀況 ，與合理、被預期的輸入狀況同樣重要 6. 修正程式錯誤的成本， 每經過一個軟體開發階段就會增加10倍 這點感觸非常深刻。 實務上未必有這麼完整的開發流程，常常只有開發者自己兼測試者，而沒有後續的測試團隊，等到產品上線後直接由使用者端回報bug。 系統為了趕著上線，功能做出來沒有時間去做詳細的測試，只能做「假設系統被正常地操作」是沒問題的，就認為沒問題了。 結果到正式上線後，開始有使用者回報錯誤，這時的debug時程會被使用者追殺，甚至會影響整個系統的正常運作，此階段需要付出的成本就非常可怕了。所以系統上線的初期通常也是地獄的開始XD

第一次參與了實務上，一個系統上線的前置階段（使用者教育訓練），第一線體會到使用者的真實反應，覺得有趣，紀錄一下自己的心得。 1.      使用者覺得系統太複雜 系統設計上，有時候要思考的是流程上的改變，而不 是純粹把原本的流程做成電子化 ，這樣不僅沒有增加效率，使用者還需要多學一套新系統的操作，難怪使用者反彈。 （但這部分有時候是各個子單位的流程本來就不一致，所以系統沒辦法提供這麼大的彈性，因此就有部分人會覺得無法支持他們的流程。） 2.      系統上線太趕 這要跟甲方討論，牽扯到的使用者太多的話，事前訓練或是推廣可能要提早或是增加場次，至少讓使用者早點有心理準備，這樣反彈的聲音會比較小。但另一方面不管怎樣都還是會有使用者反彈，就要看上層的執行力了。 3.      教育訓練的方式 以實機操作為主？究竟是要先操作帶一遍流程，還是說明後再 demo ，是個trade off，因為假設聽一兩小時的說明，聽到後來應該都恍神(或睡著)了。 我覺得可以根據使用案例，一邊進行實際操作流程，一邊講解，比靜態的 ppt 畫面截圖有效果。 至於提供影片教學，還是靜態的操作文件教學，一定都會有人反彈；提供影片有人說太長，只需要看某一個功能會找不到；提供靜態操作會說這樣看不懂，有影片 step by step 教學一看就懂，這完全取決於預算跟人力，資源不足的話還是只能擇一吧。 4.      使用者不想學習新的系統 這部分真的就要看導入的高層有沒有強力手段去推廣，或是即使造成反彈也有辦法解決。 E.g. 舊系統會下線，只剩下新系統，使用者不用也不行 … 另一方面，要反省思考是不是系統真的設計不佳，導致使用者操作困難，所以才不想使用。（我覺得設計的最高境界就是：「 第一次操作，不需要看說明就會用。 」 實務上，我們買了家電，也不會去看使用說明書，這東西是當我們不會用的時候，才去 查 ！而不是要完整看完才會用，那東西絕對沒人會買。） 5.      新舊並行？一次導入？分階段導入？ 假設沒有強制性的話，通常大家不會想換系統啦（畢竟要花學習成本，這個是額外的工作量），簡單記錄一下可能的情境。 (a)  如果是新舊並行，可能新系統根本沒什麼人用，等到舊系統要下線的時候，

初學asp.net web form框架，讀到page的 生命週期 ，看到有個階段是「驗證」。 想起之前在寫ajax時，明明很多輸入的檢查都是在client，這樣速度快多了，對於server端也比較省資源吧，不必再吃一次上傳下載的request。 睡前想到的問題是： 「 驗證階段為什麼不寫個javascript，直接在clinet端就做驗證，不要等到postback後才server端驗證，這樣該次postback只驗證了某些欄位輸入失敗這樣？ 是因為會怕javascript在瀏覽器執行的時候，有時候會執行失敗(或是直接關閉瀏覽器執行javascript的功能)，導致錯誤的值會被傳到server，然後把這些值塞到資料庫之類的導致錯誤，這大概是我暫時想到的原因吧，但這樣很吃頻寬還有瀏覽器執行的效能阿。 」 查了一下網路資料，自己試著回答一下這個問題。 這個機制還有個功能就是可以驗證跟資料庫有關的資訊，像是庫存數量等，這些訊息在client並沒有，所以要回server做驗證。(但後來想想，其實自己寫javascript做AJAX也能做到阿，不過asp.net框架內沒有提供寫好的元件這樣搞就是了。) 這當中還牽扯到一個資安的議題： 「 如果對於資料嚴謹度的要求很高，最好不要太相信client端傳來的資料；也就是說，最好都要在server端有個檢查的判斷。 」 ( 特別是那些要寫入資料庫的資料!!!) 另外「使用驗証控制項有個好處，至少可以利用ValidationSummary的訊息視窗統一顯示錯誤訊息，不需要多寫額外的程式碼。」等於是如果用框架提供的東西，就可省很多事，問題是有些是框架做不到的事情，彈性就比較低；自己還是要懂原本的機制，才有辦法修改更多的東西。 asp.net web form框架有提供 驗証控制項 (Vilidator)，有提供client-side 跟 server-side的validation ，這樣才比較合理XD 是我原本太菜，想到的菜鳥問題，人家Microsoft框架其實早就有想到了，並且提供一個簡便的方式。 這些驗證控制項有個EnableClientScript屬性，預設是true，可針對驗証控制項選擇驗証位置是要在client端或是server端。在client驗証可以立即回應驗証成

Asp.net 網頁生命週期 指的是asp.net server 端在接收到 client 端所送出的h ttp request 後，處理的流程。 分成八個階段， 依序 完成。 1. Page request （要求） 接收 client 端發出的 request 物件，決定要重新生成網頁回傳，還是快取裡面有可以直接回傳的網頁資料。 2. Start （開始） a. 準備 request跟response物件的屬性，最後會在rendering階段寫入。 b. 判斷這是第一次造訪的 request ，還是 Postback ，是的話就設定 Page.IsPostBack 這個 屬性。 3. Initialization （初始化） a. 套用佈景主題 b. 載入web 伺服器控制項( WebControls )；如果是這次是Postback，這階段還沒有把ViewState恢復。 （ ViewState 是asp.net的機制，會把控制項選好的內容用<input type="hidden" ....>偷偷記錄下來，傳遞的時候才不會造成每次控制項都清空。 因為http是無狀態協定，每一個request都是獨立的，不會紀錄client跟server端的資料，就不會知道上一次使用者選了什麼；用ViewState記錄下來的話，server這邊就會把控制項的值都設定成ViewState的狀態，再傳回client端，client端看起來就會像是沒有改變了，缺點是一來一回要傳的資料量就比較大，效能會比較差。） 4. Load （載入） a. 如果是Postback，就恢復Webcontrol控制項的ViewState。 （也就是把之前選取的狀態都設定好，傳回去client端才不會變成初始化的狀態，造成使用者需要重選。） 5. Validation （驗證） a. 呼叫每個Webcontrol控制項的Validate()方法，執行各自的驗證。並設定每個控制項和整個網頁的IsValid屬性。 6. Event Handling （事件處理） a.  處理 Postback 的事件 7. Rendering （呈現） a. 把ViewState跟Webcontrol控