摘要:記住,帶有嚴格測試的代碼可能比沒有測試的代碼更有害。保持簡單,極度簡單不要編寫復雜的代碼。并且它將是全球代碼文檔的良好開端。使用這樣的迭代來部署質量更新,而不是腰部時間和資源對不合理的愿望和犧牲與質量。
原文地址:https://hackernoon.com/few-si...
嗨,我的工作作為一個程序員超過15年,并使用許多不同的語言,范例,框架和其他狗屎。我想和大家分享我寫好代碼的規則。
優化VS可讀性 去他媽的優化始終編??寫易于閱讀且對開發人員可理解的代碼。因為在硬可讀代碼上花費的時間和資源將遠遠高于從優化中獲得的。
如果你需要進行優化,那么使它像DI的獨立模塊,具有100%的測試覆蓋率,并且不會被觸及至少一年。
我看到很多人說“我們需要快速做事,我們沒有時間做架構”。其中約99%的人因為這樣的想法而遇到了大問題。
編寫代碼而不考慮其架構是沒有用的,就像沒有實現它們的計劃一樣,夢想你的愿望。
在編寫代碼的第一行之前,你應該明白它將要做什么,它將如何使用,模塊,服務如何相互工作,它將有什么結構,如何進行測試和調試,以及如何更新。
測試是好事,但他們并不總是負擔得起,對項目有意義。
當你需要測試:
當你編寫模塊時,微服務將不會被觸及至少一個月。
當你編寫開源代碼。
當你編寫涉及金融渠道的核心代碼或代碼。
當您有代碼更新的同時更新測試的資源。
當你不需要測試時:
當你是一個創業。
當你有小團隊和代碼更改是快速。
當你編寫的腳本,可以簡單地通過他們的輸出手動測試。
記住,帶有嚴格測試的代碼可能比沒有測試的代碼更有害。
保持簡單,極度簡單不要編寫復雜的代碼。更多更簡單,那么更少的錯誤它可能有和更少的時間來調試它們。代碼應該做的只是它需要沒有非常多的抽象和其他OOP shit(尤其是涉及java開發人員)+ 20%的東西可能需要在將來以簡單的方式更新它。
注釋出現注釋說明你的代碼不夠好。好的代碼應該是可以理解的,沒有一行注釋。但是如何為新開發人員節省時間? - 編寫簡單的內聯文檔描述什么和如何方法工作。這將節省很多時間來理解,甚至更多 - 它將給人們更多的機會來提出更好的實施這種方法。并且它將是全球代碼文檔的良好開端。
硬耦合VS較小耦合始終嘗試使用微服務架構。單片軟件可以比微服務軟件運行得更快,但只能在一個服務器的上下文中運行。
微服務使您可以不僅在許多服務器上,而且有時甚至在一臺機器上(我的意思是過程分發)高效地分發您的軟件。
代碼審查可以是好的,也以是壞的。
您可以組織代碼審查,只有當您有開發人員了解95%的代碼,誰可以監控所有更新,而不浪費很多時間。在其他情況下,這將是只是耗時,每個人都會討厭這個。
在這部分有很多問題,所以更深入地描述這一點。
許多人認為代碼審查是一個很好的方式教新手,或者工作在不同部分的代碼的隊友。但是代碼審查的主要目標是保持代碼質量,而不是教學。讓我們想象你的團隊制作代碼用于控制核反應堆或太空火箭發動機的冷卻系統。你在非常硬的邏輯中犯了巨大的錯誤,然后你給這個代碼審查新的家伙。你怎么認為會發生意外的風險? - 我的練習率超過70%。
良好的團隊是每個人都有自己的角色,負責確切的工作。如果有人想要理解另一段代碼,那么他去一個負責任去問他。你不可能知道一切,更好的優秀的理解小塊代碼而不是理解所有。
重構沒啥用在我的職業生涯中,我聽到很多次“不要擔心,我們以后會重構它”。在未來,這會導致大的技術債務或從頭開始刪除所有的代碼和寫作。
所以,不要得到一個債務,除非你有錢從頭開發你的軟件幾次。
當你累了或在一個壞的心情不要寫代碼。當開發人員厭倦時,他們正在制造2到5倍或者更多的bug。所以工作更多是非常糟糕的做法。這就是為什么越來越多的國家思考6小時工作日,其中一些已經有了。精神工作不同于使用你的二頭肌。
不要一次寫全部 - 使開發迭代在編寫代碼分析和預測之前,您的客戶/客戶真正需要什么,然后選擇您可以在短期內以高質量開發的MVF(最有價值的功能)。使用這樣的迭代來部署質量更新,而不是腰部時間和資源對不合理的愿望和犧牲與質量。
自動化VS手動自動化是長期的100%成功。所以如果你有資源自動化的東西,現在應該做。你可能認為“只需要5分鐘,為什么我應該自動化?但讓我計算這個。例如,它是5個開發人員的日常任務。 5分鐘 5天 21天* 12個月= 6 300分鐘= 105小時= 13.125天?5250 $。
如果你有40 000名員工,這將需要多少費用?
差異化工作可以增加心智能力,并提供新想法。所以,暫停現在的工作,出去呼吸一下新鮮空氣,與朋友交談,彈吉他等。
ps: 莫春者,春服既成,冠者五六人,童子六七人,浴乎沂,風乎舞雩,詠而歸。------《論語.先進》。
當人們停止學習時,他們開始退化。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/81510.html
摘要:記住,帶有嚴格測試的代碼可能比沒有測試的代碼更有害。保持簡單,極度簡單不要編寫復雜的代碼。并且它將是全球代碼文檔的良好開端。使用這樣的迭代來部署質量更新,而不是腰部時間和資源對不合理的愿望和犧牲與質量。 原文地址:https://hackernoon.com/few-si... showImg(https://segmentfault.com/img/bVJdkG?w=1000&h=2...
摘要:記住,帶有嚴格測試的代碼可能比沒有測試的代碼更有害。保持簡單,極度簡單不要編寫復雜的代碼。并且它將是全球代碼文檔的良好開端。使用這樣的迭代來部署質量更新,而不是腰部時間和資源對不合理的愿望和犧牲與質量。 原文地址:https://hackernoon.com/few-si... showImg(https://segmentfault.com/img/bVJdkG?w=1000&h=2...
摘要:記住,帶有嚴格測試的代碼可能比沒有測試的代碼更有害。保持簡單,極度簡單不要編寫復雜的代碼。并且它將是全球代碼文檔的良好開端。使用這樣的迭代來部署質量更新,而不是腰部時間和資源對不合理的愿望和犧牲與質量。 原文地址:https://hackernoon.com/few-si... showImg(https://segmentfault.com/img/bVJdkG?w=1000&h=2...
摘要:工具幫助避免在編寫時出現愚蠢的錯誤。并不檢測潛在的,比如,未使用的變量或意外的全局變量等。在提到的所有工具中,它具有最廣泛的功能支持。使用工具是捕獲問題的良好步驟,但只能看到規則允許的錯誤。也可用于此目的。 Lint工具幫助避免在編寫JavaScript時出現愚蠢的錯誤。盡管有多年的經驗,我仍然鍵入不正確的變量名稱,出現語法錯誤,以及忘記正確地處理error。在浪費自己時間,或更糟糕地...
摘要:你是如何開始參加比賽的正如之前所說的,我一直在閱讀大量機器學習和深度學習方面的書籍和論文,但發現很難將我學到的算法應用于小型數據集。機器學習中,你對哪個子領域最感興趣我對深度學習的各種進步都很感興趣。 showImg(https://segmentfault.com/img/bVboxKz?w=800&h=600); 作者 Kaggle Team中文翻譯 MikaCDA 數據分析師...
閱讀 623·2023-04-26 01:53
閱讀 2749·2021-11-17 17:00
閱讀 2880·2021-09-04 16:40
閱讀 1983·2021-09-02 15:41
閱讀 830·2019-08-26 11:34
閱讀 1222·2019-08-26 10:16
閱讀 1335·2019-08-23 17:51
閱讀 815·2019-08-23 16:50