R本身的設計就是為了能讓人可以快速的分析出結果，提供人能快速利用計算機的能力來處理資料，所以R使用起來交互性很好（interactive），讓寫程式（programming）達到計算（computing）目的的隔閡變小，但隨者處理的專案和資料複雜性提高，其中撰寫代碼的策略一定要能有所區別，才能更“有條理”和“恰當時間付出”的達到目標。

在John M. Chambers這本Extending R有談論到這件事情，他提供出以下的建議來區分：

Small

目的在快速測試某個想法可不可行，這時候傾向於發會functional approach的方式來進行

“Perhaps the most important contribution of functional computing in small-scale programming, howere, is our thinking”

這部分的需求恰好是R高交互性最大的優點，但在這個階段還是需要培養好寫Function的習慣，目的是讓探索分析的過程更reproducible和系統性，且讓我們用較小的成本來驗證想法。

Medium

需要撰寫可以重複性使用的代碼，換句話說，這時候完成的程式有其重複性的價值，這時候可以藉由把程式轉換成package來提高整個效益，不可否認的，一個package本身對於架構和細節需要更多的設計心思，但這剛好是medium size的任務最合適的用心架構程度。如Rcpp package或是RStudio的開發環境都有針對如何創建package有很好的支持，相對於在small scale 的程序，在medium階段，需要有以下額外的細節和思考，或是說在搭建package時要思考的項目：

• 可分享性（Sharing）：
  可讓別人下載使用，不論是內網或是整個完全開源使用
• 良好註解或文檔說明（Documenting）：
  針對所寫的程序要有使用者說明
• 測試（Testing）：
  注重代碼的品質，而良好的品質就代表需要有測試代碼來實驗軟件品質（如在R CMD check utility有提供相關的特性，檢查整個package是否能上傳到repository），另外，RUnit package也有提供相關單元特性
• 依賴性（Importing）：
  針對自己所依賴的外部package要非常清楚，最好能清晰他們的源代碼，且定期追蹤，不過目前有些不錯的工具可以提供解決這個問題
  函數編成特性（Functionality）：
  這邊指得是是否可以把package裡面所撰寫的函數很好的利用R所能提供的函數編成（functional programming）的特性
• 物件導向設計（Object-oriented programming）：
  在演進到medium的層級，要處理的資料特性通常複雜化，利用OOP的架構創建相關的class和處理方式，可以相對有效的降低使用上的複雜性。想起到C++大師Bjarne Stroustrup說的：

Complexity will go somewhere: if not the language then the application code.

Large

整個程式為了要完成一個專案而存在，且裡頭可能要處理多樣性的計算，通常是為了滿足整個機構或是特定族群的計算需求，到了這個層級其實通常很少有專案可以使用單一種語言來解決複雜多樣的需求，所以感覺John M. Chambers強調的是程式語言和語言之間的interface，如何讓其他語種跟R有很好的串接，或是利用interface就是在large層級的任務需求要思考的，不過這邊似乎正是目前R核心開發者如John M. Chambers在思考的事情。

整體上，這樣的條理區分要花多少精力在思考如何轉寫代碼，在如今越來越多事物都可以藉由寫程式完成更顯得重要，畢竟要懂得如何“精準地”完成要做的事情，而非殺雞用牛刀。