我近来一直在反思这几年开发的实用程序，思考有没有方法设计得更好。
我大致将实用程序定义为「能够针对具体场景或业务流程解决单一或特定问题的任何项目」。
举个例子，我用PHP写了个小程序，输入来自电商店铺的输出，通过解析数据转换成下一步特定业务流程需要的格式。
怎样设计才能更出色？
我一般有了解决问题的思路就会马上动手，随手打开一个编辑器就开始敲代码了。
过了一段时间，发现需要从以前写的实用程序中照搬一些功能，但是当我开始重用代码的时候，才发觉之前写的代码真是糟糕啊。通常我不会花太多时间写实用程序，后果就是它们大都没有类，没有命名空间，甚至不是面向对象的。为了达到目的甚至用了过程式编程！
经过这件事我觉得应该更有计划性，哪怕是很小型的项目也必须如此。
现在在开始新的项目之前，我都会考虑以下要点：
1）基本功是必需的！
不管实用程序有多小，都要养成良好的编程风格！使用正确的源代码格式，命名规范和注释。让别人可以毫不费力地看懂代码。
尽可能避免过程式编程。
哪怕项目很小或者用处有限，我也不会马马虎虎地写代码。
2）定义项目
除非实用程序只有一个功能，不然的话先对项目下好定义再开始写代码。程序的定义应该包括基本的声明，比如谁会调用它，预设的输入格式如何以及预期的输出是什么。
同时要定义数据来源，安全问题以及将来程序是否会逐步增加功能。
将实用程序托管在哪里呢？
定义越详细，挑选合适的工具就越轻松，编程时更不会迷失方向。在为他人开发软件时更要注意这一点！
3）有合作者吗？
如果有其他程序员参与开发，就需要丰富文档和注释。使用源码版本控制系统，认真编写类和方法确保不会出差错。
如果根本不会有第二个人看你的代码的话，文档和注释简单写写就够了，不用勉强自己。当然你得保证自己能看得懂。
4）源代码版本控制？
源代码是否可以托管在公开库中取决于它自身的背景，比如是否属于组织内部项目。如果可以公开，就要完善文档，添加readme.md文件，添加文档块来明确代码的所有权，还要使用语义化版本号。
如果你有知识产权方面的顾虑，还可以再加一个许可证加以限制。
5）有必要长期维护吗？
如果你觉得程序很有前景，认为会有更多程序员参与进来的话，就得使用版本控制，完善文档并附加许可证。
如果实用程序属于组织内部项目，你可能不会负责长期维护它。所以还是趁早把这些琐事都搞定了吧，免得将来接手的程序员把你归入可怜程序员之列。
如果代码文档完善，你甚至会收获推荐信（虽然不能把在公司写的代码带走，有封推荐信至少可以证明你干得不错！）。
6）应该创建API或者库吗？
虽然讨论API和库超出了本文的范围，这个问题仍然需要仔细斟酌，因为它会影响编写代码的方法。
要编写的实用工具是独立的，还是作为一个库来分发？或者你想让他人通过API接口访问一些功能？
如果选择了API，那么就必须要扎实地控制好输入和输出、数据验证、数据转换、安全性、HTTP路由、断点等等。加密和认证也要重点考虑。
7）CMF，后端，配置？
实用程序是否需要自带独立于前端环境的管理界面？
实用程序是否需要配备后端使管理员有相应权限去进行控制？
最大的问题在于，任何内容管理框架（CMF）大都会塞给你一大堆根本用不到的功能，而你只需要跑一个实用程序就够了。不过话又说回来，CMF也会给你相应的API和辅助工具，可能也相当好用。
要不然就把所有的配置信息都保存在一个文件里，只允许管理员有权限访问。
大多数时候我都会创建一个config.php文件，把所有的配置数据都放在里面，纯手动编辑，不使用任何界面。
8）包管理？
包管理非常讨人喜欢，但这并不意味着非用不可。
如果只需要几个库的话，不使用包管理一样很轻松。
如果需要超过两个或三个模块，或者模块十分复杂，我还是会使用包管理的。
如果决定使用Composer模块（PHP），那么我建议你按照Composer的规则来写实用程序，这样的话你的项目自身也可以用Composer来管理。使用PSR-4 spec，文件夹命名，类的命名规范诸如此类的东西。
9）前端框架？
用户执行诸如上传文件、填写表格、审核数据、可视化数据等等多步操作的地方，需要复杂的前端。如果前端变得过于复杂，就要考虑使用前端框架。
说到框架，我其实指的是CSS框架，比如Bootstrap，Foundation，甚至是jQuery这种更庞大，包括更多可视化模组和JavaScript插件的框架。
我喜欢从头开始写CSS，万一项目壮大了，我可能就得在Foundation框架的基础上把CSS重写一遍。
10）需要日志吗？
你需要历史日志来记录使用实用工具的过程吗？你需要为审计工作记录“谁做了什么，何时做的，从哪里做的，做了多久”吗？
还有，如果是在公司里而且实用工具会被许多人用到的话，是有必要记录日志的。
一些不错的日志库可以用包管理找到，又一个使用包管理的理由，不是吗？
11）需要强化错误处理吗？
我编写实用软件的时候大多不考虑错误处理的问题。我倾向于写代码时让所有错误提示开着，一旦所有工作都搞定了而且测试没有发现问题的话，我就直接把错误提示关掉。
你要仔细考虑，是否真的需要复杂的错误处理机制、前端消息、撤销功能、后退按钮管理、自动保存而不是保存按钮、弹出窗口和模态窗口。同时还要考虑是否要和日志系统对接。
务必注意，日志、审计和错误处理都应该是前期标准中的一部分。这可以帮助你从一开始就决定如何使用包管理和框架。
12）需要加强安全性吗？
如果实用程序使用破坏性数据管理或者需要验证用户身份，那么加强安全性简直轻而易举。
我是这么想的，如果需要强大的安全性，那么就使用高安全性的框架。可以选择诸如Laravel、Kohana、Slim、Sliex之类的没有管理界面的框架。还可以选择诸如MODX、ProcessWire和Bolt之类的有界面的框架。只要框架满足你的安全要求就行了。
重新发明轮子完全没有必要。不要自己去实现日志，安全性，用户身份验证，数据库抽象等等。直接用框架。
13）要公开吗？
还有一个大问题需要考虑，你写的实用工具是仅供内部使用，还是开放给网上的所有人？如果是前者，内部是指会有几十个，上百个组织内的同事使用你的软件吗？
必须确保终端（endpoint）被严格定义过，同时确保任何需要保护的辅助文件和脚本都得到了保护。
如果你疑虑高访问流量会带来问题，其实应该考虑缓存机制，尤其是在生成数据库或高度动态的数据的地方。我们也会考虑安全问题、日志记录、身份验证等等。
这么说吧，一般而言，如果只是为普通人写实用工具的话，用寻常的库，工具，方法，文档就好了，或者干脆用框架。
在要发布公开版本的时候没什么好操心的，成事在天，只要严格按照规矩办事，使用现代可靠的模块和框架就没什么问题。
你呢？
以上就是我打开Sublime或者Netbeans开始一个新项目前需要思考的事情。
或许你已经有一套用作实用程序的常用工具集了。我想知道它们都是什么，毕竟像Laravel这样的大型框架或者全功能的CMF/CMS都过于庞大了没法直接拿来当作实用工具。你是否在使用功能不多却足够完成实用功能的更小型的微框架呢？
原文链接：http://www.gbtags.com/gb/share/9424.htm