是不是服務端編程剛開始都得從寫業務開始？

12-01

小菜剛畢業一年，先前一直在做linux服務端的開發，最近進入一家遊戲公司，寫c++遊戲服務端，進來了一個月，都是寫遊戲邏輯，感覺好沒意思。但問了一位前輩都說要寫底層網路架構，都得先從業務寫1，2年起...可是我平常加班是常態，差不多是996，業餘時間也很難自己學習。平常工作又是寫無聊的遊戲邏輯，求指點。

業務邏輯複雜起來是很考驗你的coding skill的。如果忽略技巧，用蠻力寫業務邏輯，不追求代碼之神，敲完就算，當然無聊啦。

---

你可以

switch （gender）: case "male": if (level === "gold") {


     } else if (level === "silver") {
     } else {
     }

     break;

  case "female":

     if (level === "gold") {
     } else if (level === "silver") {
     } else {
     }

     break;

  case "unknown":

     if (level === "gold") {
     } else if (level === "silver") {
     } else {
     }

     break;

這是一般業務邏輯程序員認為的「業務邏輯」，你每天寫這種代碼，當然覺得無聊。

你也可以

GENDER = { MALE: "male", FEMALE: "female』, UNKNOWN: "unknown" } LEVEL = { GOLD: "gold", SILVER: "silver", BRONZE: "bronze" }


avatars = {

  GENDER.MALE =&> {

     LEVEL.GOLD =&>

     LEVEL.SILVER =&>

     LEVEL.BRONZE =&>

  },

  GENDER.FEMALE =&> {

     LEVEL.GOLD =&>

     LEVEL.SILVER =&>

     LEVEL.BRONZE =&>

  },

  GENDER.UNKNOWN =&> {

     LEVEL.GOLD =&>

     LEVEL.SILVER =&>

     LEVEL.BRONZE =&>

  }

}
user.gender = (user.gender in GENDER) ? user.gender : GENDER.UNKNOWN

user.level  = (user.level in LEVEL) ? user.level : LEVEL.BRONZE
user.avatar = avatars[user.gender][user.level];

這樣寫業務邏輯就有趣多了。

後一種是Data Driven的思考方式，用數據，或者設計數據來驅動邏輯，讓邏輯的外觀從代碼里消失，從而讓代碼更緊湊，節奏感更強，讀起來更舒服，改起來更方便。這是在web開發里常用的技巧，遊戲邏輯里應該也有不少數據驅動的場景，如果你能為特定邏輯設計出一目了然的數據，就能大大降低邏輯的複雜度，寫出的東西更魯棒，效率通常也更高，就不會覺得寫這種業務無聊了，因為有技巧在裡面。

---

你可以

for (items) { item[..] = // or if () { return item } }

也可以

items.each(item =&> process(item)) items.filter(item =&> verify(item)) items.map(item =&> update(item))

用好函數式，能幫你化解各種無聊的循環，外觀上看，代碼的抽象層次更高了，語句更清晰了，讀起來更舒服了。

---

你可以

class { showLogo () { showAd() ... } showBanner () { showAd() ... } showSidebar () { showAd() ... } }

也可以

class { @decorated by AdDecorator showLogo, showBanner, showSidebar ... }

簡單的Decorator，是不是讓代碼緊湊精簡，有意思多了？

---

你可以

s : string = "thanks " if () { s = s + name s = s + " for purchasing if () { s = s + quantity s = s + product } } s = s + ..

也可以

t = "thanks {name} for purchasing {quantity} {product} .." s = t.compile({name, quantity, product})

把比較髒的局部拼接邏輯變成一目了然的模版，品味高出截。

---

你可以

function attach() { app.A = db.update(app.states) log(..) } function move() { app.B = db.update(app.stats) log(..) }

也可以

app.on("change", "stats", stats =&> { db.update(stats) log(..) }) function attack() { app.update(A ..) } function move() { app.update(B ..) }

...

同樣繁雜的業務邏輯可以寫得拖沓重複，無聊透頂，也可以寫得精粹漂亮，有樂趣和美感啊。只需要在敲鍵盤前多花點時間來構思，並不難。

你確定底層編程需要更高階的思想嗎，其實只是數據和操作的形態不同罷了，思維和技巧還是適用的。再說要多底層才能滿足你的虛榮心呢？

* 以上代碼非C++代碼，概念實現請參照編程語言。
* 感謝你看完，如果想評論，請對題，不要我說了一通你隨便一扯，否定為己任，我沒興趣接受那種評論

vultr.com 有目前性價比最高的 $5 VPS，768的內存

業務是上層。底層框架為上層服務。
不懂業務寫底層框架，相當於不懂需求寫業務代碼。

網路框架就那幾點東西，有什麼好寫的，反而你應該更多關注遊戲邏輯框架，怎麼做到可擴展性和可復用性等等。

業務必須要熟悉，拋開業務談開發都是扯淡。技術不重要，重要的是如何用技術實現業務。

你覺得你所謂的底層代碼和你所謂的業務邏輯有多大的區別？

無非一個是一段描述講一個故事，一個故事講網卡收發包，一個故事講一個道具從背包里拿出來。

你覺得呢？

表示來鵝廠實習。。一開始就是做框架優化。。啥都不會

框架的需求就來自於業務邏輯，自己寫業務被戳到痛點才能對框架做出最切實的改進。
舉個例子，進程間非同步邏輯寫吐了，一看到協程的概念就如獲至寶，知道可以改進框架了。

本質上需求數量是倒金字塔結構導致大多數人都必須做那些瑣碎無聊的事情；業務系統特性多變化多，團隊分工合作有優勢。而且正如樓上有些答案說過的，網路核心就那麼點東西，一個人能搞定就搞定，搞不定就換一個人，多放幾個人過去也插不上手，所以情況就是這樣了。

在很多行業中都有一個非常重要的東西，叫做行業經驗。開發也是如此，只是相對一些行業而言表面上看起來沒那麼重要。
我曾經面試過一個要來做架構師的人，號稱對設計模式熟悉無比。這裡不去討論設計模式方面的能力和架構多大關係，我更關係的是如果你沒有相應的行業經驗，架構上面其實是無從談起的。
當然，如果說一個公司能夠以很精確、清晰，細緻甚至數學方式描述自己的需求和相關邊界，或許做架構不需要了解太多業務上的東西。這也僅僅是或許而已。何況我還沒見過哪個公司能夠做到這一點。
舉個簡單例子，你做架構的時候，你是不是要了解不同層面數據CURD操作的分布？吞吐和延遲如何平衡？哪些是要求儘可能不丟失數據的操作，哪些是可以修正的操作，哪些是可以允許出現丟失的操作？我是不是需要做一些分散式的東西？光是業務需求的適配，性能需求邊界的確認就讓你夠頭痛了。而這些都是需要對業務足夠熟悉的前提下才能做到的。
如果說你可以做一個足夠強大的系統，可以通過配置來適應各種需求，那麼先不說能不能做出這樣一個系統，即便做出來了其複雜程度可能會導致每次調整都要花費相當大的代價。所以即便在這種理想的假設下，你也需要對業務足夠熟悉。

其實了解框架層面的東西，或者你說的底層網路架構層面的東西，和業務需求並不一定是矛盾的。你完全可以在寫邏輯和時候向前輩請教一些相關問題或者疑問，提出自己的看法。也有的時候你能夠在開發的過程中接觸一些框架層面的代碼，自己閱讀和思考也是一個了解除了你本身工作之外更多信息的辦法。
在實際工作中，就我個人經驗而言，你總是有很多機會了解自己部門甚至其他門的很多技術相關知識，關鍵看你自己如何去做。

但終歸沒有相當程度業務理解的支撐，你是無法做出足夠有效的架構的。

業務邏輯三年。正轉向底層開發。從面對業務轉向面向技術。感覺自己比直接做底層開發的更知道為什麼這麼做。並且不會讓做業務開發的討厭。

要不你先寫一個開源的證明一下實力？

可以關注下雲風的skynet
這是我的研究還有開源的項目雲風skynet服務端框架研究

其實我覺得業務邏輯可以作為考驗一個程序員水平的重要指標。不要說都是調用第三方庫什麼的。當業務邏輯到了一定數量的時候，比如100個，每個邏輯之間有點差異，又有部分共同點。那麼怎麼提高擴展性和維護性是一個程序員最基本的要求。

業務就是王道阿

網路層這種通用的東東，多看幾種不同的實現，開開眼界就行了，沒必要糾結。一個進程能容納1000人在線還是2000人在線，不是多大問題，依然有機會優化。還是更多關注代碼的健壯性、擴展性、可維護性比較重要。設計模式與業務邏輯的結合，很多遊戲公司做的不好。可能寫c++的人不是太重視設計模式。

一定要記住：量變才會質變

握爪，我也是寫遊戲邏輯的。。。。底層現在讓你寫，你也不敢碰吧。。。。遊戲伺服器責任還是很大吧。。。。。。

如果大家都去寫底層框架了，那業務邏輯誰去寫。

人家需要的是編碼員！底層框架不會讓菜鳥接觸的！