[size=large] 如本文的title說的那樣，在我們所做過的專案中，對話方塊的出現是再稀鬆平常不過的乙個[img]東西了。沒有過多複雜的邏輯，沒有太絢麗的ui，沒有冗雜的業務邏輯，但幸運的是，這些東西有幸能成為出現在我們客戶日常使用過程中最多的乙個元件。
我們是不是應該慶幸，我們花幾分鐘就可以開發出乙個經常呈現在客戶使用中的模組呢？或許是的，但其實並不是那麼的簡單。這篇文章我舉出很明顯的例子來做對比，多餘不說直接上圖（附件）。這個雲應用是我1年多前在a公司給team member做training的時候用的，我就不介紹這個工具是什麼了，有廣告嫌疑，只說這是乙個作圖軟體，類似viso. 我在刪除乙個resource的時候不經意的發現了這個對話方塊。right is yes, left is no. 大家可能會問，這又如何？當然對於我們的程式設計師來講這個並不難實現，設定對我這樣很少寫**的qa來講，可能也不會花太長的時間，可這樣乙個對話方塊讓我有了一些沉思。這個軟體是國外研發的，當然，我想作為開發者和需求分析者，會以自身經驗和定向思維加在這個軟體中，從而才有這樣的對話方塊，這代表了什麼？這代表的是一種文化，一種使用習慣。大多數西方國家的使用習慣就是右邊yes左邊no。看看我們做的專案，雖然做的都是歐美專案，但所有的對話方塊無疑都是左邊yes右邊no，是，這不能怎樣，而且不會影響我們的交付，這樣的對話方塊誰都做的出來，我們拿什麼去和其他競標對手競爭？可能很多人會想，合同在手，專案實施已成定局，但是更有很多專案是這樣的，客戶拿出一些需求，我們的ba分析出story，開發人員快速實現乙個原型，屁顛屁顛的去給客戶做demo，而同時，我們的競爭對手也在做。當這樣的乙個demo出去的時候，客戶看到的不是深層的業務邏輯和你的雄厚的開發實力，首先看到的是呈現在我們眼中的最直觀的乙個原型。
說到這裡我還是不得不套用一句不知道是誰說的話---細節決定成敗。當所有人都不會做的時候，你要會做，當所有人會做的時候，你要做到最好，這樣的dialog實現起來和之前的並無難度上的提公升，可是會大大影響我們客戶的滿意度，這只是乙個小的環節，在我們日常的工作中，還有更多的環節需要我們用我們的專業知識和對客戶的背景文化了解來使我們做到卓越。我敢負責任的說，沒有哪個ba和qa會去和客戶clarify這樣的對話方塊，一則我們會有思維定勢，二則，雖然軟體過程中鼓勵溝通，但並不是指一些我們本應用專業知識和經驗去解決的東西不去解決，而去提問客戶或者stakeholder。我們再做諮詢或者說外包的時候，我們代表是公司的形象和技術實力，我們就要在專業技能和卓越程度上更高一籌。
別再忽略身邊那些像dialog一樣的事情，一些小事可能會改變格局，敏感起來吧，只有你用心，周圍的事物才會給予反饋，至於你們信不信，反正我是信了。[/size]
關於JS那些容易被你忽略的那些點（3）
不知道你前面的理解的怎麼樣了。現在你來判斷下下面 的輸出 for var i 0 i 5 i 很眼熟對不對，沒錯，稍微改下就能完成想要實現的功能了 for var i 0 i 5 i i 你自己再控制台可以試一試，看是不是實現功能了 那麼再來判斷下下面這段 var arr1 john split j...
技術人員，請注意那些被你忽略的重要事情
對於很多做技術的朋友，包括我自己在內，一直以為 只要技術牛，就可以活的非常滋潤 只要技術牛，就可以拿優厚的待遇 只要技術牛，就可以拉著幾個小夥伴搞自己的 事業 只要技術牛，就可以馳騁it江湖。很多的事情，或許是我們預期太高，期望太美好，或者就是我們自己一廂情願的 意淫 因為我們總是 這山望著那山好，...
技術人員，請注意那些被你忽略的重要事情
對於很多做技術的朋友，包括我自己在內，一直以為 只要技術牛，就可以活的非常滋潤 只要技術牛，就可以拿優厚的待遇 只要技術牛，就可以拉著幾個小夥伴搞自己的 事業 只要技術牛，就可以馳騁it江湖。很多的事情，或許是我們預期太高，期望太美好，或者就是我們自己一廂情願的 意淫 因為我們總是 這山望著那山好，...