🔧 阿川の電商水電行
結論從這裡開始書寫。
AI設計並編寫的應用程式，
順利通過 App Store / Google Play 的審核，並正常公開。
沒有特別的技巧，也沒有強行推進。
不過，這並不是不費吹灰之力的結果。
對於 AI，我以日語相當詳細地指示。
「Flutter 在 Apple 的審核很嚴格」是真實的嗎？
至今仍經常聽到。
使用 Flutter 是否會讓 Apple 的審核變得嚴格？
結論是，完全沒有問題。
- 無需特別的對策
- 無需轉換為原生實作
- 不需多餘的解釋往來
非常普通地申請，並順利通過審核。
Apple 推薦使用 SwiftUI / UIKit 是事實。
但這並不意味著否定 Flutter 的存在。
Apple 所關注的並不是，
- 如何製作
而是 - 能做什麼，並且感受如何
如果 UI 的品質和使用者體驗良好，框架並不會受到歧視。
改善 UI 會導致代碼變得雜亂
在這裡，有一點必須承認。
當你想改善 UI 時，代碼會變得雜亂。
- 微調內距
- 精確指定顏色
- 響應式設計
- 針對各設備的調整
這一切都使得代碼變得冗長。
不過，使用者看到的是 UI 而不是代碼。
Apple 的審核也不是在閱讀代碼，而是實際體驗使用。
「漂亮的 UI」和「優雅的代碼」基本上是無法共存的。
如果要問你更選擇哪一個，抵達使用者的將是 UI。
「分離邏輯和 UI」對個人開發來說是錯誤的
一般來說被這樣說。
邏輯和 UI 應該分離。
但我認為這在個人開發中是錯誤的。
Flutter 是一個聲明式 UI。
在這裡編寫的是「如果這個狀態，就這樣顯示」。
狀態和顯示從一開始就是不可分割的。
強行分離反而會讓代碼變得更難閱讀。
這條原則本來是，
- 編寫邏輯的人
- 編寫 UI 的人
在不同時代的產物吧。
在個人開發中，沒有必要去分開它們。
不進行共通化。拋棄 DRY 原則
還有一條被拋棄的常識。
DRY（Don't Repeat Yourself）。
進行共通化時
- 會產生依賴
- 改變共通部件會造成多處損壞
- 追蹤代碼的範圍變廣
不進行共通化時
- 相似的代碼會增加
- 但是，它們是獨立的
- 修改一處不會影響其他部分
- 壞了只需修復那一處即可
在使用 AI 的開發中，這一點特別重要。
對於 AI 來說，問題在於「閱讀的量」而非「書寫的量」。
寫的內容再多也無妨。
問題在於 「閱讀的量」。
進行共通化會增加依賴，
而 AI 需要跟蹤的上下文會分散。
不怕重複。
比起效率，更重視獨立性。
不過並不是要捨棄一切
當然這也會帶來一些問題。
同樣的邏輯出現於多處時，
- 需求變更
- 錯誤修正
都需要全部進行變更。
因此，只有重要的邏輯才會提取成服務來管理。
結論：對 AI 要嚴格要求的只有這兩點
1. 將重要的邏輯提取成服務進行管理
AI 擅長編寫代碼。
但對於整個應用的概覽卻很不擅長。
- API 呼叫
- 數據轉換
- 商業規則
這些部分需要提取成服務，
並嚴格管理「這裡務必要正確」。
2. UI 需實際運行並嚴格要求
AI 完美地製作 UI 目前還無法做到。
UI 不是用來透過代碼管理的，
而是要實際操作，不斷修正直至滿意為止。
這與 Apple 的審核是一致的。
最後
此次公開的應用程式如下。
這是位70歲的個人開發者與 AI 共同創造的應用程式。
這是使用 Flutter 開發的第一款正規應用程式，同時也順利通過商店審核，並正常公開。
下一次，
將介紹 Flutter 的具體實作範例與適合個人開發者的提示。
如有任何意見或需求，敬請告知。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
