OO第四次部落格

body

body>*:first-child

body>*:last-child

p, blockquote, ul, ol, dl, table, pre

h1, h2, h3, h4, h5, h6

h1 tt, h1 code, h2 tt, h2 code, h3 tt, h3 code, h4 tt, h4 code, h5 tt, h5 code, h6 tt, h6 code

h1 h2

h3 h4

h5 h6

body>h2:first-child, body>h1:first-child, body>h1:first-child+h2, body>h3:first-child, body>h4:first-child, body>h5:first-child, body>h6:first-child

a:first-child h1, a:first-child h2, a:first-child h3, a:first-child h4, a:first-child h5, a:first-child h6

h1+p, h2+p, h3+p, h4+p, h5+p, h6+p

a a:hover

ul, ol

ul li>:first-child, ol li>:first-child, ul li ul:first-of-type, ol li ol:first-of-type, ul li ol:first-of-type, ol li ul:first-of-type

ul ul, ul ol, ol ol, ol ul

dl dl dt

dl dt:first-child

dl dt>:first-child

dl dt>:last-child

dl dd

dl dd>:first-child

dl dd>:last-child

pre, code, tt

code, tt

pre>code

pre

pre code, pre tt

kbd

blockquote

blockquote>:first-child

blockquote>:last-child

hr table th

table th, table td

table tr

table tr:nth-child(2n)

img

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

在我看來，前者的優點在於，當「預期」具有正確性時，它可以確確實實地保證**的正確性。缺點在於，「預期」本身有時候難以得到，當程式過於龐大、複雜，例如一台每秒幾萬響應的大流量伺服器上的程式，對於它而言，「預期」是極難通過人工獲得的。

而後者，正確性論證的優點在於它不需要進行測試那樣的窮舉操作，頂層的正確性可以分割成底層的正確性，論證複雜度逐層降低，易於實施。缺點在於哪怕程式通過了正確性論證，它也不一定是對的，因為一方面規格本身不一定正確，不一定能夠得出預期的結果；另一方面，人工進行正確性論證這件事情本身就極有可能出錯。

ocl: object constraint language.它是uml標準的一部分。wikipedia裡面的說法是：

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

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

與jsf的相似之處……都是描述性語言？ocl通常也使用前置條件、後置條件、不變式來描述方法、類。

第乙個單元講的是oo，第二個單元是多執行緒，第三個單元是規格，第四個單元是測試&正確性論證。

第一單元所講的物件導向思想是實現後三個單元的基礎，否則實現複雜度會過高。

第二單元的多執行緒，這個說實在的我覺得和我們的課程沒有太大關係，在我看來這只是為了提高作業難度而額外拓展出來的課程內容罷了。

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

第四單元的測試、正確性論證，是

一、二單元的收尾。無論是oo，還是規格，其初衷歸根結底都是為了實現「正確的程式」，這個正確性包含了現有邏輯本身的正確性、拓展後的正確性。第四單元的測試、正確性論證從兩個角度去嘗試實現這一目的。

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

最早的多項式、單執行緒電梯那裡，我依然延續以前的風格——盡可能多地考慮到後續可能的拓展。我會這麼做是因為我以前寫的**都是我自用的。這種**的初次編寫需要較高的耗時，測試也往往較為繁瑣。不過優點在於後續拓展往往是簡單的，雖然手續上可能較為繁瑣，但是邏輯上相對簡單。測試也往往因為較低的邏輯複雜度而偏向於平凡測試。這符合我自用的需求——沒有ddl，且我隨時都可能會有新的想法要去實現。

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

是的，在這一階段，我覺得我每一次作業都在成長。雖然這份成長恐怕無法體現在我找到的別人bug、別人找到的我的bug上。

但是這之後的ifttt，讓我從此停止了這種風格的**——我不再多寫，也不再追求測試的完備性。原因很簡單，我沒那麼多時間。需求變更過於頻繁，推翻重來成了家常便飯，許多需求甚至無法明確。我察覺到了以後當我成為社畜以後這會變成常態。如果我依然延續以前那種完備的**風格的話，以後我可能會變成乙個碼農，最後過勞死。如我之前所說，雖然我原本的**風格因為冗餘的設計而易於拓展，但是每次修改的手續是複雜的，這無法適應頻繁變更的需求——每一次修改我都需要耗費一兩個小時去改，而往往我剛剛改完，需求就又變了。

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

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

按照我的理解，現在我遇到乙個矛盾：

工程化開發應該力求邏輯的簡單，「傻子也會敲的**」，我一直都是如此要求自己的，這種做法能更好地進行協作、測試，也更易於維護。

工程化開發應該力求變更的快速，這一點是我從ifttt中明白的，如此要求不是為了**的質量，而是我自己的生活質量。如果我不能適應快速的需求變更，那等待著我的就是生活時間的被壓榨。

這兩者是否可以並存？我也不知道，我缺乏經驗。或許我需要作為乙個人、作為乙個敲**的，逐漸尋找這兩者的平衡點。

請思考以下幾個情景：

假設有兩位同學在第一次計程車作業的申訴過程中遇到不可調解的矛盾，這個矛盾的根源是指導書的不明確，他們兩人申請了仲裁，然而這份仲裁的結果直到第四次計程車作業都還沒出來。他們其中一人每次都按照自己對指導書的理解去編寫**，這四次計程車作業都因為那乙個「指導書的不明確」而被報bug，而每次都申請了仲裁。最後這位同學在最後一次部落格作業的時候收到自己4個仲裁都輸了的訊息。

一位同學雖然每次都認真地寫自己的**，但是他為人非常心軟，不捨得扣別人的bug，往往雖然測出來一堆bug，但是最後想了想也只掛了乙個bug，把測出來的bug都寫在了備註裡告訴對方。最後他的成績非常靠後。

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

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

OO第四次部落格

OO第四次部落格

OO第四次部落格作業！

第四次部落格

相關推薦