軟體思維 — 為什麼提到動資料,工程師就眉頭深鎖?
各位好,這篇文章想跟大家分享筆者在職場中,時常見到的一個溝通情境。
一般人: 安安工程師,我發現系統中這個表單好像少了 OO 欄位耶,可不可以加上去? 客戶會用到耶。
工程師: 咦咦,這個好像會動到資料庫喔,需要主管評估,但主管這陣子請假說…
一般人(心中): 什麼資料庫,我不太懂,但是就畫面上要多一個欄位,這麼簡單,為什麼還要等主管確認!?@?
一般人: 好吧…那我等你們主管回來再說…
假設你,就是文中所謂的『一般人』,是不是在和工程師的溝通過程中,會有個疑問,明明畫面上多放一個欄位,看起來像是很簡單操作的東西,也沒有所謂的數學公式,用 Google 表單可能甚至 1 分鐘內就完成了,但工程師卻都會面有難色的樣子。
其實工程師會有這樣的想法是很有原因的,這一切都跟軟體開發很重要的一個概念『資料庫』有關。在系統中,你看到所有呈現『有意義』『會動態改變』的資料,都會需要記錄在資料庫裡,而在上述溝通情境中,加在表單上的欄位,通常就需要記錄在資料庫裡。
而針對資料庫的任何變動,在系統開發的領域中,都是很重要的事情,所以在一些比較中大型的公司,做任何的修改變動都需樣工程師對這軟體有一定的熟悉度或能力,才有辦法決定,因此才會有些工程師只能表現很無奈啦!
而我們要怎麼判斷,自己想要提出的修改,是屬於這種,會調整到資料庫的需求呢?更延伸的來說,還會有什麼影響要先考量的呢?這裏來讓筆者介紹一下。
資料庫修改需求判斷分類
新增
新增欄位的判斷很簡單,就像上面提到的情境,就是所謂的新增欄位。
想要多加一張表單、想要表單裡多放幾個欄位、想要多在背景蒐集使用者是屬於手機或電腦的使用者,都可以算是新增的範疇
而新增要注意的點,其實不是『需求本身』要做什麼考量,而是要考量『完整性』的議題。
打個簡單的比方,可能我們網站需要開發優惠代碼功能,在結帳時提供一個框框讓使用者輸入優惠代碼。而可能一開始就這樣跟工程師說了,然後就新增好一個欄位,並放上網站看的到,並可以填寫代碼,但在測試過程,我們可能覺得不對,要再多要求使用者優惠代碼的『獲取管道』,或是確認是否是學生,要打勾『參與學生優惠方案』等等不同的資料判斷,這時對許多工程師來說的心中 OS: 每次都沒想好,然後又要改了,又要加欄位了。
這就是所謂的完整性,在軟體開發領域,比較偏好『完整』的需求,當然在這個變化多的時代,不是不能一直調整,而且我相信有許多人是在老闆或客戶的威壓下,得提出做修改,但如果是所謂應注意而未注意( 很像交通法規XD) 的調整,如果能提前先做出思考並規劃,是可以有效提升和工程師的關係喔~
移除
移除的情境在成熟的商業和軟體情境中,不是說很常遇到,移除比較常在一些更新快速的新網站、App 會看到,但可能我們心中會想: 移除也有問題?這不是應該比新增更簡單嗎?
但其實移除一個資料欄位在軟體思維中,很重要的概念是『連動性』,因為系統的邏輯設計要非常縝密,很有可能畫面中一個不起眼的欄位,會影響另外一個很重要功能的判斷,但卻沒有任何非工程師人員知曉( 甚至可能執行的工程師不曉得,導致移掉 B 卻壞掉 C ),因此如果需要移除一個欄位,最好要先評估思考,這個欄位『有沒有可能』在另外某個地方,被拿來做判斷,甚至先提問工程師,畢竟真的有什麼問題,相信身為使用者的大家也是很痛的。
編輯
編輯欄位的需求並不是很直覺的判斷,他可能需要一些對軟體的熟悉度比較好判斷,或是還是得工程師評估後才能知曉。但這邊筆者可以分享一種最常見的編輯修改調整,假設你的網頁上有像這樣子,可以打勾的方塊:
現在你想要改成,可以選擇的清單:
這其實就是會非常高機率撞到『編輯』欄位這個需求的可能,而這部分造成的改動通常都是大的,所以工程師面有難色的機率又會大幅提高 XD。而最好的解法,其實可以評估是否能將自己的需求調整成,將原本的框框移除,並新增一個欄位『狀態』,然後再提供一個下拉式選單,雖然在工程師實作細節上其實差異並不大,但可以變向指引工程師用調整幅度更不大的方式思考喔!
但在編輯欄位上,技術還是有很多不確定性和可行性,所以還是很有機會遇到和工程師溝通實做可行性的狀況,但相信讀完這篇文後,你可以更清楚工程師煩惱背後的原因囉 ^^