這一看就是一個多小時，楚垣夕走馬觀花大致看了一下，發現比上次看趙杰那個可是工整的多了。說一絲不茍有些過譽，但是該寫注釋的寫注釋，也沒有明顯的低級錯誤，像趙杰那樣用str存數字之類的奇葩事情是不存在的，只是寫特例的情況也比較多。
似乎要求游戲開發少寫特例是一種不人道的事情。
楚垣夕的水平僅限于挑大面上的刺，你讓他判斷兩段代碼的水平高低，在看起來都不差的情況下，他是百分之百麻爪的。
當然毛病還是得挑，楚垣夕打開一張策劃表格指著問：“哎你們這個表格為什么要求策劃賦ID的時候必須從0開始然后保持連續啊？”
“因為這樣程序好寫啊。”陳然理所當然的說，“程序機制不一樣，這種表格程序運行起來效率多高啊？”
“但是要是進行多個平臺的移植和擴張呢？”楚垣夕閑聊天一樣問：“有些時候游戲是需要交給別的公司運營的對不對？可是版本的更新工作是自己負責的。那你第一個版本傳過去，對方在表格里加了一段內容，就得有一段新ID被占用，然后你們第二個版本更新過去的時候對方怎么辦？他們已經把那段ID占上了，你們傳過去的新版本里也有這一段ID。”
“楚總，我們就是開發一個外包項目，不用考慮那么遠的事情吧？”
陳然知道楚垣夕說的是什么，而且對楚垣夕能問出這么專業的問題來感到很吃驚。
表格中的ID不連續有個很大的好處，就是可以通過“ID段管理”的方式進行擴充和識別。
比如角色表，ID的第一位表示性別，男性為1女性為2，第二至四位表示種族，人類為100，獸人為200，血精靈為300，這樣九個種族各占一個ID段，第五至七位為具體的ID，需要添加角色的時候直接在表格里相應位置添加一行就可以。比如ID為1201017的，就代表男性狼人第17號角色（假定獸人中狼人代號201）。
這種方式有些類似程序中的數據結構，看起來非常清晰。1201017下面一行可能是蜥蜴人，1202001，中間有很大的間斷，這樣如果需要再添加一個18號狼人，直接在17號下面插入即可。
而使用陳然要求的方式，所有ID必須連續，那么必然出現混亂排序。仍舊以角色表為例，第一版100個角色，可能是按種族性別排好順序的0-99，第二版再添加50個新的，完蛋了，沒法往前插，必須從99的后邊開始寫起100-149，新舊兩版的狼人在表格里隔得天南地北，幾個版本過后再也沒有順序可言。
如果這個問題還不嚴重，那楚垣夕說的情況就嚴重多了。項目組給運營方傳過去的第一個版本的表格是0-99，寫的清清楚楚，運營方拿過去一看，角色這么少？這不好賣卡牌啊，于是自己添加了50個新角色，是100-149，然后拿去賣。
然而項目開發組不知道，下一個版本他們也添加了50個新的角色，ID同樣是100-149，傳給運營方，這時運營方除了草泥馬簡直無話可說。
楚垣夕能夠接受陳然的解釋，但是接受不了陳然的工作方式，因為他所謂的效率高，對于產品來說高不了萬分之一，就連代碼“好寫”都要打一個星號。