開發者開心不開心

最近看到一篇用各種方法在試著將程式設計師與程式語言關聯起來的文章: What programming language has the happiest developers?，作者為 Ing. Jan Jileček。這主題不常見，但也不是第一次有人做這題目。在幾年之前這裡裡發表過的「幸福快樂的程師設計師...嗎？」一文裡，也分享了另一則主題一模一樣的研究：The Programming Language with the Happiest Users，作者為 Lukas Biewald。（原文章所在網站已消失，此處分享之連結為 Internet Archive 上的典藏檔。）

一前一後相距了十年以上的這兩研究，看來研究方法十分類似。兩者都是去統計特定關鍵字出現於選定文本中的比例。Lukas 是以人工去統計推特文中的情緒字眼，Ing. 則是是在程式註解中，每一千次裡出現幾次 "fuck" 或 "awesome" 等等特定字眼。不過，兩人所選文本特性不同，雖然方法相通，結果卻不能直接相比。

選擇在程式註解中找情緖字眼可能是個不錯的開頭。不過以個人觀點出發來想的話，我個人幾乎不會在程式中多寫註解，就算有，也幾乎不會在其中讚揚演算法之神或稱頌資料結構之美。非常難想像有人會寫出「你看看這二分搜尋法走得真是穩健」之類的註解，有幸目睹的話應該會讓人失去兩顆蕃茄鐘左右的生產力。

說起來，假設「幸福感」是可以量化的, 那能讓程式設計師的心中幸福感升降的因素有哪些？在那些因素中，會化為推文或程式註解的，又有多少？這些都不是容易能答出的問題，或許也就等待未來的研究者來發掘。

不過大家一定或多或少都碰過與程式語言無關，而與專案開發較為相關的小確幸或不幸狀態。事實上，這類因素說不定遠強於程式語言本身。

像是唯獨尾巴過不得這種一直有 5% 要做的結案結不了的狀態、或是「規格一直改 時程估不對 報價報太少 好像沒下班」的這種「在瀑布底下敏捷開發」的這種輪迴、或是「你就是那條龍生產線」這種，嗯，都是能讓人想罵髒話的狀態。

有那麼一些些時侯，能花上幾天時間重構一部份程式碼而取得效率上或「美感」上的改進，這的確能算上一種小確幸。不過，在重構後若需要多加程式註解，也不見得就一定會寫下代表「幸福感」的字眼（真的有人讀過「這邊現在是 O(n) 了我好激動啊！」這類的註解嗎？）。反而是在開發初期，為了開發速度，先大致上寫個正確的版本，並且加上了「XXX: 這裡好髒，以後再改」之類的註解。然後幸運的話，在三年之後整個模組砍掉重練。畢竟，開發者的興趣從來就不是蓋房子，更不是房子的品質，而是拆別人的房子。每個 RD 的心裡都住著一隻劉政鴻。

不過，那也是一種「重構」，並非「重新設計其構造」(refactoring) ，而是「重新建設其結構」(re-architecturing)。但無論如何，即便在成就感當中做為填充物的多數就是那些狗屁倒灶無足輕重的事，偶爾成功重構、成功學到一些新東西等等，確實是能帶來成就感、那也確實是幸福感吧。

依此想來，這些案外之物所帶來的情緖波動，出現在 SNS 上的機會，可能遠高於程式註解。畢竟，SNS 對於不少人來說原本就是情緖的出入口。只是後來不小心變成 Social Media 了。科科。

解鈴還須繫鈴人、檔案開了之後就必需要關。或許近年不少強頭公司提倡的免費午餐福利、小組出遊、彈性上下班時間等等這些政策，一定程度上扮演了緩衝或是補償作用吧。

莫非那些幸福感關鍵字所直接連結上的難道其實是公司福利嗎？