想寫這個日記，算是個記錄，而且這內容，也會比手寫的記錄來得多。
「爭論，總該得到些什麼」
這是我這一次省思得到的項目。
今日下午，又與David討論程式開發的項目。
他原本是要問我SearchModel，以及時間區間類的查詢該怎麼做？
這部份，的確目前也只能用字串去組它的Filter資訊，再填值進去。
在說明的同時，我看到他在Function外都有包了Try Catch。
而這，也開始今日的程式爭論主題。
這樣的爭論，對我來說不算是個壞事，
只是，我「表達」時，比較像是在「吵架」而已~~
在這之中，聽到這類的話，因而有了個想法：
「Howard，你沒聽懂我要表達的意思，你都只是在說服我而已」
？？？，怎麼讓他有這樣的印象？？
我的記憶力是較短沒錯，但不至於沒有理解你的意思才是。
是在聽了你的意思之後，直接表達我所「不認同」的地方。
而這「不認同」的地方，當然就是我「所認為」該怎樣的情況。
但，別人「聽」起來，認為你就是在「說服」他。
嗯~~~的確，彼此討論之下，要找到「第三種選擇」，是一種藝術。
=========================
若大家是「就事」來討論，相信是「理越辯越明」。
所以，某種狀況下，我沒辦法在「不服理」的狀況下乖乖做事。
而要講到我「懂」，的確是要花「時間成本」。
但，這會是值得的。
==========================
今日這樣，雖花了兩個小時，都在「爭論」「為什麼我加Try Catch不行」這件事。
雖"效率"不高，但這也是彼此交流、了解彼此的情況。
而這前題是：我們就事來論事。
不要牽扯到個人的刻版印象。
==========================
某種程度，自已會因為這樣的「爭論」，而得到不同的角度來思考事情。
昨日討論的是「CUF」，今日討論的主題算是「程式規範之粗細程度」
後來，我在上完廁所想到，若David他自已遇到這樣的事件，他會怎麼處理？？
就這樣問他：
「我跟你的角色對調，如果你遇到一個，跟他講了之後，他還是堅持要用他的方法做，
再怎麼說明，他還是不會想照你所說的方式處理，那你該怎麼辦？？」
他說，他會盡「告知」的責任，跟他說這樣做會不好，
說明「未來」會面對的事情。
若他仍這樣做，就要負起這後果。
而這部份，可以盡早讓它「面對這後果」。
比如，這樣寫會造成效能問題，就在壓測時間，把這項當成壓測項目。
讓這「後果」浮出來，
但他也再反問，假若壓測出來，「效能」還是可以過關呢？？那若這樣，為什麼當初一定要照你的方式寫？？？
我認為，這樣壓測雖可過關，但若用我所說的寫法，效能會更好！
而且在這時間點當下，你怎知你這樣的寫法效能會過關呢？？？
所以，若我明知你這樣寫效能一定很不好，那我一定當下會講到讓你跟著我的意思做。
因為，明知會錯的項目，為何要等到「後果」出來時，再來調整呢？
============================================
另外個心得就是，當我們大家都是「做事」的，就要盡量把「人」的成份降低。
就是，你不可以因為我這人固執，就認為我所講的事情都是不對的。
這就是「對人不對事」，我不希望自已是這樣。
=============================================
因外得到的東西，就是Framework在使用上，針對「SearchModel」及時間區間 查詢這事
遇到的機率實在是太大了，
但目前卻沒有「好」的解法~~~
該思考這架構「怎麼做了」。
(THE END)
「爭論，總該得到些什麼」
這是我這一次省思得到的項目。
今日下午，又與David討論程式開發的項目。
他原本是要問我SearchModel，以及時間區間類的查詢該怎麼做？
這部份，的確目前也只能用字串去組它的Filter資訊，再填值進去。
在說明的同時，我看到他在Function外都有包了Try Catch。
而這，也開始今日的程式爭論主題。
這樣的爭論，對我來說不算是個壞事，
只是，我「表達」時，比較像是在「吵架」而已~~
在這之中，聽到這類的話，因而有了個想法：
「Howard，你沒聽懂我要表達的意思，你都只是在說服我而已」
？？？，怎麼讓他有這樣的印象？？
我的記憶力是較短沒錯，但不至於沒有理解你的意思才是。
是在聽了你的意思之後，直接表達我所「不認同」的地方。
而這「不認同」的地方，當然就是我「所認為」該怎樣的情況。
但，別人「聽」起來，認為你就是在「說服」他。
嗯~~~的確，彼此討論之下，要找到「第三種選擇」，是一種藝術。
=========================
若大家是「就事」來討論，相信是「理越辯越明」。
所以，某種狀況下，我沒辦法在「不服理」的狀況下乖乖做事。
而要講到我「懂」，的確是要花「時間成本」。
但，這會是值得的。
==========================
今日這樣，雖花了兩個小時，都在「爭論」「為什麼我加Try Catch不行」這件事。
雖"效率"不高，但這也是彼此交流、了解彼此的情況。
而這前題是：我們就事來論事。
不要牽扯到個人的刻版印象。
==========================
某種程度，自已會因為這樣的「爭論」，而得到不同的角度來思考事情。
昨日討論的是「CUF」，今日討論的主題算是「程式規範之粗細程度」
後來，我在上完廁所想到，若David他自已遇到這樣的事件，他會怎麼處理？？
就這樣問他：
「我跟你的角色對調，如果你遇到一個，跟他講了之後，他還是堅持要用他的方法做，
再怎麼說明，他還是不會想照你所說的方式處理，那你該怎麼辦？？」
他說，他會盡「告知」的責任，跟他說這樣做會不好，
說明「未來」會面對的事情。
若他仍這樣做，就要負起這後果。
而這部份，可以盡早讓它「面對這後果」。
比如，這樣寫會造成效能問題，就在壓測時間，把這項當成壓測項目。
讓這「後果」浮出來，
但他也再反問，假若壓測出來，「效能」還是可以過關呢？？那若這樣，為什麼當初一定要照你的方式寫？？？
我認為，這樣壓測雖可過關，但若用我所說的寫法，效能會更好！
而且在這時間點當下，你怎知你這樣的寫法效能會過關呢？？？
所以，若我明知你這樣寫效能一定很不好，那我一定當下會講到讓你跟著我的意思做。
因為，明知會錯的項目，為何要等到「後果」出來時，再來調整呢？
============================================
另外個心得就是，當我們大家都是「做事」的，就要盡量把「人」的成份降低。
就是，你不可以因為我這人固執，就認為我所講的事情都是不對的。
這就是「對人不對事」，我不希望自已是這樣。
=============================================
因外得到的東西，就是Framework在使用上，針對「SearchModel」及時間區間 查詢這事
遇到的機率實在是太大了，
但目前卻沒有「好」的解法~~~
該思考這架構「怎麼做了」。
(THE END)
0 意見 :
張貼留言