在使用模板引擎時，遇到了乙個糾結的問題，現需要分析一下。
在介面完全一樣的情況下，所需的變數，也就是put到標記語言中的內容不一樣 時，是選擇重寫介面，還是選擇在底層進行邏輯區分？
場景假設 ：有27個介面，平均每個介面需要裝載4個小介面，也就是4個 panel。有8種panel。
當然對於愛好偏向介面的我來說， 重寫介面是最好、最快速的選擇。可是從對產品負責的方面考慮，讓我們來假設下不同選擇的結果！
首先介面不需要重寫，可以節約介面十分之三 的工作量（重寫介面只需貼上複製，修改模板語言標記）。在此假設108（=27*4）個頁面，美工，css，瀏覽器差異為2個人日，108介面工作量為8 個人日，去處重複的100（=(108/8-1)*8）個頁面，也就是只需3個人日，節約了7個人日。
介面不重寫，唯一能確定put的內容到底該 是什麼值時需要根據你開啟頁面的瞬間，通過servlet傳遞的引數來進行區別。那麼在底層，就需要很多的if...else...。在此有平均有4種類 型，每種型別有27個判別情況。也就是需要108次判別。即使你使用了設計模式，**看起來可能簡介，易於重構，可是到底層，還是一樣的 if...else...。效能上面肯定存在一定的影響。這樣姑且不說，節約的7個人日中至少有5個人日又被if...else..折磨殆盡，工作量上基 本是一樣的。因此可見，重寫模板是最好的選擇。
產生此問題的原因歸結於整個系統的key不夠靈活抽象，如果key根據4種 型別，27個情況，按照組合的方式進行定義，那麼杯具就不會產生，同樣的模板，只需要4次判別即可，也就是節約了重寫模板的7個人日和底層 if...else...的5個人日，加起來共節約了11個人日（哇咔咔）。可惜木已成舟，我們需要的不是去責備和哀怨，只能尋找最適合的辦法去解決它。
如何面對工作中的困難和糾結
先寫一段話 大發展，小困難 小發展，大困難 不發展，最困難！我當年畢業之後的第乙份工作是到了一家汽車製造企業。這家企業歷史悠久，最初是央企，在全國各地有很多公司和機構。不幸的是，90年代末期由於市場變化 管理混亂導致嚴重虧損，資不抵債，不得已在2000年破產重組，一分好幾，全部下放到地方國資委管轄。...
工作中的介面測試同類bug總結
工作中測試介面出現的常見bug的簡單總結 1 對於傳入引數的校驗，以及新增時對引數需要校驗時，那麼如果該引數可編輯，編輯介面也需要對引數進行校驗。2 新增介面如果要求傳入引數非空，需要校驗，為空時給出提示資訊，編輯介面一樣。3 有時突然出現介面不通，可能是資料庫欄位有改動 4 全域性變數需要放在he...
工作中遇到的
今天，在工作中，發現乙個問題，簡要描述 用perl寫的cgi程式獲取表單元素的值，用獲得的值拼接sql語句，假如有個表單元素這樣寫 其中 type id 由perl寫成的同乙個cgi程式執行時寫入。另設乙個表單元素，供使用者輸入值使用 在cgi中獲得表單元素的值 my type id cgi par...