很久沒寫東西了，叨叨兩句

最近寫了個簡單的命令行工具，用node 知足一些工做上的需求。是一個處理圖片的腳本，一開始只有一個指令，將指定圖片輸出成配置好的不一樣大小尺寸的圖片。後面加上了圖片壓縮，以及圖片轉base64的功能。就在寫這個圖片處理工具的過程當中，本身獲得了一些理解。

項目結構

項目一開始的幾個文件夾，先新建好。什麼constants,lib,utils之類的都安排上。雖然麻煩點，但起碼看着舒服，別人查看你的項目的時候也方便。至少不會以爲你外行（就在寫這個的同時，忽然想到能夠在本身的腳手架工具中加一個文件夾結構生成指令。。。哈哈哈

代碼結構

• 代碼風格必定要統一好，linter 選一個本身用的慣的，能夠參考別的大佬怎麼配置，總之就是要有一套統一的代碼風格。這一塊在編輯器上能夠安裝上插件幫忙檢測，code formater 也能夠幫忙調整。
• 上面提到的項目結構這裏就有用了。在敲代碼的時候總歸會用到一些常量，工具函數，這時候就能夠把這些要用到的常量，工具函數統一管理起來，分配好。一開始會以爲麻煩，可是相信我。這個習慣養成了本身的代碼質量也會提升（同時很裝逼
• 能夠適當的在邊編寫代碼的時候邊運用一些設計模式。雖說設計模式在一些簡單的項目中多是多此一舉，可是從簡單的項目練習起來，造成思惟習慣，不失爲一個好的鍛鍊。
  TL;DR
  我此次就遇到一個代碼設計模式上的缺陷，我所寫的一些指令方法其中的logger和主程序都寫在了一個主函數中。這時有了一個場景，我在轉base64的指令中發現當圖片說起過大，生成的base64編碼量是很龐大的，這時候就加了個圖片體積的限制。不過這裏更好的解決方法是能夠提示用戶圖片體積過大，程序能夠先自動壓縮圖片，再生成base64。然而這裏實現起來就限於我以前提到的，代碼耦合，致使主要的腳本程序沒法獲得複用，從而增長了工做量。
  以上，我描述了我在敲代碼時的一個場景。而我接下來作的可能就是會去把各個指令的主要程序從執行函數中抽離出來，給代碼解藕，這樣就能夠很自如的應對不一樣的需求挑戰
• 建議閱讀一些關於設計模式的知識，一開始理解起來會比較抽象，但總得有開始咯

實際代碼中的嗨點

我是前端程序員，慢慢的在寫JS的時候，發現一些很舒服的點（自嗨）

適當的運用閉包，尖頭函數，高階函數，這些概念要多去理解，多運用。實踐起來以後真的很嗨

好比：

const handleGenerateFail = spinner => err => {
  spinner.text = `壓縮圖片失敗：\n\n${err}`
  spinner.fail()
}

const handleGenerateSucceed = spinner => _output => {
  spinner.text = `壓縮圖片成功`
  spinner.succeed()
  console.log('\n查看', _output)
}

const spinner = ora(`圖片壓縮中`).start()
const failHandler = handleGenerateFail(spinner)
const successHandler = handleGenerateSucceed(spinner)

最後

記錄一下本身在洗澡的時候想到的一些東西（廁所真的是一個激發靈感的好地方