發表文章

[轉] 怎麼提高代碼質量?-來自Google的研發經驗總結

圖片
你的團隊有沒有過這樣的經歷:開發效率低,招了很多人,天天加班,出活卻不多,線上bug頻發,領導發飆,中層束手無策,工程師抱怨不斷,查找bug困難。其實這些都是程式碼質量差惹的禍。程式碼質量是研髮質量管理的根本,它決定了整個開發團隊的開發效率,項目質量,其他監控,告警,日誌等手段都只能是事後補償。本文就如何保證程式碼質量總結了一些經驗和方法,供大家參考。 程式碼質量本身並沒有一個特別明確的量化指標,而且根據公司發展的不同階段,團隊規模的大小不同,項目性質的不同等,對程式碼質量的要求也不盡相同。不過如果項目中出現以下情況時候,就說明程式碼質量要值得重視了。 添加或修改一個簡單功能時,涉及要修改的地方特別多,而且很分散; 程式碼不可復用:相似的功能無法復用程式碼,要重新開發; 線上bug頻發,排錯困難,修復難度大,時間長; 有很多奇怪的程式碼,程式碼讀不懂,新人無法很快瞭解程式碼; 程式碼中坑特別多,不敢大動,一不小心就踩坑; 以上這些問題,基本上都是程式碼質量不高導致的,包括程式碼無註釋,無文檔,命名差,項目層次結構差,調用關係混亂,到處hardcode,臨時解決方案等等。怎麼才能時刻保證程式碼的高質量,避免以上問題發生?當然團隊的技術素質很重要,除此之外,還有一些方法可循的。 1. 吹毛求疵般地執行編碼規範 嚴格執行程式碼編寫規範,可以使一個項目乃至一個公司的程式碼具有完全統一的風格,就像同一個人編寫的一樣,而且命名良好的變量,函數,類和註釋,也無疑可以提高程式碼的可讀性。具體落實到執行層面,可以參照Google的編碼規範或者java官方的編碼規範,網上可以找到,關鍵是要嚴格遵守,並且在code review時,嚴格要求,沒有按照規範的一定要指出並且要求修改。 實際情況往往是雖然大家都知道優秀的程式碼規範是怎樣的,但在具體寫程式碼的過程中,卻執行的差強人意,很多情況是認識上不夠重視,覺得一個變量或者函數的命名成哪樣關係不大,所以不夠推敲,註釋很多也都不寫,code review的時候大家也都事不關己心態,或者覺得沒必要太摳細節,導致慢慢的整個code base變得越來越差。所以這裡還是要強調一下,細節決定成敗,提高團隊對程式碼規範的認同及其嚴格的執行是關鍵。 2. 編寫高質量的單元測試 單元測試是最容易執行,且對提高程式碼質量見效最快的方法之一還。但還是有很多

每個程式設計師/程序猿/碼農 都該問自己的14個問題

圖片
Coder 又譯 程式設計師 程序猿 碼農 寫代碼的 ... 在 IT 環境打滾久了,還是會看到很多有資歷的 Coder 寫出的程式碼難以維護, 邏輯混亂,又臭又長,甚至連註解都沒有。 程式開發並不是寫愈久經驗值就愈高 ... 這不是遊戲啊! 想不想進步,要不要進步都端看個人願不願意學習與精進。 很多寫了 6~7 年以上的 Coder 依然只會 Copy and Paste , 很多時候連自己 C&P 的 Code 內容是什麼都不知道 ... 😞😞😞 或者按照既有團隊規則與流程就這樣寫下去,一點疑問也沒有, 對原理與過程一點興趣也沒有。😖😖😖 這就是現實啊! 但是既然走了 IT(哀踢) 路,就無法後悔了,正所謂: IT無涯,回頭無岸 真的是很辛苦的一條路,走下去全靠興趣。 在對岸王爭的專欄《設計模式之美》,其中提到的如何發現程式碼質量問題, 可以從以下幾個方面審視程式碼, 這也是每次開發的過程中都應該要在內心問自己的問題: 專案目錄設置是否合理、模組劃分是否清晰、程式碼結構是否滿足“高內聚、低耦合”? 是否遵循經典的設計原則和設計思想(SOLID、DRY、KISS、YAGNI、LOD 等)? 設計模式是否應用得當?是否有過度設計? 程式碼是否容易擴展?如果要添加新功能,是否容易實現? 程式碼是否可以復用?是否可以復用已有的項目程式碼或類別庫? 是否有重複造輪子? 程式碼是否容易測試?單元測試是否全面覆蓋了各種正常和異常的情況? 程式碼是否易讀?是否符合團隊的編碼規範 (比如命名和註釋是否恰當、代碼風格是否一致等)? 程式碼是否實現了預期的業務需求? 邏輯是否正確?是否處理了各種異常情況?是否保留彈性? 日誌紀錄是否得當?是否方便 除錯(debug) 排查問題? API是否易用?是否支持冪等、交易事務等? 程式碼是否存在平行處理問題?是否為安全的執行續? 性能是否有還有優化空間,比如,SQL、算法、邏輯是否可以再優化? 是否有安全漏洞?比如輸入輸出校驗是否完整且全面? 這些問題都很不簡單,但時常問自己,久了就會改善, 過程中經驗值就會提升了。 希望這些對大家有幫助。 All rights reserved. ------------------------ 設計模式/Design Pattern/軟

Apple WWDC 2020 落幕拉 - 推出了 iOS 14/iPadOS 14/tvOS 14/mac OS??

圖片
--- ---  萬眾注目的年度大會 WWDC 終於在台灣時間 2020/06/23 凌晨召開拉。 因為這次疫情的關係,採用線上直播的方式舉辦, 也因為是新的方式,所以全程免費啦!這算是史上第一遭。 這次的重點除了標準發布 OS 新版本外,最令大家不意外的就是 ... APPLE 發表自己的晶片了。 以後的 APP 就真的是開發一次,多平台到處跑了。 真的是有好有壞,壞的是跑 Windows 軟體就是要回歸虛擬化了, 這就需要再等一段時間了。 ARM 的潛力真是威阿,APPLE 從自己與IBM合作開發晶片 轉向與 INTEL 合作, 接著又繼續走回自己開發晶片的路,每隔 N 年就會一次大轉換。 從精簡指令集 轉向 複雜指令集 又轉回 精簡指令集 ~~~ 我想在這兩個領域,蘋果應該已經很有經驗了。💪💪💪 使用者要花些時間適應外,最累的應該還是開發人員了吧~  😂😂😂 接下來最亮眼的是:全新 iOS 14的「客製化」畫面! 這是標準 APPLE 創新 Style 了。 這畫面如果已經是在使用 Android 的人應該很熟悉不過了。 Android Widget 與 App 自動分類已經行之有年了,直到最近 Apple 才看齊。 這也不易外,想當年 Apple 就是這樣拿到 MP3 霸主地位的。 孰悉的功能融合了 Apple DNA 創造了屬於 iOS 的「客製化」畫面。 其他新鮮貨還有: 新增iPhone影片「多工」模式 內建iOS語音翻譯 用iPhone解鎖汽車 WatchOS洗手倒數+睡眠追蹤 Apple TV+ 原創影集 全新MAC作業系統「Big Sur」 SAFARI翻譯功能+分頁預覽 全新網頁隱私設定+擴充功能 iPad用「手寫」完全代替打字。用筆手寫這部分原本就已經很強大了。 滿期待新的功能,可惜一樣都是要等待秋季與新 iPhone hone 一同發布了~ 以上所有圖片資源皆來自 APPLE官方直播 截圖

[技巧] 值得記起來/你一定要知道的 10個 20 個 Excel 快速鍵

圖片
--- ---  俗話說的好,事倍功半。 大部分在使用電腦時,雙手都是在鍵盤上遊走, 若突然想要使用個功能時,就會需要有一隻手離開鍵盤去操作滑鼠, 在這樣的移動過程中,少數幾次還無感,次數一多就會覺得效率下降了。 EXCEL 又是常用的辦公軟體,認識與記住這些快速鍵可以降低手臂移動的次數, 可以大大增加操作效率,值得大家學習。 Ctrl + R ➠ 公式向右填滿 Ctrl + Alt + V  ➠ 叫出選擇性貼上功能 Ctrl + ➡️ ➠ 移動到本列最末端 Ctrl + ⬅️ ➠ 移動到本列最前端 Ctrl + ⬆️ ➠ 移動到本欄最頂端 Ctrl + ⬇️ ➠ 移動到本欄最末端 Ctrl + Shift + ➡️ ➠ 從目前的儲存格往右選取該(列)的儲存格,直到最後 Ctrl + Shift + ⬅️ ➠ 從目前的儲存格往左選取該(列)的儲存格,直到開頭 Ctrl + Shift + ⬆️ ➠ 從目前的儲存格往上選取該(欄)的儲存格,直到頂端 Ctrl + Shift + ⬇️ ➠ 從目前的儲存格往下選取該(欄)的儲存格,直到末端 Ctrl + [Page Up] ➠ 跳到上一個工作表 Ctrl + [Page Down] ➠ 跳到下一個工作表 Ctrl + Shift + 4 ➠ 套用(貨幣)格式 Ctrl + Shift + 5 ➠ 套用(百分比)格式 Ctrl + 1 ➠ 開啟儲存格格式設定視窗 Ctrl + A ➠ 全選,選取所有資料 Ctrl + B ➠ 儲存格文字變粗體 Ctrl + D ➠ 公式向下填滿 Ctrl + ➕ ➠ 插入新欄或新列 Ctrl + ➖ ➠ 刪除新欄或新列 All rights reserved. ------------------------ Microsoft 365/Office 365/Excel/Word/HotKey/Shortcut/xslx/docx/pptx 教學/密技/一定要知道的/秘訣/一次搞定/Excel 常用 18 個快速鍵/官方認證Excel最常用的22個快速鍵 學會這5個Excel快速鍵/工作效率/翻倍/Excel 基礎教學/Excel 說明與學習/絕對用得到/ 6個Excel小訣竅讓報表更專業/搞定10個EXCEL難題 ------------

[靈異事件簿] MS SQL Server Linked Server 資料源為空白時的異常行為 | Strange behavior of SQL Server Linked Server When Data Source Is Null

圖片
某日同事回報 SQL 從遠端抓取資料的時候怪怪的, 透過 Linked Server 查詢的結果跟直接連到機器上查詢的結果不一樣!😕 經檢查 Linked Server 的設定,發現設定項目怪怪的,如下圖: 在選擇 [Other data source] 選項下,並沒有特別指定 [Data source] 的項目, 也就是說 Data source IS NULL!! (大驚 👀👀👀) 建置的過程中並沒有出現任何錯誤訊息 💀💀💀 這就怪了,展開資料庫後發現 .... 怪怪的, 怪怪的, 怪怪的 怎麼連到自己本機了??? 為什麼會知道是連到自己?因為平常為了區別自己連到哪台機器, 所以會設定一個旗標資料庫(Database Flag)用來區別。 要是沒有設定這個的話,我想找老半天也很難發現疑點 Orz... 這就奇怪了,既不是使用 Linked server 名稱指定的資訊,Data source 又是空的!? 那他到底是怎麼連線的呢? 檢查建立語法也並無特別之處 只好從 [sp_addlinkedserver] 下手,看了一下發現裡面針對參數檢查主要是檢查 @srvproduct 與 @provider 這兩個值,而 @datasrc 本身就是預設 NULL, 所以當執行時也是正常的,而 [sys.sp_MSaddserver_internal] 似乎照不到,不得而知。 最後只得再找找 MDSN 了。 sp_addlinkedserver (Transact-SQL) 從文件上可以看到,若 @srvproduct 指定為 [SQL Server] 時,其他參數都不用指定, 而且會使用 @server 的內容來連線伺服器,這也是一般常用的方式。 但這次的問題是使用其他方式的連線且  Data source IS NULL,只好繼續看下去 ... 唯一最接近的就是備註內提到的 provider_name 是 [SQLNCLI] 項目: 真的是有看但沒有很懂。 目前只能推測當 data source (@datasrc) 如果沒有指定到時,預設會帶入 NULL, 而當 [OLE DB 提供者] 在初始化的過程當中,*可能*內部判斷若沒有資料來源時, 就會預設使用 本機/Localhost 來當作資料來源,而不會產生錯誤。 由於許多預設的行為無法深入查

微笑日偏食 上帝的微笑 心靈的微笑 | God's smile

圖片
😀                                 😀 豔陽高照的天氣 😀 天空在對你笑 😀 😀 上帝在對你笑 😀 😀 眾神在對你笑 😀 😀 你也在對你笑 😀 😀😀😀😀😀 世界真美好 😀😀😀😀😀 All rights reserved. ------------------------ 上帝的微笑/世界變美好/日偏食/奇景 百年難得/本世紀/最後一次/錯過可惜 沒有天文望遠鏡/數位相機 ------------------------

20160621 日蝕 日食 日環蝕 日偏蝕 | Solar eclipse

圖片
--- --- 今年因為新冠疫情,讓大家過的苦悶悶地。 難得最近有比較新的議題,這幾天大家都很關心並期待的話題就是 2020/6/21的日環食 。 幸運的是今年在台灣就可以看到了,最佳地點在嘉義。 臺灣前一次見到日環食,是在8年前的2012年5月21日,當時為日出帶食,觀測時間較不理想。 而下一次環食帶通過臺灣本島的日環食則要再等到195年後的2215年6月28日! 所以就把握這次的機會! 可惜的是昨天是補上班日,所以沒有動力到處亂跑,只能在家看! 雖然無法看到 100% 的是環食,相隔幾十公里遠的台南也可以看到 70% 的環食, 這次看到的是 自右下進左上出 ,也是很特別的行進方向。 也算是很不錯的天文體驗,至少有跟到本世紀的大事件。 因為沒有專用的設備,所以土炮了減光鏡,讓攝影設備不會因此壞掉。 使用的是隔熱紙重複貼上 8 層,隔熱紙是偏藍色的,所以成像結果就很科幻。 這也算是意外的收穫,下面就是一些照片欣賞拉~~~ 微笑日偏食 All rights reserved. ------------------------ 天文望遠鏡/數位相機/日蝕/上帝/指環/ 日蝕/食日/天狗/偏食/百年難得/百年奇景 錯過可惜 ------------------------