20155303 實驗二 Java面向對象程序設計
目錄
一、單元測試和TDD
用程序解決問題時，要學會寫以下三種代碼：
- 偽代碼
- 產品代碼
- 測試代碼
正確的順序應為：偽代碼（思路）→ 測試代碼（產品預期功能）→ 產品代碼（實現預期功能），這種開發方法叫“測試驅動開發”（TDD）。TDD的一般步驟如下：
- 明確當前要完成的功能，記錄成一個測試列表
- 快速完成編寫針對此功能的測試用例
- 測試代碼編譯不通過（沒產品代碼呢）
- 編寫產品代碼
- 測試通過
- 對代碼進行重構，並保證測試通過（重構下次實驗練習）
- 循環完成所有功能的開發
基於TDD，可以有效避免過度開發的現象，因為我們只需要讓測試通過即可。
任務一：實現百分制成績轉成“優、良、中、及格、不及格”五級制成績的功能
以這個任務為例，我們來對TDD方法進行一次小小的實踐。
首先要明白自己的程序需要進行哪些操作？要實現什么目標？偽代碼可以幫我們理清思路。
百分制轉五分制：
如果成績小於60，轉成“不及格”
如果成績在60與70之間，轉成“及格”
如果成績在70與80之間，轉成“中等”
如果成績在80與90之間，轉成“良好”
如果成績在90與100之間，轉成“優秀”
其他，轉成“錯誤”
偽代碼不需要說明具體調用的方法名，甚至不需要強調你打算使用的語言，理清思路即可。
其次，選擇一種語言把偽代碼實現，也就成了產品代碼。
public class MyUtil{
public static String percentage2fivegrade(int grade){
//如果成績小於0，轉成“錯誤”
if ((grade < 0))
return "錯誤";
//如果成績小於60，轉成“不及格”
else if (grade < 60)
return "不及格";
//如果成績在60與70之間，轉成“及格”
else if (grade < 70)
return "及格";
//如果成績在70與80之間，轉成“中等”
else if (grade < 80)
return "中等";
//如果成績在80與90之間，轉成“良好”
else if (grade < 90)
return "良好";
//如果成績在90與100之間，轉成“優秀”
else if (grade <= 100)
return "優秀";
//如果成績大於100，轉成“錯誤”
else
return "錯誤";
}
}
產品代碼是為用戶提供的，為了保證正確性，我們需要對自己的程序進行測試，考慮所有可能的情況，來判斷結果是否合乎要求。這是我們就需要寫測試代碼。
根據我們現在的理解，測試代碼不就是不斷調用System.out.println()，來判斷輸出是否合乎預期嘛？所以可能會寫成下面這種代碼：
public class MyUtilTest {
public static void main(String[] args) {
if(MyUtil.percentage2fivegrade(55) != "不及格")
System.out.println("test failed!");
else if(MyUtil.percentage2fivegrade(65) != "及格")
System.out.println("test failed!");
else if(MyUtil.percentage2fivegrade(75) != "中等")
System.out.println("test failed!");
else if(MyUtil.percentage2fivegrade(85) != "良好")
System.out.println("test failed!");
else if(MyUtil.percentage2fivegrade(95) != "優秀")
System.out.println("test failed!");
else
System.out.println("test passed!");
}
}
如果輸出test passed!，那就代表通過測試咯~
可是...如果輸出test failed!呢？那事情就很糟糕了。我們需要把每一個測試用例的結果都打印出來，看看到底是哪里出現了該死的“test failed”。本題中的測試用例很少，那如果做大的項目時有成千上萬個用例呢？
不用擔心！Java中有單元測試工具JUnit來輔助進行TDD，我們用TDD的方式把前面百分制轉五分制的例子重寫一次，體會一下有測試工具支持的開發的好處。
鼠標放在需要測試的類上單擊，出現一個黃色燈泡，點擊選擇“Create Test”，就可以新建一個測試類啦~
那么，我們可以這么寫測試代碼：
import org.junit.Test;
import junit.framework.TestCase; //注意導包！！！
public class MyUtilTest extends TestCase {
@Test
public void testNormal() {
assertEquals("不及格", MyUtil.percentage2fivegrade(55));
assertEquals("及格", MyUtil.percentage2fivegrade(65));
assertEquals("中等", MyUtil.percentage2fivegrade(75));
assertEquals("良好", MyUtil.percentage2fivegrade(85));
assertEquals("優秀", MyUtil.percentage2fivegrade(95));
}
}
如果出現問題，IDEA就會提示我們具體是哪一步出錯了。比如下面這個實例（我把95分的斷言值改成了“良好”，我們知道測試肯定不會通過）：
可以看出，IDEA提示我們Expected:良好； Actual:優秀，最后一行還有at test2.MyUtilTest.testNormal(MyUtilTest.java:11)，這下我們明白了，是testNormal()方法中一個為“良好”的斷言錯了。這樣一來，是不是比上面那種方法方便很多了呢？
當然了，測試代碼不能隨便一寫草草了事，作為開發者的我們必須要考慮得足夠周全，尤其是各種邊界情況以及非法輸入等等。比如本題我們需要添加testExceptions()、testBoundary()等等各種方法進行測試。這些老師的教程里寫得很詳細，我在此就不贅述了。
任務二：以TDD的方式研究學習StringBuffer
這個任務主要鍛煉我們自己寫JUnit測試用例的能力。老師在教程里給出的程序如下：
public static void main(String [] args){
StringBuffer buffer = new StringBuffer();
buffer.append('S');
buffer.append("tringBuffer");
System.out.println(buffer.charAt(1));
System.out.println(buffer.capacity());
System.out.println(buffer.length());
System.out.println(buffer.indexOf("tring"));
System.out.println("buffer = " + buffer.toString());
首先我們需要對這個程序進行改寫，寫成上面的產品代碼那種類型的，以便於我們進行測試。
對於這個程序，我們先來看一看哪些方法需要測試？有四個，charAt()、capacity()、length()、indexOf。在產品代碼里，我們需要為這四個方法加上返回值，並與我們的斷言進行比較。產品代碼如下：
public class StringBufferDemo{
StringBuffer buffer = new StringBuffer();
public StringBufferDemo(StringBuffer buffer){
this.buffer = buffer;
}
public Character charAt(int i){
return buffer.charAt(i);
}
public int capacity(){
return buffer.capacity();
}
public int length(){
return buffer.length();
}
public int indexOf(String buf) {
return buffer.indexOf(buf);
}
}
接下來我們需要對調用各種方法的返回值進行猜測。查詢API文檔可知，對charAt(int i)的解釋為：“返回此序列中指定索引處的 char 值。第一個 char 值在索引 0 處，第二個在索引 1 處，依此類推，這類似於數組索引。”indexOf(String s)則返回輸入的子字符串的第一個字母在母字符串的位置。這兩個看起來都比較好理解，那capacity()和length()呢？我在學習StringBuffer的時候也遇到了這樣的困惑，對於這兩者之間的區別問題，可以參考我博客的“問題解決”模塊。
基於以上的思考和學習，我們可以對各個方法的返回值有一個精確地分析，接下來只需要比較產品代碼中的方法與我們的斷言值是否相等即可。
出於對老師這篇博客中問題的思考，我設置了長度不同的三個字符串進行測試，代碼如下：
public class StringBufferDemoTest extends TestCase {
StringBuffer a = new StringBuffer("StringBuffer");//測試12個字符（<=16）
StringBuffer b = new StringBuffer("StringBufferStringBuffer");//測試24個字符（>16&&<=34）
StringBuffer c = new StringBuffer("StringBufferStringBufferStringBuffer");//測試36個字符（>=34）
@Test
public void testcharAt() throws Exception{
assertEquals('S',a.charAt(0));
assertEquals('g',a.charAt(5));
assertEquals('r',a.charAt(11));
}
@Test
public void testcapacity() throws Exception{
assertEquals(28,a.capacity());
assertEquals(40,b.capacity());
assertEquals(52,c.capacity());
}
@Test
public void testlength() throws Exception{
assertEquals(12,a.length());
assertEquals(24,b.length());
assertEquals(36,c.length());
}
@Test
public void testindexOf() throws Exception{
assertEquals(0,a.indexOf("Str"));
assertEquals(5,a.indexOf("gBu"));
assertEquals(10,a.indexOf("er"));
}
}
可以看到，出現了“green bar”，說明測試通過了，我們對StringBuffer也有了更加深刻的認識。
二、面向對象三要素：封裝、繼承、多態
面向對象(Object-Oriented)的三要素包括：封裝、繼承、多態。面向對象的思想涉及到軟件開發的各個方面，如面向對象分析（OOA）、面向對象設計（OOD）、面向對象編程實現(OOP)。OOA根據抽象關鍵的問題域來分解系統，關注是什么（what）。OOD是一種提供符號設計系統的面向對象的實現過程，用非常接近問題域術語的方法把系統構造成“現實世界”的對象，關注怎么做（how）,通過模型來實現功能規范。OOP則在設計的基礎上用編程語言（如Java）編碼。貫穿OOA、OOD和OOP的主線正是抽象。
任務三：使用StarUML對實驗二中的代碼進行建模
UML是一種通用的建模語言，可以非常直觀地表現出各個結構之間的關系。
基於以上學習，我們在UML中實現了類，繼承和接口的組合：
當然，UML還可以實現更多更復雜的功能，以上只是一個小小的實踐。
三、設計模式
面向對象三要素是“封裝、繼承、多態”，任何面向對象編程語言都會在語法上支持這三要素。如何借助抽象思維用好三要素特別是多態還是非常困難的，S.O.L.I.D類設計原則是一個很好的指導：
- SRP(Single Responsibility Principle,單一職責原則)
- OCP(Open-Closed Principle,開放-封閉原則)
- LSP(Liskov Substitusion Principle,Liskov替換原則)
- ISP(Interface Segregation Principle,接口分離原則)
- DIP(Dependency Inversion Principle,依賴倒置原則)
下面，我們通過具體的題目來學習設計模式。
任務四：對MyDoc類進行擴充，讓其支持Long類，初步理解設計模式
OCP是OOD中最重要的一個原則，要求軟件實體（類，模塊，函數等）應該對擴充開放，對修改封閉。也就是說，軟件模塊的行為必須是可以擴充的，在應用需求改變或需要滿足新的應用需求時，我們要讓模塊以不同的方式工作；同時，模塊的源代碼是不可改動的，任何人都不許修改已有模塊的源代碼。OCP可以用以下手段實現：（1）抽象和繼承，（2）面向接口編程。
以這道題為例，已有的支持Int型的代碼如下：
abstract class Data{
public abstract void DisplayValue();
}
class Integer extends Data {
int value;
Integer(){
value=100;
}
public void DisplayValue(){
System.out.println(value);
}
}
class Document {
Data pd;
Document() {
pd=new Integer();
}
public void DisplayData(){
pd.DisplayValue();
}
}
public class MyDoc {
static Document d;
public static void main(String[] args) {
d = new Document();
d.DisplayData();
}
}
如果要求支持Long類，Document類要修改構造方法，這還違反了OCP原則。封裝、繼承、多態解決不了問題了，這時需要設計模式了：
abstract class Data {
abstract public void DisplayValue();
}
class Integer extends Data {
int value;
Integer() {
value=100;
}
public void DisplayValue(){
System.out.println (value);
}
}
// Pattern Classes
abstract class Factory {
abstract public Data CreateDataObject();
}
class IntFactory extends Factory {
public Data CreateDataObject(){
return new Integer();
}
}
這樣一來，我們只需要class Long extends Data、class LongFactory extends Factory即可使系統支持Long類型，測試代碼如下：
public class MyDoc {
static Document d;
public static void main(String[] args) {
d = new Document(new LongFactory());
d.DisplayData();
}
}
我們看到，通過增加了一層抽象層使代碼符合了OCP原則，使代碼有良好的可擴充性、可維護性。不過，設計模式也不能過度使用，具體在哪些場合應用還要看實際問題。
附：練習
任務五：以TDD的方式開發一個復數類Complex
經過以上的學習，我們已經可以基本熟練地應用TDD方法，並跟隨TDD方法的節奏設計出偽代碼、產品代碼和測試代碼了，這個任務算是對以上學習內容的回顧。
TDD的編碼節奏是：
- 增加測試代碼，JUnit出現紅條
- 修改產品代碼
- JUnit出現綠條，任務完成
首先，我們來寫偽代碼：
（1）屬性：復數包含實部和虛部兩個部分，
double RealPart;復數的實部
double ImagePart;復數的虛部
getRealPart():返回復數的實部
getImagePart();返回復數的虛部
setRealPart():設置復數的實部
setImagePart();設置復數的虛部
輸出形式：a+bi
（2）方法：
①定義構造函數
public Complex()
public Complex(double R,double I)
②定義公有方法:加減乘除
Complex ComplexAdd(Complex a):實現復數加法
Complex ComplexSub(Complex a):實現復數減法
Complex ComplexMulti(Complex a):實現復數乘法
Complex ComplexDiv(Complex a):實現復數除法
③Override Object
public String toString():將計算結果轉化為字符串形式並輸出
在測試代碼中，我們需要對以上提到的方法進行測試。寫測試代碼時，如果調用了不存在的方法，可以點擊這個方法旁邊的小燈泡進行修復，這個操作會對應的產品代碼中增加一個方法，我們只需要描述這個方法的操作即可，非常方便。
public class ComplexTest extends TestCase {
Complex c1 = new Complex(0, 3);
Complex c2 = new Complex(-1, -1);
Complex c3 = new Complex(2,1);
@Test
public void testgetRealPart() throws Exception {
assertEquals(-1.0, Complex.getRealPart(-1.0));
assertEquals(5.0, Complex.getRealPart(5.0));
assertEquals(0.0, Complex.getRealPart(0.0));
}
@Test
public void testgetImagePart() throws Exception {
assertEquals(-1.0, Complex.getImagePart(-1.0));
assertEquals(5.0, Complex.getImagePart(5.0));
assertEquals(0.0, Complex.getImagePart(0.0));
}
@Test
public void testComplexAdd() throws Exception {
assertEquals("-1.0+2.0i", c1.ComplexAdd(c2).toString());
assertEquals("2.0+4.0i", c1.ComplexAdd(c3).toString());
assertEquals("1.0", c2.ComplexAdd(c3).toString());
}
@Test
public void testComplexSub() throws Exception {
assertEquals("1.0+4.0i", c1.ComplexSub(c2).toString());
assertEquals("-2.0+2.0i", c1.ComplexSub(c3).toString());
assertEquals("-3.0 -2.0i", c2.ComplexSub(c3).toString());
}
@Test
public void testComplexMulti() throws Exception {
assertEquals("3.0 -3.0i", c1.ComplexMulti(c2).toString());
assertEquals("-3.0+6.0i", c1.ComplexMulti(c3).toString());
assertEquals("-1.0 -3.0i", c2.ComplexMulti(c3).toString());
}
@Test
public void testComplexComplexDiv() throws Exception {
assertEquals("-1.5 -1.5i", c1.ComplexDiv(c2).toString());
assertEquals("1.2+0.6i", c1.ComplexDiv(c3).toString());
assertEquals("-0.6 -0.6i", c2.ComplexDiv(c3).toString());
}
}
通過不斷修復，產品代碼也寫好了，測試一下能不能出現“green bar”，如果測試不通過再根據提示修改產品代碼。
產品代碼如下：
public class Complex{
private double r;
private double i;
public Complex(double r, double i) {
this.r = r;
this.i = i;
}
public static double getRealPart(double r) {
return r;
}
public static double getImagePart(double i) {
return i;
}
public Complex ComplexAdd(Complex c) {
return new Complex(r + c.r, i + c.i);
}
public Complex ComplexSub(Complex c) {
return new Complex(r - c.r, i - c.i);
}
public Complex ComplexMulti(Complex c) {
return new Complex(r * c.r - i * c.i, r * c.i + i * c.r);
}
public Complex ComplexDiv(Complex c) {
return new Complex((r * c.i + i * c.r)/(c.i * c.i + c.r * c.r), (i * c.i + r * c.r)/(c.i * c.i + c.r * c.r));
}
public String toString() {
String s = " ";
if (i > 0)
s = r + "+" + i + "i";
if (i == 0)
s = r + "";
if (i < 0)
s = r + " " + i + "i";
return s;
}
}
四、實驗過程中遇到的問題及解決
問題一：@Test或者import junit.framework.TestCase;是紅色的怎么辦？
我和大多數同學一樣都遇到了這種情況，是因為沒有導入相應的包。參考老師的教程並查閱了相關資料解決了這個問題。
解決方法如下：
首先，進入頁面左上角File→Project Structure...：
進入之后，根據你的IDEA安裝地址導入這兩個包就可以了。
問題二：如何寫好一個測試單元？怎樣使用各種斷言方法？
本次實驗我們着重學習了如何使用Junit進行單元測試，深入思考一下：單元測試中需要考慮哪些情況呢？
博客單元測試應該測試什么？——Right-BICEP對這個問題進行了較為詳細的分析，大致可以總結為：
-
結果是否正確
這是最基本的，就是看程序運行之后的結構和文檔是否一致。
-
邊界條件
- 一致性(Conformance)——值是否符合預期的格式？
- 有序性(Ordering)——一組值是該有序的，還是該無序的？
- 區間性(Range)——值是否在一個合理的最大值和最小值的范圍之內？
- 引用、耦合性(Reference)——代碼是否引用了一些不受代碼本身直接控制的外部因素？
- 完全偽造或者不一致的輸入數據、格式錯誤的數據、空值或者不完整的值，如0， 0.0， “”， null之類的等等。
-
...
在本次實驗的單元測試中，我們大量使用了assertEquals()方法，來判斷測試值是否與期望值相等。assertEquals()是應用非常廣泛的一個斷言，它的作用是比較實際的值和用戶預期的值是否一樣。
通過學習了解到，還可以使用assertThat(actual, matcher)方法，查看實際值是否滿足指定的條件。assertThat(actual, matcher)方法可以實現一般匹配、字符串匹配、數值匹配、collection匹配等等，非常實用。
以下面這個程序為例，我隨意寫了幾個方法，打算使用assertThat(actual, matcher)方法進行測試：
import java.util.List;
import java.util.ArrayList;
public class AssertDemo {
public int add(int a, int b) {
return a + b;
}
public String getName(String name) {
return name;
}
public List<String> getList(String item) {
List<String> l = new ArrayList<>();
l.add(item);
return l;
}
}
JUnit4.4引入了Hamcrest框架，Hamcest提供了一套匹配符Matcher，這些匹配符更接近自然語言，可讀性高，更加靈活。不過需要注意的是，使用assertThat(actual, matcher)方法必須導入相應的類或方法：
import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.matchers.JUnitMatchers.*;
得到測試代碼如下：
public class AssertDemoTest {
@Test
public void testAdd() {
//一般匹配符
int s = new AssertDemo().add(1, 1);
//anything：無論什么條件，測試都通過
assertThat(s, anything());
//is：變量的值等於指定值時，測試通過
assertThat(s, is(2));
//not：和is相反，變量的值不等於指定值時，測試通過
assertThat(s, not(1));
}
@Test
public void testgetName() {
//字符串匹配符
String n = new AssertDemo().getName("Magical");
//containsString：字符串變量中包含指定字符串時，測試通過
assertThat(n, containsString("ci"));
//startsWith：字符串變量以指定字符串開頭時，測試通過
assertThat(n, startsWith("Ma"));
//endsWith：字符串變量以指定字符串結尾時，測試通過
assertThat(n, endsWith("l"));
//euqalTo：字符串變量等於指定字符串時，測試通過
assertThat(n, equalTo("Magical"));
}
@Test
public void testgetList(){
//集合匹配符
List<String> l = new AssertDemo().getList("Magical");
//hasItem：Iterable變量中含有指定元素時，測試通過
assertThat(l, hasItem("Magical"));
}
}
JUnit框架Assert類中還有很多斷言方法，比如assertTrue與assertFalse斷言、assertNull與assertNotNull斷言、assertSame與assertNotSame斷言、fail斷言等等，還有待我們進一步學習總結。
問題三：如何解決這個“red bar”？
在實驗過程中遇到了這樣的問題：
在測試類中定義了c1、c2和c3：
Complex c1 = new Complex(0, 3);
Complex c2 = new Complex(-1, -1);
Complex c3 = new Complex(2,1);
並測試復數的減法：
public void testComplexSub() throws Exception {
assertEquals("1.0+4.0i", c1.ComplexSub(c2).toString());
assertEquals("-2.0+2.0i", c1.ComplexSub(c3).toString());
assertEquals("-3.0 -2.0i", c2.ComplexSub(c3).toString());
}
但是測試的時候卻出現了“red bar”：
檢查產品代碼中復數的減法也沒有問題：
public Complex ComplexSub(Complex c) {
return new Complex(r - c.r, i - c.i);
}
那錯誤在哪里呢？
觀察錯誤提示，斷言值為-3.0 -2.0i但實際輸出值為-5.0i，-5.0恰巧是-3.0 -2.0i實部和虛部的和。好像有點思路了...返回去看產品代碼中的toString()方法，注意到當虛部小於零時，我直接進行了s = r + i + "i";操作，而在Java中，這個式子的含義是：先計算r + i的值，再轉化為字符串形式，所以會得到錯誤的輸出。將代碼改為：s = r + " " + i + "i"，先進行強制類型轉換，就解決了這個問題。
問題四：Java中StringBuffer的capacity問題探究
在研究學習StringBuffer的過程中，對capacity()有疑惑，查詢了API文檔了解到：
從API查到capacity的作用是查看StringBuffer的容器容量是多少，剛開始納悶這個跟length的區別在哪？
於是自己寫了一個程序進行測試分析：
public class capacityDemo {
public static void main(String[] args) {
StringBuffer b = new StringBuffer();//初始分配空間為0+16
for(int i = 0; i < 50; i++){
b = b.append("A");
System.out.println(b);
System.out.print("length()="+b.length());
System.out.println("capacity()="+b.capacity());
}
}
}
打印運行結果：
可以看到，對於空字符串，調用capacity()方法初始分配值為16；大小超過16時則擴充容量為34，再次擴充得到70。
那么問題來了！16、34、70是怎么得到的呢？試驗了幾次還是有點不解。所以直接跟進源碼分析。
直接通過new StringBuffer(String str)；時，capacity是str.length+16，從源碼可知：
如果小於16則默認容器的大小為16。如果大於16則會調用expandCapacity 函數進行容量的擴展，擴展方式如下：
由源碼可以看到擴展的規則是把舊的容量（value的長度）*2+2，然后與現有的比較，如果小於則把現有的容量當做新的，如果大於則用新得到的容量。
所以第一次append時，小於16則不需擴展，如果大於16則會直接擴展到34（16*2+2），比較得到大於append后的長度的話則用34，如果不 是則用append后的長度。
此時capacity的大小等於append后的長度，如果在append的話，若不超過70（34*2+2）的話，此時則capacity為70，如果超過70則繼續用第二次append后的總長度。
這樣一來，對capacity()的理解就比較透徹了。
五、實驗體會與總結
這周的實驗內容非常豐富，主要學習了如何編寫測試代碼。
在開發軟件的過程中，用戶需要實際運行所編寫的代碼以確保程序的正確性。當軟件變得越來越大，再去添加新的功能或做一些新的改動時，就很容易帶來新的問題，甚至會使程序無法正常運行。然而要手動的運行代碼，測試代碼的可行性也是非常枯燥以及非常耗費時間的事情。
為了減少這種手動測試，可以通過創建單元測試來自動完成測試的工作。當修改代碼或者添加新功能后，可以執行單元測試來保證代碼運行無誤。所有測試工作都是由單元測試自動完成的，開發人員所要做的就是看看程序的執行狀態。
使用單元測試的另一個理由是實現測試驅動的開發。測試驅動的開發嘗試首先寫出單元測試，然后完成實際的代碼。通過單元測試來提供類的定義，當實際開始編寫代碼時，用戶僅僅需要做的就是具體類的實現，只要單元測試運行通過，代碼的實現也將告一段落了。寫單元測試的同時，也在同時在做項目的設計，當項目結束后，單元測試還將是不錯的文檔，何樂而不為呢？
在Java語言中，可以通過JUnit框架進行單元測試。單元測試的實現是很簡單的，可以認為它只是判斷在某一個時刻，程序運行的值和預期的值是否一致，但在實際的應用的時候是很靈活的，在此介紹JUnit中的一些斷言以及JUnit測試框架的使用，使讀者能夠快速的進入單元測試的領域，更快的進行開發。
JUnit提供了一些輔助函數，用於幫助開發人員確定某些被測試函數是否工作正常。通常而言，把所有這些函數統稱為斷言，斷言是單元測試最基本的組成部分。
除此之外，本次實驗還學習了TDD方式、UML建模、S.O.L.I.D原則以及設計模式等等，既加深了對之前內容的理解，又規范了我們的編程流程，對思維也是一個很好的梳理，希望能把這些知識在今后的學習實踐中廣泛應用。
| 步驟 | 耗時 | 百分比 |
|---|---|---|
| 需求分析 | 12min | 10% |
| 設計 | 10min | 8% |
| 代碼實現 | 48min | 40% |
| 測試 | 40min | 34% |
| 分析總結 | 10min | 8% |