今天，晚上9點下班回住的地方，和同事一起走到10號線地鐵（牡丹園站）裏面，看見地鐵地面上有個機子，這時候地鐵還沒有來，於是乎我倆就走到了地鐵的指示機前，是觸屏的，但是不支持多點觸控，點了一點，感覺還可以！有一些方便大家的提示，比如：地鐵出口附近的公交車有哪些？但是沒有詳細的哪一個公交車具體經過的站牌是哪些？有地鐵的最早發車時間和最晚發車時間表，就在看這個的時候，發現了一個bug，13號線開往西直門的全程末班車的時間有一個居然是13:10分，感覺不太對勁，地鐵怎麼可能在13:10分停運呢、於是乎我就上網查地鐵運營時間表！
地鐵乘客信息查詢系統
紅色標出的是錯誤的時間表
公司網址：http://www.sgs.com.cn/news_show.asp?id=1414&channel=5&classid=5
網上查詢正確的結果如下：
希望貴公司發現此bug，趕緊處理！
看到回龍觀這一行，發現時間是23:10。
哎! ---->bug啊！這麼嚴重的bug，數據庫中插入的值肯定輸入錯誤了，這個測試怎麼測試的呢！開發人員的測試呢?QA的審批？等等！
一系列的問題都暴露出來了！軟件的開發週期是多久，開發人員的測試，測試人員的系統測試，這些測試案例怎麼寫的？？種種因素導致了以上的錯誤，其實生活中我們難免出錯！但怎麼才能避免產品出現這麼顯而易見的錯誤呢？
現在的軟件行業都是抱着“短，平，快”的效率發展，很少人原因多花錢在測試身上，都是找一些剛畢業的做測試，開發也是一個人頂3個人用！軟件行業的“高”起點收入下背後往往是一些苦逼的程序員在不停的加班，做事沒有章法，別管用什麼方法，老大隻看結果。往往小公司都是這麼幹的。---->還所謂的敏捷開發。再來看看一些大的公司，華爲，提交一個bug，要找3-4個人review，而且被review的人必須每行代碼都必須講清楚。否則就不允許提交---->入庫。修改100行代碼要寫風險方案評估等等。這些看似浪費時間，降低我們的開發效率。但其實這種方法纔是真正意義上的減少重複錯誤的出現。一些小的開發公司，往往忽略這些，每天的bug都忙着解不過來，哪有什麼時間寫風險評估？比如一些公司會開展分模塊開發，往往都是每一個人單挑一個模塊的大梁，在review的時候，往往別人都看不懂（甚至不熟悉他的模塊的情況下），就匆匆簽字提交，只是會負責任地問一聲“驗了嗎？”往往在這種高壓的工作環境下，人出錯的概率會大一些。然後我們會重複解決一些已經解決的bug，一些bug是因爲我們以爲解決了，但是會引起另一個（甚至好幾個bug）。我就遇到這種事！中國程序員的命運有部分就是是這麼悲慘的！
提點意見：注意總結，提交代碼儘量把這個問題搞清楚，下次在出什麼問題，能很快定位到什麼地方！和同事多交流，這樣知識是流動的，會像一條條河流流向一個方向形成大海一樣。準備一個本子，寫下自己每天解決的bug，然後每隔一個月對比一下，看哪些是重複的問題？養成一個良好的習慣----多寫註釋！尤其在關鍵的地方。
