Revision history and IPFS entry, back to latest
Sam Huang
IPFS What is this

Content Hash

如何在開發討論看起來很厲害

Sam Huang
·
·
系統開發的討論有他的迷人之處:一方面是工程及自然科學,背靠邏輯嚴謹性,另一方面又揉和了一些比較軟性的(甚至涉及到社會科學)開放議題。常常討論到後來不知道是在「盍各言爾志」還是真的有聚焦收斂。

軟體開發是在虛擬的空間重新描述並解決現時的問題,多數時候並不存在正確答案。如何穿越這些不確定及未知就體現了開發者的功力以及對事物的把握度

過去的開發及顧問生涯跟很多形形色色的人合作,正向積極的討論固然有之,但也常碰到討論後反而讓事情變得更模糊的情況。當中部分的情形事後復盤覺得對方是有意為之,甚至可能出自於想要顯擺的奇怪心態。

標題有點聳動,但且以這篇短文紀錄幾個印象比較深的、飛一陣後發現什麼節論都沒得到的可能作法(?

所以其實是要反著看 …

如果去查詢 WIKI 上關於廢話的定義,大概如下

廢話(英語:Nonsense),即無意義的話。廢話指的是一段在當時情況下對事情發展沒有任何正面作用的語言,或者是在邏輯上矛盾的話。另外,亦指以文字或符號組成但不具備任何意義的聲音或句子,或可指某人。

當然把這些對於事情發展無益的話直接歸成廢話是有點武斷了。想表達的只是說有效的討論及溝通前提必定是建構在一致的背景理解及目標,如果無法真正的收斂,那結果可能確實與廢話也沒有差太遠。

以下列舉三個常碰到的情況跟大家分享

1. 「你的架構有問題!」

這句真的是大殺器,搭配上莫測高深的表情效果不錯。聽到的人通常會先檢討自身。如果不夠有經驗甚至會直接掉入自我審查的泥淖 (然後越想越覺得有道理 …)。

說到底哪裡有百分之百完美的系統架構呢?假如真存在這麼一個完美的解,隨著成功架構帶來的紅利,也會逐漸使系統變得不完美。比如經典的 C10K 問題就會發生在取得一定的業務成功之後。

真實世界的開發是商業模式、領域知識、開發技術、成本規劃及流程管理的複合結果。「你的架構有問題」這句話如果為真,其實也只是描述一個結果,重要的是更細緻的拆分問題。

https://www.instagram.com/gudim_public/?hl=zh-tw

2. 多聊理念而不聊取捨

「你們要寫完整的測試再開發啦!」「你這個抽象層不夠清晰?」「你們這個的資安做到什麼地步?」「這樣效能會不會受到影響?」…

不知道大家會不會常聽到這些話?

其實這些都是很好的意見,但說實在過度強調往往會遮蔽真實發生的問題 — 比如時間或資源不足。這類型資訊太過的話很常其實會落入各說各話的情形,到最後可能只是在闡述自己在意什麼而不是什麼對解決當前問題有幫助

有句話說得很好,「大家都不滿意的結果才是最好的結果」。系統開發亦然,更多時候是妥協取捨而不是理念之爭

https://pixabay.com/photos/stones-waterfalls-balance-5677828/

3. 聚焦在一些不太會發生的情境以示自己的滴水不漏

當今的軟體系統開發後,面對的外在環境變化往往超出想像。任何一個事前沒預料到的情境都可能造成問題。

您總有遇過死不更新手機的用戶對吧?這些 bug (?) 需要被解決嗎?

其實系統的正確運行,是環境、操作者與軟件本身三方面合作的結果。或者我們可以說,錯誤的發生是由於三者中有一方沒有正確履行自己的職責而導致的。假如以這個視角觀察,引入類似「契約」的概念的來理解系統,這些所謂的 bug 更可能是一種已知的未知

而這並不是說我們可以不處理例外狀況,但一樣的,過度強調也是一種忽視現實考量的超譯。

當然這可能會讓你看起來很聰明(?

總結:時間有限,但問題無窮

系統開發的討論有他的迷人之處:一方面是工程及自然科學,背靠邏輯嚴謹性,另一方面又揉和了一些比較軟性的(甚至涉及到社會科學)開放議題。常常討論到後來不知道是在「盍各言爾志」還是真的有聚焦收斂。

作為一個工程開發人員,我們的目標往往明確,但內容卻充滿不確定。說到底我們時間有限,但面對的問題卻數都數不完。穿越那些無效的對話及話術才能省掉浪費。

您又聽過哪些似是而非的廢話呢?






CC BY-NC-ND 2.0