說起軟件設計,不得不頭痛.
曾有朋友說過,設計好麻煩,想來想去沒有結果.
我也曾經經歷過這樣一個困境.
難就難在沒有多少經驗.
因爲你只想需求,再數據庫,再邏輯,再界面.這樣一步一步來的話,確實在實現的時候,覺得自己當時的想法,設計全亂套了.
這個是正常的.
一,是你的技術問題,因爲你想那東西的時候,很少會考慮你的技術問題,但是設計時,也應該不考慮技術問題,因爲一考慮的話,你設計的產品,可能就是自己的暇想,不是別人想要的東西,而由於你的技術問題,或者是頁面效果處理,或者是邏輯較亂,就會造成出來的產品,都是一些基本的增刪查改.我也問過一些老師,他們說,有些學員開始做項目時,想得很好,但到頭來,就只是一些很基礎的增刪查改,這是因爲他們的邏輯越想越亂,又爲了應付項目,不得不放棄原先的想法.
二,界面與需求有出入,這個也很正常,計算機的界面,可以說來來去去都差不多,因爲來來去去都是那樣的控件,就WEB而言,來來去去都是些html表單,所謂的富集控件之類的東西,都是用最基本的div p html表單等拼出來的,雖然可以千變萬化,但是拼出來的東西,總會跳不出一個規則,所以這樣就會與你的需求有出入
三,你的需求分析沒有到位.這個很正常.一談到需求,很多時候就是你有你說,我有我想,根本就不會怎樣互位思考,也很難換位思考.因爲你做慣了技術,想時很自然往技術方向鑽,這個按我以往經驗,應該是搞一個表格,這樣統計出來的.而有家的想法就是,我只需要顯示統計的信息就足夠了.就差一句確認的說話,就很容易存在這樣的差異,所以與別人談話時,如果什麼都不會,你就不用談了,問他拿好基本資料,基本流程,然後就開始着手設計,搞原型開發得了.如果他是老手,那就要什麼都談好,這裏是要這樣顯示,用什麼實現,多點確認,也不要過渡承諾,因爲這樣的人,會坑你的,實現這個很好很好的效果,你答應了,他很高興,如果你完成不了,那後果可想而之,等,如果又不是菜鳥又不是老手,那這樣的人就比較好對付.儘量談好條件就是了.談需求的時候,我與我一個朋友都有共適,就是要錄音,因爲一個人跟他談完後,再複述一遍後,什麼東西都已經變樣了,這樣出來的產品可想而之,所以錄下來,給技術人員去分析,或者給設計者去分析.如果不行,就帶一位記性好點的技術人員去吧.這個我也不知爲什麼,代碼想多了,一天要處理那麼多東西,要想那麼多邏輯,很容易就會健忘了.
所以,要這樣的話.
設計的時候,就採用選代法則
從需求到實現到界面.然後把想法草圖都畫出來,最好用圖來輔助
然後到了界面後,就想清楚流程,然後反過來想清楚軟件的邏輯,想清楚數據庫的查法.確認一下,再重頭來過.
這樣反覆幾次後,最後一次出來的結果,肯定與第一次出來的結果有很大出入.除非你大腦內存不足,想一個忘一個,那我就沒說話可說了.
在確認邏輯方面,你是想用數據型的邏輯還是程序型的邏輯.
就是把所有代表性的東西,都存放在數據庫,用增刪查改來組合.
還是在程序,用OO的思想,用枚舉,用設計模式等組合起來?
不過現在的程序員,都習慣了數據型的邏輯,所以用前者會好點.再說前者的話,也不用考慮太多設計模式.再大型的軟件,只不過是用了一些MVC,策略,工廠這幾個模式而己.很多框架都有很多工廠方法,那個人家都幫你想好了,所以基本上設計模式方面都不用考慮.
這個,我覺得很好用.所以迭代法則,不失爲初學者或者經驗少者的首選.