OO第四次博客

 

4

1.測試與正確性論證的比較

這二者在我看來不可比較。前者是對代碼正確性的驗證，是對代碼實際運行結果與預期運行結果的比較。後者是檢查代碼邏輯與規格邏輯的一致性。

在我看來，前者的優勢在於，當「預期」具備正確性時，它能夠確確實實地保證代碼的正確性。缺點在於，「預期」自己有時候難以獲得，當程序過於龐大、複雜，例如一臺每秒幾萬響應的大流量服務器上的程序，對於它而言，「預期」是極難經過人工得到的。

然後者，正確性論證的優勢在於它不須要進行測試那樣的窮舉操做，頂層的正確性能夠分割成底層的正確性，論證複雜度逐層下降，易於實施。缺點在於哪怕程序經過了正確性論證，它也不必定是對的，由於一方面規格自己不必定正確，不必定可以得出預期的結果；另外一方面，人工進行正確性論證這件事情自己就極有可能出錯。

2.OCL語言

OCL: Object Constraint Language.它是UML標準的一部分。wikipedia裏面的說法是：

OCL はUMLを補うものであり、天然言語の曖昧さを排していると同時に複雑な數學的記法を扱わなくてもよいという特徴がある。OCL は、図に基づいたモデルのためのナビゲーション言語でもある。

翻譯過來就是，OCL是對UML的補足，在去除了天然語言的曖昧性的同時，也避免了複雜的數學記法，是用於基於圖的模型的標記語言。

與JSF的類似之處……都是描述性語言？OCL一般也使用前置條件、後置條件、不變式來描述方法、類。

與JSF的區別之處在於OCL沒有拋棄天然語言，它考慮到它自身是一種標記語言，更多的是爲人所閱讀，而沒有采用極爲複雜的數學記法。JSF恰好走了相反極端。

3.UML圖

4.總結

4.1四個單元的聯繫

第一個單元講的是OO，第二個單元是多線程，第三個單元是規格，第四個單元是測試&正確性論證。

第一單元所講的面向對象思想是實現後三個單元的基礎，不然實現複雜度會太高。

第二單元的多線程，這個說實在的我以爲和咱們的課程沒有太大關係，在我看來這只是爲了提升做業難度而額外拓展出來的課程內容罷了。

第三單元的規格，是第一單元OO思想的延伸與補足，也是第四單元正確性論證的基礎。在代碼的基礎上再追加一層邏輯抽象，而這一層抽象相較於代碼而言更加容易驗證。

第四單元的測試、正確性論證，是1、二單元的收尾。不管是OO，仍是規格，其初衷歸根結底都是爲了實現「正確的程序」，這個正確性包含了現有邏輯自己的正確性、拓展後的正確性。第四單元的測試、正確性論證從兩個角度去嘗試實現這一目的。

4.2自身成長的梳理

那我就實實在在，不摻半點水分地梳理一遍吧。

最先的多項式、單線程電梯那裏，我依然延續之前的風格——儘量多地考慮到後續可能的拓展。我會這麼作是由於我之前寫的代碼都是我自用的。這種代碼的初次編寫須要較高的耗時，測試也每每較爲繁瑣。不過優勢在於後續拓展每每是簡單的，雖然手續上可能較爲繁瑣，可是邏輯上相對簡單。測試也每每由於較低的邏輯複雜度而偏向於平凡測試。這符合我自用的需求——沒有DDL，且我隨時均可能會有新的想法要去實現。

後來的多線程電梯我也依然延續這種風格，不過由於多線程接觸得較少，因此那次我花了極多的時間在設計上，在設計這個層面花了極多的精力去避免多線程陷阱。結果也很好，事實上多線程電梯中我基本徹底複用了單線程電梯時的代碼，雖然代碼層次愈來愈深，可是每一個層次的複雜度依然很低。追加的線程部分的代碼與多部電梯的調度邏輯，都很好地和原來的代碼分離了開來。在實現多線程電梯的過程當中，註釋、標記、日誌的使用讓我爲之一振，它們的出現雖然讓代碼看起來變得繁瑣，可是在複雜的多線程測試中，它們的存在極大地下降了測試複雜度。輸入輸出的重定向實現，測試線程的應用也讓我由本來的批處理測試轉向了具備更高複雜度的自動測試。

是的，在這一階段，我以爲我每一次做業都在成長。雖然這份成長恐怕沒法體如今我找到的別人bug、別人找到的個人bug上。

可是這以後的IFTTT，讓我今後中止了這種風格的代碼——我再也不多寫，也再也不追求測試的完備性。緣由很簡單，我沒那麼多時間。需求變動過於頻繁，推翻重來成了屢見不鮮，許多需求甚至沒法明確。我察覺到了之後當我成爲社畜之後這會變成常態。若是我依然延續之前那種完備的代碼風格的話，之後我可能會變成一個碼農，最後過勞死。如我以前所說，雖然我本來的代碼風格由於冗餘的設計而易於拓展，可是每次修改的手續是複雜的，這沒法適應頻繁變動的需求——每一次修改我都須要耗費一兩個小時去改，而每每我剛剛改完，需求就又變了。

我確確實實地察覺到了個人代碼風格不適合這種需求環境。因而我改變了個人代碼風格、測試風格。代碼中雖然依然保持各個邏輯的分離，可是再也不進行任何冗餘設計，儘量地將每次微小改動侷限在一小段代碼中，哪怕多是要重寫整片代碼，哪怕邏輯可能複雜——可是修改量很小，修改時間很短，只是對「我」的要求很高。測試風格也再也不追求高覆蓋率，不然每次需求變動我就幾乎每次都要從新準備測試樣例。我轉而僅僅只針對需求的每一條獨立地進行測試，在這之上再進行隨機測試。

這種風格的轉變在以後的若干次出租車一直延續了下去——我不知道何種風格是好的，我只是選擇了一種「我能完成一份有效做業，同時不會花費過多時間」的方法。對於我而言，「進步」這個概念在IFTTT以前都確實存在着，可是這以後，我可能更多地是在適應。

4.3對工程化開發的理解

按照個人理解，如今我遇到一個矛盾：

1. 工程化開發應該力求邏輯的簡單，「傻子也會敲的代碼」，我一直都是如此要求本身的，這種作法能更好地進行協做、測試，也更易於維護。
2. 工程化開發應該力求變動的快速，這一點是我從IFTTT中明白的，如此要求不是爲了代碼的質量，而是我本身的生活質量。若是我不能適應快速的需求變動，那等待着個人就是生活時間的被壓榨。

這二者是否能夠並存？我也不知道，我缺少經驗。或許我須要做爲一我的、做爲一個敲代碼的，逐漸尋找這二者的平衡點。

4.4對課程的建議

請思考如下幾個情景：

1. 假設有兩位同窗在第一次出租車做業的申訴過程當中遇到不可調解的矛盾，這個矛盾的根源是指導書的不明確，他們兩人申請了仲裁，然而這份仲裁的結果直到第四次出租車做業都還沒出來。他們其中一人每次都按照本身對指導書的理解去編寫代碼，這四次出租車做業都由於那一個「指導書的不明確」而被報bug，而每次都申請了仲裁。最後這位同窗在最後一次博客做業的時候收到本身4個仲裁都輸了的消息。
2. 一位同窗雖然每次本身代碼沒怎麼很差好寫，可是他很是熱衷於互測，每次都會反反覆覆地發issue、發微信，和多位助教積極溝通，由此得到了較好的成績。
3. 一位同窗雖然每次都認真地寫本身的代碼，可是他爲人很是心軟，不捨得扣別人的bug，每每雖然測出來一堆bug，可是最後想了想也只掛了一個bug，把測出來的bug都寫在了備註裏告訴對方。最後他的成績很是靠後。

以上情景都是我胡扯的，和具體人物沒任何關係。

我想說的有不少，濃縮成一句話的話就是：還好這門課掛不掛科和排名不要緊，若是規定倒數多少名直接掛科的話，這門課——不，可能這個系就完了。