给程序员的18个忠告
发布于 2024-10-02


版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

扫码阅读
手机扫码阅读
编程效率提升要点摘要
理解和沟通:为了真正达到清楚的理解,需要花时间去沟通和澄清需求,确保把握正确的开发方向。理解需求的错误远比代码错误更加成本高昂。
编程习惯:程序员常犯的错误是急于编码而不充分准备。一次性正确完成任务比重复返工更能提升开发效率。在编写代码前,应该明确任务目标、实施方案以及测试方法。
代码质量:专业程序员注重设计,业余程序员侧重于调试。避免复制粘贴和重复代码,这些行为容易引发bug且难以调试。维持代码简洁,通过功能命名的小函数和方法可以减少注释的需要。
开发实践:采取测试驱动的开发方式,逐步开发并测试可以最小化返工。方法的复杂度应控制在一定范围内,以便于调试。并且,应该随时重构代码,避免留下低质量代码。
代码健康:消除代码中的静态检查警告和错误是必须的。职业程序员应致力于预防bug的出现,而非仅仅修复bug。
经验总结:常规的经验总结和记录对于个人成长至关重要。面对复杂问题,可以通过按时间顺序或整体分部的方法来简化处理。
项目管理:实施每日构建和确认,以便尽早发现并纠正错误,减少返工的可能。

麦哲思科技任甲林


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 244.2K
麦哲思科技任甲林的其他文章
杂谈推理逻辑的严密性
我们在日常生活中的逻辑推理可以分为两类:必然性推理、或然性推理。从前提条件推理出的结论是确定的,这就是必然性推理。比如:人都有父母。这种结论是必然的,不可否认的,所以没必要争论。从前提条件推理出的结论并非是确定的、必然的,这就是或然性推理。比如:痴情女子负心汉。女人—>痴情女;男人—>负心汉这就不是必然性推理,仅仅是部分人的经验。我们的经验大都...
概要设计主要描述哪些内容?
要点如下: (1) 本项目的技术路线,即: Ø 采用的技术方法,如是采用OO的方法、还是结构化的方法,是采用.net还是JAVA; Ø 总体的技术结构,如采用几层体系结构,每层的责任是什么; Ø 系统的网络结构,如系统的功能在网络上的部署分布; Ø 核心技术难点的解决方案
CMMI中的过程管理
EPG进行过程的优化,可以参考DMAIC方法。在CMMI模型中有多个PA是和过程管理相关的,如果映射到DMAIC方法,可以进行如下的对应:(1)D定义过程:OPD,首先刻画当前的过程;(2)M度量过程:MA,然后度量当前过程输入与输出,对当前的过程建立量化的了解;(3)A分析过程:OPP,CAR,判断过程的稳定性,建立过程性能基线与过程性能模型,识别过程的关键控制因子;(4)I改进过程:OPF,O
过程描述的方法
图片: 图片: 在CMMI模型中提供了一种描述过程元素的方法,包含了12个要素:• 过程角色(Process roles):哪些角色参与本过程的哪些活动,可以用角色-职责矩阵表示• 适用的过程和产品标准(Applicable process and product standards),包括企业内的或者企业外的• 适用的规程、方法、工具和资源(Applicable procedures, meth
实例:评审速度与缺陷密度之间的相关性
某公司的项目分为两类:MIS类软件开发与嵌入式软件开发,对这两类项目的需求评审的速率与需求评审发现的缺陷密度分别积累了度量数据,分别见表一和表二,共计52次的需求评审数据。 表一:MIS软件开发项目的需求评审度量数据 表二:嵌入式软件开发项目的需求评审度量数据 对这两类项目的需求评审的速率与缺陷密度分别画散点图如图一和图二所示。 图一:MIS软件开发项目需求评审的缺陷密度
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线