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

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

最后

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