? ? 非常多時候我們要做龐大project, 就像一棵大樹, 方方面面都有自己的細枝末節，而作為開發員的我們，無法時時刻刻去保持對程序的全面認知，所以我們要把程序設計與邏輯設計區分開來。

? ? 那么什么是程序設計和邏輯設計，舉個樣例來說，統計一群人，程序上能夠做到對人群的歸類字典統計。也能夠做成每一個人有自己的屬性之類的，而作為邏輯上，須要知道人的名字。性別。身高之類。事實上這個樣例你可能看不太清晰。非常多時候程序和邏輯是混合在一起的。比方我拋一個小球。邏輯上已經設計了重力，環境，以及墻壁，從邏輯上我這個小球會依照一切安排的正確執行。可是這一切基于什么？決定因素都不在小球，重力，環境。以及墻壁的改變都會影響到小球的結果變化。

這個邏輯不如叫間接程序設計。程序上直接對小球進行本身的控制更有把握。

再比方說我要做個僅僅同意小球上拋的動作。 可能上拋有可能碰觸到天花板和側墻。而假設我后來取消了限制小球的拋出角度。那么小球有可能被拋向不論什么地方，可能是地面也說不定。這樣的時候你肯定不會第一時間就知道這一影響并修正，有可能你還是僅僅是慣性思維的做想上拋的動作。而忽略了向下拋全然可能出問題，后來經過重復測試，你才漸漸地找出問題所在。

? ? 所以敲代碼，不能靠邏輯來綁定你的思維。你不能就這么認為“恩。這樣沒問題了。a,b,c這些影響下就是這個結果"，拜托，這不是日常生活，這不須要慣性思維，你該限制小球速度就是須要限制，該給沒可能的情況添加條件推斷就該去添加推斷，這樣你的project代碼才健壯。邏輯條件僅僅是一個架起虛空的云梯，你摔下去的因素有千萬種可能。

? ? 或許你會認為做多重推斷以及不是必需的條件添加代碼全然不是必需，并且添加執行成本。

但漸漸的這些問題在你的project中后期就會都慢慢浮現出來。

? ? 你僅僅是個碼代員，不是主宰項目的存在。真正主宰項目的是經理，客戶和終端用戶。

所以，給代碼健壯的邏輯，給后期穩健的開發速度。

轉載于:https://www.cnblogs.com/cxchanpin/p/6748197.html

總結

以上是生活随笔為你收集整理的project开发的程序设计与逻辑设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。