编程习惯
belllsky
这个作者很懒,什么都没留下…
展开
-
2015061607 - 前后端接口校验
我在思考,如果给前端的接口设置某个字段为必填,那么后端是不是需要对前端数据进行各种各样的校验,以保证在错误的时候顺利运行下去.此时的校验不是安全性校验,那么就是攻击性的校验了. 从前端传递过来的数据,非空校验,准确性校验,安全性校验.对应返回不同的错误信息提示. 非空校验;准确性校验;安全性校验. 后端强制使用POST方式提交,少GET方式.是不是需要对前端输入数据的原创 2015-06-16 23:09:50 · 1298 阅读 · 0 评论 -
2015061508 - 注释分析(1)
下面截图是绝大部分接口中类似的一部分 稍好一点的接口如下: 说明接口用途,只要参数名称和实际意义相同.但是依旧有问题 比如查询获取剩余每日额度,如果额度为0,那么返回值是null还是new BananaQuota()呢.对于方法调用者来说,需要知道方法做什么,方法需要什么,需要注意什么,返回值代表什么.如果方法定义时候无法提供,那么调用原创 2015-06-16 00:33:15 · 331 阅读 · 0 评论 -
2015061507 - 注释说明
注释一般是对代码的说明和补充,如果代码能说明问题可以不添加注释,但是存在一个问题就是你认为表达的很清楚了,也许事实上真是表达很清楚.但是对于别人而言,未必能认为你的代码能表达很清楚.所以若干注释是必要的. 对于特定的业务,首批开发者对业务都比较熟悉,从技术开发角度而言可能对他来说很简单很容易,几句话的事情.对于中途接手的继任者而言,从业务的不熟悉不了解到逐渐了解,难度不是从无到有的按照原创 2015-06-16 00:29:37 · 348 阅读 · 0 评论 -
2015061509 - 注释分析(2)
对于下面类似的接口 接口参数过多就表明设计有问题.可以实现功能,但是没有考虑可扩展性,没有替维护人员考虑.考虑的只是眼前功能而已.如果不考虑上面问题,那么新项目和现在的代码可维护程度都差不多.严重破坏开闭原则. 个人还是建议类上说明类的用途,重要属性的含义,方法的作用,方法如何实现,方法的注意事项.当然不是全部,而是有侧重点地加以注释说明. 没用的注释原创 2015-06-16 00:35:48 · 289 阅读 · 0 评论 -
2015061504 - 代码分析之代码格式(1)
新入职的公司已经两个月,最近特意花费两天时间对代码的不足进行分析. 针对代码格式的说明. 如果说编程是书写优美的文章,那么格式就是文章的语句段落的样式,比如首行空格两个,使用排比,比喻,进行换行空格等,我们不可能一逗号到底,不可能全篇只有一个段落.如果文章段落有空格,有不空格,有的空多个,那么给阅读者的印象就是第一印象就是不协调不完整的.文章语句段落都原创 2015-06-15 23:56:37 · 425 阅读 · 0 评论 -
2015061505 - 代码分析之代码格式(2)
具体问题对比情况如下: a01.属性的位置(类定义下边) b01.属性位置不定 从个人的阅读习惯看,成员属性聚集一起. a02属性和类定义间距(不建议空行) b02类定义和属性空行 b03在具体的操作类中,如果某个属性只在某个方法内部才适用,那么建议放在方法内部作为局部变量,原创 2015-06-16 00:10:05 · 346 阅读 · 0 评论 -
2015061506 - 代码分析之代码格式(3)
a04.方法之间空行 b04 方法和方法凑在一起的感觉 a05.花括号的使用 b05 没有对错,只要开发人员同一风格即可. a06.逗号后有一个空格 逗号之后加空格主要起强调的作用,以及不杂糅的感觉 b06,逗号原创 2015-06-16 00:27:55 · 286 阅读 · 0 评论 -
2015061706 - 工作反思
今天新入职不久的同事的返回给web前端开发的同事的返回值,并没有严格要求现有的数据类型进行数据拼装,而是根据当时的Action类内部已经有的代码,参考原有代码,而原有代码处理方式不是那么明智,自己拼装的. 所以返回值就是各种各样的字段,给IOS和移动端的接口都是如此,结果导致数据格式不匹配,导致很多问题. 这个问题出现了,具体问题给我什么启发呢? 1.原来的代码原创 2015-06-17 22:02:51 · 380 阅读 · 0 评论 -
2015061805 - 10年程序开发经验总结(2)
9.bug总是难免的 我不喜欢那些宣称软件开发可以“一蹴而就”的高谈阔论。不论你再怎么费尽心机,bug总是难免的。最好能够做成可以快速故障排除、修复bug和部署修复的系统。 10.解决故障报告 每个开发人员都应该花时间去处理来自客户的故障报告,并修复bug。这能让你更好地理解客户的意图,明白如何使用系统,知道排除故障的难易程度,了解系统的设计情况。这也是转载 2015-06-18 23:19:30 · 392 阅读 · 0 评论 -
2015061804 - 10年程序开发经验总结(1)
开发 1.从小事做起,然后再拓展 无论是创建一个新的系统,还是添加功能到现有的系统中,我总是从一个简单到几乎没有任何所需功能的版本启动,然后再一步一步地解决问题,直到满意为止。我从来没有妄想过能够一步登天。相反,我一边开发一边学习,同时新掌握的信息还可以用于解决方案中。 我很喜欢John Gall的这句话:“复杂系统总是源于简单系统的演化。”转载 2015-06-18 23:13:22 · 302 阅读 · 0 评论 -
2015061806 - 10年程序开发经验总结(3)
15,面对面的交流最有效 当我们需要讨论如何解决问题时,那么面对面的交流比视频、打电话和电子邮件都要好。 16.橡皮鸭法 遇到你绞尽脑汁也解决不了的问题时,不妨找一个同事,然后将问题解释给他们听。很多时候,当你在叙述时,即使你的同事一言不发,你可能也会突然灵光乍现找到问题的关键。 17.问问题 阅读和运行代码往往非常有助转载 2015-06-18 23:23:09 · 318 阅读 · 0 评论 -
2015061903 - 浏览器市场份额
转载:http://www.oschina.net/news/62055/global-browser-market?from=20150503 全球浏览器统计:IE 占 56% Chrome 首超 25% 从图示可以看到IE占据半壁江山,其次是谷歌和火狐.开发调试基本主要以IE,火狐,谷歌为主.转载 2015-06-19 21:50:43 · 333 阅读 · 0 评论 -
2015061605 - 网站前后台数据传递方法
从界面传递给后台数据时,在后台的action中的Method中使用POST方式. 原因在于使用GET方式后,很多情况下都可以通过数据尝试进行破解.使用POST安全性角度来说更好点.原创 2015-06-16 23:03:56 · 404 阅读 · 0 评论 -
2015061510 - 枚举
对于常量,建议适用枚举类型 适用枚举好处1.数据在一个范围内选择,而不能随意写入数据.可以强制保证数据的有效性.原创 2015-06-16 00:41:35 · 287 阅读 · 0 评论