深夜聊聊程序员规范

yiyefangzhou24 2016-07-06 11:55:07
做业余windows程序员已经n年了,读读程序照葫芦画瓢写写问题不大,但总感觉自己处在一个瓶颈,自己写的程序作坊味儿比较重,难以和商业级程序比拟,短小的还行,稍微上分量的程序bug几何指数上升以至于没法调试,如何提高程序健壮性和书写规范成了当务之急,我相信我不是个案,各位有何看法?各位畅所欲言
...全文
301 10 打赏 收藏 转发到动态 举报
写回复
用AI写文章
10 条回复
切换为时间正序
请发表友善的回复…
发表回复
zycxnanwang 2016-07-07
  • 打赏
  • 举报
回复
我只是想问一下,window开发主要是从事什么开发方向?我才学一年编程!
赵4老师 2016-07-07
  • 打赏
  • 举报
回复
请牢记:源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要,重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理,再简洁,也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错,更方便修改,出错了更容易找到哪里出错和具体出错的原因,更容易改正错误。 试对比 图书馆(对图书的分类够结构化了吧) 和 搜索引擎(可看作是扁平化任何结构数据,仅支持全文检索) 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂,越难修改,越难除错。 有时(甚至大多数时候),看上去越合理、越简洁的代码,运行起来性能越差,出错时查找原因越难,找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误,而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误,“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题;他觉得前同事们应该用这些问题来问自己;实际上不管在哪里工作的开发者们都应该经常问问自己这些问题: ◆“要保证这个问题不会再出现,我该怎么做?” ◆“要想少出些Bug,我该怎么做?” ◆“要保证Bug容易被修复,我该怎么做?” ◆“要保持对变化的快速响应,我该怎么做?” ◆“要保证我的软件的运行速度,我该怎么做?” 如果大多数团队都能不时问一下自己,必定会从中得益,因为这些都是真正强而有力的问题。
  • 打赏
  • 举报
回复
读读软件 软件工程相关的书吧。 《代码大全之》类的
天上的猩猩Y 2016-07-07
  • 打赏
  • 举报
回复
paschen 2016-07-07
  • 打赏
  • 举报
回复
错多了以后就会在之前错过的地方有教训了...
赵4老师 2016-07-07
  • 打赏
  • 举报
回复
比用什么风格更重要的是在任何地方,任何时候都坚持用一种风格。 比爱哪种美眉更重要的是在任何地方,任何时候都坚持爱一个美眉。
xigua1102 2016-07-07
  • 打赏
  • 举报
回复
商业程序也是人写出来的,说不定某些部分还是新手写的 个人觉得,健壮性这种东西,跟架构啊,实现算法啊什么的有关,又涉及到测试什么的,东西太多 而代码书写规范这个,实际上和健壮性关系不太大了,更多的是为了便于阅读吧 代码规范这个没有固定的要求,一般都是常规的写法加上公司要求 一般大公司都有自己的一套书写规范吧
帅得不敢出门 2016-07-07
  • 打赏
  • 举报
回复
一边靠自己积累,一边要多看书,看开源代码。
bluewanderer 2016-07-07
  • 打赏
  • 举报
回复
当然,在做好分析的基础上,老老实实测试模块。
bluewanderer 2016-07-07
  • 打赏
  • 举报
回复
绝大多数人写程序一堆bug是因为事先没做好分析,没想好自己究竟要写的是啥。架构分析不光是架构分析师的工作,特别是你要自己做一个完整项目的时候。

15,440

社区成员

发帖
与我相关
我的任务
社区描述
C/C++ 非技术区
社区管理员
  • 非技术区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧