本文經作者 Tiffany Wu 同意轉載，原文網址在此
進《P#》實習之前，我對程式設計在新聞編輯工作中的想像，只有資料新聞的製作。回顧一年來的實習過程，讓我意外的是，除了採訪、寫稿，用程式能力來解決工作需求的機會也不少。
從新聞製作過程的資料搜集、即時資料分析，到行銷企劃相關的流量追蹤，或是幫忙網頁套版或串選舉票數API等支援工程師的任務，都能靠著基本的程式能力完成。
對我來說，這是相當難得的機會，讓我知道在學校上了程式課之後，能對應到什麼實際的媒體工作內容，以及看到幾個未來學習的方向。我也想藉著這篇實習心得，談談學程式設計與編輯工作之間的關聯。
經驗分享前，我想先提一下，文章裡所談的「程式能力」指的是用程式來解決問題，例如為了原始資料設計爬蟲，或是處理API資料；如果是「程式設計概念」，則泛指能夠理解腳本(script)、原始碼或網頁構成原理等，例如看得懂HTML標籤、知道JS與CSS與網頁互動的關係之類。
快速介紹一下我自己！
我是《P#新聞實驗室》（以下簡稱《P#》）實習生亭霓，一年來跟著《P#》團隊一起製作數位敘事專題。最常擔任的角色是特約記者、專案企劃或管理者。
所以，學會看code可以幹嘛？
這一段其實只有一個重點 — —
擁有基本的程式設計概念可以讓你問對問題。
從目前的經驗總結，我覺得參與數位專題製作時，看得懂網頁原始碼有這些好處：
1. 追蹤專題成效、檢視敘事設計自己來：
做專題頁面的時候，我們經常想的是：「要怎麼讓更多人看到我的內容？」、「為什麼他們看一下就不想看了？」要回答這些問題，就需要讀者回饋，加上從網頁追蹤到的數據來理解使用者的行為。
實習期間，我們剛好碰到《P#》開始掛上新的GTM來管理流量追蹤的轉換期。GTM全名是Google Tag Manager，是一種管理流量追蹤碼的整合型工具，讓我們除了可以得知流量、跳出率等成效（一般GA可以看到的），也能知道使用者在網頁上的其他動作。
處理GTM的時候，略懂網頁結構能大大提升工作效率，因為看得懂使用者作用的區塊在哪裡，才能找到真正與使用者進行互動的元件，並針對想追蹤的項目進行設定。
舉例來說，在《性私密專案》中，我想要知道大家會不會用上面的索引欄來跳到該段落，所以需要針對這一排按鈕設定追蹤機制。大致流程如下：
- 檢查了一下原始碼之後，我發現使用者點選第一個索引標題「多少人受害」，實際上點到的元素位置在.sc-fzoydu > a:nth-child(1) 。
2. 這一列索引欄的寫法都一樣，其他索引標題分別是.sc-fzoydu > a:nth-child(1)、.sc-fzoydu > a:nth-child(2)、.sc-fzoydu > a:nth-child(3)⋯⋯。因此可以很合理的推論，只要我叫GTM追蹤到.sc-fzoydu > a，就可以找到索引欄裡的這些標題。
3. 最後在GTM測試中確實追蹤到這些元素。
以上處理過程，只要有基本的HTML、CSS概念就能完成。而從GTM收下來的資料，在專題頁需求討論上扮演著重要的角色。
例如在《性私密專案》中，我們追蹤了問卷回饋、側邊故事欄等功能，從GTM數據中可以看到使用者的點擊狀況，幫助我們思考原先引導的動線是不是出了什麼問題，或是設計網頁互動時漏掉什麼面向。
再結合讀者回饋以及其他記者的建議，就能更進一步討論使用者為什麼讀到一半就放棄，或是對某些功能沒有興趣等問題。
溫馨提醒：設定GTM是一段不斷 debug的路，記得要多留時間設定要追蹤的內容。:)
2. 上手基本SEO：
跟了幾個專題之後，每次看到Google搜尋排名，總會忍不住好奇：「為什麼A專題在第一頁，B專題要跳到第二頁才找得到？」
影響排名的原因有很多，除了流量之外，也跟該網站是否提供足夠的資訊讓Google爬蟲分析有關係。（關於這個概念，這一系列的文章可以幫助你理解Google搜尋引擎爬蟲的方式）
這個時候，如果有基本的HTML概念，就能夠打開搜尋排名做得好的網站來參考Metadata（詮釋資料）的寫法，看看別人拿什麼給Google爬，再應用在自己的專題中。（有時候編輯們會把這個工作暱稱設定OG、做meta）
再加上對 Metadata在Google（搜尋引擎）、臉書或推特（社群平台）作用的理解，編輯們就可以自己設定出最符合專題需求的Metadata以及修正，不用透過工程師協助測試。
例如我們在《性私密專案》針對不同平台的使用者搜尋特性，設計不同Metadata內容：
這樣的操作過程有個好處，工程師有時候會不清楚不同設定的差別，或是改錯地方。如果編輯能夠自行操作，除了減少資訊誤差、提升溝通效率，也可以針對自己的企劃需求，完成設定結構化資料、解決臉書顯圖錯誤等常見工作。
除了設Metadata、看HTML標籤內容的能力，對網頁呈現（專有名詞：算繪，render）方式擁有基本概念，也有助於SEO debug，能進一步釐清自己的網站為什麼被排到搜尋結果第二頁、第三頁的問題。
舉例來說，前一陣子有幾個專題，Metadata該做了都做了、結構化資料也寫好了，排名就是在其他同類專題網頁後面。顧問看一看，結果找到了一個我沒注意過的因素 — — 當時我對技術不夠熟悉，忘了提醒工程師注意SSR，讓Google有足夠資訊可以爬，錯過了SEO優化的良機 。（關於SSR可以參考——跟著小明一起搞懂技術名詞）
如果不懂網頁呈現方式，或是沒有相關經驗，就不會注意到SSR的重要性。
不過老實說，做單頁式的特製頁面其實不用特別討論SEO成效。很感謝每次專題製作過程跟檢討的時候，UI設計師、工程師跟技術顧問不厭其煩手把手教學，回應我們的 SEO麻瓜問題XD。
3. 提出更具體的數位敘事建議：
討論數位專題網頁需求時，我們總是戰戰兢兢，最怕空氣突然安靜，就像這張圖：
這時候，如果能夠看懂HTML的標籤層級，以及略懂CSS、JS控制網頁呈現的方式，跟設計以及工程師討論時，更容易有效率地釐清專題需求。
原因在於網頁設計並不是單純把東西畫出來，而是考慮企劃者的需求，將各個元素安排到合理的位置上，再加上適當的美術技巧來完成設計。
而工程師也不是把所有東西丟上某個地方、按個按鈕，就能夠照企劃者所想變出一個專題網頁。從基本的樣式調整，例如照片大小、段落間距，到進階的網頁互動，例如置換素材、動態呈現，工程師需要寫好各種的設定，才能夠達到企劃者的要求。
舉一個我最近很喜歡的互動專題為例[How a Massive Bomb Came Together in Beirut’s Port — The New York Times]，在其中幾個區塊，隨著我們的滑鼠滾動，爆炸發生的時間線與地點一一被揭露。
因為略有概念，我們分析這個視覺呈現的時候，基本上就可以知道在網頁背後是一段影片或照片，隨著滑鼠控制，滑到設定好的關鍵影格（播放時機點／特定事件），觸動下一段影片的播放。
當下一個專案也想要用類似的效果，除了可以拿出這個專題的片段當作demo範例，也可以直接問工程師，怎麼利用JS偵測滑鼠滾動事件的發生，隨之觸發下一個動作，以及衡量自己的素材適不適合等問題。
幾個案子下來，在討論的時候我漸漸把「我想要這樣動」、「我想要這種滾」，替換成「這邊能不能做視差？像這個範例一樣」、「這邊換圖的速度跟大小可以調整嗎？」之類的。
這樣的問法對工程師或設計來說相對友善，畢竟提出需求的時候，如果問題太模糊、導致對方根本沒辦法理解，那對方也只能夠通靈來找答案了吧。
如果你很懂網頁，再更進一步來說，你可以針對某些效果，幫工程師找套件或資源，不過他們不一定會理你就是了XD
寫新聞的時候，會寫Python、懂資料處理，實際上有什麼幫助？
就一般新聞資料分析來說，在google試算表用vlookup加上樞紐分析就可以完成大半任務；而數位敘事的製作過程中，說故事的能力比起程式能力更被看重，因為讀者通常不管你的設計背後有什麼細節，而更在意他們能不能好好看完一篇報導、看到了什麼。
所以一開始，我不覺得會寫Python，在新聞工作中有什麼好處。但經過這些專案，我的心得是：
多會一種工具讓你更有彈性，用對工具做事效率更高。
1. 不靠工程師自己拿資料、即時分析資料：
在今年幾波選舉間，《P#》推出「數字看選舉」的懶人包式選舉結果分析圖卡，在臉書的成效都不錯。這些圖卡的製作流程為：
- 開票後1–2小時：選舉結束，中選會送出最後的票數資料包（final.json），這時候就能夠自行抓下資料檔
- 開票後3–4小時：分析完資料，跟設計討論數據圖卡的呈現，請編輯開始抓重點、寫文案
- 開票後5–6小時：推播選舉結果分析圖卡
在抓資料跟分析資料的步驟，因為我們自己具備處理資料的能力，所以不用透過工程師也能順利拿到資料，同時整理成可以直接上傳google試算表的csv檔案，以便後續分析。
2020總統、罷韓跟補選的選舉結果開票，都在這樣的架構下處理完《P#》的「數字看選舉」分析資料。
、
2. 支援前線 — 幫忙處理開票網站的選舉資料：
今年高雄市長補選，《P#》製作了開票網頁 ，串上即時票數後，用直白的長條圖，讓讀者一眼看到各地區的得票數差異。不過這個專案，原本差點胎死腹中。
在7月底 《性私密專案》結束後，補選網頁緊接著就要開版的時候，長期合作的工程師決定不接案，我們只好緊急接洽其他工程師。
但是開票網頁需要串接即時票數，雖然前工程師先前已經寫好資料處理架構，找到的工程師們熟悉的框架／工具跟前工程師不同，貿然進行合作有很大的風險，因此遲遲沒有人接案。
最後，我們找來與《P#》配合過多次的工程師刻網頁，我則幫忙處理中選會即時開票資料及其他設定的工作，加上公司其他部門的工程師當顧問，合作解決工程需求，讓這個網頁順利上線。
在備案的評估中，因為過去我做過幾次選舉資料的即時分析，對中選會常用的資料格式不陌生；再加上我需要處理的部份就是抓資料及更新資料，認為難度並不高，才說服大家採用備案。
具體來講，我實際操作的部分為：
- 每三分鐘把中選會提供的資料拉回來（做排程任務（CronJob））
- 把資料處理成頁面所需要的資料格式
- 將資料更新在前端取用資料的地方
從結果來看，這次的任務完成度很高。事後檢討時，其他工程師也肯定了編輯／PM本身具備程式能力的價值 — — 如果編輯室自己能夠累積足夠的開發能量，不依靠其他部門的技術資源，也能夠完成專題需求，降低了開發的限制。
結語：做新聞的人真的需要會寫程式嗎？
不過話說回來，對於編輯室裡到底需不需要一個會寫程式的編輯，我還沒有確切答案。也許你可以參考這張圖：
過去我在學校學了資料視覺化、資料處理、輿論分析，開始寫Python，其實很難直接對上編輯室開出來的工作內容描述（JD）。
再加上我目前是實習生，並沒有對應的業務責任或基本KPI，所以有機會接觸不同的工作內容，而這些工作在人手足夠的團隊中，可能是分在資料記者、專案經理（PM）、工程師的範疇裡。
所以說實話，真正的新聞編輯需要程式能力嗎？我也還在找答案。
至少《P#》幾個案子做下來，一路跟程式碼好好培養感情，除了累積不少資訊素養，也實實在在解決不少編輯的日常工作需求，算是某種學習的正增強XD
以上就是我見縫插針地，在不影響進度的前提下，把程式能力應用在日常工作任務上的經驗。
如果你現在也是學生，非常建議好好地選修一堂有興趣的程式課。各學院其實都有開，文學院有社會科學程式設計、商學院有商管程式設計，理學院也有類似的課程，例如基礎的文字探勘、資料處理、資料視覺化等。
上這些課其實不怎麼輕鬆，總是要啃很多生硬的專有名詞，不過我很喜歡跟同好一起交流解題的過程。畢竟每個人看問題的方式不同，一件事也不只有一個解決方法，就像上面提到的，我認為多會一種工具後，自己在解決問題時也會更有彈性。
編註:
1.原文標題為「P#實習經驗談》新聞編輯為什麼要學程式設計？」
2.本文作者並未在ALPHA Camp購買過課程，如有相關需求請直接洽詢 ALPHA Camp
3.想與作者聯繫可洽詢粉專「融數基地 DD Story Hub」（https://www.facebook.com/ddstoryhub）
