以前總說手動擋車型省油，但現在不少自動變速箱與發動機的匹配愈發爐火純青，油耗也持續往下走，有些自動擋車型的油耗數據完全不輸手動擋。曾經我認為四缸是一台車的底線，沒想到現在三缸機已經越來越普遍。最經典的就是寶馬1系，連一向對發動機輸出有苛刻要求的寶馬都推出了1。

隨着我國經濟的飛速發展，不少人民的錢包變得越來越鼓。近幾年，我國汽車的人均汽車保有量在迅速攀升，銷量已經連續幾年位居世界第一。各國的廠商已經越來越重視中國市場，甚至有不少車型都是為中國市場量身定做的。

這十幾年中國汽車市場的變化還是挺大的，但這些變化我個人認為並不能說都是好事，只能說是一種對現實的妥協，下面就來和大家談談那些變化。

在08年左右的時候，自然吸氣發動機的車還是大行其道，那時候對排放沒有捉得這麼嚴，所以各路廠家都喜歡推出自吸車。我自己家裡也有一輛1.6L老世嘉，一腳油門下去時，加速力雖然不是很猛，但循序漸進的感覺確實美妙。

到了現在2018年，自吸車雖然不至於說退出歷史舞台，但是佔比已經愈來愈低，渦輪車的普及程度越來越高。早些年的時候，渦輪還是比較容易壞的。不過經過這麼多年的發展，渦輪的耐用性得以大幅提升。

連一向崇尚自吸的日系車都大力推渦輪，就知道這個趨勢已經不可逆轉。不過日系車的渦輪車普遍體驗還是不錯的，像1.5T的思域、2.0T的漢蘭達都給消費者帶來了良好的駕乘質感。自吸這條路，目前也只有日產和馬自達等寥寥無幾的車企在苦苦支撐。

在過去的時候，雖然也有自動擋，但普及程度沒有現在這麼高。現在感覺10台車裡面有9台都是自動擋的，而大多數人估計拿了駕駛證以後就沒有再開過手動擋，也有不少女生是直接考了個C2駕照。

自動擋車型的門檻越來越低，這對於廣大消費者來講絕對是一件好事，畢竟不是所有人都喜歡開車這件事。以前總說手動擋車型省油，但現在不少自動變速箱與發動機的匹配愈發爐火純青，油耗也持續往下走，有些自動擋車型的油耗數據完全不輸手動擋。

曾經我認為四缸是一台車的底線，沒想到現在三缸機已經越來越普遍。最經典的就是寶馬1系，連一向對發動機輸出有苛刻要求的寶馬都推出了1.5T三缸發動機來搶佔更多的市場份額。

雖然現在的三缸機在抖動控制方面已經做得相當不錯，在車內如果不是仔細體會，還真不容易感覺出來。不過也有一些汽修人員指出，三缸機在老化以後，抖動要比四缸機明顯不少，這也是不少人擔心的地方。

儘管如此，隨着汽車技術的不斷髮展，三缸機的技術也會得到進一步優化。就像別克的英朗、閱朗和GL6已經全面三缸化，未來相信會有越來越多的車型加入其中。

在各種政策的大力鼓勵下，各種電動車企業像雨後春筍般湧現出來，不少品牌連我們都不大認識。毫無疑問電動車會是下一片紅海，很多企業都想從中分一杯羹。不過就目前來看，自願買電動車的人還是少數。

一直以來困擾電動車發展的兩大難題是充電速度和續航里程，前者的話，蔚來已經提出了換電服務，這算是頗為便捷的一個解決方式；後者的話，經過這幾年的發展，不少電動車的理論續航里程都能達到450km以上，未來我相信能持續增多。

我曾經駕駛過特斯拉，無可否認，那種一點就有的加速確實不錯。但沒有了引擎和排氣的聲音，感覺整個駕駛參与度不夠高，就像關了聲音看恐怖片般索然無味。這也不是無法彌補，現在有不少汽車都有聲浪彌補功能，可根據駕駛員踩踏油門的深度來模擬出引擎和排氣的聲音，但假的真不了。

總結

這幾個汽車的變化，到底是好還是壞，不同的人有不同的看法。這些轉變就像青春期的愛情變為工作后的愛情，前者是單純懵懂的，後者則是現實清晰的。更為關鍵的是，汽車和愛情都是不可逆轉的，而我們唯一能做的就是珍惜和享受眼前的汽車生活。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

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

sjlj (setjump/longjump)與dwarf-2為mingw32兩種異常處理模型的實現。sjlj有着開銷，而隨linux發行的mingw32開發庫包都是用sjlj版編譯的，而Qt卻採用dwarf-2版，那麼兩者之間有多少差異，本文就這問題對兩版的異常代碼的反彙編進行分析比較。

我使用mingw-w65-i686-810的sjlj與dwarf-2兩個版本對下面異常代碼編譯。

__attribute__((dllimport)) int dllfunc();
int main()
{
    dllfunc();
    //_create_locale(LC_ALL, "C");
    printf("abc");
    //return 0;

    try
    {
        try
        {
            throw std::exception();
        }
        catch(std::exception&)
    　　{
            std::rethrow_exception(std::current_exception());
    　　}
        
    }
    catch(int)
    {
        
    }
    catch(std::exception& e)
    {
        std::cout << e.what() << std::endl;
    }
    catch(...)
    {
        std::cout << "unknown" << std::endl;
    }
    return 0;
}

代碼邏輯：

兩層 try/catch，

1. 裡層 try/catch

1.1 try塊， throw 異常

1.2 catch塊， rethrow

2. 外層 try/catch

2.1 有三catch分支。

 

開刷前，先定義一下。

如果將 try/catch 去除 c++語言特性后，基本就是一種由c++庫還有c++編譯器共同管理的 goto。

throw相當於goto， catch相當於label（一種以類型區分的）。

那麼c++編譯器與c++庫為我們提供了什麼樣的管理呢？

c++編譯器

0. 利用c++支持對象析構進行try塊保護。

1. 將 throw 關鍵字生成彙編 call __cxa_throw，調用 c++庫的函數。

2. 為每個catch塊生成代碼片斷，只能通過jmp跳轉進來。

2.1 開頭 call __cxa_begin_catch。

2.2 結尾 call __cxa_end_catch。

2.3 最後跳出到 try/catch塊邏輯代碼的下條執行指令。

3. 為同一try/catch塊的所有catch塊產生分支控制代碼。

4. 為try塊的析構代碼產生跳轉入口。

5. 為每一層try/catch塊生成 uncaught 代碼塊，調用 _Unwind_Resume。

c++庫：

1. __cxa_throw，馬上_Unwind_RaiseException。跳轉到當前最裏面一層 try/catch的支路控制代碼片斷。

2. _Unwind_Resume，向上繼續展開。

3. std::rethrow_exception，調用 __gcclibcxx_demangle_callback，

3.1 要麼有 catch可達跳回到原來代碼的控制流，直接離開std::rethrow_exception的調用上下文。

3.2 要麼從__gcclibcxx_demangle_callback返回，執行terminate結束進程。

 

sjlj 版的反彙編代碼比 dwarf-2 版的多了50行。

先來看dwarf-2的反彙編代碼 

  1  <+0>:    lea    0x4(%esp),%ecx
  2  <+4>:    and    $0xfffffff0,%esp
  3  <+7>:    pushl  -0x4(%ecx)
  4  <+10>:    push   %ebp
  5  <+11>:    mov    %esp,%ebp
  6  <+13>:    push   %esi
  7  <+14>:    push   %ebx
  8  <+15>:    push   %ecx
  9  <+16>:    sub    $0x2c,%esp
 10  <+19>:    call   0x401890 <__main>
 11  <+24>:    mov    0x4071a4,%eax
 12  <+29>:    call   *%eax
 13  <+31>:    movl   $0x404045,(%esp)
 14  <+38>:    call   0x4027c4 <printf>
 15  <+43>:    movl   $0x4,(%esp)
 16  <+50>:    call   0x4017ac <__cxa_allocate_exception>
 17  <+55>:    mov    %eax,%ebx
 18  <+57>:    mov    %ebx,%ecx
 19  <+59>:    call   0x402890 <std::exception::exception()>
 20  <+64>:    movl   $0x4017d4,0x8(%esp)
 21  <+72>:    movl   $0x4042a8,0x4(%esp)
 22  <+80>:    mov    %ebx,(%esp)
 23  <+83>:    call   0x401794 <__cxa_throw>
 24  <+88>:    mov    $0x0,%eax
 25  <+93>:    jmp    0x401723 <main()+355>
 26  <+98>:    mov    %edx,%ecx
 27  <+100>:    cmp    $0x2,%ecx
 28  <+103>:    je     0x40162b <main()+107>
 29  <+105>:    jmp    0x401663 <main()+163>
 30  <+107>:    mov    %eax,(%esp)
 31  <+110>:    call   0x4017a4 <__cxa_begin_catch>
 32  <+115>:    mov    %eax,-0x1c(%ebp)
 33  <+118>:    lea    -0x28(%ebp),%eax
 34  <+121>:    mov    %eax,(%esp)
 35  <+124>:    call   0x4017cc <_ZSt17current_exceptionv>
 36  <+129>:    lea    -0x28(%ebp),%eax
 37  <+132>:    mov    %eax,(%esp)
 38  <+135>:    call   0x4017c4 <_ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE>
 39  <+140>:    mov    %eax,%esi
 40  <+142>:    mov    %edx,%ebx
 41  <+144>:    lea    -0x28(%ebp),%eax
 42  <+147>:    mov    %eax,%ecx
 43  <+149>:    call   0x4017ec <_ZNSt15__exception_ptr13exception_ptrD1Ev>
 44  <+154>:    call   0x40179c <__cxa_end_catch>
 45  <+159>:    mov    %esi,%eax
 46  <+161>:    mov    %ebx,%edx
 47  <+163>:    cmp    $0x1,%edx
 48  <+166>:    je     0x40166f <main()+175>
 49  <+168>:    cmp    $0x2,%edx
 50  <+171>:    je     0x401683 <main()+195>
 51  <+173>:    jmp    0x4016ca <main()+266>
 52  <+175>:    mov    %eax,(%esp)
 53  <+178>:    call   0x4017a4 <__cxa_begin_catch>
 54  <+183>:    mov    (%eax),%eax
 55  <+185>:    mov    %eax,-0x24(%ebp)
 56  <+188>:    call   0x40179c <__cxa_end_catch>
 57  <+193>:    jmp    0x401618 <main()+88>
 58  <+195>:    mov    %eax,(%esp)
 59  <+198>:    call   0x4017a4 <__cxa_begin_catch>
 60  <+203>:    mov    %eax,-0x20(%ebp)
 61  <+206>:    mov    -0x20(%ebp),%eax
 62  <+209>:    mov    (%eax),%eax
 63  <+211>:    add    $0x8,%eax
 64  <+214>:    mov    (%eax),%eax
 65  <+216>:    mov    -0x20(%ebp),%edx
 66  <+219>:    mov    %edx,%ecx
 67  <+221>:    call   *%eax
 68  <+223>:    mov    %eax,0x4(%esp)
 69  <+227>:    movl   $0x6ff07a00,(%esp)
 70  <+234>:    call   0x4017b4 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
 71  <+239>:    movl   $0x4017bc,(%esp)
 72  <+246>:    mov    %eax,%ecx
 73  <+248>:    call   0x4017f4 <_ZNSolsEPFRSoS_E>
 74  <+253>:    sub    $0x4,%esp
 75  <+256>:    call   0x40179c <__cxa_end_catch>
 76  <+261>:    jmp    0x401618 <main()+88>
 77  <+266>:    mov    %eax,(%esp)
 78  <+269>:    call   0x4017a4 <__cxa_begin_catch>
 79  <+274>:    movl   $0x404049,0x4(%esp)
 80  <+282>:    movl   $0x6ff07a00,(%esp)
 81  <+289>:    call   0x4017b4 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
 82  <+294>:    movl   $0x4017bc,(%esp)
 83  <+301>:    mov    %eax,%ecx
 84  <+303>:    call   0x4017f4 <_ZNSolsEPFRSoS_E>
 85  <+308>:    sub    $0x4,%esp
 86  <+311>:    call   0x40179c <__cxa_end_catch>
 87  <+316>:    jmp    0x401618 <main()+88>
 88  <+321>:    mov    %eax,%ebx
 89  <+323>:    call   0x40179c <__cxa_end_catch>
 90  <+328>:    mov    %ebx,%eax
 91  <+330>:    mov    %eax,(%esp)
 92  <+333>:    call   0x402770 <_Unwind_Resume>
 93  <+338>:    mov    %eax,%ebx
 94  <+340>:    call   0x40179c <__cxa_end_catch>
 95  <+345>:    mov    %ebx,%eax
 96  <+347>:    mov    %eax,(%esp)
 97  <+350>:    call   0x402770 <_Unwind_Resume>
 98  <+355>:    lea    -0xc(%ebp),%esp
 99  <+358>:    pop    %ecx
100  <+359>:    pop    %ebx
101  <+360>:    pop    %esi
102  <+361>:    pop    %ebp
103  <+362>:    lea    -0x4(%ecx),%esp
104  <+365>:    ret    

我們的主要代碼邏輯只有20-30條指令

 

 當 throw時，__cxa_throw函數是不會返回的， 如同goto最後是跳轉到他處，若被本層catch處理完才會跳轉回來<+88>。

然後看c++編譯器為我們生成的異常代碼 。

 

 

 

 

 

 對於沒有發生異常時，代碼執行路徑基本不會去涉及到異常代碼支路，開銷幾近為0，只是代碼量增大。

下面來看 sjlj 版的彙編代碼，

  1 function main():
  2  <+0>:    lea    0x4(%esp),%ecx
  3  <+4>:    and    $0xfffffff0,%esp
  4  <+7>:    pushl  -0x4(%ecx)
  5  <+10>:    push   %ebp
  6  <+11>:    mov    %esp,%ebp
  7  <+13>:    push   %edi
  8  <+14>:    push   %esi
  9  <+15>:    push   %ebx
 10  <+16>:    push   %ecx
 11  <+17>:    sub    $0x68,%esp
 12  <+20>:    movl   $0x4017ac,-0x44(%ebp)
 13  <+27>:    movl   $0x402958,-0x40(%ebp)
 14  <+34>:    lea    -0x3c(%ebp),%eax
 15  <+37>:    lea    -0x18(%ebp),%ebx
 16  <+40>:    mov    %ebx,(%eax)
 17  <+42>:    mov    $0x4015b4,%edx
 18  <+47>:    mov    %edx,0x4(%eax)
 19  <+50>:    mov    %esp,0x8(%eax)
 20  <+53>:    lea    -0x5c(%ebp),%eax
 21  <+56>:    mov    %eax,(%esp)
 22  <+59>:    call   0x402790 <_Unwind_SjLj_Register>
 23  <+64>:    call   0x4018b0 <__main>
 24  <+69>:    mov    0x406194,%eax
 25  <+74>:    movl   $0xffffffff,-0x58(%ebp)
 26  <+81>:    call   *%eax
 27  <+83>:    movl   $0x404001,(%esp)
 28  <+90>:    call   0x4027e4 <printf>
 29  <+95>:    movl   $0x4,(%esp)
 30  <+102>:    call   0x4017cc <__cxa_allocate_exception>
 31  <+107>:    mov    %eax,-0x60(%ebp)
 32  <+110>:    mov    %eax,%ecx
 33  <+112>:    call   0x4028b0 <std::exception::exception()>
 34  <+117>:    movl   $0x4017f4,0x8(%esp)
 35  <+125>:    movl   $0x404264,0x4(%esp)
 36  <+133>:    mov    -0x60(%ebp),%eax
 37  <+136>:    mov    %eax,(%esp)
 38  <+139>:    movl   $0x1,-0x58(%ebp)
 39  <+146>:    call   0x4017b4 <__cxa_throw>
 40  <+151>:    mov    $0x0,%eax
 41  <+156>:    mov    %eax,-0x60(%ebp)
 42  <+159>:    jmp    0x401733 <main()+547>
 43  <+164>:    lea    0x18(%ebp),%ebp
 44  <+167>:    mov    -0x54(%ebp),%edx
 45  <+170>:    mov    -0x50(%ebp),%ecx
 46  <+173>:    mov    -0x58(%ebp),%eax
 47  <+176>:    test   %eax,%eax
 48  <+178>:    je     0x4015e6 <main()+214>
 49  <+180>:    sub    $0x1,%eax
 50  <+183>:    test   %eax,%eax
 51  <+185>:    je     0x40161b <main()+267>
 52  <+187>:    sub    $0x1,%eax
 53  <+190>:    test   %eax,%eax
 54  <+192>:    je     0x4016f8 <main()+488>
 55  <+198>:    sub    $0x1,%eax
 56  <+201>:    test   %eax,%eax
 57  <+203>:    je     0x401712 <main()+514>
 58  <+209>:    sub    $0x1,%eax
 59  <+212>:    ud2    
 60  <+214>:    mov    %edx,%eax
 61  <+216>:    mov    %ecx,%edx
 62  <+218>:    mov    %edx,%ecx
 63  <+220>:    cmp    $0x2,%ecx
 64  <+223>:    je     0x4015f3 <main()+227>
 65  <+225>:    jmp    0x401642 <main()+306>
 66  <+227>:    mov    %eax,(%esp)
 67  <+230>:    call   0x4017c4 <__cxa_begin_catch>
 68  <+235>:    mov    %eax,-0x1c(%ebp)
 69  <+238>:    lea    -0x28(%ebp),%eax
 70  <+241>:    mov    %eax,(%esp)
 71  <+244>:    call   0x4017ec <_ZSt17current_exceptionv>
 72  <+249>:    lea    -0x28(%ebp),%eax
 73  <+252>:    mov    %eax,(%esp)
 74  <+255>:    movl   $0x2,-0x58(%ebp)
 75  <+262>:    call   0x4017e4 <_ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE>
 76  <+267>:    mov    %edx,-0x60(%ebp)
 77  <+270>:    mov    %ecx,-0x64(%ebp)
 78  <+273>:    lea    -0x28(%ebp),%eax
 79  <+276>:    mov    %eax,%ecx
 80  <+278>:    call   0x40180c <_ZNSt15__exception_ptr13exception_ptrD1Ev>
 81  <+283>:    mov    -0x60(%ebp),%eax
 82  <+286>:    mov    %eax,-0x60(%ebp)
 83  <+289>:    mov    -0x64(%ebp),%esi
 84  <+292>:    mov    %esi,-0x64(%ebp)
 85  <+295>:    call   0x4017bc <__cxa_end_catch>
 86  <+300>:    mov    -0x60(%ebp),%eax
 87  <+303>:    mov    -0x64(%ebp),%edx
 88  <+306>:    cmp    $0x1,%edx
 89  <+309>:    je     0x40164e <main()+318>
 90  <+311>:    cmp    $0x2,%edx
 91  <+314>:    je     0x401665 <main()+341>
 92  <+316>:    jmp    0x4016b3 <main()+419>
 93  <+318>:    mov    %eax,(%esp)
 94  <+321>:    call   0x4017c4 <__cxa_begin_catch>
 95  <+326>:    mov    (%eax),%eax
 96  <+328>:    mov    %eax,-0x20(%ebp)
 97  <+331>:    call   0x4017bc <__cxa_end_catch>
 98  <+336>:    jmp    0x4015a7 <main()+151>
 99  <+341>:    mov    %eax,(%esp)
100  <+344>:    call   0x4017c4 <__cxa_begin_catch>
101  <+349>:    mov    %eax,-0x24(%ebp)
102  <+352>:    mov    -0x24(%ebp),%eax
103  <+355>:    mov    (%eax),%eax
104  <+357>:    add    $0x8,%eax
105  <+360>:    mov    (%eax),%eax
106  <+362>:    mov    -0x24(%ebp),%edx
107  <+365>:    mov    %edx,%ecx
108  <+367>:    call   *%eax
109  <+369>:    mov    %eax,0x4(%esp)
110  <+373>:    movl   $0x6ff29a00,(%esp)
111  <+380>:    movl   $0x3,-0x58(%ebp)
112  <+387>:    call   0x4017d4 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
113  <+392>:    movl   $0x4017dc,(%esp)
114  <+399>:    mov    %eax,%ecx
115  <+401>:    call   0x401814 <_ZNSolsEPFRSoS_E>
116  <+406>:    sub    $0x4,%esp
117  <+409>:    call   0x4017bc <__cxa_end_catch>
118  <+414>:    jmp    0x4015a7 <main()+151>
119  <+419>:    mov    %eax,(%esp)
120  <+422>:    call   0x4017c4 <__cxa_begin_catch>
121  <+427>:    movl   $0x404005,0x4(%esp)
122  <+435>:    movl   $0x6ff29a00,(%esp)
123  <+442>:    movl   $0x4,-0x58(%ebp)
124  <+449>:    call   0x4017d4 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
125  <+454>:    movl   $0x4017dc,(%esp)
126  <+461>:    mov    %eax,%ecx
127  <+463>:    call   0x401814 <_ZNSolsEPFRSoS_E>
128  <+468>:    sub    $0x4,%esp
129  <+471>:    movl   $0xffffffff,-0x58(%ebp)
130  <+478>:    call   0x4017bc <__cxa_end_catch>
131  <+483>:    jmp    0x4015a7 <main()+151>
132  <+488>:    mov    %edx,-0x60(%ebp)
133  <+491>:    call   0x4017bc <__cxa_end_catch>
134  <+496>:    mov    -0x60(%ebp),%eax
135  <+499>:    mov    %eax,(%esp)
136  <+502>:    movl   $0xffffffff,-0x58(%ebp)
137  <+509>:    call   0x402788 <_Unwind_SjLj_Resume>
138  <+514>:    mov    %edx,-0x60(%ebp)
139  <+517>:    movl   $0x0,-0x58(%ebp)
140  <+524>:    call   0x4017bc <__cxa_end_catch>
141  <+529>:    mov    -0x60(%ebp),%eax
142  <+532>:    mov    %eax,(%esp)
143  <+535>:    movl   $0xffffffff,-0x58(%ebp)
144  <+542>:    call   0x402788 <_Unwind_SjLj_Resume>
145  <+547>:    lea    -0x5c(%ebp),%eax
146  <+550>:    mov    %eax,(%esp)
147  <+553>:    call   0x402780 <_Unwind_SjLj_Unregister>
148  <+558>:    mov    -0x60(%ebp),%eax
149  <+561>:    lea    -0x10(%ebp),%esp
150  <+564>:    pop    %ecx
151  <+565>:    pop    %ebx
152  <+566>:    pop    %esi
153  <+567>:    pop    %edi
154  <+568>:    pop    %ebp
155  <+569>:    lea    -0x4(%ecx),%esp
156  <+572>:    ret    

下面的分析只列出不同的地方 

 上圖的註釋有誤沒有勘誤過，lea是不訪問內存，通常代替add指令做加法，應該是6條指令要訪問內存。

支路控制代碼：

 

 

 

 

 可以看出，支路選路控制指令多而且複雜，還有就是跳轉多。

最後是函數結束前。

 

 

 

 可以看出在 sjlj 版本中，即使代碼不發生異常，函數在進入與離開時都要為登記維護付出一此成本，當涉及異常代碼時，支路選路控制更加複雜更多跳轉。這裡有一個成本比例，你的函數邏輯簡單，上面的開銷比重就越大，如果是頻繁調用的輕量函數就要考慮不用exception這樣的error handle。

還有就是當發生異常時，需要交給c++庫去管理，不同異常處理模型的實現，有着不同的開銷，本文並沒有涉及到。只是單純從c++庫以外的代碼進行分析，也足夠看出他們之間有着一定的差別。

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

【其他文章推薦】

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

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

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

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

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

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

台灣知名電動機車品牌 Gogoro 將與日本著名機車品牌 YAMAHA 共同合作研發機車，此共同合作的車種將於 2019 年夏天發售，由台灣山葉機車發售，新車型將採用 Gogoro 的充換電結構與網路，Gogoro 這次與老牌機車廠合作無疑給其換電系統打了劑強心針，甚至有可能藉由 YAMAHA 之助在世界各地推動其系統，這個合作勢必也將對光陽（Kymco）與尚未選擇何種充換電系統的三陽（SYM）帶來更多壓力。

根據兩公司發出的資料顯示，該合作計畫的內容是有關電動機車的產品開發、委託製造以及電池交換系統的使用，雙方預計於今年內簽署正式合約。屆時將以 Gogoro 市面銷售的車款為基礎，進行 YAMAHA 品牌的電動機車設計，並委由 Gogoro 生產。所完成的車輛則交由台灣山葉機車的銷售通路進行銷售，預計 2019 年夏季將推出第一個車款。

同時，兩家公司的事業合作夥伴「住友商事株式會社」，在促成雙方合作上也扮演了重要的角色。

YAMAHA 自 1966 年起投入台灣機車市場，目前以台灣山葉機車所生產的機車為主，年間販賣 29 萬台（2017 年實績）。同時也製造、銷售電動機車 E-VINO，並輸出到日本。以開發機能來說，YAMAHA 在台灣設有 YAMAHA Motor R&D Taiwan，主要是負責台灣市場的速克達機車開發。此次和 Gogoro 的合作案，不只是想要在台灣市場擴充其包含燃油車種在內的產品種類，在電動車的部分，也想透過運用 Gogoro 所擁有的電池交換站網路，提高消費者使用上的便利性。

Gogoro 自 2015 年起投入台灣機車市場，以製造自有品牌的智慧雙輪和可方便交換電池的電池交換站，開展全新的電動機車商業模式。Gogoro 能源網路目前在台灣已設置超過 750 個電池交換站，預計 2019 年初將超過 1,000 站。並且，自產品上市以來，已達到 1,700 萬次以上的電池交換次數，透過此次的合作，Gogoro 可望擴大電動機車的產能。

YAMAHA 發動機株式會社 MC 事業本部長木下拓也表示：「此次和台灣 Gogoro 的合作，不只增加顧客對移動工具的選擇，同時透過共用先進的電池交換系統，將對新的移動工具服務和創造市場帶來挑戰。」

Gogoro 創辦人暨執行長陸學森表示：「Gogoro 為推動能源開放平台的創新品牌，並運用能源網路的建置來推進大型智慧城市的轉型。這次我們非常榮幸能與 YAMAHA 合作，向實現能源願景的目標邁出重要的一步。」

（合作媒體：。首圖來源：）

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

【其他文章推薦】

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

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

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

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

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

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

分佈式事務

分佈式環境下的事務

要了解分佈式事務，首先要了解分佈式環境

分佈式

如一網站，訪問一個服務A（查詢自己用戶信息）， 提供服務A的服務器分別有A1（上海）A2（廣州） A3（新加坡）

同一個服務分佈在三個區域的服務器上，這就是分佈式。你可以訪問 上海的服務器，廣州的或者新加坡的，但是

三個服務器之前通信是有延遲的，所以數據同步需要一定時間

分佈式中的問題

舉例一個分佈式場景

如果用戶Y個人信息 名字為 “南柯一夢” Y改為 “南柯夢”， 同一時間，Y用戶好友查看Y的名字，好友查詢的結果是”南柯一夢” 還是 “南柯夢” 這是分佈式系統常見的問題（數據修改發生在上海，訪問發生在新加坡）。

CAP原則

CAP原則又稱CAP定理，指的是在一個分佈式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。

參考文章
An Illustrated Proof of the CAP Theorem
CAP 定理的含義

以為網絡有延遲和不可測故障，因此分佈式系統是保持服務穩定的常用手段，但是分佈式因為服務機器分佈在不同地點，因此也會有分佈式的特點問題。

分佈式中 一致性 可用性 容災性 是三個指標

Consistency

數據一致性，分佈式環境下，不同地點的服務器，數據庫數據同步一致。

Availability

服務可用性，分佈式環境下，調用服務，都可用

Partition tolerance

分區容錯性，容災能力

分佈式環境多台服務器運行，其中一部分機器故障了，整個系統仍然可以正常運行提供服務

CAP不能同時滿足

必須滿足P

首先分佈式環境，系統需要穩定運行，一台服務器意外斷電，不應該影響系統整體功能正常，另一台或多台服務器還能穩定提供服務，所以分區容錯是必須要滿足。

滿足C

數據一致性，所指的是同一個服務所在不同服務器的數據是同步的。如上改名字的場景 南柯一夢 改為 南柯夢 （在上海的數據庫被修改） 那麼系統要做到滿足數據一致性，必須馬上同步廣州和新加坡的數據庫，這樣才能滿足廣州或者新加坡的訪問者獲得的結果也一致是 “南柯夢” 而不是”南柯一夢”

滿足A

服務可用性，指任何時候訪問服務，都返回結果

A與C是衝突的，上海服務器南柯一夢改為南柯夢后，為了服務可用，此時間訪問新加坡和廣州的服務器，返回的結果應該是南柯一夢(任何時候服務都返回結果) 但是嚴格上講，數據是錯誤的，因為用戶已經改了名字，改為南柯夢，但是數據在上海的才是正確的。

滿足數據一致性必須犧牲服務可用性 或者相反

要達到數據一致性的要求，必須在上海服務器修改數據的同時，同步廣州和新加坡的數據庫，並且在數據同步完成之前，訪問廣州和新加坡的數據庫中這條數據需要等待，返回同步后的結果（一致性）。

失去了服務可用性（這裏服務是等待數據同步完成才返回結果，而不是立刻返回）

因此CAP 要麼 滿足AP （分區服務可用）要麼 CP （分區數據一致）

分佈式中事務

商品購買中的事務

以商品購買生成訂單為例子

網絡上用戶A 購買 一雙鞋子 價格50 付款後生成消費訂單

事務中包含子的服務

這裏簡單設為三個服務，他們是事務相關的

1.商品信息服務

提供商品信息等服務

鞋子 顏色 價格 庫存數量等信息 這裏設 價格price為 50 庫存數 num 9

2.商家賬號收款服務

提供金額收入信息等服務

用戶購買鞋子，需要付款50元到商家賬號

3.用戶消費訂單服務

提供購買消費憑證信息等服務

首先分析用戶購買鞋子，三個服務分別要做什麼

@1 鞋子庫存減1

@2 商家賬號金額增加50

@3 生成 用戶購買鞋子的訂單記錄， 包括數量金額等信息

事務特性

原子性

@1 @2 @3 要麼同時發生，要麼都不發生

一致性

鞋子庫存減少1，收入增加50

隔離性

鞋子庫存減1，後續用戶最多只能購買(9-1=8)雙鞋子

持久性

動作執行成功后，訂單生效，收入新增50生效，庫存減1生效

上述三個服務他們可以在不同的地點，不同機器上部署的，並很常見。

保證數據正確

開啟事務

確定要執行的服務，每個服務的數據庫事務開啟

執行業務

調用庫存減1，轉賬，生成訂單等子服務

提交

業務執行過程中沒有意外，各子服務的數據庫提交事務，生效數據修改

回退

回退，如果服務調用出現了差錯，或者某個子服務執行失敗，可以通過回滾所有數據庫達到數據正確。

補償

某些情況下，某個子服務執行失敗，但是不影響整體業務，也可以提交事務，後續補償機制將失敗的子服務重新執行。

補償機制

個人認為就商品購買而言，補償機制多數情況可以使用且實用。（對強一致要求沒那麼高的情況下）

@1 庫存減1

@2 收入增加50

@ 3生成訂單記錄

如果這次執行的動作， 只有@3失敗，@1 @2成功 說明金額交易，商品庫存業務都沒問題，只是訂單記錄失敗，這是可以提交事務的，訂單錯誤可以生成一條記錄（攜帶商品，金額等信息），發送到MQ消息隊列（或者其他設計）通過消息隊列通知訂單相關服務，補償重新執行生成訂單，達到最終一致性。

分佈式事務控制問題

不同服務在不同區運行

不管是從安全性，穩定性，還是服務粒度細化方便維護等多因素考慮，都是很有必要讓不同的服務分開在不同服務區運行。

單體數據庫的事務不被支持，購買商品到生成訂單所有操作加起來算一個事務，涉及的數據在不同一服務（不同的數據庫），並且同一個服務可能運行在多台服務器上。

數據庫開啟事務針對的是單台服務器，多個服務多個數據庫，並不支持數據庫的事務，需要額外設計處理數據一致性問題（或者最終一致性）

同一個服務運行在多個區

不同服務不在一個服務器，同樣的，分佈式為穩定性可用而生，因此，一個服務大多有在多個區的服務器上運行，開啟事務的時候，如何保證事務開啟提交等事務相關命令每次發送到同一個區的同一個服務器，也是一定要考慮的問題。

分佈式事務處理方式

如上所述分佈式服務代表多個數據庫，不支持數據庫的事務，

如何保證事務中涉及的數據庫數據修改都提交生效或者都回滾。

建立控制中心

控制中心在執行業務時，統一發送開始事務的命令給三個服務，返回狀態

狀態沒問題執行數據修改，

都沒問題就發送給三個服務，提交事務，否在回滾事務

消息機制事務

MQ消息隊列，達到控制事務正確目的，項目中kafka聽的比較多，可在高併發環境下穩定運行，可以通過消息機制發送事務處理結果到子服務，子服務收到消息，通過分析消息內容，做出對應的操作，達到事務一致性或者最終一致性等目的
思考圖：

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

【其他文章推薦】

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

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

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

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

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

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

回顧，再出發

項目	內容
這個作業屬於哪個課程	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  ?

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

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

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

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

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

※聚甘新

  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  ?

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

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

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

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

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

※聚甘新