－理論再次印證－
一開始規範好的開發流程，變成習慣後，很難再改變，尤其委外，欠缺面對面溝通．
藉由這次的經驗，也得知自己的Framework有哪些不足之處，因為沒親自面對案子．
但也發現開發者深受前一階段的影響，一個轉接，又變回前一段Framework的寫法，
就想到一個笑話，老師要學生用英文寫作，有個學生就這麼寫：
Student: Can you speak Chinese?
Teacher: Yes, I can.
Student: 那我們就說中文.
一開始規範好的開發流程，變成習慣後，很難再改變，尤其委外，欠缺面對面溝通．
藉由這次的經驗，也得知自己的Framework有哪些不足之處，因為沒親自面對案子．
但也發現開發者深受前一階段的影響，一個轉接，又變回前一段Framework的寫法，
就想到一個笑話，老師要學生用英文寫作，有個學生就這麼寫：
Student: Can you speak Chinese?
Teacher: Yes, I can.
Student: 那我們就說中文.
新舊Framework沒有好與不好，在中途接手專案，藉由舊的Framework的思維了解需求
進而修改程式，遠比新Framework快．相對的新的Framework也用於新起的專案實施，
則無此問題．再想一想新的Framework終究也會變舊．也會牴觸更新的Framework．
所在意的，maintain，Debug，Trace是否會更為吃力．
進而修改程式，遠比新Framework快．相對的新的Framework也用於新起的專案實施，
則無此問題．再想一想新的Framework終究也會變舊．也會牴觸更新的Framework．
所在意的，maintain，Debug，Trace是否會更為吃力．
全站熱搜
留言列表
