嘛，這是一個比較爭議性的標題。畢竟全端工程師印象中是一個源自於對低薪卻要求一堆的職位需求進行嘲諷的名詞，我不確定是不是真是這樣，但是依照術業有專攻這個前提，有成為全端其實是很困難的。那為什麼，我今天會用這個標題呢？主要是剛好在《為團隊與組織導入敏捷的經驗分享》 系列文中的〈嘗試營造團隊的氛圍〉講到「盡量讓一件事不要只有一個成員會做，而是彼此都至少暸解一點，這樣在必要之時才可以互相支援。」這件事。是的，所以我是說我們都應該「略懂」全端，而不是要成為資深全端。

其實一個軟體專案的開發，很難不與其他人合作的，畢竟這之中涵蓋了許多技術，每一項技術或層面可能都要工程師或設計師耗費大量的時間去學習，所以造成每個人擅長的領域有限，很難獨力完成一個專案。所以漸漸的一個軟體專案在開發上，所需要的相關職責越分越細，簡單的去分就有設計師、有前端工程師、有後端工程師，再細一點可能又有資料庫工程師、測試工程師、特別需要某專業領域演算的工程師等等。

在職責越分越細的前提下，就會有更多需要合作、溝通的部分。這時候交流久了，理論上都要會一點對方的知識，以降低合作與溝通的成本，這就是我所謂的略懂。更進一步的，你若能略懂另一個專業的知識，你就能設計出更能讓對方易用的架構、介面與設計。

以 API 為例，後端工程師在寫 API 時，除了遵循自己的設計原則外，也要考量前端工程師會怎麼呼叫，把這些情境和方式納入設計考量；同樣的，前端工程師再要求 API 時，除了自己的需求外，也要考慮後端在實作上哪種方向會比較方便。

以使用者介面設計和前後端程式邏輯實作的合作，設計師若能懂一點樣版引擎的概念和簡易版控工具的使用方式，就可以省下工程師很大的困擾。畢竟也是很常聽到身邊的朋友說，設計師不願意學習語法，所以在塞資料上常常花很多時間在溝通與協助。

這些都是一些比較簡單的例子，實際上遇到情況可能都更複雜。為了要有更大的生產力，很多軟體開發都勢必是以多人開發，且越分越細的趨勢發展。為了能夠讓彼此合作愉快，我們應該相互學習彼此的長處，這樣才能互相體諒彼此，而且能夠更有默契。我們所要會的可能不及對方在這個領域耕耘的一成，但是就是多了那麼一點，在協作上可能就會更加順暢。