如果你對自己有要求 | “回顧,再出發”——記2020軟工提問回顧與個人總結

回顧,再出發

項目 內容
這個作業屬於哪個課程 2020春季計算機學院軟件工程(羅傑 任建)
這個作業的要求在哪裡 提問回顧與個人總結
我在這個課程的目標是 完成一次完整的軟件開發經歷
並以博客的方式記錄開發過程的心得
掌握團隊協作的技巧
做出一個優秀的、持久的、具有實際意義的產品
這個作業在哪個具體方面幫助我實現目標 為自己一學期的努力畫上句號
對下一個階段的展望

作業要求:

  • 鏈接到以前提問題的博客
  • 請嘗試對自己曾經提出的問題進行解答,並闡明,是如何通過看書,實踐,或者討論弄清楚的。
  • 是否原來的問題還不明白?如果有,請分析。
  • 是否產生了新的問題?如果有,請提出。
  • 軟件工程這門學問有很多 “知識點”, 這門課強調 “做中學” – 在實踐中學習知識點。
    • 請問你們在項目的 需求/設計/實現/測試/發布/維護階段(一共6 個階段)中都學到了什麼“知識點”,每個階段只要說明一個知識點即可。
  • 結合自己在個人項目/結對編程/團隊項目的經歷,談談自己的理解或心得。

​ 2020年3月3日下午16:48,在博客園發表了本學期軟件工程的第零篇博客——停下來,回頭看 ——記2020BUAA軟工第一次作業-熱身! ,1萬5千字的長文收穫了1256次閱讀和6個評論,其中ScalersTalk作者Scalers專門註冊了博客園在我的評論下方留言回復2500字,令我備受鼓舞,還有鄒欣老師和寶玉老師的建議我牢記在心,mio4學長的經驗之談也對我很大啟發。懷着對所有閱讀過我的文章和評論我的文章的人的感激,踏上了軟件工程的學習道路。

​ 2020年3月8日臨晨2點56分,發出了軟件工程這門課正式的第一篇博客——初窺構建之法——記2020BUAA軟工個人博客作業 ,這片博客中都是在閱讀完鄒欣老師的《構建之法》后,對書中存疑的地方提出的問題,並加入自己的思考和理解。這片博客收穫了594次閱讀9條評論,有其他學校的軟件工程老師,還有仰慕已久的SivilTaram學長在我的博客下留言。最令我沒有想到的是,負責鄒欣老師的《構建之法》和吳軍博士的《浪潮之巔》出版的周筠老師聯繫了我,加了我的微信,帶我走進了大神們的世界,周筠老師的群聊中有吳軍博士,有輪子哥,還有各行各業的優秀人士,看着他們在群里的討論愈發能夠感受到自己所學和認識的狹隘,除了自己的學習之外,還需要更多的與優秀的人的交流,在交流中增長自己的眼界。為了完成這篇博客,我將《構建之法》每一個章節都進行了閱讀,書中還有很多博客的鏈接我也大多點開來看,對於提出的問題也事先在網上做了充分的調查和搜尋,給出了自己的理解和嘗試性的解答。雖然一周的閱讀時間很短,但是這個過程真的十分漫長,看完《構建之法》感覺自己在理論上已經開始嘗試着從軟件工程的思維去思考問題。特別是對PM的章節,除了書之外還搜索了很多地方關於Program Manager和Product Manager的區別,並嘗試着將自己代入體驗。

​ 2020年3月10日下午18:59,發布了“深度評測官”——記2020BUAA軟工軟件案例分析作業,對候選素材中最難啃的OCR識別表單的開源工作進行了測評,做第一個吃螃蟹的人,後面總結了經驗推廣開來,陸續也出現了幾篇OCR的測評,收穫了1754次閱讀,成為了後面團隊開發時的產品介紹。在這次作業中,開始體會軟件之間的差異,開發軟件需要側重什麼,什麼樣的軟件是一款優秀的軟件。

​ 2020年03月21日,我和我的組員拼裝成了一個團隊,並給我們的團隊發布了第一篇博客——“介紹一下自己吧”——記2020BUAA軟工團隊介紹和採訪:

我們是 BUAA軟軟軟件工程小隊 ,簡稱 軟軟軟,但是大家也可以看到我們的博客的 TITLE 是 HARD_CORE_SE,指的是 “硬核的軟件工程” ,軟軟軟其實是希望我們遇到硬核的軟件工程也可以 化硬為軟,直面困難,在我們的眼裡沒有 硬核 二字,一切困難在團隊面前都是紙老虎!
雖然我們都沒有大型的工程經驗,是一直拼裝起來的軍隊,但是我們相信通過我們團隊的配合一定能夠在軟件工程這門課中發揮出色,不只是取得成績,而且能做出像樣的、能流傳的、實用的項目出來。

​ 雖然當時我們還沒有選好題目,但是我們核心的目標已經確定——做出像樣的、能流傳的、實用的項目出來。

​ 2020年4月1日,我們團隊發布了項目選擇博客——“媽媽再也不用擔心我忘交作業了!”——記2020BUAA軟工團隊項目選擇,結合本學期的疫情分析了同學們的痛點,決定開發一款幫助同學規劃提醒日程的Web應用,而我作為想出這個點子的人,對這個應用有什麼頁面,有什麼功能,能夠實現什麼最為清楚,因此成為了團隊的負責人。

​ 2020年5月5日,修復完所有的Bug、走過不知道多少次流程,我們確定首次公開發布我們的產品——DDLKiller,一款專門面向北航本科生設計的日程提醒助手,並在朋友圈,班級微信群,QQ群等小範圍內進行推廣:

​ 從後台統計數據來看,發布第一天註冊用戶達到77人,第二天達到148人,僅僅使用两天的時間就已經超額完成預期的100人,並且從反饋來看,同學們對這一款簡潔美觀、功能強大的日程管理助手非常滿意,並且积極給我們提供反饋意見,幫助我們在Beta階段做的更好。

​ 第一次發布說實話是非常忐忑的,我們熬了無數個夜晚,開了無數的視頻會議,做了無數次測試的軟件,突然開放給大家,不知道大家是喜愛,還是無感,我們當天晚上守在後台,看着註冊登錄的日誌,看着註冊的人數一個一個往上漲,一個一個開始新建事項,使用我們的功能,守到過了午夜1點仍然沒有異常,我們的心才放了下來,大家相互鼓勵,洗洗睡了。

​ 2020年6月2日,又經過一輪的迭代,我們發布了Beta版本的DDLKiller,雖然是6月2日發布,但是用戶們早已體驗過新的功能,結合很多人性化的新功能進行二次推廣,用戶量達到240人,相比Alpha階段增長90人。後來經過最後一次項目展示答辯,我們的軟件工程這門課程,結束了。

​ 但DDLKiller還沒有結束,就像我們UltraSoft – Beta – Postmortem事後分析中所說的:

BUAA – UltraSoft – 軟軟軟小組 2020春大三下學期的軟件工程, 全劇終。

但我們DDLKiller的故事還在繼續,不要走開,馬上回來

​ 我們還留了兩個功能沒有實現,我們感受到了大家對客戶端和小程序的呼聲,我們希望在自己的大學生涯中,甚至在未來的生活中,依然繼續使用這款我們親手打磨,親手建設的產品,說實在的,我們還挺不捨得的。雖然在專業人士的眼中看來這個實現非常簡單,可能一個前端大神两天就能做完的事情,一個後端大神一天就能寫完的東西,我們卻花了整整一個學期。

​ 可是,我們在這個學期裏面不是學習的如何寫前端,如何使用Vue,不是學習如何寫後端,如何使用Django,我們團隊的賬號發表了39篇博客,技術博客都是在我們的個人賬號中發表,這說明什麼,團隊博客中所記錄的,是實實在在的軟件工程。那一篇篇設計與規劃、Scurm Meeting、發布說明、測試報告、項目展示、事後分析,是DDLKiller像一個新生兒一樣,成長的記錄。

​ 我們學會了團隊成員之間如何高效合作,我們學會了如何使用Github、Gitee管理團隊項目,我們學會了使用MockPlus設計產品原型,我們學會了如何權衡需求和實際。確實專業的工程師照着我們的網站實現一個是很快,但是他可能很難做到從0到1的過程。他沒有進行痛點的分析,他不知道用戶真正需要什麼,他沒有一個需求和實際使用之間的權衡,他的開發確實了團隊協作的樂趣。

​ 說實話剛開始團隊開發的時候我還是不習慣多人協作,覺得一個人做完了事就可以省去交流的時間,後來我才發現不是我不會開發,是我不會交流。我們團隊後期自研創新的交流方式非常高效,一個石墨文檔把鍋和坑明確到人,每個人不需要問自己需要干什麼,還可以干什麼;一天十幾個小時在線的騰訊會議,有問題直接進來說,語音來的總比打字快,共享屏幕來的總比截圖直接。大家高效交流之後整個難度就下來了,只要說好了誰負責開發什麼模塊,最晚什麼時候需要驗收,還有不懂的我們共享屏幕聊,幾乎不會產生歧義或者推鍋的情況出現。作為一個PM我的體會最深:在Alpha階段的前期由於缺乏有效的溝通,PM和組員都很累,每個人都有點不清楚自己要干什麼,我知道大家要干什麼卻不能很好布置下去,每天群里的提問和回答帶來的卻只有效率的低下,我也想着自己一個人做好就算了,要那麼多人干什麼,但也發現自己越是想全部做完做好越是什麼都做不完做不好。這是一段非常難忘的經歷,是軟件工程這門課提供給我的,給了我一個在步入社會前體驗社會毒打的經歷,幸好是在課內體會到的,不至於“死”得太慘。

​ 回首望去,覺得這學期很長,也不知道是不是疫情在家的緣故,還是無窮無盡的騰訊會議的緣故,雖然只過了3個月,但是感覺自己做了很多事情一樣。3個月後再看自己的第一篇博文,確實有了些不一樣的體會。

回答自己

​ 在初窺構建之法——記2020BUAA軟工個人博客作業中,我提出了七個小問題,其實在當時已經回答的差不多了,但現在有了一定的軟件工程經驗之後,又有了一點小的看法。

問題一:是否真的沒有銀彈

​ “把重點放在質量上,生產力將隨之而來”,這是Jones的觀點。基於這個觀點我當時提出了這樣的觀點:

我之所以對銀彈是否存在持有懷疑態度是因為在大環境下,有一些本可以提高的生產力沒有提高,還有很多團隊會出現文檔與實現分離的情況,出現進度卡在某一個人負責的環節的情況,這些情況都是我們會在後續的團隊編程中可能會遇到的,所以我覺得現在就應該思考,如何在團隊中破除沒有銀彈的詛咒,提升團隊的整體水平和能力。

​ 我們團隊的生產力就有一個拐點,從一開始的效率低下到後來的慢慢摸索再到後來形成體系之後組員們心照不宣。是否真的沒有銀彈?我們組可能找到了自我協作的方式,充分將每個人的能力在其崗位上發揮,做到了效率的最大化和能力發揮的最大程度,整體生產力得到了提高,是否一定程度上找到了銀彈?

​ 其實大家都在尋找屬於自己的“銀彈”,我看到每個小組都有自己組內的成熟的管理機制和協作方法,大部分是Github的Issue和Pull Request,還有一個Github的看板,還有一些在線文檔。並沒有說Github上面使用的管理方式就比石墨文檔更有技術,我們團隊覺得上Github的速度太慢,石墨文檔就能很好的解決我們的問題,也可以定位到人,還有具體的任務細節:

Beta階段開發明顯更加得心應手一些,外加Gitee上面的清晰的Issue和Pull Requests:

無論是對內的石墨文檔還是對外的Gitee,都對我們的實際開發極大提高了生產力。

問題二:如何選擇合適的團隊模式

當時鄒欣老師給到我的回答是:

想請教老師和助教,業餘劇團模式的具體形式能夠結合助教的經歷或是老師的觀察給一個更加清晰的講述嗎?

就是大家可以選擇各種角色來扮演, 在下一個項目中,又可以有全新的分配方式。
你們就是用‘業餘’ 時間來開發的, 比較適合這樣的模式。

​ 在實際的開發中,我們確實也是業餘劇團的模式,大家先分好了大方向,前端和後端,然後分配一個模塊的任務吧,如日曆視圖、課程視圖等,如數據庫、爬蟲等,在實際的開發中,主體上不太發生改變,在細分的任務上比較靈活自由。特別是在Alpha發布之後,項目已經成型,大家已經不再限制於模塊的開發,細化到功能的開發,比如要實現一個快速創建的功能,可以在日曆中,也可以在日程列表中,兩個都進行添加。甚至前端的同學可以來優化一下後端的代碼,後端的同學學習一下前端的實現,都是“互通有無”的。

問題三:每日例會的效果如何?

在這個問題下面我當時又提出了一個問題:

敏捷開始是否是一個偽命題?

當時找到了Vczh輪子哥的回答:

敏捷不是一群開發者對着甲方的第一版需求猛做幾天,而是在做的過程中始終和甲方進行有效的、不間斷的溝通,來幫助甲方更加清晰地認清自己的需求,也幫助整個團隊確定一個當前的完成進度,也就是一個迭代中的需求分析和驗收

​ 經過兩輪的迭代和20餘次的Scrum Meeting,感受到了一些敏捷開發的意義:雖然我們沒有甲方,但是我們自己就是自己的甲方,我們不斷反省和思考着自己需要什麼功能,自己不需要什麼功能,認清自己的需求,掌握團隊的進度,不斷驗收。

​ 每日例會一開始是拒絕的,我們在Alpha階段還弄錯了例會的時間,導致缺少兩篇,覺得這些東西在Github上都有,為什麼還要記錄呢?後來其實發現每日例會重要並不在於記錄,其一在於每日隱隱地督促着每一個成員,“今晚要彙報,自己做了什麼?”;其二在例會,一個常規的,團隊的固定“節目”,有例會才像是一個成熟的團隊而不是一個個散兵,在例會中大家可以找到歸屬感,大家可以有問題在例會中大膽提出來,有什麼想法提出來大家一起實現,有什麼功能其實沒有什麼用大膽刪去,例會還是一個平台,提供給大家自由說話、表達意見和想法的平台,在例會中每個人都有說話的權利,每個人的話都能被所有人所聽見,這是我理解的每日例會的意義。至於效果,見仁見智吧,我們團隊的例會效果我還是比較滿意的,大家都有準時參与,都敢說,都是為了我們DDLKiller更好的發展去說。

問題四:為什麼除了微軟很少見到Program Manager

​ 當時我其實沒有找到這個問題合適的答案,也是遺留了下來,自己作為這個學期軟軟軟團隊的PM,無論是Product Manager也好還是Program Manager也好,談一下自己的看法。

​ 很多地方都在吐槽產品經理,說產品經理不管需求是否能夠實現,產品經理是程序員的天敵諸如此類,無非就是在說產品經理不動技術,只懂調研和分析需求。作為我們團隊的PM,我也參与了調研,我也確定了產品的需求,但我也在我的崗位——後端、部署、測試上工作,所以當我有新的需求的時候,作為一名程序員,我也會要麼憑藉自己的經驗對需求的實現難度進行預估,要麼根據已經實現了的功能對需求進行預估。比如臨時加入一個消息中心,我其實也是從前端小白到了解了一點前端的知識,我知道這個功能並不麻煩,前後接口一設置分別實現就行了,所以大膽的安排了下去這個臨時的任務,我得力的組員也很快完成了,經過我的連接和測試,一天內用我們的“業餘”時間就上線了這個功能,提供了極大的便捷。

​ 至於為什麼除了微軟很少見到Program Manager,希望我能夠親身去微軟和其他公司體驗一下吧。

問題五:對於小團隊而言小強地獄是否可行?

​ “小強地獄”聽着特別可怕,但其實在我們的實際開發中沒有太多遇到,首先是代碼總量不大,經過幾次定位就可以找到問題所在;其次是我們保證了合併進入主分支錢經過“充分”的測試,這裏的充分之所以打上引號是因為100%的充分並不存在,就像我們的同步課程中心的爬蟲核心功能,在我們團隊的幾個人的賬戶上測試都沒有出現問題,結果小範圍的內測立刻炸鍋,趕忙修復然後加大內測的範圍,在幾輪的測試都無誤之後我們才正式上線功能,這也是為什麼我們發布比較晚的原因。

​ 我們團隊也並沒有測試這個職位,大家前端和後端自己先測試自己的代碼,然後連接的時候再測試連接的代碼,不需要不參与開發的人去讀代碼,只要提供充分的測試樣例就行了。小團隊連開發都人數有些不夠,在項目的尾期設置專門進行覆蓋性測試的測試人員即可,這種開發方式在我們的項目中並沒有出現什麼大礙,所以小強地獄這種東西,只是一個提出來的權衡feature和bug的模式,每個團隊可以根據自己的實際情況進行調整。

問題六:迷思之六:技術的創新是關鍵?

​ 我們的項目有創新嗎?可以說有:我們使用郵件給用戶進行提醒,只要有網就能收到提醒;也可以說沒有,有一部分的用戶是被我們的美觀的界面吸引過來的,可能並沒有使用郵件的功能,而且其實我們的產品有類型的原型——Microsoft的ToDo。但是我們創新性地將同學們的所需以一個更好的形式呈現了出來,進行了高度集成再展現的過程,這也不失為一種創新。

​ 我們在開發的時候想過創新嗎?說實話我沒有。用戶在使用到這樣一款產品的時候會主動想到有什麼創新嗎?可能也沒有。無論是開發者還是使用者,大家都在關注一樣東西——是否解決痛點。我們可能從來沒有想過郵件提醒是一種創新,靈感來源於博客園的作業提醒,我們想的是如何解決用戶沒有在日程的DDL前被提醒的痛點,郵件只是解決這個痛點的一個可行方式罷了。

​ 我不是在否認創新的重要性,只是在說有的軟件可能目的不在於創新,也能夠贏得大家的喜愛。新鮮感固然是好東西,但是新鮮感不能持久,當新鮮感褪去,用戶是否還會對我們的產品滿意?是否會選擇其他更具有新鮮感的東西?這些是根據用戶的需求是否被解決所決定的,也是一個產品的核心部分,真正被考量的部分。

問題七:最難的問題——排座次

​ 當時提出這個問題時,還是太嫩了,其實排座次在實際執行起來是整個開發中最簡單的事情,就像鄒欣老師說的,有的人想得60分有的人想得90分,根據大家的Pull Requests和實現的功能的工作量就可以看出來。我們團隊的成員大家都非常积極,甚至主動找我領取任務,所以在最後的打分大家都差不多;其他組比如NAG2020就可以看到,其中有一名成員就是想拿60分的,兩個階段的貢獻分都是最低,代碼貢獻也是最少,自然就給了最少的分數。

​ 使用Gitee、Github等項目管理軟件之後,每個人的积極程度、活躍程度、項目的貢獻量都一目瞭然,所以排座次的問題,客觀公平公正得到了解決。

新的問題

​ 疫情之下,我們體驗到了全新的軟件工程,可能我們是唯一一屆在線上開展軟件工程這門課的學生,我們線上開會,線上協作,線上發布,線上展示。Work From Home 成了疫情中主流的工作方式。之前看到Vue的開發團隊就是分佈在世界的各個角落,線上交流和協作維護,他們已經形成了一種十分成熟的WFH的工作方式。

​ 試想,在WFH是否會成為未來的發展方向?特別是對於程序員而言,WFH其實可以在不影響開發的前提下能節省很多的時間,如通勤等等,很多大公司已經或者開始嘗試WFH,包括美國的巨頭Google、Facebook、Twitter等等,請問老師和助教覺得,本學期的WFH與之前學期的線下軟工有什麼區別,有意料之外的提高嗎?

“做中學”

需求階段

學會取捨:衝刺只有兩周,而且我們是業餘開發,所以不可能將所有的功能都實現,甚至在Alpha階段我們僅有的反饋中有一項是希望在課程列表中加入測試模塊,這個想法在Beta設計與規劃前是列入到了Todo List中的,然而在Beta設計與計劃實際的權衡中我們將其丟棄了,替換為了課程的通知,因為通知使用的更多,幾乎每門課都有,而測試只有少量的一兩門課有。

設計階段

顏值即正義:一款顏值高的產品不一定是最好的但一定是最吸引用戶的,我們的Web程序也是因高顏值吸引了不少用戶,大家對於課程中心陳舊的排版感到視覺疲勞的時候看到我們的產品會眼前一亮從而想要體驗,這是在推廣階段特別重要的一點。

實現階段

考慮可擴展性、注意代碼風格:以我負責的後端爬蟲來說,從開始時的只爬取課程作業和課程資源到迭代中加入爬取課程通知再到期末季中爬取考試日程安排,這幾樣東西應該做到合理歸類與分離,以免造成代碼太過臃腫接手的人難以及時上手。

測試階段

回歸測試和覆蓋測試的重要性:在發布新功能時,要一併考慮到舊有功能是否正常運行,我們在迭代中就遇到這樣的問題,比如在Beta階段我們支持了重複日程的提醒,向日程中加入了字段 repeat,然而我們只測試了常規的添加日程,沒有考慮下方的快速添加日程和模板添加日程,導致發布之後出現內部錯誤,檢查日誌才發現錯誤所在然後緊急修復。如果每個新功能在發布的時候都能夠有回歸測試則可以避免這一問題。

發布階段

漸進式發布:當一個應用的新功能準備發布的時候,會進行一些測試,比如灰度測試,即選取一小部分用戶可以體驗到該功能,其他用戶維持原來的功能不變,以查看新功能的運行效果和用戶反饋意見,在我們的開發中,我們有多台主機可以進行訪問,所以會先使用其他主機的ip訪問使用“內測版本”的DDLKiller,然後過一段時間再發布。在Alpha的正式發布前我們也做了小範圍的內測,讓一些自己的舍友和朋友先使用,看看有沒有問題,還有么改進的地方,確實內測找出了一些問題,幫助我們在正式發布的時候減少很多事情。

維護階段

文檔文檔文檔:經驗教訓是有心東西一定要以文字的形式在文檔中呈現,首先是提高了團隊內部的溝通效率,大家不用反覆詢問可以直接查閱文檔,其次是積少成多,為後面接手的同學做充足的準備。特別是前後端分離的團隊開發,只要文檔維護得好,直接事半功倍,反之事倍功半。

理解、心得

​ 個人項目->結對項目->團隊項目,是一個課程組有意設計的一個遞進的關係,在這一點上我覺得羅老師和任老師班級的軟工做的最好,相比於歐陽老師班級的個人項目直接到團隊項目,我們中間有一個過渡期,很多人其實在過渡期的時候就知道自己想要干什麼了,大致可以分為前端和後端了,這樣一來在團隊中的項目分工也簡便了很多。

​ 在個人項目中,我們實現了一個求交點的程序,沒有頁面显示,只有命令行的交互;在結對項目中,我們加大了求解交點的難度,同時用圖形化的界面將交點的位置呈現在了眼前;在兩個衝刺,前後兩個月的團隊項目中,我們分工更加細緻,實現了一個軟件。一步步走來,感覺越來越難了,但是也越來越簡單了。難在項目確實更大,從技術上來說難度確實增大了;簡單在我們不是一個人在戰鬥了,我們身邊從沒有人到一個人再到一群人,集體的力量是不容小覷的,每個人都有自己擅長的部分,這一點感觸特別深。在團隊中,一個人花了很久不能解決的事情,丟出來大家都积極主動伸出援手,一起將困難啃下來;在這個學期學習是在很累的時候,也是我們團隊的成員陪伴着我,在此感謝陪我熬夜最多的Kkkk,有時候大家就算不需要說話,只要會議室裏面有人,心靈就能得到慰藉——“我背後還有一個團隊”。

​ 在團隊項目中,我既是PM又是後端開發,還負責部署,這個工作可能比有的團隊PM只負責文書麻煩一些,但也暴露出來了一人多職的缺點。由於Alpha階段對時間的理解錯誤外加新項目開發難度大,導致Scrum Meeting有一兩次開會了但是沒有及時記錄導致會議紀要缺失的情況,還有就是寫完代碼之後沒時間寫文字了於是產生拖延,這一部分應該專人來記錄會好一些。在團隊項目階段確實學習到了很多新知識,無論是Django開發還是NGINX部署,都需要啃官方文檔,特別是NGINX和Uwsgi的兩個官方文檔還有不清楚的地方需要自己解決,在五一的五天假期連肝五天才總算把前後端連接和服務器部署徹底啃下來,終於在五一假期的尾聲進行小面積的推廣。這也讓我對網絡與系統這一方面產生了興趣,在暑假期間我會嘗試涉獵一些分佈式和網絡編程相關的內容,如果感興趣的話希望有機會往這方面發展下去。若是因軟件工程這門課能夠找到我自己的真實興趣所在,也是太值得了。

​ 作為PM,特別感謝我的軟軟軟團隊的隊友們,包括Alpha階段結束之後轉走的Dz,一樣非常感謝。是你們一起幫助我完成了我的一個想法,讓他不再是一個想法,成為了一個真正能夠使用,大家都可以使用,甚至受到好評的一款軟件。其實DDLKiller是我實在找不到一款可以提醒我日程的軟件下的“被迫選擇”,想要一款DDLKiller這個念頭在我剛開學的時候就有了,當時和舍友嘗試了Tower協作也不好用,嘗試了Microsoft的Todo也不好用,自己又開發不了,但是居然在團隊開發中被我們做出來了,和我預想的完全一致,甚至某些功能超出預期。是你們讓我第一次體會到想法到實現的喜悅,第一次切身體會到代碼的魅力,第一次感受到團隊的強大,體會到1+1+1+1+1+1+1>7。DDLKiller就是我的軟軟軟團隊的孩子,離不開每一個人的付出。

​ 我們在第一篇自我介紹中說到:

雖然我們都沒有大型的工程經驗,是一直拼裝起來的軍隊,但是我們相信通過我們團隊的配合一定能夠在軟件工程這門課中發揮出色,不只是取得成績,而且能做出像樣的、能流傳的、實用的項目出來。

​ 至少在我自己看來,我們已經成功了。

最後想說的

​ 大概的都說的七七八八了,若是要用幾個詞語總結這學期的軟件工程課程的話:

魔幻、刺激、充實、欣慰

​ 在每次的個人作業前面老師都讓我們寫下這門課程的目標,我寫的是:

完成一次完整的軟件開發經歷
並以博客的方式記錄開發過程的心得
掌握團隊協作的技巧
做出一個優秀的、持久的、具有實際意義的產品

​ 現在看來,我都已經做到了:

  • 一次完整的軟件開發經歷:從使用MockPlus畫出草圖,到真正用網址就能訪問

  • 博客團隊的開發:39篇團隊博客就在BUAA軟軟軟件工程小隊中

  • 團隊協作的技巧:我們甚至自研了石墨文檔+騰訊會議的創新性協作方式

  • 優秀的、持久的、具有實際意義的產品:DDLKiller——懂你的日程管家

    從UltraSoft – Beta – Postmortem事後分析中摘取一段話出來:

如果下一年有學弟學妹問我:軟件工程哪個老師的課好?

我會如實回答:如果你對自己有要求,如果你想這個學期不碌碌無為,如果你想學期結束收穫滿滿,如果你想逼自己一把,選擇羅傑、任健老師的班級吧。過程會很痛苦,你會看到別人都在玩的時候你在寫博客,你會看到別人開發的時候你在寫博客,你會看到別人只開發一次就結束的時候你在寫博客,你在開例會,你在Beta階段開發,但是當你的博客得到了老師的認可,得到了助教的讚賞,得到了《構建之法》作者鄒欣老師的點評,得到了輪子哥Vczh對你的提問的親自回復,得到了《持續行動》《刻意學習》作者Scalers為你特地開賬號的留言,你會感覺,這一切都值了。

​ 慶幸當初的自己沒有聽到負面的評論就退縮,堅持選擇了羅老師和任老師的班級,做出了像樣的東西。我確實心裏吐槽過博客,用心寫真的很累,每次博客能花上3~5個小時,每次都是動輒上萬字,但是確實寫完之後獲得了有意義的評論和建議心裏特別舒服,讓我受寵若驚的是第一次的Scalers為我註冊博客園賬號留言7500字,讓我感覺到自己的博客沒有白費。自己也是北航面向對象課程的助教,也能夠一定程度上理解老師和助教的良苦用心,很多東西學生在做的時候是會不理解甚至罵出聲的,但是做完之後又是另一種感受了,老師和助教只能委屈成為暫時的惡人,逼着同學去思考,逼着去寫下文字,逼着做看不到短期利益的事情,等待着一切都結束時候的理解。

​ 軟件工程這門課雖然結束了,但我們的軟件開發依然在繼續,回顧,為的是更好的出發。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

聚甘新

Python 為什麼推薦蛇形命名法?

關於變量的命名,這又是一個容易引發程序員論戰的話題。如何命名才能更具有可讀性、易寫性與明義性呢?眾說紛紜。

本期“Python為什麼”欄目,我們將聚焦於變量命名中的連接方式,來切入這塊是非之地,想要回答的問題是——Python 為什麼要推薦蛇形命名法?

首先一點,對於單個字符或者單詞 (例如:a、A、PYTHON、Cat),當它們被用作變量名時,大致有全小寫、全大寫和首字母大寫這幾種情況。編程語言中出現這些情況時,它們基本上跟英語的表達習慣是相同的。

但是,編程語言為了令變量名表達出更豐富的含義,通常需要使用多個單詞或符號。 英語習慣使用空格來間隔開單詞,然而這種用法在編程語言中會帶來一些麻煩,所以程序員們就創造出了另外的方法:

  • 蛇形命名法(snake case)
  • 駝峰命名法(camel case)
  • 匈牙利命名法(HN case)
  • 帕斯卡命名法(Pascal case)
  • 脊柱命名法(spinal case)
  • 自由命名法(studly caps)
  • 駝峰蛇形命名法

總體而言,這些命名法都是要克服單詞間的空格,從而把不同單詞串連起來, 最終達到創造出一種新的“單詞”的效果。

我畫了一張思維導圖,大略區分了這幾種命名法:

如果按照受眾量與知名程度排名,毫無疑問排前兩位的是駝峰命名法和蛇形命名法。

我們可以簡單比較一下它們的優缺點:

  • 可讀性:蛇形命名法用下劃線拉大詞距,更清楚易讀;駝峰命名法的變量名緊湊,節省行寬
  • 易寫性:駝峰命名法以大小寫為區分,不引入額外的標識符;蛇形命名法統一小寫,輸入相對方便
  • 明義性:對於某些縮寫成的專有名詞,例如 HTTP、RGB、DNS等等,一般習慣全用大寫表示,但是如果嚴格遵循這兩種命名法的話,須得只留首字母大寫或者全小寫,這樣對原意都會造成一些“破壞”,有時候甚至讓人感覺到彆扭。如果保留全大寫,IDE 可能識別不準,反而會出現波浪提示

由此可見,它們各有優缺點,但哪一方都不具有壓倒性。我個人稍微偏好於蛇形命名法,但是在需要用駝峰命名的時候(比如寫 Java 時),也能無障礙切換。

需要指出的是,Python 也推薦使用駝峰式命名,那是在類名、Type 變量、異常 exception 名這些情況。而在包名、模塊名、方法名和普通變量名 等情況,則是推薦用蛇形命名(lower_case_with_underscores)。

那麼,為什麼 Python 會推薦用蛇形命名法呢?

最大的原因是歷史原因。 蛇形命名方式起源於 1960 年代,那時它甚至還沒有特定的名稱。Python 從 C 語言中借鑒過來后,給它起名為“lower_case_with_underscores”,即帶下劃線的小寫命名。

直到 21 世紀初的幾年,在 Intel 和 Ruby 社區中,才有人開始以“snake_case”即蛇形命名來稱呼它。

現今有不少編程語言在某些場景下會推薦使用蛇形命名法,而 Python 則是其中最早這麼做的之一,並且是使用場景最多的語言之一。

維基百科上統計了一份清單,可以看出 Python 對它的偏好:

其次,還有一個比較重要的原因,那就是 Python 對下劃線“_”的獨特偏愛。

比如類似於 _xx、__xx、xx_、__xx__ 等等的寫法就隨處可見,甚至還有孤零零一個下劃線 _ 作為變量的特殊情況。這樣看來,下劃線作為單詞間的連接,恰恰是這種傳統習慣的一部分。

最後,我還看到過一種解釋:因為 Python 是蟒蛇啊,理所當然是用蛇形命名……

對於這三個解釋,你們是如何感想的呢?對於蛇形命名法,大家是喜歡還是不喜歡呢?歡迎留言交流。

寫在最後:本文屬於“Python為什麼”系列(Python貓出品),該系列主要關注 Python 的語法、設計和發展等話題,以一個個“為什麼”式的問題為切入點,試着展現 Python 的迷人魅力。部分話題會推出視頻版,請在 B 站收看,觀看地址:視頻地址

公眾號【Python貓】, 本號連載優質的系列文章,有Python為什麼系列、喵星哲學貓系列、Python進階系列、好書推薦系列、技術寫作、優質英文推薦與翻譯等等,歡迎關注哦。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司“嚨底家”!

※推薦評價好的iphone維修中心

聚甘新

ZooKeeper使用入門

ZooKeeper簡介

ZooKeeper是一個分佈式的,開源的分佈式應用程序協調服務,是Hadoop的子項目之一。它是一個為分佈式應用提供一致性服務的軟件,提供的功能包括:配置維護、域名服務、分佈式同步、組服務等。

安裝ZooKeeper

操作系統要求

操作系統 客戶端 服務端 原生客戶端 附加組件
GNU/Linux 開發/生產 開發/生產 開發/生產 開發/生產
Solaris 開發/生產 開發/生產 不支持 不支持
FreeBSD 開發/生產 開發/生產 不支持 不支持
Windows 開發/生產 開發/生產 不支持 不支持
Mac OS X 開發 開發 不支持 不支持

軟件要求

Java 8及Java 11以上版本(Java 9和10不支持)

硬件要求

此硬件資源為官網推薦的配置,實際開發過程中不需要這麼大,筆者測試1核1G內存20G硬盤的虛擬機即可運行。

  • 2核
  • 2G內存
  • 80G硬盤

下載安裝並進行單點配置

  1. 下載頁面地址:https://zookeeper.apache.org/releases.html
  2. 官網只提供tar.gz格式的壓縮包,windows下載后按照zip之類的解壓方式可能會導致解壓后的包無法使用,筆者使用Git帶的命令行執行linux的解壓命令解壓后使用,如果沒有安裝Git則建議使用虛擬機安裝Linux使用。以下是正確解壓和錯誤解壓后的對比。

  1. 解壓后的ZooKeeper默認是無法執行的,需要進行配置,將 apache-zookeeper-3.6.1/conf/zoo_sample.cfg複製一份並重命名為zoo.cfg,沒什麼特殊需要裡邊的配置項默認即可,筆者因為是在windows下使用,所以將datadir修改了。配置文件項說明如下:
配置項 說明
tickTime ZooKeeper使用的時間,單位毫秒,一般用於心跳檢測,而ZooKeeper中的最小session超時時間是此項的兩倍
dataDir 保留內存數據庫快照的地址,如果不單獨指定,事務日誌也會記錄在此
clientPort 服務端監聽的端口號
initLimit 集群中的follower服務器與leader服務器之間初始連接時的最大心跳數
syncLimit 集群中follower服務器與leader服務器之間通訊時的最大心跳數
  1. 配置完成后即可在bin目錄下執行對應的文件啟動了,Windows下為zkServer.bat,Linux下為zkServer.sh

ZooKeeper應用

通過zkCli進行使用

  1. ZooKeeper啟動后,可以通過bin目錄下自帶的客戶端進行訪問,Windows下為zkCli.bat,Linux下為zkCli.sh
  2. 啟動時默認連接localhost:2181,如果有需要連接遠程或其他端口的情況,可以如下添加參數:
zkCli.sh -server IP:Port
  1. 進入客戶端后執行help(此處是一個隨意的指令,只要不是zkCli支持的操作都可以)可查看其支持的操作,關於所有操作的介紹請參考官方頁面:https://zookeeper.apache.org/doc/current/zookeeperCLI.html

  2. 常用操作介紹:

  • 查看節點信息,節點路徑不能以“/”結尾
ls /
ls /zookeeper
  • 創建一個節點
create /test
create /test/testa
  • 查看節點狀態
stat /test
stat /test/testa
  • 刪除節點
# 刪除單個空節點
delete /test/testa
delete /test

# 級聯刪除
deleteall /test

*退出客戶端

quit

通過ZooKeeper客戶端使用

因為筆者的第一開發語言是Java,這裏以Java為例。常用的ZooKeeper Java客戶端用zkclient和Apache Curator兩種。zkclient是github上的一個開源項目,該項目在2018年10月2日後停止更新;Apache Curator是Apache基金會的開源項目,目前持續更新,推薦使用。常用的分佈式RPC框架DUBBO也在2019年1月份推出的2.7.0版本中將默認的ZooKeeper客戶端由zkclient切換為Apache Curator,此文中的示例也使用Apache Curator。

  1. 創建一個Maven項目,然後在pom.xml中引用Apache Curator,以下是筆者的文件內容,除了Apache Curator外添加了測試使用的junit並設置了編譯使用的java版本。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>apache-curator</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <!-- https://mvnrepository.com/artifact/org.apache.curator/curator-recipes -->
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>4.3.0</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>5.6.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>
  1. 之後在src\test\java\目錄創建com\aotian\curator\test\Tester.java,文件基本框架如下,主要是創建一個空的測試類
public class Tester {

    @Test
    public void testCurator() {
      
    }

}
  1. 接下來就是使用Apache Curator提供的API對ZooKeeper進行訪問了。首先介紹下常用的API
  • 創建客戶端
RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
CuratorFramework curatorFramework = CuratorFrameworkFactory.newClient("localhost:2181", retryPolicy);
curatorFramework.start();
  • 檢查節點是否存在,存在的話返回Stat對象,不存在則返回null
curatorFramework.checkExists().forPath("/localhost/aotian");
  • 創建節點,forPath第二個參數可以指定節點內容,不設置時創建空節點
curatorFramework.create().creatingParentContainersIfNeeded().forPath("/localhost/aotian", message.getBytes());
  • 設置節點內容,僅適用於已存在的節點,否則會報錯
curatorFramework.setData().forPath("/localhost/aotian", message.getBytes());
  • 獲取節點信息,以下代碼錶示將獲取的節點信息保存到result對象。
Stat result = new Stat();
curatorFramework.getData().storingStatIn(result).forPath("/localhost/aotian");
  • 獲取節點內容
byte[] results = curatorFramework.getData().forPath("/localhost/aotian");
  1. 完整示例如下,結尾添加了線程睡眠的代碼,可以在睡眠時間內通過zkCli查看服務端中的內容。
    @Test
    public void testCurator() {
        // 創建客戶端
        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        CuratorFramework curatorFramework = CuratorFrameworkFactory.newClient("localhost:2181", retryPolicy);
        curatorFramework.start();
        // 定義節點內容
        String message = "testCurator";
        try {
            // 判斷節點是否存在不存在則創建,存在則設置指定值
            Stat a = curatorFramework.checkExists().forPath("/localhost/aotian");
            if (a == null){
                curatorFramework.create()
                        .creatingParentContainersIfNeeded()
                        .forPath("/localhost/aotian", message.getBytes());
            }else{
                curatorFramework.setData().forPath("/localhost/aotian", message.getBytes());
            }

            // 獲取節點信息
            Stat result = new Stat();
            curatorFramework.getData().storingStatIn(result).forPath("/localhost/aotian");
            System.out.println(result.getCtime());

            // 獲取節點內容
            byte[] results = curatorFramework.getData().forPath("/localhost/aoitan");
            System.out.println(new String(results));

            // 線程睡10S,這段時間內可以通過客戶端查看節點內的信息,結束后只能查看到空節點
            Thread.sleep(100000);
        } catch (Exception e) {
            e.printStackTrace();
        }finally {
            curatorFramework.close();
        }
    }

ZooKeeper集群搭建

ZooKeeper集群中包含兩種角色:Leader和Follower,因為ZooKeeper集群是半數節以上節點正常時才會正常提供服務,所以一般ZooKeeper集群中節點數量均為奇數。我們按照最小數量算,準備三台zookeeper服務器。

  1. 分別按照本文一開始的單機配置配置好三個ZooKeeper服務。個人聯繫或可以在同一台機器上部署三個ZooKeeper,只要解決端口衝突問題即可,實際生產過程中務必使用三台機器進行搭建,否則一旦機器出問題則整個集群癱瘓。
  2. 準備好三台ZooKeeper服務器之後我們準備開始集群的配置,首先我們需要規劃好ZooKeeper的ID,然後在datadir屬性對應的目錄下創建一個myid文件。然後在文件內寫上當前服務對應的ID,筆者規劃的是0、1、2,所以我需要添加的配置文件如下:
IP地址 文件路徑 文件內容
192.168.142.7 /tmp/zookeeper/myid 0
192.168.142.8 /tmp/zookeeper/myid 1
192.168.142.9 /tmp/zookeeper/myid 2

datadir屬性默認在/tmp目錄下,此目錄會被定期清理掉,生產環境不要使用。

3、配置完以上文件后,需要配置之前的zoo.cfg,在最後添加以下內容,其中server.*對應myid文件中的ID號,192.168.142.7是IP地址,2888是ZooKeeper集群的通訊端口,3888是集群選取Leader使用的端口。

server.0=192.168.142.7:2888:3888
server.1=192.168.142.8:2888:3888
server.2=192.168.142.9:2888:3888

4、最後檢查防火牆是否開放了2181、2888、3888端口,確認開放后啟動ZooKeeper即可。通過執行zkServer.sh status命令可以查看當前機器的狀態。

[root@centos-server-01 bin]# ./zkServer.sh status
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: /usr/apache-zookeeper-3.6.0/bin/../conf/zoo.cfg
Client port found: 2181. Client address: localhost.
Mode: follower

[root@centos-server-02 bin]# ./zkServer.sh status
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: /usr/apache-zookeeper-3.6.0/bin/../conf/zoo.cfg
Client port found: 2181. Client address: localhost.
Mode: leader

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨,RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準

聚甘新

【譯】Announcing Entity Framework Core 5.0 Preview 5

  今天我們宣布EF Core 5.0發布第五個預覽版。

1 先決條件

  EF Core 5.0 的預覽版要求  .NET Standard 2.1。這意味着:

      • EF Core 5.0 在 .NET Core 3.1 上運行,不需要 .NET 5。根據 .NET 5 計劃的改變,這可能會在未來發生變化。

      • EF Core 5.0 運行在其他支持 .NET Standard 2.1 的平台上。

      • EF Core 5.0 將不會在 .NET Standard 2.0 平台上運行,包括 .NET Framework。

2 如何獲取EF Core 5.0預覽版

  使用NuGet添加,例如添加SQL Server的提供程序:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 5.0.0-preview.5.20278.2

  目前發布的 EF Core包包括:

      • Microsoft.EntityFrameworkCore – 主程序

      • Microsoft.EntityFrameworkCore.SqlServer – SQL Server與SQL Azure提供者

      • Microsoft.EntityFrameworkCore.Sqlite – SQLite提供者

      • Microsoft.EntityFrameworkCore.Cosmos – Azure Cosmos DB提供者

      • Microsoft.EntityFrameworkCore.InMemory – 內存數據庫提供者

      • Microsoft.EntityFrameworkCore.Tools –Visual Studio Package Manager Console的 EF Core PowerShell命令

      • Microsoft.EntityFrameworkCore.Design – EF Core的設計時組件

      • Microsoft.EntityFrameworkCore.SqlServer.NetTopologySuite – SQL Server 空間類型支持

      • Microsoft.EntityFrameworkCore.Sqlite.NetTopologySuite – SQLite空間類型支持

      • Microsoft.EntityFrameworkCore.Proxies –延遲加載與變化跟蹤代理

      • Microsoft.EntityFrameworkCore.Abstractions – 分離的EF Core抽象

      • Microsoft.EntityFrameworkCore.Relational – 關係數據庫提供程序的共享EF Core組件

      • Microsoft.EntityFrameworkCore.Analyzers – EF Core的C#分析器

      • Microsoft.EntityFrameworkCore.Sqlite.Core – SQLite提供者(沒有打包的本機二進制文件)

  我們還發布了Microsoft.Data.Sqlite.Core ADO.NET provider的預覽版。

3 安裝dotnet ef

  與EF Core 3.0和3.1一樣,dotnet EF命令行工具不再包含在.NET Core SDK中。在執行EF Core的migration或scaffolding命令之前,必須將此包作為全局或本地工具安裝。

  若要全局安裝預覽版工具,需要先使用以下命令卸載現有的版本:

dotnet tool uninstall --global dotnet-ef

  然後,進行安裝:

dotnet tool install --global dotnet-ef --version 5.0.0-preview.5.20278.2

  可以將此新版本的dotnet ef與使用較舊版本的EF Core運行時的項目一起使用。

4 EF Core 5.0預覽版的一些新功能

4.1 數據庫排序規則

  現在可以在 EF Model中指定數據庫的默認排序規則。

modelBuilder.UseCollation("German_PhoneBook_CI_AS");

  然後,Migrations將生成以下內容以在 SQL Server 上創建數據庫:

CREATE DATABASE [Test]
COLLATE German_PhoneBook_CI_AS;

  也可以指定用於特定數據庫列的排序規則。

  例如:

modelBuilder
     .Entity<User>()
     .Property(e => e.Name)
     .UseCollation("German_PhoneBook_CI_AS");

  為了那些不使用migration的人,現在,在 DbContext scaffolding時,將從數據庫進行反向工程。最後,EF.Functions.Collate() 允許使用不同的排序規則進行臨時查詢。

  例如:

context.Users.Single(e => EF.Functions.Collate(e.Name, "French_CI_AS") == "Jean-Michel Jarre");

  這將生成 SQL Server 的以下查詢:

SELECT TOP(2) [u].[Id], [u].[Name]
FROM [Users] AS [u]
WHERE [u].[Name] COLLATE French_CI_AS = N'Jean-Michel Jarre'

  請注意,臨時排序規則應謹慎使用,因為它們會對數據庫性能產生負面影響。

4.2 傳遞參數給IDesignTimeDbContextFactory

  參數現在從命令行傳入IDesignTimeDbContextFactory 的 CreateDbContext 方法。

  例如,為了指示這是開發構建,可以在命令行上傳遞自定義參數(例如 dev):

dotnet ef migrations add two --verbose --dev

  然後,此參數將傳遞到工廠:

public class MyDbContextFactory : IDesignTimeDbContextFactory<SomeDbContext>
{
    public SomeDbContext CreateDbContext(string[] args)
        => new SomeDbContext(args.Contains("--dev"));
}

4.3 具有標識解析的無跟蹤查詢

  現在,可以將無跟蹤查詢配置為執行標識解析。

  例如,以下查詢將為每個Post創建新的Blog實例,即使每個Blog具有相同的主鍵也是如此。

context.Posts.AsNoTracking().Include(e => e.Blog).ToList();

  但是,可以更改此查詢以確保只創建單個 Blog 實例,但代價通常是稍微慢一點,並且使用更多內存:

context.Posts.AsNoTracking().PerformIdentityResolution().Include(e => e.Blog).ToList();

  請注意,這僅適用於無跟蹤查詢,因為所有跟蹤查詢都已表現出此行為。

4.4 持久化計算列

  大多數數據庫允許在計算后存儲計算列的值。

  雖然這佔用磁盤空間,但計算列在更新時只計算一次,而不是在每次檢索其值時計算。

  這還允許對某些數據庫的列設置索引。

  EF Core 5.0 允許將計算列配置為存儲列。

  例如:

modelBuilder
    .Entity<User>()
    .Property(e => e.SomethingComputed)
    .HasComputedColumnSql("my sql", stored: true);

4.5 SQLite計算列

  EF Core 現在支持 SQLite 數據庫的計算列。

5 有用的短鏈接

  提供了以下短鏈接,便於參考和訪問。

      • 主要文檔:https://aka.ms/efdocs
      • EF Core 的問題和功能請求:https://aka.ms/efcorefeedback
      • EF路線圖:https://aka.ms/efroadmap
      • EF Core 5.x 中的新增功能是什麼:https://aka.ms/efcore5

原文鏈接

  https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-5-0-preview-5/?utm_source=vs_developer_news&utm_medium=referral

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

聚甘新

圖解MySQL索引(三)—如何正確使用索引?

MySQL使用了B+Tree作為底層數據結構,能夠實現快速高效的數據查詢功能。工作中可怕的是沒有建立索引,比這更可怕的是建好了索引又沒有使用到。
本文將圍繞着如何優雅的使用索引,圖文並茂地和大家一起探討索引的正確打開姿勢,不談底層原理,只求工作實戰。

1. 索引的特點

page之間是雙鏈表形式,而每個page內部的數據則是單鏈表形式存在。當進行數據查詢時,會限定位到具體的page,然後在page中通過二分查找具體的記錄。

並且索引的順序不同,數據的存儲順序則也不同。所以在開發過程中,一定要注意索引字段的先後順序。

最左匹配原則

當一個索引中包含多個字段時,可以稱之為組合索引。MySQL中有個很重要的規則,即最左匹配原則用來定義組合索引的命中規則,它是指在檢索數據時從聯合索引的最左邊開始匹配。假設對用戶表建立一個聯合索引(a,b,c),那麼條件a,(a,b),(a,b,c)都會用到索引。

在匹配過程中會優先根據最左前面的字段a進行匹配,然後再判斷是否用到了索引字段b,直到無法找到對應的索引字段,或者對應的索引被”破壞“(下文中會介紹)。

以下是本文中操作實踐用到的初始化語句,有條件的同學可以再本地執行,建議使用MySQL5.6+版本,畢竟實操才是學習的最佳途徑。

SET NAMES utf8mb4;
-- ----------------------------
-- Table structure for test_table
-- ----------------------------
DROP TABLE IF EXISTS `test_table`;
CREATE TABLE `test_table` (
  `id` bigint(20unsigned NOT NULL AUTO_INCREMENT,
  `a` varchar(255COLLATE utf8mb4_bin NOT NULL,
  `b` varchar(255COLLATE utf8mb4_bin NOT NULL,
  `c` varchar(255COLLATE utf8mb4_bin NOT NULL,
  `d` varchar(255COLLATE utf8mb4_bin NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_a_b_c` (`a`,`b`,`c`)
ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- ----------------------------
-- Records of test_table
-- ----------------------------
BEGIN;
INSERT INTO `test_table` VALUES 
(1'zhangsan''12222222222''23''aafasd'),
(2'lisi''13333333333''21''cxvcxv'),
(3'wanger''14444444444''24''dfdf'),
(4'liqiang''18888888888''18''ccsdf');
COMMIT;

2. 正確創建索引

盡量使用自增長主鍵

使用自增長主鍵的原因筆者認為有兩個。首先能有效減少頁分裂,MySQL中數據是以頁為單位存儲的且每個頁的大小是固定的(默認16kb),如果一個數據頁的數據滿了,則需要分成兩個頁來存儲,這個過程就叫做頁分裂。

如果使用了自增主鍵的話,新插入的數據都會盡量的往一個數據頁中寫,寫滿了之後再申請一個新的數據頁寫即可(大多數情況下不需要分裂,除非父節點的容量也滿了)。

自增主鍵

非自增主鍵

其次,對於緩存友好。系統分配給MySQL的內存有限,對於數據量比較多的數據庫來說,通常只有一小部分數據在內存中,而大多數數據都在磁盤中。如果使用無序的主鍵,則會造成隨機的磁盤IO,影響系統性能。

選擇性高的列優先

關注索引的選擇性。索引的選擇性,也可稱為數據的熵。在創建索引的時候通常要求將選擇性高的列放在最前面,對於選擇性不高的列甚至可以不創建索引。如果選擇性不高,極端性情況下可能會掃描全部或者大多數索引,然後再回表,這個過程可能不如直接走主鍵索引性能高。

索引列的選擇往往需要根據具體的業務場景來選擇,但是需要注意的是索引的區分度越高則價值就越高,意味着對於檢索的性價比就高。索引的區分度等於count(distinct 具體的列) / count(*),表示字段不重複的比例。

唯一鍵的區分度是1,而對於一些狀態值,性別等字段區分度往往比較低,在數據量比較大的情況下,甚至有無限接近0。假設一張表中用data_status來表示數據的狀態,1-有效,2-刪除,則數據的區分度為 1/500000。如果100萬條數據中只有1條被刪除,並且在查詢數據時查找data_status = 0 的數據時,需要進行全表掃描。由於索引也是需要佔用內存的,所以在內存較為有限的環境下,區分度不高的索引幾乎沒有意義。

聯合索引優先於多列獨立索引

聯合索引優先於多列獨立索引, 假設有三個字段a,b,c, 索引(a)(a,b),(a,b,c)可以使用(a,b,c)代替。MySQL中的索引並不是越多越好,各個公司的規定中往往會限制單表中的索引的個數。原因在於,索引本身也會佔用一定的空間,並且維護一個索引時有一定的代碼的,所以在滿足需求的情況下一定要盡可能創建更少的索引。

執行語句:

explain select * from test_table where a = "zhangsan";
explain select * from test_table where a = "zhangsan" and b = "188466668888";
explain select * from test_table where a = "zhangsan" and b = "188466668888" and c = "23";

執行結果分析:

實際上建立(a, b, c)聯合索引時,其作用相當於(a), (a, b), (a, b, c) 三個索引。所以以上三種查詢方式均會命中索引。

覆蓋索引避免回表

覆蓋索引如果執行的語句是 select ID from T where k between 3 and 5,這時只需要查 ID 的值,而 ID 的值已經在 k 索引樹上了,因此可以直接提供查詢結果,不需要回表。也就是說,在這個查詢裏面,索引 k 已經“覆蓋了”我們的查詢需求,我們稱為覆蓋索引。由於覆蓋索引可以減少樹的搜索次數,顯著提升查詢性能,所以使用覆蓋索引是一個常用的性能優化手段。

覆蓋索引的查詢優化

覆蓋索引同時還會影響索引的選擇,對於(a,b,c)索引來說,理論上來說不滿足最左匹配原則,但是實際上也會走索引。原因在於,優化器認為(a,b,c)索引的性能會高於全表掃描,實際情況也是這樣的,感興趣的小夥伴不妨分析一下上文中介紹的數據結構。

explain select a,b,c from test_table where b = "188466668888" and c = "23";

執行結果:

滿足查詢和排序

索引要滿足查詢和排序。大部分同學在創建索引時,通常第一反應是查詢條件來選擇索引列,需要注意的是查詢和排序同樣重要,我們建立的索引要同時滿足查詢和排序的需求.

包含要排序的列

select c, d from test_table  where a = 1 and b = 2 order by c;

雖然查詢條件只使用了a,b兩個字段,但是由於排序用到了c字段,我們能可以建立(a,b,c)聯合索引來進行優化。

保證索引字段順序

如上文中的介紹,索引的字段順序決定了索引數據的組織順序。要想更高性能的檢索數據,一定要盡可能的藉助底層數據結構的特點來進行。如,索引(a, b)的默認組織形式就是先根據a排序,在a相同的情況下再根據b排序。

考慮索引的大小

內存中的空間十分寶貴,而索引往往又需要在內存中。為了在有限的內存中存儲更多的索引,在設計索引時往往要考慮索引的大小。比如我們常用的郵箱,xxxx@xx.com, 假設都是abc公司的,則郵箱後綴完全一致為@abc.com, 索引的區分度完全取決於@前面的字符串。

針對上述情況,MySQL 是支持前綴索引的,也就是說,你可以定義字符串的一部分作為索引。默認地,如果你創建索引的語句不指定前綴長度,那麼索引就會包含整個字符串。

如果使用的 email 整個字符串的索引結構執行順序是這樣的:從 index1 索引樹找到滿足索引值是’liqiang156@11.com’的這條記錄,取得 id (主鍵)的值ID2;到主鍵上查到主鍵值是ID2的行,將這行記錄加入結果集;

取 email 索引樹上剛剛查到的位置的下一條記錄,發現已經不滿足 email=’liqiang156@qq.com’的條件了,循環結束。這個過程中,只需要回主鍵索引取一次數據,所以系統認為只掃描了一行。但是它的問題就是索引的後半部分都是重複的,浪費內存。

這時我們可以考慮使用前綴索引,如果使用的是 index2 (email(7) 索引結構),執行順序是這樣的:從 index2 索引樹找到滿足索引值是’liqiang’的記錄,找到的第一個是 ID1,到主鍵上查到主鍵值是 ID1 的行,判斷出 email 的值是’liqiang156@xxx.com’,加入結果集。

取 index2 上剛剛查到的位置的下一條記錄,發現仍然是’liqiang’,取出 ID2,再到 ID 索引上取整行然後判斷,這次值仍然不對,則丟棄繼續往下取。
重複上一步,直到在 index2 上取到的值不是’liqiang’或者索引搜索完畢之後,循環結束。在這個過程中,要回主鍵索引取 4 次數據,也就是掃描了 4 行。通過這個對比,你很容易就可以發現,使用前綴索引后,可能會導致查詢語句讀數據的次數變多。

不過方法總比困難多,我們在建立索引時可以先通過語句查看一下索引的區分度,或者提前預估餘下前綴長度,對於上述問題我們可以將前綴長度調整為9即可達到效果。索引,在使用前綴索引時,一定要充分考慮數據的特徵,選擇合適的

對於一些比較長的字段的等值查詢,我們也可以採用其他方式來縮短索引的長度。比如url一般都是比較長,我們可以冗餘一列存儲其Hash值

 select field_list from t where id_card_crc=crc32('input_id_card_string'and id_card='input_id_card_string'

對於我們國家的身份證號,一共 18 位,其中前 6 位是地址碼,所以同一個縣的人的身份證號前 6 位一般會是相同的。為了提高區分度,我們可以將身份證號碼倒序存儲

 select field_list from t where id_card = reverse('input_id_card_string');

3. 正確使用索引

建立合適的索引是前提,想要取得理想的查詢性能,還應保證能夠用到索引。避免索引失效即是優化。

不在索引上進行任何操作

索引上進行計算,函數,類型轉換等操作都會導致索引從當前位置(聯合索引多個字段,不影響前面字段的匹配)失效,可能會進行全表掃描。

explain select * from test_table where upper(a) = "ZHANGSAN" 

對於需要計算的字段,則一定要將計算方法放在“=”後面,否則會破壞索引的匹配,目前來說MySQL優化器不能對此進行優化。

explain select * from test_table where a = lower("ZHANGSAN")

隱式類型轉換

需要注意的是,在查詢時一定要注意字段類型問題,比如a字段時字符串類型的,而匹配參數用的是int類型,此時就會發生隱式類型轉換,相當於相當於在索引上使用函數。

explain select * from test_table where a = 1;


a是字符串類型,然後使用int類型的1進行匹配,此時就發生了隱式類型轉換,破壞索引的使用。

只查詢需要的列

在日常開發中很多同學習慣使用 select * … 來構建查詢語句,這種做法也是極不推薦的。主要原因有兩個,首先查詢無用的列在數據傳輸和解析綁定過程中會增加網絡IO,以及CPU的開銷,儘管往往這些消耗可以被忽略,但是我們也要避免埋坑。

explain select a,b,c from test_table where a="zhangsan" and b = "188466668888" and c = "23";

其次就是會使得覆蓋索引”失效”, 這裏的失效並非真正的不走索引。覆蓋索引的本質就是在索引中包含所要查詢的字段,而 select * 將使覆蓋索引失去意義,仍然需要進行回表操作,畢竟索引通常不會包含所有的字段,這一點很重要。

explain select * from test_table where a="zhangsan" and b = "188466668888" and c = "23";

不等式條件

查詢語句中只要包含不等式,負向查詢一般都不會走索引,如 !=, <>, not in, not like等。

explain select * from test_table where a !="1222" and b="12222222222" and c = 23;
explain select * from test_table where a <>"1222" and b="12222222222" and c = 23;
explain select * from test_table where a not in ("xxxx");

模糊匹配查詢

最左前綴在進行模糊匹配時,一般禁止使用%前導的查詢,如like “%zhangsan”。

explain select * from test_table where a like "zhangsan";
explain select * from test_table where a like "%zhangsan";
explain select * from test_table where a like "zhangsan%";

最左匹配原則

索引是有順序的,查詢條件中缺失索引列之後的其他條件都不會走索引。比如(a, b, c)索引,只使用b, c索引,就不會走索引。

explain select * from test_table where b = "188466668888" and c = "23";

如果索引從中間斷開,索引會部分失效。這裏的斷開指的是缺失該字段的查詢條件,或者說滿足上述索引失效情況的任意一個。不過這裏的仍然會使用到索引,只不過只能使用到索引的前半部分。

explain select * from test_table where a="zhangsan" and b != 1 and c = "23"

值得注意的是,如果使用了不等式查詢條件,會導致索引完全失效。而上一個例子中即使用了不等式條件,也使用了隱式類型轉換卻能用到索引。

同理,根據最左前綴匹配原則,以下如果使用b,c作為查詢條件則不會使用(a, b, c)索引。

執行語句:

explain select * from test_table where b = "188466668888" and c = "23";

執行結果:

索引下推

在說索引下推之前,我們先執行一下SQL。

執行語句:

explain select * from test_table where a = "zhangsan" and c = "23";

上述的最左前綴匹配原則相信大家都能很容易的理解,那麼使用(a, c)條件查詢能夠利用(a, b, c)嗎?答案是肯定的,正如上圖所示。即使沒有索引下推也會會根據最左匹配原則,使用到索引中的a字段。有了索引下推之後會增加查詢的效率。

在面試中通常會問到這樣一個問題,已知有索引(a,b,c)則根據條件(a,c)查詢時會不會走索引呢?答案是肯定的,但是是有版本限制的。

而 MySQL 5.6 引入的索引下推優化(index condition pushdown), 可以在索引遍歷過程中,對索引中包含的字段先做判斷,直接過濾掉不滿足條件的記錄,減少回表次數,是對查詢的一種優化,感興趣的同學可以看一下官方說明https://dev.mysql.com/doc/refman/8.0/en/index-condition-pushdown-optimization.html。

上述是沒有索引下推,每次查詢完之後都會回表,取到對應的字段進行匹配。

利用索引下推,每次盡可能在輔助索引中將不符合條件數據過濾掉。比如,索引中已經包含了name和age,索引不妨暫且忽略破壞索引匹配的條件直接匹配。

查詢優化-自適應索引順序

查詢時,mysql的優化器會優化sql的執行,即使查詢條件的順序沒有按照定義順序來使用,也是可以使用索引的。但是需要注意的是優化本身也會消耗一定的性能,所以還是推薦按照索引的定義來書寫sql。

explain select  * from test_table where b="12222222222" and a="zhangsan" and c = 23;
explain select  * from test_table where a="zhangsan" and b="12222222222" and c = 23;

4. 總結

索引並不是什麼高深的技術,從底層來看,不過是一個數據結構罷了。要想使用好索引,一定要先將B+Tree理解透徹,在此基礎上對於日常使用和面試則是信手拈來。

脫離業務的設計都是耍流氓,技術的意義在於服務業務。所以,索引的設計需要充分考慮業務的需求與設計原則之間做一些取捨,滿足需求是基礎。

在工作中,各個公司的版本可能大不相同,會存在一些奇奇怪怪,不確定的問題。所以為了驗證索引的有效性,強烈推薦把主要的查詢sql都通過explain查看一下執行計劃,是否會用到索引。

參考資料:
[1] 《MySQL 45講》—極客時間
[2] 《InnoDB存儲引擎》
[3] 《高性能MySQL》
[4] https://dev.mysql.com/doc/refman/8.0/en/

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

網頁設計最專業,超強功能平台可客製化

聚甘新

Tesla 推出半掛電動卡車和新款 Roadster 超跑,性能爆表但量產能力依然受存疑

  2017 年 11 月 16 日電動車製造商 Tesla 在洛杉磯進行產品發表會,推出了首款半掛電動卡車,這款卡車在空載的狀況下 0 到 100 公里加速僅需 5 秒,續航達到了驚人的 800 公里,整體設計科技感十足,還加入自動輔助駕駛功能,可適應簡單路況的高速公路行駛需求,2019 年量產。在此次發表會上 Elon Musk 還給電動超跑的愛好者帶來了一個驚喜,Tesla 新款 Roadster 發表,這車款從時速 0 到 100 公里加速僅需要 1.9 秒,續航達到了 1,000 公里,預期在 2020 年上市。   Tesla 的電動卡車經過半年多的預熱宣傳終於在 11 月 16 日的發表會上亮相,該公司 CEO Elon Musk 乘坐全新的 Tesla 半掛卡車出場,全球最知名的電動車製造商開始進軍運輸市場。 Tesla 半掛電動卡車的性能非常驚人,在空載的狀況下 0 到每小時 100 公里加速僅需要 5 秒,相當於性能出眾的轎車水準,其他同類的卡車 0 到每小時 100 公里加速大概需要 15 秒,Tesla 的卡車即使在滿載 36 噸貨物的狀況下加速到每小時 100 公里也只需要 20 秒,最高時速可達到每小時104公里。   電動卡車需要面臨的最大挑戰就是續航,運輸貨物往往需要遠距離的行程,Tesla 電動卡車採用了 4 個獨立電機,單次充電可在高速公路路況下行駛約 800 公里,Tesla 為電動卡車打造了專用超級充電站 Megacharger,充電 30 分鐘就可行駛 650 公里,可應對 6-7 個小時的行程。  

  Tesla 半掛電動卡車的設計極具未來感,駕駛空間位於卡車前部中央的位置,空間較大,司機可完全站立,另外還配有有可拆卸的乘客座位。操控系統的設計延續了 Tesla Model 系列電動車的風格,採用了多個大尺寸觸控螢幕,用於顯示導航和車況資料。   為了提升電動卡車的安全性,在電池的部分採用了特殊的安全設計,電池位置較低降低了卡車的重點,同時擋風玻璃可有效地減少撞擊的衝擊力,車身上的鏡頭可實現 360 度的路況監控,一旦出現緊急狀況可向司機發出警告,必要時自動輔助駕駛系統可自動剎車。  

  雖然這款卡車上沒有配上無人駕駛功能,但應用到 Model S 上的自動駕駛升級後推廣到了卡車上,在高速公路等簡單路況下,自動駕駛系統可實現車道保持和變換,加速和停車等功能,降低司機在開車時的工作強度,提升行駛的安全性。   Tesla 電動卡車的目標市場主要是中短途運輸市場,每公里運輸成本大約是其他燃油卡車的 80%,由於安全性提升,運輸公司在車輛維護和保險方面的支出會相應減少。這款產品將在 2019 年量產,售價暫沒有公開。  
Roadster 再現,性能續航力爆表   此次發表會上 Elon Musk 還帶來了一款之前沒有任何消息曝光的新品──新款 Roadster 電動超跑,這是 Tesla 有史以來速度最快的電動車,從時速 0 到 100 公里加速僅需要 1.9 秒,幾乎超越了市面上其他昂貴的超級跑車,最高時速達到了每小時 400 公里,採用了 200kWh 的電池,單次充電續航達到了驚人的 1,000 公里,這款產品預期在 2020 年上市,售價為 20 萬美元起,第一批 1,000 台售價為 25 萬美元。  

  無論 Tesla 的半掛卡車還是新款超跑,在產品性能和外觀設計上都獲得了好評,但擺著這家電動車製造商面前的難題並沒有解決,產能問題使得 Tesla Model 3 還有 50 萬台訂單沒有交車,這兩款至少需要等到 2020 年才開始量產交付的新車會讓消費者等到什麼時候呢?   為了提升產能,Tesla 每一季需要投入 10 億美元建廠。傳統汽車製造商在新車推出之前,一般需要對產能進行長期的規畫,工廠建設、生產線配置和產能提升都需要時間,一般從工廠建設到生產線量產需要 3 年時間,同時製造商還需要面非常大的資金壓力,Tesla 應對這一問題的辦法就是提前 3 年時間發表產品,再進行工廠的建設和產品量產,Elon Musk 在產能提升方面也表現了極強的信心,Tesla的製造工廠自動化程度較高,能夠在一定程度上加快產能提升的速度。   一般汽車製造商的新品提升產能的時間週期大約是 6 個月,Tesla 在 2017 年第三季僅生產了 260 台 Model 3,產能不到預期的一成,這意味著 Tesla 面臨了更大的麻煩,有媒體報導 Tesla 的製造商機器人數量不足,僅有 150 台組裝機器人,部分生產線仍需要手工配裝,雖然 Tesla 否認的這一消息,作為車輛製造產業的新創公司,Tesla 的供應商管理、製造流程控制等方面確實存在缺陷。   (合作媒體:。首圖來源:Tesla)  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

聚甘新

福斯拼2025年躍居電動車龍頭、砸500億歐元採購電池

  福斯集團(Volkswagen Group)11月18日宣布,2018~2022年期間旗下核心品牌將在全球投資228億歐元、當中有140億歐元將會投入德國地區工廠。位於德國茲威考(Zwickau)的工廠將獲得10億歐元的挹注、藉此轉型為純電動車生產線。   福斯預估2025年旗下電動車產量至少可達100萬輛。採用MEB(Modular Electric Drive Kit)模組化電動車平台技術的電動車續航力將介於400~600公里之間。首款搭載MEB的Volkswagen I.D.預計在2020年發表、當年產量預估將達10萬輛。   福斯集團11月17日宣布,2018~2022年期間集團將投入340億歐元在電動移動、自主駕駛、新型移動服務以及數位化等領域。福斯9月宣布,2030年底以前旗下所有車款都將具備電動驅動選項。   福斯執行長Matthias Muller表示,上述投資將為集團在2025年躍居全球最大電動車廠商奠定基礎。Muller提到,未來數年整個汽車業將面臨根本性的變化。 為了滿足對電池產能的巨大需求,福斯集團已啟動了旨在建立長期戰略合作夥伴關係的全球(包括中國在內)招標程序、金額預估將超過500億歐元。   福斯集團預期巴西、中國、俄羅斯以及北美將會是未來數年的主要成長來源。   福斯汽車公司(中國)11月16日宣布,從現在到2025年這段期間公司與合資企業夥伴將投資逾100億歐元在電動移動工業化領域。   Thomson Reuters報導,英國財政部19日表示,財長Philip Hammond將在11月22日公布的政府預算書當中宣布提供總額達1.0億英鎊的電動車購買補助金。   (本文內容由授權使用。首圖來源:pixabay)  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司“嚨底家”!

※推薦評價好的iphone維修中心

聚甘新

殼牌與IONITY聯手,歐洲據點大增、EV充電5分鐘搞定

  Thomson Reuters 27日報導,荷蘭皇家殼牌(Royal Dutch Shell plc)宣布與IONITY GmbH結盟、2019年將在歐洲(包括比利時、英國、法國、荷蘭、奧地利、捷克、匈牙利、波蘭、斯洛伐克和斯洛維尼亞)高速公路80個據點設置超高速電動車(EV)充電站。殼牌零售部門主管Istvan Kapitany表示,如果加上德國境內預計要增設的20座,兩年內殼牌在歐洲高速公路的加油站將有四分之一會提供高速充電服務。   殼牌指出,350 kW的充電功率搭配IONITY技術可讓EV充電時間縮短至5~8分鐘,遠比一般的數小時充電時間還要快。依據殼牌最樂觀的估算,全球EV車隊占整體車隊比重將從目前的1%成長至2025年底的10%,全球原油日需求量將因而縮減80萬桶。殼牌競爭對手BP 8月表示正與電動車製造商洽談合作案、預計在旗下加油站內將設置充電樁。根據歐洲替代燃料瞭望台的統計,2014~2017年期間歐洲EV充電樁成長將近三倍、逼近12萬大關。   英國金融時報報導,殼牌在全球各地擁有4萬座加油站、平均每天服務3千萬名客戶。殼牌將安裝的IONITY充電樁功率為350 kW、遠大於業界目前的標準規格(50kW)。IONITY成立於2016年,股東包括福特、BMW、戴姆勒、Volkswagen。   (本文內容由授權使用。首圖來源:public domain CC0)  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨,RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準

聚甘新

能源發展仍需時間,統振前3季營運近損平

 

 

    統振前三季數據服務、流通事業與數位娛樂獲利持穩成長,惟能源部門則仍處於投入階段,前3季營運維持在損平邊緣,與去年表現相當;看好電動車長期發展趨勢,統振持續耕耘電動自行車、電動機車等市場,目前在兩岸也有開發案進行中,惟因相關開發案都需要一段時間醞釀,對整體營運貢獻仍需持續觀察。   統振母公司目前從事行動電話預付卡銷售、網路遊戲儲值卡買賣,動能主要來自外勞預付卡市佔率成長,而統振旗下轉投資數位電通則主要經營電商通路,去年起新增美妝產品,至於數位點子多媒體則以數位內容業務為主,包括連續劇版權買賣及演唱會業務;另外,統振旗下還有兩家從事電池模組相關業務的子公司達振與統達,達振在中國擁有工廠,目前主要生產3C相關電池模組,未來將逐步轉型至電動車電池模組,而統達則負責開發相關電動自行車、電動機車電池模組與交換系統。   統振前3季數據服務部門(母公司部份)約占合併營收61%,能源部門(統達與達振)佔29%,流通事業(數位電通)佔7%,數位娛樂(數位點子多媒體)3%,而前3季除了能源部門持續虧損,其他部門獲利則都穩定增長,但因能源部門前3季虧損約9,000多萬元,而其他部分獲利合計則約7,000多萬元,前3季營運仍在損平邊緣,統振前3季EPS為 -0.06元,Q3底每股淨值為12.63元。   看好電動車長期發展趨勢,統振持續投入高功率電池模組開發,而有鑑於台廠較難直接切入電動汽車供應鏈,統振也先從電動腳踏車、電動機車切入,而目前中國電動兩輪車仍以鉛酸蓄電池為主流,惟考量環保、輕量化等趨勢,加以政策驅動,且近年鋰電池成本也持續改善,將有助於提升鋰電池轉換需求,統振目前也持續與相關廠商合作,等待市場規模逐步放大。   統振今年前3季合併營收為22.34億元,年減9.7%;前3季EPS為 -0.06元,與去年同期的 -0.02元差異不大。統振近幾年本業大多呈現小幅虧損,主要係因能源部份仍在支出階段,但其他部門獲利則相對穩定。   (本文內容由授權使用,首圖為統振旗下達陣能源鋰電池模組,來源:)  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

聚甘新

車王電電動工具訂單貢獻續看升,能見度達明年4月

  車王電11月30日召開法說會,董事長蔡裕慶表示,目前電動工具訂單受惠於美國通路商挹注,產能滿載、訂單能見度看到2018年4月;此外,投資入股的華德動,預期在未來2年,可成為公司獲利金雞母。   蔡裕慶指出,看好電動車將是未來趨勢,新能源、儲能、電動巴士及汰役電池等,將是車王電未來經營重點。此外,華德動為是唯一可接受交通部補助的電動巴士廠商,其透過與日本住友等廠商,將電動巴士技術及供應鏈輸出至全球,預期未來2年,可望成為公司獲利金雞母。   另外,在電動工具部份,車王電表示,整體訂單能見度可看到明年4月,同時,預期第四季電動工具出貨將年成長3、4成,今年佔營收比重將從去年17%攀升至25%,且明年電動工具出貨更將比今年成長40%以上。     (本文內容由授權使用。首圖來源:華德動)  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

網頁設計最專業,超強功能平台可客製化

聚甘新