【做業4.0】HansBug的第四次面向對象課程思考

嘛。。不知不覺這門課程要結束了，那麼就再說點啥以示慶祝唄。

測試vs正確性論證

說到這個，相比不少人對此其實頗有疑惑，請讓我慢慢分析。

邏輯概覽

首先咱們來看看兩種方式各自的作法和流程是什麼樣的：

單元測試

在測試中，咱們是這樣的一個流程

此外，爲了保證測試能覆蓋到工程代碼的每個區域，須要保證測試的覆蓋率。

正確性證實

在證實中，咱們是這樣的一個流程

在這一過程當中

• 基於行爲分析的repOk永真性證實依賴於JSF中的modifies項
• 方法正確性將基於JSF中所描述的effects和requires項
• 各方法內其餘方法的調用須要依賴被調用方法的正確性，具體來講
  • 對於系統自帶的類與方法實現一概默認正確
  • 對於其餘位置的調用，正確性則依賴於其具體方法或類的正確性證實

關鍵細節

基於以上的邏輯，咱們不難發現一個細節：

• 在單元測試的流程圖上，當程序經過測試後，是假定程序爲正確而不是程序爲正確

或者更具體地說，這裏多出了一個名爲假定的字眼。

這是什麼緣由的？其實說來也很是簡單——由於測試，只能證實程序有錯，而不能證實程序是對的。

雖然有大數定律的理論支撐（即只要測試集數量無限大，則一定能夠覆蓋一切狀況），但是實際上並不存在無限大的測試集，故測試上的死角總仍是會存在的。

設一個有限集 $ T $ ，爲測試集（單元測試中的測試集不可能作到無窮），而 $ S $爲全集。然而，在實際狀況下，可能遇到的狀況經常是無窮多的，故 $ S $ 是一個無窮集。

故，$ \complement^{S}{T} $ 即爲測試集沒有覆蓋到的地方。又 $ T $ 有窮， $ S $ 無窮，故 $ T \subset S $ 恆成立，$ \complement^{S}{T} \neq \emptyset $

故永遠有覆蓋不到的數據，且對於這部分沒法覆蓋到的區域，是沒法僅依靠測試來證實正確性的。

故基於測試的正確性驗證的嚴謹性問題是不可避免的。若要嚴格意義上地論證正確性，基於程序邏輯的正確性證實是惟一的選擇。

異與同、取與舍

在上面的分析中，咱們論證了單元測試方法存在的硬傷。

然而，咱們爲啥還要保留這樣的方法呢？

由於，實際問題與應用大都不是一元線性的，而是時間、經濟、人力等多方面成本以及多方面效益指標所構成的高維量。

其實，在工業界各種應用中，經常有如下兩種模式能夠長久而穩定的存在：

• 較高的成本，絕對高的質量（或者說其質量水準具備不可替代性），可是部署門檻稍高
• 成本低廉，較高的質量，且易於普遍普及與部署，易於操做易於維護

實際上，不只在計算機行業，在其餘工業界乃至於商業中，也經常會造成這樣兩種模式並存的局面。

而反映在軟件質量保證領域，則分別是基於程序設計邏輯的正確性證實（正確性從原理層面上就有絕對的保障，但是成本嘛，各位都寫過一次論證，體驗過其成本之高昂）和面向數據指望的單元測試（操做很是簡便，方便大範圍部署，且能覆蓋絕大部分實際狀況）。

因此，在實際應用中

• 嚴格的正確性證實經常只會被運用在一些對產品質量要求絕對高的局部區域（例如航天器的核心控制程序，對錯誤的容忍度爲零）
• 普通的單元測試則會被普遍運用在通常工程項目的測試中（對錯誤有必定的容忍限度，但務必兼顧時間、經濟成本和效益，創業公司的項目中更是如此）

說到底，這二者其實很難去嚴格區分一個優劣。不少問題，根本上仍是一句話——具體問題具體分析，適合的就是對的。

OCLvsJSF

何謂OCL

OCL，英文全稱object constraint language，翻譯過來就是對象約束語言。

顧名思義，其做用在於對設計的對象進行約束，且保證不存在二義性。且實際上，OCL和UML（統一建模語言，Unified Modeling Language）捆綁使用。

異與同

從以上的一些基本概述中，咱們不難發現OCL實際上和JSF有着類似之處：

• 都是對於程序設計上的約束（其中包含了類合法性、以及方法行爲等要素）
• 最終目標都是描述程序設計的預期行爲，做爲一個統一的標準

然而進一步研究與分析，其區別也是很大的：

• 首先，OCL約束的核心對象和JSF有較大差異。JSF在圍繞方法和類，而OCL則在對象，以及對象內、對象間所包含的數據項。
• 基於以上的緣由，OCL的表達能力遠遠比JSF豐富。OCL做爲約束語言，能夠自由地約束各處的數據項和設計規範。而JSF的不變式約束相比之下就遜色了很是多。
• 也正是因爲OCL的豐富性和完備的可計算性，因此OCL徹底具有相似SQL那樣的查詢能力。
• 可是，爲了支撐如此龐大豐富的能力，且保證無二義性，OCL所付出的代價就是重量化。而JSF則相比之下更輕便更快捷。

而至於具體應用呢，則仍是老規矩——適合的就是最好的。在不一樣的工程項目，不一樣的場合下，天然會有不一樣的選擇。

關於第十四次做業

UML類圖

順序圖

狀態圖

其餘

知識點之間的關係

首先，咱們來回顧下咱們這學期四章的各個標題：

• 第一章 Java與對象（Java和麪向對象基本概念入門）
• 第二章 併發與安全（多線程程序設計入門）
• 第三章 抽象與規格（規格化與總體設計進階）
• 第四章 測試與論證（工程化質量保證措施學習與體驗）

其實這很明顯，是一個按部就班的過程，體如今兩個不一樣的層面上：

• 從學生學習的角度而言，知識體系是層層遞進的
• 從工業生產的角度而言，這個也很接近一個產品從設計到交付，自底向上的一個完整流程

我的收穫與小結

實際上，筆者在多年前，就已經接觸並使用了面向對象程序設計語言。

因此，實際上在這個學期，筆者的主要收穫以下：

• 經過十幾回做業對程序框架設計的反覆揣摩，筆者在總體框架設計上的水平更加趨於成熟
• 更加深刻的瞭解了嚴格工業界的一些作法（例如普遍地規格化程序設計，以及正確性證實等）
• 此外，筆者結合以前多年的實踐經驗（理論課上講到過的坑，筆者當年幾乎全都親自踩過一遍）和對工業界的一些基本瞭解（筆者已經作過多筆的外包項目，目前仍在着手運營的項目也有數個），對面向對象和工程化的理解也更加深刻了。

工程化的我的看法

關於工程化呢，其實說難也難，說簡單也簡單得很。

一些具體的好處呢，筆者在前三次博客做業中均有不一樣程度的論述（此處再也不贅述）：

• 【做業】HansBug的前三次OO做業分析與小結
• 【做業2.0】HansBug的5-7次OO做業分析與小結，以及一些我的體會
• 【做業3.0】HansBug的第三次博客規格總結

不過說到底呢，其實就幾件事：

• 任什麼時候代任何狀況下，左右戰局的決定性因素，永遠是人
• 所以，工程化的一個基本思想就是以人爲本
  • 從開發者角度，爲開發者提供方便提升效率（不管是短時間仍是長期，不管是單人仍是團隊，都是須要考慮的）
  • 從商業團體角度，提升總體戰鬥力，創造更大的效益和價值
  • 從用戶角度，讓用戶體驗更優（或者說給用戶提供足夠的方便），讓用戶更加願意直接或間接地掏腰包（統計意義上的）
• 此外，對於不一樣的解決方案，通常狀況下存在即合理（或者說，對於尚未被淘汰的解決方案，其存在終究是能夠良好知足某些場合下的需求的）。對此，咱們該作的，就是具體問題具體分析，選擇在具體狀況下最優的方案。

課程思考與建議

我的的思考與建議

關於這個問題，筆者在兩三個月前，就已經開始思考了。

衆所周知，面向對象課程的槽點仍是不算少的。

不過，據筆者看，這些問題看似龐雜，可是只要仔細去理一理背後的邏輯關係，其實也很簡單。

筆者根據自身瞭解的一些事實，和大半個學期以來的觀察與分析，粗略的獲得了下面的這張邏輯圖：

不過這樣一來，看似錯綜複雜的事情也就清楚了。

稍加觀察，即可以發現問題的根源——沒有一個相對公平合理的橫向比較機制。（稍微瞭解拓撲排序的概念，即可以得出這樣的結論，找到節點的上游）

其實，不少同窗（包括16級的和之前的學長學姐們）以前所吐槽過的問題，根源都在這邊。

假如，咱們有一個很靠譜的自動化橫向比較機制

• 那麼，咱們的分數將更具備梯度和區分度，且評分核心依據將是程序的真實質量
• 那麼，互測的實際門檻將能夠考慮提升，互測人員的總體素質也將提升
• 那麼，基於上一條，咱們將再也不須要每次祈禱不趕上壞人（指的是爲了本身的分數能夠不要臉良心還從不痛的那種）
• 那麼，基於上一條，咱們的助教們將再也不須要面臨巨大的仲裁任務壓力
• 那麼，基於上一條，咱們的同窗們將再也不須要承受等待助教仲裁的痛苦煎熬
• 那麼，咱們的評測將能夠考慮部分模糊化，以適應模糊化的需求
• 那麼，基於上一條，咱們的同窗能夠再也不不停地糾結需求細節（經常仍是可有可無的細節），助教們也將大大減小issue答疑時間
• 那麼，基於以上全部條，咱們的同窗們的總體體驗將有質的飛躍
• 那麼，基於上一條，同窗們將更加願意積極努力學習這門課程

實際上，想作出改變，也並不難，好比：

• 公測再也不嚴格面向bug出數據。或者至少不徹底面向bug，面向bug的部分能夠做爲功能性弱測。
• 自動化公測引入模糊化測試。好比相似於oj中的Special Judge和提交答案題裏面的部分分機制相結合，讓程序只要不違背基本法（例如電梯不許瞬移不許分身）就能有分數，且各個水準的程序得分有梯度。
• 能夠將面向bug的功能性弱測和模糊化性能強測相結合，構建出更有遊戲性的制度（也能夠容許在必定時間內公測屢次提交，屢次刷分，追求卓越）。
• 由此，能夠基於公測最終成績，設立必定的互測門檻，經過門檻者方可進入互測環節。
• 在互測環節中，能夠設計相似codeforces那樣的多對多大混戰hack模式（也能夠考慮待測程序不匿名，今後再也不有無效做業的坑），保證互測的運氣成分降到最低。

固然以上只是一些初步構想，筆者對於這個（自認爲）靠譜的新制度，已經有了更深層次的計劃和構想，更具體的計劃等細節將在另外一篇文章中詳細闡述。

想對接下來的分析者們說的一些話

筆者寫到這裏以前，看過以前很多同窗的一些思考與建tu議cao。

不得不說，雖然大部分的所謂分析徹底流於表面，透過現象看本質的幾乎沒有（截至2018.6.25 6點整），可是，你們反映的問題，也很真實，或者說很真實地描繪了大衆水平同窗眼中的面向對象課程。

說這個，其實不是想吐槽各位（實際上，筆者更但願你們能繼續描述心裏的真實體驗）。

引用筆者以前說過不止一遍的一句話

無法帶來絲毫改變，甚至只會讓事情更壞的怒火，是毫無心義的。

因此呢，但願接下來看到筆者文章的各位，能在吐槽的基礎上和自身能力所及的狀況下，進行更深刻的思考，能夠的話也多想一想到底如何才能讓事情變得更好，而不是一味地抱怨與泄私憤。

抱怨沒有用，實幹才能解決問題。