天天看點

程式的本質在于邏輯

有時候,特定的場合下,你會發現寫一個bash腳本都會帶來這樣那樣的問題,有些地方沒有考慮到,而有些則過于備援。即使你熟悉N中進階語言,同時精通底層彙編語言,又精通網絡協定,配置各類網絡裝置已經到了爐火純青的地步,即使如此,如果你是一個毫無邏輯的人,或者一時半會兒沒有徹底了解需求導緻邏輯不清晰,你都無法正确的編寫出代碼,哪怕是一段很短的bash腳本-如果不是冗長的C代碼的話。

        是以程式的本質在于邏輯。語言隻是一種實作邏輯的工具而已,不管什麼語言,其基本特征都一樣,無非就是那些if-then-else,while,for-each,AND/OR/XOR之類的,差別隻是在于某些針對某類程式寫起來以及了解起來較其它的更友善些。然而如今大多數的人癡迷于語言本身,學了且精通那麼多種語言,卻寫不好一個程式,這也難免,正如如今很多人學了英語,又學日語,法語,德語,阿拉伯語...然而很少有人哪怕能用其母語創造出一段-如果不是一篇的話-美妙的文字,這也是為何外語學習中聽說讀寫遠遠比精通文法來的重要的原因,畢竟自然語言是訴諸耳口筆的。計算機語言是訴諸邏輯的,是以要想寫出美妙的代碼,理清邏輯要比精通語言重要的多。

        我一直以來都不把程式界面-UI-看得很重要,然而事實證明我錯了。實際上一個可用的程式,其邏輯往往展現在界面上,是以如何去設計界面是一個很考驗人邏輯思維的事情,要點在于你如何能設計一個界面,讓使用者無論怎麼操作都能保證底層邏輯執行的正确性,該設計應該是封閉的,假設使用者毫無邏輯概念,然而你的程式不能因為使用者的過錯而出現錯誤結果或者不可預知的結果,在這一點上,Apple的設計尤其好。

        在界面設計中,尤其複雜的是一個操作會帶來什麼連鎖反應,其下面是一個複雜的狀态機,如果能事先把該狀态機畫出來,事情就會好辦的多,然而畫狀态機要比畫流程圖複雜的多,狀态機涉及到複雜的基于狀态轉換的關聯效應,而流程圖僅僅是一個if-then-else-then的序列。我從不設計界面,這種事實應該改變了,我自認為寫出的程式無誤,然而僅僅是自己用或者試驗罷了,畢竟我當然知道自己程式的雷區在哪裡,一旦把我的程式和其它程式結合,上面鋪蓋一層便于傻瓜式操作的UI,我的麻煩就來了,沒完沒了地查漏補缺...實際上,我真的很精通底層語言以及網絡協定棧,包括原理和實作我都很精通,然而卻不能利用它堆建一座高樓大廈。

        一個例子如下:我在設計一個網關産品,有30個節點之間要互相兩兩通信,其中某些節點之間的通信需要受控,而某些節點之間的通信不需要受控,我該如何設計它的UI?實際上這是一個典型的例子,其UI下面是一個二維矩陣,類似公共汽車上貼的那種裡程-票價表,整個節點間互訪規則如下圖所示:

底層邏輯就是上圖所示,然而界面要如何設計,我不得而知,不是說沒有一點辦法,大不了就把這個矩陣放到界面上也OK,然而使用者能友善的操作嗎?是以集邏輯合理性,糾錯,操作友善于一體的UI其實真的很難設計的。上例中展現的是一個多對多的複雜關系,如果僅僅是初始配置也還簡單,但是如果加上增删改查操作,那真的可夠老子喝一壺的了。碰到過這種問題的應該都知道,如果你在某個地方增加了一個資訊,那麼你必然要想到在哪個地方删除這個資訊,而這是最容易引發bug的地方。

        實際上,如果想實作完成某個操作之後的動作,對于一個有半年工作經驗的程式員來講不是什麼難事,關鍵的難點不在這裡,而是你的設計如何應對使用者操作的連續性,比如如果使用者增加或者删除或者修改了一個節點,其它節點的配置如何與之關聯,如果設計不好,就會牽一發而動全身,當然這是最醜陋的做法,修改一個配置,所有其它配置就都要更新。如何實作一個對使用者而言最少影響程式的設計是至關重要的。UI設計追求的是完美,而底層的程式設計追求的是健壯,二者原則是不同的。

        如果是做一個産品,那麼首先要考慮的就是底層程式的健壯以及UI的完美。當然如果隻是為了試驗一下可行性或者僅僅為了玩一玩,怎麼搞都可以,哪怕手工寫死一段代碼都無所謂,可是這種程式是千萬不要用于産品代碼中的,否則日後的維護将會陷入泥潭。總而言之,邏輯最重要,而UI設計中邏輯及其重要,你不光要考慮你自己的程式,還要考慮使用者操作的友善性以及你的程式如何應對使用者的胡亂操作,還要考慮可維護性...畫一個狀态圖吧,雖然很麻煩但是卻省去了日後的bug排查将要耗費的時間。如果僅僅是想證明一下自己的能力,那麼可以胡亂搞,怎麼都行...然而事實是,對于軟體工程,實驗室的成果不算什麼成績,也不能展現你的能力,是以除非你是大學或者研究機構專業搞研究的,否則不要總是用實驗室的結論來為自己抹金。

        程式的本質在于邏輯,其它的有的是浮雲,有的是浮雲下面的東西...

 本文轉自 dog250 51CTO部落格,原文連結:http://blog.51cto.com/dog250/1268971

繼續閱讀