Re: [討論] 怎樣算是一個合格的junior cpp programme
※ 引述《HZYSoft (PCMan)》之銘言:
: 補充一下,TDD 是還沒有開始寫任何的 code 之前,就先針對
: 程式寫好之後 "預期應該要有的行為" 先寫 test cases
: 接著,先跑一次測試親眼看著他 fail
: 因為還沒寫任何 code,所以測試絕對會 fail,
: 如果沒寫 code 卻 pass 那表示你的 test case 根本沒有測到。
: 接著才開始寫 code,重複跑測試直到確認 pass 為止,就是完成了。
: 不同於先寫 code 再測試,TDD 是顛倒,先測試再寫 code,所以才叫 test driven
: 如果程式被報 bug,也是先寫一個會 fail 的 test case,確認可以重現 bug
: 接著才開始改 code 修正,直到測試 pass 為止,就表示修好了。
: 這是一個觀念很特別的流派,他們的主張都是有道理的,就只是比較違反直覺不好實現。: 如果你無法先寫出測試,那表示你還沒弄清楚要實作什麼行為,
: 或是你原先構思的 API 介面難以使用,以至於你寫不出 test case
: 這是強迫你釐清 spec 以及設計好介面的方法,但實在有點極端,被不少人視為邪教 XD
推文看到有人問前端.
我個人是做客戶端所以很多傳統的測試方法論對介面其實效用很低.
上述段落讓我想起以前寫作的經驗.單純分享.
我在2018~2020年在阿布達比UB維護手機線上遊戲Growtopia.
當時的案子有很多駭客想要破解我們的遊戲的攻擊行為.
當時的主程式教給我一個我以前沒這樣試過的技巧.
(但我必須強調.這整個系統跟時程就是不允許我們重構.
所以也不可能有甚麼有序的測試方式.
功能($$$)產生的速度就是比測試碼(COST)來得快
該專案幾年的程式碼簡單來講就是靠優秀的程式員無止盡的縫補.)
不過.當我分享給同僚的時候.他們都給我一種我在講甚麼歪理的眼神.
簡單說
我們當時遇到很多透過奇妙行為(譬如說破解封包)來try我們遊戲server的行為.
因為那些行為不是正規動作.所以我們的QA部門無法用正規手段重現這些步驟.
(當然終歸到底就是沒有那麼多時間/資源
去真的學著逆向重建一個駭客軟體
/線上的問題就是以天為單位要解掉)
所以我們無法知道這些破壞到底起因如何.(來龍去脈/竄改點)
我們只能夠知道具體來說發生破壞的時間點.(ex.爆炸點/因為有exception log)
A) 爆炸點 已知爆炸發生了.程式碼假如這樣:
{
Func1();// 我們只知道這函式進去的特定一行發生爆炸(ex. null reference),
// 而函式發生前server環境就已經被竄改/攻擊為會爆炸的情況
}
B) 埋點: 製作一個駭客的模擬入口
{
DEBUG_HACKER_ACTION(); // 製作一個入口,
// 我們猜測並刻意模擬駭客的行為就是會把上述那個會爆
// 炸的某個記憶體抹掉.
Func1();
}
C) 用後門指令手動觸發埋點 DEBUG_HACKER_ACTION() : OK 現在可以重現駭客的爆炸了.(紅燈)
D) 修復: 在Func1()裡面布下重重安全機制.只要有異常就吐LOG然後封鎖該玩家(強制離開/行動取消/黑名單,etc)
E) 這步驟最重要.再次用特殊指令手動觸發埋點DEBUG_HACKER_ACTION() : OK server安全了.Log正常吐出. (綠燈)
F) 把後門指令+埋點mark起來.上線測試.抓有問題的玩家.封號.
G) 這步也很重要,如果之後又發生類似的問題.再把後門指令搬過去開起來用.快速觸發錯誤.同時也可以確認之前修掉的問題沒有再出現.
好像不是甚麼很玄妙的高招.
但是面對一些客戶端/前端無法重現
(譬如說一秒鐘按鈕連打60下這種不可能正常可以達到的行為所觸發)的問題.
QA又兩手一攤沒辦法重現只好自救的時候,不失為一個方法.
--
"May the Balance be with U"(願平衡與你同在)
遊戲設計教學,討論,分享。歡迎來信。
黑水溝歷史文庫 https://ndark.wordpress.com/
--
這個比較偏整合測試?TDD的T通常是指unit test
這例子在說找不到問題,那就解決提出問題的人?
樓主遇到的問題,可以透過側錄封包來解(ex: Wireshark
). 透過-回放-爆炸點時間附近的封包s, 然後一直限縮,
你可以找到到底是哪一顆(或哪幾顆)封包送進你的serve
r 後會讓它掛掉. 然後,從這個地方開始解.
可以查特定ip的request log 看看是從哪個點進來的
加個類似CSRF token的機制把非特定入口進來的reqeust擋
掉
領域不同 錄封包還是記request log兩個做法都不實際
原po的招數已經算遊戲伺服維護這個領域中兼顧危機處理跟
可以解決問題的良好範例了
每天有多少駭客在利用你的漏洞挖錢 一定是先滅火再說
抓出來封號是打擊破壞者相當有效的手段
一個容易忽視的點是 這些都是合法玩家 即便他們在鑽漏洞
令很多伺服器端的專家會意外的是
從2012遊戲開賣值到我2020離開這個專案
Client/Server之間的通訊都是明碼在傳輸
"應該要加密" 這議題不存在.因我文中已講 功能永遠是高優先
所以在滅火封號之後,
server 上那道可以撞出
null reference(ex:) 的漏洞,
是不用修,還是盡量修.
我實在想不出來,
在沒有神奇子彈的指引下,
如何盡量修
修是修到堪用這艘船繼續開的情況就好.繼續開就繼續賺錢.
技術這邊無法給出一個重構方案 其成本是小到管理層能買單
了解
這只是很一般的自動測試而已吧
只是直接尻記憶體滿暴力的
1
關於 TDD 個人一點看法 我覺得 TDD 最大的用處是讓你 "做一下,想一下", 這件事本身就很有用,相信有不少人有類似經驗, 很快想到一個版本,在幾個循環後陸續想到 3~5 個改版, 其中則有某個版本特別好實作,可以用初版 1/5 以下的時間完成,3
剛好看到這個影片 觀摩資深人員是怎麼深入原始碼把 wasm64 轉成 wasm32 還能正常執行 他有一些直覺解臭蟲的作法讓人感受到真不愧是資深人員,而且猜函式名稱的準度有夠 高8
我提一個好像沒有人討論的點 一個合格的junior/entry-level C++ programmer應該要良好的trace code技能 這個也不是只有C++適用 而是所有語言都適用 在學校除非個人興去的關係碰過open source code 否則很難碰超過1萬行的code23
針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖!重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題,TDD 不只要測試,還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序,是否一定要 TDD 這有爭議 08/23 21:3438
個人淺見,這點不見得是必要的,template 的 code 常常不好讀不好除錯 正確使用能寫出高彈性高效能的程式,但用過多維護跟閱讀起來會很痛苦 即便不用 template,日常大多數的事情都還是可以完成的, 如果是多人一起維護程式,有時為了提升可讀性,反而會避免太炫麗的 template 技巧 新人的話推薦不妨投資點時間,學習如何改善可讀性和與別人協作6
先說 我不會寫C++ 但是關於軟體架構和Design Pattern我可以補充一下 軟體架構實際上在台灣多數職場裡的狀況 大概可以用一句話來形容18
首Po諸位資工大神好,我本身是EE背景的 因為想脫離design house的生活 一直有在刷題+補充Cpp, oop 相關知識 之前有幸找到一份junior寫Cpp的工作 想了解對各位來說,有沒有一個對於qualified cpp programmer的具體標準1
錢很多,人難找。 : 2.維護legacy code 錢不錯到很多,公司賺錢有一些是爽缺。 : 1.的話重點是一堆效能增進的技巧 : 像是如何提高cache hit rate 或是multi threading的技術9
現在語言這麼多 你想學c++的目的是什麼 其實個人感覺你提的點以c++來說都不是重點 這年頭如果還有公司有c++的職缺 通常分兩大類 1.高效能運算21
STL 之外 boost () 也要會用一點, 有餘裕的話這兩個也稍微看一下: 如果確定公司偏好用哪一套的話可以指向性學習。
爆
[爆卦] 我眼中的bump21:01修文提供一些佐證與回應推文質疑. ---- 在比較深入參與GASO台灣這邊的運作之後 因為近期警察家訪之後很多人才發現 「什麼? 我兒子去了柬埔寨?」爆
[討論] 真的是我的問題嗎?最近跟男友討論到結婚的問題 婚後勢必要跟公婆一起住 我最在意的點就是男友家的廁所 因為馬桶老舊 前一位上完廁所下一位使用者沒辦法使用爆
[閒聊]遊戲開發者抱怨現在程式碼誇張膨脹「可能有99%的內容都是垃遊戲開發者Cliffski抱怨現在程式碼誇張膨脹「可能有99%的內容都是垃圾」 作為一名從事獨立遊戲設計和程式業務的開發者,克裡夫斯基(Cliffski)在一篇文章中 吐槽道 —— 這年頭的「程式碼膨脹」,已經到了令人髮指的地步。 他以自己常使用的一個雲端備份服務為例來說明,這個由某個大公司提供的雲端備份工具爆
[討論] 法環-建立在讀指令的難度?大家可能有看過這張動圖 基本上就是門外小怪讀你放法術(攻擊)的指令來閃避 打一些ai可能也會發現 像是百足怪 幾乎是只要你第一次攻擊他就會往旁邊閃爆
Re: [討論] 「遊戲翻譯」是怎樣的工作啊?原文恕刪 大家好,我是遊戲翻譯資歷大概8年,不算資淺但也不敢說資深的譯者。 先前在西洽PO過幾次文,但主要是和配音有關,但其實遊戲文本翻譯才是主要收入。 之前在台灣暴雪待過快五年,做過在地化、配音和發行的職務,現在自己出來開公司 「牛灣娛樂」,主要也是接遊戲在地化的工作,然後有用在地化賺來的錢開發獨立遊戲92
Re: [法環] 所以BOSS會讀玩家指令有什麼問題?我也不太能理解讀指令這件事在一些人批評中 好像變成法環的致命缺陷這樣 目前能用簡單小動作讓Ai無力化 幾乎都是那些重複的精英怪 神皮 樹精 紅靈那些77
[心得] 為什麼幹了20年 我終究還是一個測試仔前情提要: [心得] 20年測試 在講接下來故事之前,我先闡述我對於工作態度的定義。 我想引用我在方格子的一篇文章:25
Re: [討論] 法環-建立在讀指令的難度?這影片稍微看了一下覺得實在錯得太離譜, 難怪那篇下面推文這麼亂 分析一下這影片提到的狀況 1. 拉達岡開場衝過去站住就不會動, 同時用一些法術打他也沒反應 這個是妥妥的bug, 跟讀指令沒太大關係. 判斷應該是寫成他要先讓你幾刀才會開打 偏偏有些法術不知道為什麼沒被列入攻擊行動, 導致這個bug