不得不說 Xcode 的功能跟其他 IDE 相比,真的挺陽春的,多虧網路上一堆熱心的開發者,幫忙開發了不少 plugins,稍稍補強了 Xcode 的功能。底下就列出我目前有用到的 plugins,當作一個備忘,也歡迎大家跟我分享好用的 plugins。

強烈推薦使用 Alcatraz 管理這些 plugins!


AutoHighlightSymbol

Xcode 有內建高亮度同一個變數的功能,但它所謂的高亮度只是為每個變數底部加上虛線,所以很難讓人注意到。這個 plugin 加強了原有的功能,當選中某個變數的時候,同一個變數都會自動加上背景高亮度。當想要追蹤某個變數在函式的哪些地方被用到時,這個 plugin 就會非常有用。另外這也是我寫的第一個 Xcode plugin :D

Backlight

高亮度當前列,這是很多編輯器都有的功能,不知道為何 Xcode 沒有內建。

BBUFullIssueNavigator (新版的 Xcode 已經不需要它了)

當有 issue 產生的時候,顯示完整的 issue 內容,而不是只有顯示前幾行。

BBUncrustifyPlugin-Xcode

支援 Uncrustify 跟 ClangFormat 這兩種程式碼整理工具,可以方便的讓程式碼擁有一致的風格。

DerivedData Exterminator

有時候 Xcode 會因為舊的 derived data 而有奇妙的問題,這個工具讓你可以快速的清除 derived data。

FuzzyAutocomplete

最好用的程式碼自動補完工具,能夠大幅減少打字的次數,加快開發速度。尤其 Objective-C 的程式碼通常都很長,有了這個工具之後真的差很多。

HTYCopyIssue

開發難免會出現 error,這個工具可以幫忙快速複製錯誤訊息,然後一鍵搜尋 Google 或 StackOverflow 有關這個錯誤的資訊。

IntelliPaste

讓你更方便的複製貼上 method 跟 RGB color。

KSImageNamed

自動補完圖片檔名,並且還提供圖片預覽功能,讓你不會選錯圖片。

MLAutoReplace

透過自訂的設定檔,可以自動取代某些字串,加快開發速度。

ColorSense for Xcode

方便預覽與輸入顏色的工具,調整 UI 的時候非常好用。

Dash Plugin for Xcode

將 Dash 整合到 Xcode,方便開發者查詢文件。

ProjectWindowName

它會改變 Project/Workspace window title,將 project name 附加到 file name 前面。如果你會同時開啟多個 project 或 workspace,這個工具能讓你輕鬆辨別每個檔案。

SCXcodeSwitchExpander

自動補完 switch-case,減少許多打字次數,又可以避免漏打某個選項,非常方便。

SCXcodeTabSwitcher

用 ⌘cmd + [1..9] 切換分頁。

VVDocumenter-Xcode

幫你快速產生註解,並且符合 appledoc,Doxygen,或 HeaderDoc 格式。

XcodePlus Delete Line

這個工具做的事情很簡單,就是透過熱鍵快速刪除一行或多行程式碼。

XReset

不用啟動模擬器就能重設模擬器的設定與內容。

,

Posted by Nelson at 痞客邦 PIXNET Guestbook(1) 人氣()

這幾年都在 start-up 打滾,跟著做了一些產品,也有一些小小心得,就紀錄下來跟各位分享討論。

不要一開始就寫程式

你(或你們公司)想到了一個好點子,這時你要做的第一件事是什麼?馬上捲起袖子把點子實作出來嗎?千萬不是!你們要做的第一件事是確認真的有客戶需要這個點子,而不是草率投入大量時間、人力、金錢成本,最後做出來的東西卻可能沒人要。

或許你會想說東西都還沒做出個雛形來,怎麼知道有沒有客戶呢?方法有很多種,例如你們可以把點子解釋給陌生人聽,看看對方的反應如何。或是先快速開發一個 landing page 來介紹你們的點子,並收集使用者的回饋。

確定真的有人需要這個點子,並且確定這個點子真的需要寫程式之後,再開始動手寫。

寫好 User Story

你可以不寫 Spec,但千萬不能沒寫 User Story。User Story 的寫法很簡單,長得大概就像這樣:「為了解決什麼問題,身為一個使用者,我希望在某種情況下,能夠做某件事」。

寫 User Story 有幾個好處:

  1. 可以讓所有人都看得懂因為 User Story 就是用大家都明白的語言,把想要做的事寫出來,所以無論是不是技術背景的人,都可以看懂「為何需要這個功能、這個功能是為了解決什麼問題」。
  2. 可以幫助整理思路因為你得把你在什麼情境底下想要完成什麼功能寫出來,在寫的過程當中就可以整理自己的思路,檢查這樣的需求是否合理。然後因為大家都能看懂,所以無論是否有技術背景的人,都可以一起來討論,這樣就可以幫忙找出盲點,並且完善整個需求。
  3. 可以讓開發者用最適合的解法解決問題為什麼我會覺得不需要寫 Spec 呢,因為寫 Spec 的人不一定是要開發的人,所以很容易就寫出很莫名其妙的 Spec。更糟糕的是,有可能一開始就寫 Spec,少了互相討論完善的階段,結果最後整個歪掉。所以我會說不要寫 Spec,寫 User Story 就好,然後把 User Story 寫完整。有經驗的開發者看到 User Story 自然就會找出最適合的方式去解決問題。千萬不要外行領導內行,亂下指導棋。
  4. 方便驗收既然 User Story 都寫得那麼完善了,要驗收的時候只要一一對照 User Story 就可以知道是否完成所有需求。對驗收人員來說,看 User Story 就會知道這個功能到底是什麼,也就代表很容易就能理解要驗收什麼。

一定要使用版本控制系統

版本控制系統的好處我就不多說了,無論是單打獨鬥或是團隊合作都應該要用版本控制系統。我個人最推薦的當然是 Git,雖然它的入門門檻頗高,但熟悉它之後所帶來的好處真是讓人無法抗拒的。

近年來 Git 有越來越多好用的 GUI,已經大大降低初學者上手的難度,SourceTreeTowerGitUp 都是不錯的選擇。至於要如何將版本控制系統整合到你的開發流程,可以先參考 Git Flow 跟 GitHub Flow,再逐步調整成適合你們團隊的作法。

有了版本控制,當然就得記得要下版本號,如果不知道該怎麼決定版本號,可以參考語意化版本號的作法。

不必一開始就寫測試

可能有些人覺得這是邪魔歪道,不過我真心這麼覺得:「你應該寫測試,但你不應該一開始就寫測試」。

身處在 start-up,無論前期的思慮有多麼周到,產品的需求還是很容易就會變更。如果採用「測試先行」的話,最後你會發現絕大多數開發的時間都拿去寫測試了,而且因為需求在前期很容易變更,所以你的測試也很容易一改再改因而難以重複使用。(P.S. 降低需求變更機率的一個方法就是好好寫 User story)

所以我會建議,等產品到達一定的穩定度之後(例如主要的功能或畫面都已經固定),再來補上測試。到時可以特地安排一段時間專心來寫測試,或是在需要重構程式的時候邊重構邊補上測試。

善用追蹤工具

做任何決定之前都要有所本,不要突然「通靈」了就做出莫名其妙的決策。那要根據什麼做決定呢?很簡單,讓數據說話。善用至少一款追蹤工具(GAMixpanelFlurryKissmetricsKeen IOCustomer.ioSegment 等等)並在上線第一天就開始追蹤使用者的行為,這樣才能知道有多少使用者在用你的產品,以及如何用你的產品。總之,就是要透過數據收集與分析,來了解你的使用者。

日後當你要做 growth hacking 的時候,追蹤工具更是不可少,你會需要這些追蹤工具來幫你統計,看哪些修改會有助於你的業務成長,哪些修改反而會讓業務衰退,以及成長或衰退了多少。

如果有開發 APP 的話,你也會需要想辦法取得 crash log,這樣才知道程式掛在哪,我推薦使用 Crashlytics 幫你收集分析這些 crash log,它非常的好用。

愛用第三方元件

近年來 open source 越來越受到歡迎,網路上有各式各樣的第三方元件讓你取用,所以真的沒必要每一樣功能都自幹,如果有現成的可以符合你的需求,就大膽的用吧。再加上第三方元件的管理程式(像是蘋果開發者常用的 CocoaPods 跟 Carthage)也越做越好,早期會遇到的第三方元件版本控管問題已經很少見了,所以我建議各位可以盡量用第三方元件,或是將第三方元件修改成符合自己需求,沒事不要自己造輪子。

方便的更新機制

隨著時間過去,你的產品需求一定會有所變化,該怎麼向後相容以及如何要求使用者升級就變成一件不得不面對的問題,這裡我有幾點建議讓你參考。

  • 設計 API 的時候要考慮版本化同一支 API 背後的商業邏輯很有可能會變化,如果一開始設計的時候沒有考慮版本化,你就會為了 API 名稱而大傷腦筋:可能原本的叫做 checkout,後來叫做 checkout_new,再後來叫做 the_new_checkout。但如果一開始有考慮版本化的話,你就可以一開始叫做 checkout/v1,後來叫做 checkout/v2。或是直接改 API end point,例如一開始的 end point 是 api.myserver.com/v1/,後來的是 api.myserver.com/v2
  • 呼叫 API 的時候附上環境參數雖然現在送 request 的時候,大部分都會在 header 附上 client 的一些資訊,但每個 client 送出的 request header 格式有可能並不統一,所以要 server 去 parse header 來取得所需資訊,其實成本蠻高的。比較方便的方法是,client 每次在呼叫 API 的時候就主動附帶一些參數讓 server 好判斷。例如可以送 platform 參數指明是 ios / android / webdevice 指明是 phone / tablet / desktopversion 表示程式的版本等等。Server 就可以根據這些參數有不同的邏輯與回應資料,例如根據 device 回傳不同尺寸的圖片網址,或是根據 version 來得知對方是否使用最新版本。
  • In-App Announcement如果一開始就有設計 in-app announcement 機制的話,就可以更輕易讓使用者得知最新消息。例如有新版本可以下載了,讓使用者知道有什麼新功能並引導使用者去下載。或是有在舉辦什麼活動的時候,也可以透過這個機制讓使用者知道(例如 Uber 時常會舉辦不同活動,車子圖示也會跟著變)。或是有什麼新貼圖、新佈景主題、新內容,也可以讓使用者知道(例如 Line 或各款遊戲)。
  • 儲存資料的時候要考慮版本化有很多時候我們必須儲存一些資料在本機,可能是透過寫入設定檔或是寫入資料庫,如果儲存資料的時候有考慮到版本化,之後要處理資料相容或是要將舊資料轉換成新資料的時候,都會相對簡單許多。

寫文件

所有人都知道寫文件的重要,但是大概沒人會喜歡寫文件,但其實文件沒那麼難寫。文件存在的理由是什麼?不就是為了日後的查詢參考嗎。

所以 User Story 就是文件的一部分,你一邊設計產品的同時,就一邊在寫文件了。這樣有沒有覺得寫 User Story 很划算,會不會更有動力寫好它!

程式碼註解也是文件的一種,現在有很多工具能夠將註解轉換成說明檔,日後只要註解有所變動,說明檔就會自動更新,這可以幫忙省下超多時間。像我們的後端都會在程式碼裡頭註解說明這支 API 的用途是什麼、傳入的參數是代表什麼意思、是什麼型態、是否可以不傳、回傳值是什麼、有可能產生哪些 error,對應的 error code 是什麼等等。我個人覺得,維護程式碼的註解比額外維護一份說明文件(可能是 wiki 或是 doc 等等)簡單多了。

文件也不是寫完丟在一旁就算了,它是讓人日後可以查詢參考的,所以最好可以把所有文件統一放在一個地方,然後有個方便的作法讓人查詢(可能是規劃良好的目錄結構,或是提供搜尋功能等等)。

簡單來說,文件有三大重點:要完整、要保持最新版本、要讓人找得到。

畫 Wireframe

通常設計師會畫好 wireframe 讓工程師知道整個使用流程,明白該從哪個畫面跳到哪個畫面。如果很不幸的,你們公司沒有這種東西(可能是不見了或根本就沒有),那 APP 開發工程師就認份一點自己畫一個吧。對工程師來說,畫這個並不難,只要把 APP 每個畫面都擷取下來,然後用箭頭把彼此之間的前後關係串起來就可以了。

擁有一份完整的 wireframe 的好處在於,當你們想要增刪或修改某些功能的時候,可以把 wireframe 拿出來,看看增刪或修改這個功能之後,整個使用流程是否順暢合理。千萬不要功能都做完,才發現流程變得卡卡的,這樣浪費的成本太高了。


老實說,就算每一點都做到了,也不保證你的產品會成功,但絕對會讓你開發一款新產品時比較不會走歪,就算歪了也可以早一點救回來,降低你犯錯的成本。

Posted by Nelson at 痞客邦 PIXNET Guestbook(2) 人氣()

TL;DR

前一陣子 AFNetworking 被爆出存在安全性漏洞,它們也針對這件事情發出聲明稿

簡單的說,就是建議開發者使用最新版的 AFNetworking,並且啟用安全連線。不過它們也承認這一部份的說明文件沒有寫得很齊全,所以困擾了不少開發者。

今天花了一點時間研究,順手把它記錄下來。安全相關的東西不是我的專長,所以如果有任何錯誤的地方,請留言告訴我。

Posted by Nelson at 痞客邦 PIXNET Guestbook(0) 人氣()

在網路上已經有很多人分享各種 Objective-C 的程式碼風格,例如 NYTimesGitHubRay Wenderlich,我相信各位讀者公司應該也有一套自己的規範(如果沒有,那請趕快制定一套吧!),所以今天我不是要分享我們的程式碼規範,而是要來說說要怎麼將不符合規範的程式碼轉成合乎規範。

我研究了一些程式碼美化的工具,最後選用的是 BBUncrustifyPlugin-Xcode 這個 Xcode plugin,它最早只有支援 Uncrustify,最近也開始支援 ClangFormat 了,我個人是比較偏好 Uncrustify,因為它可以調整的選項比較多。

, ,

Posted by Nelson at 痞客邦 PIXNET Guestbook(0) 人氣()

Perfect Effects 8 是一套相片後製軟體,支援 Windows 跟 Mac 平台,原價近 $100 美金,這幾天正在限時免費中。有在玩攝影的朋友可以考慮抓回去玩玩看,只不過它的硬體需求不低,下載前要注意一下。

只要填寫好基本資料跟 Email,它就會把下載網址跟序號寄給你囉!

活動頁面:http://www.ononesoftware.com/landing/pe8offer

Posted by Nelson at 痞客邦 PIXNET Guestbook(0) 人氣()