前端漫長的全棧之路

目錄

• 1.爲什要遵照代碼規範
• 2.css代碼規範

• 3.js代碼規範與設計模式

  • 3.1 js代碼規範
  • 3.2 設計模式
• 4.關於混合式開發的總結
• 5.關於reactNative總結
• 6.sql基本操做

1爲什要遵照代碼規範

軟件bug的修復是昂貴的，而且隨着時間的推移，這些bug的成本也會增長，尤爲當這些bug潛伏並慢慢出如今已經發布的軟件中時。當你發現bug 的時候就當即修復它是最好的，此時你代碼要解決的問題在你腦中仍是很清晰的。不然，你轉移到其餘任務，忘了那個特定的代碼，一段時間後再去查看這些代碼就 須要：

• 花時間學習和理解這個問題
• 花時間是瞭解應該解決的問題代碼
• 還有問題，特別對於大的項目或是公司，修復bug的這位夥計不是寫代碼的那我的（且發現bug和修復bug的不是同一我的）。所以，必須下降理解代 碼花費的時間，不管是一段時間前你本身寫的代碼仍是團隊中的其餘成員寫的代碼。這關係到底線（營業收入）和開發人員的幸福，由於咱們更應該去開發新的激動 人心的事物而不是花幾小時幾天的時間去維護遺留代碼。

另外一個相關軟件開發生命的事實是，讀代碼花費的時間要比寫來得多。有時候，當你專一併深刻思考某個問題的時候，你能夠坐下來，一個下午寫大量的代碼。

你的代碼很能很快就工做了，可是，隨着應用的成熟，還會有不少其餘的事情發生，這就要求你的進行進行審查，修改，和調整。例如：

• bug是暴露的
• 新功能被添加到應用程序
• 程序在新的環境下工做（例如，市場上出現新想瀏覽器）
• 代碼改變用途
• 代碼得徹底從頭從新，或移植到另外一個架構上或者甚至使用另外一種語言

因爲這些變化，不多人力數小時寫的代碼最終演變成花數週來閱讀這些代碼。這就是爲何建立可維護的代碼對應用程序的成功相當重要。

可維護的代碼意味着：

• 可讀的
• 一致的
• 可預測的
• 看上去就像是同一我的寫的
• 已記錄

2.css代碼規範

1.css使用雖然很簡單，但在在一個複雜的項目中，氾濫而自由的寫css,這會出現不少問題。

2.1 項目中出現的問題

• 1 有時候開發的時候爲了防止和別人css,衝突，咱們會把名字取的很是很是longer,這實際上是沒有必要的。
• 2 有時候咱們按照語意進行命名，如：‘help-guest-regist’，這樣致使不能複用。
• 3 有時候學寫許多無用的代碼。 ‘#login .a .b, #login .a .c’.這其實也是很沒有必要的。

經歷過幾年上班經驗的總結，和在無心中參考張旭鑫老師的 面向屬性的命名。終於找到了一套比較規範的標準。

我本身按照標準和規範制定了一套css，採用less寫的，很是簡單，你們去本身公司，能夠爲公司制定一套標準，提供公司使用。

2.2 less與sass

在使用寫組建的時候咱們須要使用less和sass,進行擴展。提升效率。

2.2.1 less官網

2.2.2 sass官網

注意：sass的文件格式分紅兩種，一個是.scss(不嚴格語法)，一個是.sass(嚴格語法)