zoukankan      html  css  js  c++  java
  • 高效设计构建软件的十三条建议

    我近来一直在反思这几年开发的实用程序,思考有没有方法设计得更好。

    我大致将实用程序定义为「能够针对具体场景或业务流程解决单一或特定问题的任何项目」。

    举个例子,我用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

  • 相关阅读:
    HDU 2955 Robberies(01背包)
    HDU 2602 Bone Collector(01背包)
    HUST 1352 Repetitions of Substrings(字符串)
    HUST 1358 Uiwurerirexb jeqvad(模拟解密)
    HUST 1404 Hamming Distance(字符串)
    HDU 4520 小Q系列故事――最佳裁判(STL)
    HDU 2058 The sum problem(枚举)
    【破解】修改程序版权、添加弹窗
    HDU 1407 测试你是否和LTC水平一样高(枚举)
    HDU 1050 Moving Tables(贪心)
  • 原文地址:https://www.cnblogs.com/gbtagscom/p/5000287.html
Copyright © 2011-2022 走看看