很久没写东西了，叨叨两句

最近写了个简单的命令行工具，用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)

最后

记录一下本身在洗澡的时候想到的一些东西（厕所真的是一个激发灵感的好地方