最近重新接下前端團隊調整的工作，還在陸續調整團隊目標。

最近重新接下前端團隊調整的工作，還在陸續調整團隊目標。 這幾天在溝通一個很有趣的事情是，同仁對 lint 要求的事情背的很熟。 這年頭的人.....使用工具的時間多，但自己創作的時間少了.......再花點力氣改習慣吧。 嗆我不懂 es6 ，我是覺得亂講話也就算了，唉，這些東西一路走過來的，bad pattern 我們很熟。 但對 class 語法一點都不熟，寫了繼承用 class 還問我怎麼跟官方的 class 語法不一樣。 要一樣，那還叫 base class 嗎？ Es6 最重要的 class syntax ，看到新增 constructor ，不懂得去看子類的 super 。 這才是 es6 的核心目標之一，有時候覺得很有趣，對 class syntax 這麼不熟，嗆我不懂 es6 。XD await async 也沒人寫，繞一圈做 reducer ，但沒思考我們元件抽 redcuer 的優缺點.......就先別說 saga 了，saga 對現在產品是用不到的。 有個思考是這些都是「帶狀態的元件」，自己可能就一定會搭配資料 input ，所以如果照我們過去的習慣真要做元件分離，會抽 stateless component 再組裝成 stateful component 。 page 裡面使用 stateful compoenent。 但因為目前元件還沒做共用層，所以要抽共用層的前提是要先把 stateful 元件先正確的組裝完畢。 (把一個 stateful 為目的的元件抽象為 stateless ，而不抽出兩層是沒有意義的，你只是把所有髒東西都藏去 redcuer 以一種更髒的形式，最後你終究還是得在 component lifecycle 如 mount 拉回來，你花了十倍力氣只在逃避一個錯誤的方針。) 照理說是要從一堆 stateful 的元件先安心寫 stateful ，然後在這些之中找出公約數，抽 stateless 的 function 提供給 child 或引用。 (這些抽象的目標都只有一個，避免重複撰寫的程式碼。集中邏輯。 犧牲寫 code 的時間都是為了換來這個，但如果都換到一次性的頁面元件，那就是開發成本極大化，換得的成果是負數了。 ) 不"需要"那些東西是因為，早年我們是被訓練了不用那些的寫法，如同我一直在說的，好的 principle 更為重要。 但要寫也沒問題，如同我講的，把核心顧好，你能寫出重要的核心架構，這些旁枝做跟不做我們是沒意見的。 互相 review 我也沒問題，反正這些也不是壞事，只要不漏下核心目標都好。 至於重要的核心還沒發芽就急著強調自己多瞭解細節，這就是需要點耐心，要持續透過 review 溝通討論。 使用十倍的程式碼，十倍的複雜度解決問題，而我拉出了簡化的 interface ，要思考的是這個 interface 對目標的簡化程度。 換言之，我如何在未來寫更少且更好懂的程式碼來解決問題，而他在 question 我沒照過去的實作走。 我說，過去的實作我不用兩小時就能實作完。沒說的是，要你繼承這個父類是因為未來我想簡化這段邏輯，而對方思考的是這東西會不會動。(其實是會動，因為我分段抽象，他在意的那一段在 page 層。不過跟他討論後，我重新實作一份到 base 層了。) 所謂的過去的實作，是多年來因為各種需求而重新擴充過的，而我之所以要重寫的理由是，過去的假設是抽離於 component 的，用類似 mixin 的方式在最後 compose 進目標 class。 但這樣的缺點是，這個模組設定外部於 component 。但實際上這個操作卻 100% 相依於 component 。 按我的說法，這叫錯誤的相依性，可能透過適當的子類再繼承父類，給定正確的 config 在 class memeber 就能一行解決的事情。 變成在每個 page 都得載入外部元件，每個 page 透過另一套獨立的 config，吃進當前 base component。 如果一個 component 是常用的功能跟責任，抽象出一個適合他的 base 是很常見的做法，且要確保抽象後的結果確實是有幫助開發。 而且這樣才能根據 page 元件，打造可測試性。 把複雜的事情用契約一次集中是所有簡化的核心精神， 另外要考慮重構後對現在程式碼在結構下的最小改動。 這篇的東西要再組織案例跟元件，再來幫團隊上課，讓他們思考元件設計的思維。 這就是我說的，工具會讓你以為自己好像掌握了，best practice，他們重視的是彈性跟通用性。 但所謂的模組，如不帶入使用的模式跟方法，要走歪實在是太容易了。 而且這些人在意的已經不是 code 寫的多少，而是自己的 code 有多像best practice，在意的是 code 的形狀而非目標。 我們在談工具方法論，最大的困境就是我們終究只能創造出 copy kid ，但那些真正的 pattern 卻是得掙扎的戰鬥過才能學會的。 有趣的是同仁最後丟下一句話問我說，這樣嗆我會不會下週一就不用來了，我是說，你覺得好的我們來討論哪些是好的，不好的我們來討論哪些是不好的。 但我們還是要好好的再聊聊你的程式碼組織，會戰的我覺得都還有救，就看是誰救誰。 所謂的好東西是一看就會愛上的東西，而不是寫了很久還不知道自己在寫什麼的東西。 團隊整理就是要這樣走過去吧。 老人家要吐槽的事情很多，但反過來說，其實這些都不難調整，團隊對程式碼，每個都說舊的架構不好， 但看新的架構還是在複製舊的架構中不好的部分， 每隔一陣子就在重寫，但重寫後的結果還是一樣在自我複製。這種循環還是要有人來告訴他們怎麼打破。 缺單一語系的架構人員這件事情真的是有點麻煩，有興趣想來幫忙重修架構的人可以找我聊。待遇好談。

原始 Facebook 貼文