技術債務可能是這樣來的

2021-07-11 06:34:31 字數 4596 閱讀 6687

看我技術部落格的朋友可能有注意到,最近更新了一系列與cef、ppapi、skia相關的文章。在研究它們的過程中,有一些有意思的經歷,非常典型,可以從乙個方面解釋「技術債務」的由來。

接下來我會講講這次經歷,並從此展開,看看形成技術債務的原因及應對策略。

因為業務需要,我得在ppapi外掛程式中顯示另乙個模組(已有模組,基於c++**完成)傳遞過來的影象資料。那個模組提供的資料,影象格式是rgba32,我在intel pentium主機上編譯出的skia庫,預設的顏色型別是kbgra_8888_skcolortype(kn32_skcolortype),這導致在使用skia繪製之前,必須將收到的rgba32格式的資料轉換為bgra,否則就什麼也畫不出來。轉換確實可行,我試了試,不過在影象解析度較高時,耗時會明顯增加。因為需要逐畫素轉換,乙個畫素轉換至少需要三次賦值和兩次索引操作,百萬畫素的就需要百萬次操作。

當我完成畫素格式轉換,看到cef中顯示出顏色正常的資料後,大大松了口氣。此時我有兩個想法:

就這樣吧,功能實現了,ppapi外掛程式程序就顯示影象也不幹別的,慢點沒太大影響

研究skia,看為什麼skcanvas以rgba格式的skbitmap為後端繪圖時失敗

那天臘月二十八,馬上要過年了,第一種選擇所需要的工作僅僅是找理由說服自己,說服領導。這很容易,我們程式設計師老這麼幹啊,不是嗎?

第二種選擇就要困難一些,得做實驗,得硬著頭皮看skia原始碼……這且不說,做了努力也不見得就能解決,說不定耽擱了時間和進度,最後還得回到第一種選擇上去。總之我發現自己內心有點兒小拒絕,也能找到各種理由讓自己放棄這個相對較難的選擇。你遇到過這種情況嗎?

哦賣糕的,我該怎麼做呢?

後來過完年,2.14號情人節那天我就去上班了。大部分人還沒到崗,我覺得研究一下第2種選擇裡那個問題很有必要——有時慢就是最大的缺陷啊。於是就做了下面這些事情:

總之折騰了一天,沒找到原因!此時又想就這麼算了……

選擇容易的路,這種想法貌似難以避免,往往是不經意間就冒出來了。而真正去解決問題,則需要鼓足勇氣努力說服自己。

第二天我覺得研究skcanvas到底怎樣使用skbitmap來繪圖的,花了大半天時間做實驗、閱讀skia的原始碼,終於發現skcanvas基於skbitmap繪圖時會建立乙個skbitmapdevice,而skbitmapdevice會根據kn32_skcolortype來分支操作,而intel pentium主機是小端位元組序,skia的預設編譯選項編譯出來的庫kn32_skcolortype就是bgra,所以當我傳遞把skbitmap的colortype設定為krgba_8888_skcolortype,再將這個skbitmap傳遞給skcanvas時,skcanvas構建skbitmapdevice來作為繪圖的backend,就注定了失敗!

原因明白了,我又有兩個選擇:

認為這是skia的侷限,就此打住

研究skia的編譯系統,看怎樣在小端序的主機上編譯出缺省使用rgba的庫

第乙個選擇,工作就到此完了,也可以解釋給領導和小夥伴了。

第二個選擇,得研究skia的構建系統,還得了解控制顏色型別的那些巨集定義,還得看skbitmapdevice、skbitmap到底如何使用顏色型別……就這還不知道編譯出來的庫是否有其它***(結果證明是有的,後話)……

我又為這個糾結了一陣,這天就這麼下班了……

第二天上班,我鼓起勇氣選擇了研究skia,嘿,別說,經過對ninja指令碼、config標頭檔案以及skimageinfo相關類庫的研究,我真了解清楚了怎樣才能編譯出缺省使用rgba的庫,並且下班前編譯出來了哦。哇,我做實驗時寫的小demo,使用這個新版本的庫,rgba的bitmap用作後端正常了!

接下來的一天,我修改了ppapi外掛程式的**框架,取得了大大的進步:接收到的資料可以不經轉換就正常顯示了!

心裡挺高興:我戰勝了自己從權的想法。

然而問題來了,從本地檔案載入時,red和blue通道反了,用到的圖示看起來詭異得很,效果全部不對……折騰了三種載入本地的方法,都不行。可是記憶體裡繪製是正確滴……

又來到了十字路口,面臨了幾個選擇:

不用skia載入,用其它的,解碼成rgba

用skia,載入後獲取影象資料,交換r和b(圖示都不大,效能損耗可接受)

研究skia從磁碟載入並解碼的流程,搞明白問題出**

你說我選哪個?

第2個,前面幹過了,就是複製點兒**,工作量很小,很有**力。

第1個,bitmap用windows api,png、jpeg也都有解碼庫,之前也用過其他的影象庫,解碼出的資料也是rgba的,看起來也沒什麼難的,就是多一些工作量。

第3個,充滿未知和阻力。要知道看別人的**總是很頭疼的,尤其想skia這種優秀的開源庫,**很棒很巧妙,模組間設計的介面挺簡潔的,很多東西都抽象、封裝了,要理解需要不少時間……還有,缺少文件(好吧,**就是最好的文件,永不會遭遇文件和實現脫節的問題)……

找了會影象庫,什麼freeimage、cximage,看了會skia原始碼,……思想鬥爭到下班也沒決定,記錄到本子上,第二天接著選擇吧。

我回到家裡就琢磨這個問題:為什麼我老想選擇容易的路

是啊,為什麼總是拈輕怕重咧?

此時我腦子裡就回想之前的工作歷程,哪些能run能出結果的**被迫重構了,哪些臨時策略導致了技術債務造成了惡劣影響……

後來我決定選擇 3 !

現在問題已經解決了!

程式設計師出於(我不代表所有程式設計師)本能都想省事兒,選擇容易的路、確定性高的路,這沒什麼好非議的——假如容易的路能漂亮的解決問題,它就是最好的選擇。

然而為了擺脫壓力而採用易行的、湊合的、從權的、臨時的技術方案,多數時候會帶來技術債務

如你所見,我在使用skia在ppapi外掛程式中繪製另乙個模組傳遞過來的rgba影象資料時遇到了問題,在解決問題的過程中,經歷了三次選擇,每一次都面臨容易的妥協方案和較難的、不確定的但真正解決問題的方案。我在這三個時刻,都傾向於選擇容易的、工作量小的、耗時短的方案

這不單是我個人的情況,而是大多數程式設計師從某個問題的多個備選解決方案中選擇時的習慣性行為。這種習慣性行為,一方面出自人的一種本能——人總是不假思索地放棄挑戰選擇那條容易的路。因為挑戰伴隨著不確定性和自我控制,不如唾手可得的方法來得快速。以小孩子為例,你在他面前放兩顆糖,告訴他有如果明天吃掉就可以再得到兩顆糖現在吃掉就再也沒有了,他很可能稍稍猶豫後就抓起那兩顆糖吃掉。

我們傾向於即刻的滿足,延遲滿足是需要經過練習才能形成的思維和行為習慣。這是程式設計師選擇易行解決方案的乙個重要緣由。

避免麻煩和煩惱是本性,所以即便沒有外界壓力,我們還是傾向於選擇看起來更省事兒的方案。然而這並不是程式設計師做出這種選擇的所有原因。程式設計師這麼做,往往還有其它的原因:

稍稍展開一下下。

這是導致選擇簡單粗暴解決方案的最常見最直接的原因。

回到我前面說的問題,其實是個小問題,在這樣的小問題上花將近一周的時間,在交付時間緊張的情況下是很難被允許的(我是剛好在過完春節這個緩衝期才有可能從容來解決它),自己不允許領導也不允許。當你感知到交付時間的強大壓力,結果往往就是先實現再說,以後有時間再來優化。然而這是程式設計師說過的最大的、最堂而皇之的謊言,那些湊合事兒的實現,往往就那麼著了,直到它出問題被使用者和領導逼著限時修改,才開始新一輪的迴圈。

很多公司鼓(qiang)勵(po)大家幹更多的活,如果你能更多的並行工作、更快的交付、完成更多的版本,績效就會更好。在這種導向(制度)下,我們就會更重視數量和速度,忽略質量和可維護性,眼前不出問題就得過且過,慢慢形成只管拉屎不管擦屁股的開發習慣。

不但是程式設計師,程式設計師的領導的績效往往也是這麼個導向,所以一線管理者往往會接受中層、高管的不合理交付要求,轉身就會給程式設計師更緊迫的交付時間把壓力傳遞下來。

這也是乙個重要原因,有時程式設計師遇到的問題他眼下根本解決不了,只能粉飾過去或繞道而行——要從根兒上解決那就花得時間太久了,誰都無法接受(參考前面兩點)。

這也是很多程式設計師做事兒時的常見心態:能run就先run,不出問題就先這麼著,想那麼多幹嘛,出了問題再說,反正幹不完的活

這就是典型的幹活心態

過年時和我原來的老闆吃飯,他說了一句讓我印象深刻的話:如果乙個公司不能讓員工覺得是給自己工作,那這個公司遲早完蛋。這其實說的是事業心態

你覺得自己是在幹活還是幹事業,是給自己幹還是給公司幹,很大程度上決定了你怎麼幹。

回頭來看我前面的經歷,有兩點是需要特別注意的:

我根本沒想到會碰到這個問題(意外總是存在)

時間寬鬆時我才會有徹底解決問題的可能(時間允許時程式設計師才會向難題發起挑戰)

ok,這也是軟體開發過程中避免堆積技術債務時需要參考的非常重要的兩點。

關於這兩點,做過兩年開發的都有體會。然而深有體會的人往往並不掌握決定權,所以,我們還要讓管理層和老闆們意識到下面幾點:

對軟體開發來講,沒有一條道路是重複的。人家走過的路我們來走,仍然可能走不好,被別人驗證過的方案,我們採用時仍然可能遇到各式各樣的問題。即便我們開始前做了自以為最充分的評估,還是有考慮不到的問題跳出來碾壓我們。

軟體開發是手藝活兒,必須留夠時間讓程式設計師耐心打磨才能出好東西。

只有意識到了這幾點,技術氛圍、績效導向才會改變,才有利於形成向技術債務說no的文化。

差異可能是重要的

3位可儲存8個值。n位可儲存2 n值。因為乙個位元組的8位,乙個位元組可以存放2 8 256 的值。變數的大小對大量的資訊可以儲存 這是更大的變數可以容納更多的限制。我們將進一步解決這個問題的時候,我們進入不同型別的變數。第二,電腦有乙個有限的可用記憶體。每一次我們宣告乙個變數,那游離的記憶是只要用...

你可能是自由的

序 一直都愛吃甜,甜到微微的澀。一直都想寫作,寫到天昏地暗。一直追逐自由,飛到天涯海角。孤獨的牧羊人在廣廖的草原牧著他的羊兒們,一生孤獨的他在3歲那年,父母已離開人世,剩下相依為命的奶奶也在10歲時離他而去,留下的只有兩頭羊兒。那一年,他哭的是那麼傷心,周圍嬉皮笑臉的人帶著乙個悲傷的面具,假惺惺的來...

3奈米製程 可能是終極技術

半導體製程技術已推進到10奈米,據台積電董事長張忠謀先前估計,3奈米應該會出來,2奈米則有不確定性,意即3奈米有可能是半導體終極先進技術。3奈米是指積體電路的線寬大小,隨著線寬越小,每片晶圓能產出的晶元數量越多,只是製程技術推進有其物理極限,依張忠謀估計,若2奈米製程無法推出,3奈米便將是半導體終極...