搬家公告

現在 Gelis 新的文章會以點部落的為主，下面為新的網址：
http://www.dotblogs.com.tw/gelis/
兩處新舊文章都歡迎各位能夠多多支持。感謝各位啦 :)

留言

張貼留言

這個網誌中的熱門文章

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當...
閱讀完整內容

占空間的Google Chrome暫存檔

圖片
在一次使用CCleaner清除系統的垃圾的時候發現，怎麼Google Chrome怎麼有220M的網際網路快取資料？ 這時突然意會到，平時都只記得清除IE的Temporary Internet Files，卻忘了Google Chrome也是瀏覽器，一樣會產生暫存檔案，還有Google Earth產生的暫存檔居然更高達688M… Orz 因此突然間也非常好奇這些暫存的資料夾的路徑到底在哪裡呢？因為我們知道在Windows Vista/7 之後使用者資料已改在c:\Users 的下面，由於IE的是在"C:\Users\gelis\AppData\Local\Microsoft\Windows\Temporary Internet Files" 、所以我想應該也在這裡附近。果然讓我找到了！ Google Chrome : C:\Users\gelis\AppData\Local\Google\Chrome\User Data\Default\Cache Google Earth : C:\Users\gelis\AppData\Local\Google\GoogleEarth\models 可是突然間又發現Google Earth的資料夾居然是空的！這讓我很疑惑，明明掃出688M，究竟這些檔案是在哪裡呢？筆者的求知慾又非常強烈，每當發現問題如果不找出來是不罷休！因此常常熬夜只是為了找一個問題… 後來上Google才發現，原來我找錯位置，Google Earth的暫存資料是存在LocalLow的下面！不是Local的下面，所以路徑應該是如下： C:\Users\gelis\AppData\LocalLow\Google\GoogleEarth 而且是單一檔案"dbCache.dat"，總算解了疑惑 ^_^
閱讀完整內容

SA (System Analysis) 系統分析師 與 軟體架構師的差別？

圖片
SA (System Analysis) 與軟體架構師的差別？ 前言 這其實是先前在臉書回復其他社團的貼文，為避免當時的內容與想法被臉書淹沒，於是將其整理成文章，表示我沒有將臉書當成文章在寫。 雖然現在流行 AI 撰寫文章，但我可以證明本文章絕對不是 ChatGTP 撰寫的，內容與想法 + 圖片都是出自我的想法 與 工作相關經驗。 版篇文章以台灣軟體產業為基準，不適用於歐美國家。 SA 與 BA 角色 也有朋友提到 BA 這個角色，其實我當時所處年代 (約西元 2000 年左右)還不盛行 BA (Business Analysis) 這個角色，尤其在台灣。其實在灣大部分一人分飾多角，像我現在同時是架構師、顧問、Traniner、有時是 Developer，有時也協助制定或定義開發（流程 / 規範）等等。 我認為 BA 的角色若相較於 SA 更為狹隘點（就軟體開發來說 / 或者說目的不同），怎麼說呢？一般軟體開發還是重在最後產出『成品/Product』、但 BA 並不是，他更著重在商業、滿足的所謂的『業務成果』，這又讓我想起 POPIT 模型，有興趣可參考附件連結。 SA 系統分析師 vs. 軟體架構師 的差別？ 回歸到主題，究竟 SA 與 架構師 的差別是什麼？ 我覺得差別蠻大的，是職能與本質上的差別。 架構師的職能更廣、而 SA 通常較為狹隘（了解商業需求／有的 SA 要為使用者需求負責） 12年前我是某家 SI 公司的 SA & 2010~2014 擔任軟體架構師的感想。 我畫張簡圖，即上方的 Logo 圖，簡要說明這兩者職能上的差別，越往（左邊是更懂技術 / 右邊更趨近商業流程）：  (1). 我認為架構師更全能、甚至含括 SA 的範圍。  (2). 許多軟體公司的 SA 是不碰技術的，頂多繪製 ER-Model  (3). 甚至許多軟體公司 SA 不是技術出身 結論： 因為軟體架構師在分析系統架構時，同時得要考量商業需求，並在軟體架構中落實， 套用先前敏捷的軟體架構， 除了不做（過多 / 過度）的設計之外，還要讓系統保持高度彈性 、 要因應需求、也要因應客戶端的環境、考量 Cost 成本問題、又同時得要考量團隊的 Skill，不是一窩蜂的導入新技術，在專案中， 任何技術的使用都需要 成本 的 ，軟體...
閱讀完整內容