83行代碼挑戰賽正在進行中，10.24-10.31，等你來戰！
目前已有2500+人參賽，和阿裡工程師同台競技，秀出你的代碼肌肉，抱走MacBook Pro等精美大獎。
參賽域名：
https://code83.ide.aliyun.com/通關攻略：83行代碼第1題
本題有一半題目衍生自阿裡巴巴開發規約，屬于日常開發中需要掌握的規約條例。
以下是本題涉及到的規約條例，需要參賽選手對開發規約靈活應用。
【日期處理1】
【并發處理5】
【集合處理14】
【OOP規約24】
【并發處理7】
【并發處理16】
【控制語句2】
通關攻略：83行代碼第2題
解題思路
本賽題解題思路較為多樣化，不僅限于本攻略提供的思路。
本賽題是一個字首字元串查找的算法題，需要拿到好的性能結果，需要有良好的資料結構。本攻略提供以下幾種思路，但不僅限于以下思路：
自己實作算法結構
• 比如Trie Tree，最基礎資料結構，一個較好的Trie Tree實作，基本能夠達到通關的水準線。建議：查找時盡量不使用遞歸，添加字元串時最好不預配置設定大記憶體空間
• 如果想拿到更高的分數，可以嘗試Radix Tree、PATRICIA Tree、Crit-bit Tree等
• 以上資料結構可通過搜尋引擎查詢相關細節。
巧妙的使用JDK自帶的資料結構
• JDK自帶的很多資料結構性能是較高的，通過巧妙的使用Map、Set、List等資料結構，同樣可以通過本關，并得到較高的分數，而且代碼量很小，可以參閱JDK資料結構部分的文檔。
雙層循環暴力計算
• 暴力通過雙層循環，并使用startsWith進行篩選的方式性能是較為低下的，很容易逾時。但是，本賽題的資料量并不是特别多，這種方式隻要使用得體，同樣能夠通關本賽題。我們可以分析一下，這種雙層循環+startsWith的方式，主要性能消耗在哪裡，是循環本身嗎？還是連續調用startsWith的性能問題？針對性能的消耗點可以采取一些解決辦法（比如，如何既能字首比對，又不會像startsWith一樣逐個字元計算），這種方式同樣能拿到較好的分數。
評分指南
評分資料集分為多個幾十萬數量級的小資料集，以及多個幾百萬數量級的大資料集。在參賽者點選送出後，系統會随機選擇一個小規模資料集和一個大規模資料集，并依次串行運作參賽者的代碼，并針對這兩個資料集對參賽者編寫的代碼從準确性、性能、記憶體消耗次元進行評估。
運作結果：評分系統會随機生成幾十萬條字首字元串輸入到參賽者的代碼中，并評估參賽者的結果是否準确
• 注意：在運作結果次元，小資料集得分占80分，大資料集得分占20分，每個資料集在評分時隻要有一條不準确，那麼該資料集的得分為0分。
性能開銷：代碼運作耗時越短，性能次元分數越高。
• 注意：小資料集需在2分鐘内完成計算，大資料集需在3分鐘内完成計算，如果超過單個資料集的限時，那麼該資料集的評測結果将沒有分數；如果兩個資料集總體計算耗時超過5分鐘，則會報執行逾時，有可能沒有分數，需要參賽者優化代碼的執行性能。
記憶體消耗：代碼運作記憶體消耗越低，記憶體消耗次元分數越高，200MB以下可達到滿分。
• 注意：預設最大記憶體為3GB
FAQ
1、送出後為什麼沒有分數？
觀察一下是否有執行逾時的提示，如果有，說明你的代碼存在性能問題需要優化，如果沒有，請回報給我們。
2、OSS鑒權報錯
排查一下建立OSS Client時填寫的ak、sk是否正确，是否填錯了參數位置。
AK/SK填寫錯誤：
下載下傳OSS檔案參數填寫錯誤：
3、分數低，不知道如何優化？
請參考“解題思路”，選擇一種你擅長的方式進行嘗試。
4、是否能檢視運作結果錯誤的案例？
無法檢視，請根據以下提示情況排查原因：
a：輸出的結果中缺少了部分字首
• 比如，輸入資料要求計算1000個字首字元串的結果，但是輸出時隻有998個
b：部分字首計算的結果不全
• 比如，包含某字首的字元串結果有10條，但是輸出的隻有9條
c：記憶體消耗過多，導緻OOM
5、字首字元串是否包含與它同名的字元串？
比如，輸入的字首是Buffered，如果資料集中有字元串是Buffered，那麼Buffered的計算結果中也是需要包含Buffered
6、為什麼運作結果分數隻有80分？
說明在幾十萬的小資料集上運作正确，但是在幾百萬的大資料集上運作錯誤或記憶體溢出
通關攻略：83行代碼第3題
本題是一道代碼重構的題目。現有程式中存在 Bug，導緻初始代碼無法完全通過單元測試。可參考一下建議，完成第三題的作答。
良好的程式應該遵循“高内聚、低耦合”的标準。在原始的 Store.java 檔案中，把所有商品的價格變化政策都耦合在一個類中，顯然是違反了這一标準。同時，因為不同商品價值變化政策不同，導緻 Store.java 檔案中的 updateValue 方法異常複雜，難以維護。
是以，重構的第一步，需要你借助原有的 updateValue 方法以及 README.md，摸清楚不同商品價值變化的政策。第二步通過良好的抽象，設計出易擴充的程式結構。随後，完善程式代碼，盡可能的準守 Java 開發規約。
評分共4個次元（每個次元滿分為100分），取不同權重綜合計算出總分：
• 代碼規約：在本題中，因為存在多款商品，很有可能需要對比商品名稱，采取不同的價值計算政策。是以需要格外注意規約中對于 Object.equals 方法的約定；
• 代碼複雜度：根據代碼圈複雜度計算該項得分；
• 面向對象：根據代碼中類、接口的設計，計算該項得分；
• 運作結果：會使用背景的4組單元測試驗證程式正确性，正确運作1組可獲得該項的25分；
需要特别注意的是，如果工程代碼出現編譯錯誤，則各項得分均為0。
1、 問：過期後sellin是固定1還是要減成負數？
答：sellin 可以為負數。
點選下方連結，直接傳回大賽官網。
83行代碼重構大師賽 · 1024程式員代碼大賽 · 阿裡雲雲效