Rework & Debug? Ready to Die?
評：高層最愛說的話就是「客戶意見至上」需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
評：大多數人都努力朝後者走，所以現在的軟體都比肥比笨重，看看從6MB成長到600MB的Nero...我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare
評：笨蛋！不這樣做哪有機會出差出國玩！(毆)程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！
評：理論上最需要reversion的應該是使用手冊，卻往往都是spec draft的version number最大..要殺一個程式設計師不需要刀，改三次規格就好
評：客戶就是最好的beta tester！開發沒有終點。只有釋出(release)。
評：最近深深感到寫FW的人被這條婊很大，HW總是會delay，SW可先寫UI可先設計，FW卻是要等兩邊都ready才算正式開工..無論規格多晚才能確定，結案期限永遠不會變。這是所謂的「期限守恆定理」。
評：bug就是規格的一部分！你看看誰用windows會期待他不附贈bug？bug過了一晚可能就變成規格了。
評：肝的硬化速度也是一樣。品質的劣化程度依規格改變的次數與規模而定。
評：台灣的歪曲責任制萬歲～準時離開公司，工作會變多。
評：其實..在趕論文或proposal的研究生也是這樣的，我們的教育體制其實很早就開始訓練大家了XD地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
評：同上，研究生時就早已習慣迷航的船長(指導教授)了。程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
評：正所謂出來寫遲早都是要用on site來還的..所謂交案期限，是指開發現場從公司換到客戶那裡的日子。
評：所以通常Q愈不懂電腦愈好，就跟當教授的通常都愛用一根手指打字一樣。不懂電腦的操作者是發現bug的天才。而且無法重現。
評：業務一二三－一台好車、兩套西裝、三寸不爛之舌程式設計師需要的技能，包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。
評：正所謂打不倒敵人就與之同化，改不掉bug就美化一下寫在規格上就好了，真實案例太多了，寫論文也是。不會動的bug就只是普通的bug。（會動的bug則能視為規格）
評：再說一次..去你●的責任制～如果可以改行的話，想找個準時下班不叫「逃跑」的工作。
評：其實未必，被data sheet甚至standard耍的人也是有的XD自己看規格書。不能跑的是規格。
評：意思就是其實一個人當3~5個人用是非常正常的。一天常常指的是3人日，一個月常常是指4.5人月喔。
評：進資訊系的學生有一半曾天真認為自己可以寫出比魔獸世界更偉大的遊戲，另一半則認為只要打魔獸世界就能畢業。小學生時第一次看到電腦 國中時第一次學會怎麼用
高中與大學學會程式語言 出社會後才發現自己走錯路
評：所以我一向認為軟工無用，真的照作還得了？漂亮的設計三天或許就膩了 骯髒的設計三天就習慣了
tag :
