Re: [ js ] 從C/C++到Javascript
好像不小心回到信箱了?
※ 引述《stan0227 (一切從零開始)》之銘言:
: 各位版眾好
: 我過去三年工作經驗以C++為主
: 最近團隊新專案使用Javascript + Node.JS作為主要開發語言與環境
: 團隊人數約5人 過去皆無開發Javascript經驗
: 在開發過程中遭遇到不適應Javascript語言特性的狀況
: 想在此與各位討論看看 在Javascript開發圈中是如何面對這些問題
: 1) Dynamic Type v.s. Static Type
: 過去習慣Static Type的我們
: 遇到Dynamic Type非常不適應
: 例如function的parameters
: 由於常常需要繼續開發或維護其他成員所撰寫的function
: 我們常常無法直接一目了然了解該function的parameters究竟是什麼
: 是boolean, number, string或是其他更複雜的物件?
: 雖然變數的命名規則可以稍微改善這個狀況
: 但是例如像var FunA = function( message ) {...}
: 這個message究竟是什麼?
: 目前團隊除了透過命名規則外,另外就是每個函式之前都要有個註解來解釋這些參數
利用object當作參數
var rectangle = function ({
width: '100px',
height: '200px',
color: 'black'
})
然後你怕傳錯物件的話, fucntion裡面的檢查是不可少的~
: 2) 物件的property是動態的
: 這是一個很powerful的特性
: 但是在開發過程中一樣很困擾團隊
: C++的開發IDE提供了Intellisense幫助我們很快的選取到物件的property
: 或是回到物件定義的地方了解實際的實作方式
: 但是Javascript的動態property讓Intellisense難以實作
: 因此在使用物件時,我們常常不曉得有哪些property可以使用
: 而回歸搜尋物件定義的地方也很麻煩
: 另外由於此特性,可能你預期的property在runtime中被移除掉了
: 例如var playerCount = playerQueue.size();
: 原本預期得到人數,但是由於size()可能被移除或是被賦予了其他的意義
: 而造成與預期有落差的狀況
js 有遍歷object的方式, 另外可能要寫在prototype裡面並且避免prototype pollution
建議貴團隊可以共同先分享js 的書, 例如javascript: good parts
有不少的js 書其實能解決你很多疑問, 而且更了解js
: ======================================================================
: 不曉得Javascript開發圈的朋友們是如何解決上述開發過程中的議題?
: 團隊目前就是透過命名方式, 註解以及落實單元測試來協助開發
: 很想了解一下Javascript在開發上的慣例
: 謝謝!
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.113.235.116
推
01/23 16:53, , 1F
01/23 16:53, 1F
→
01/23 16:54, , 2F
01/23 16:54, 2F
→
01/23 16:54, , 3F
01/23 16:54, 3F
※ 編輯: lyforever 來自: 140.113.235.116 (01/23 16:56)
推
01/23 19:09, , 4F
01/23 19:09, 4F
推
01/23 20:34, , 5F
01/23 20:34, 5F
→
01/23 22:53, , 6F
01/23 22:53, 6F
→
01/23 22:54, , 7F
01/23 22:54, 7F
→
01/23 22:54, , 8F
01/23 22:54, 8F
推
01/24 09:59, , 9F
01/24 09:59, 9F
推
01/24 16:19, , 10F
01/24 16:19, 10F
推
01/24 17:00, , 11F
01/24 17:00, 11F
推
01/24 20:17, , 12F
01/24 20:17, 12F
→
01/24 20:17, , 13F
01/24 20:17, 13F
→
01/24 20:17, , 14F
01/24 20:17, 14F
推
01/25 23:47, , 15F
01/25 23:47, 15F
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 2 之 2 篇):