欢迎来到
扫码阅读
手机扫码阅读
给程序员的18个忠告
301 2024-10-02
我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。
查看原文：给程序员的18个忠告
文章来源：
麦哲思科技任甲林
扫码关注公众号
编程效率提升要点摘要
理解和沟通：为了真正达到清楚的理解，需要花时间去沟通和澄清需求，确保把握正确的开发方向。理解需求的错误远比代码错误更加成本高昂。
编程习惯：程序员常犯的错误是急于编码而不充分准备。一次性正确完成任务比重复返工更能提升开发效率。在编写代码前，应该明确任务目标、实施方案以及测试方法。
代码质量：专业程序员注重设计，业余程序员侧重于调试。避免复制粘贴和重复代码，这些行为容易引发bug且难以调试。维持代码简洁，通过功能命名的小函数和方法可以减少注释的需要。
开发实践：采取测试驱动的开发方式，逐步开发并测试可以最小化返工。方法的复杂度应控制在一定范围内，以便于调试。并且，应该随时重构代码，避免留下低质量代码。
代码健康：消除代码中的静态检查警告和错误是必须的。职业程序员应致力于预防bug的出现，而非仅仅修复bug。
经验总结：常规的经验总结和记录对于个人成长至关重要。面对复杂问题，可以通过按时间顺序或整体分部的方法来简化处理。
项目管理：实施每日构建和确认，以便尽早发现并纠正错误，减少返工的可能。
想要了解更多内容？
查看原文：给程序员的18个忠告
文章来源：
麦哲思科技任甲林
扫码关注公众号
相关推荐
麦哲思科技（北京）有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员，中国分部主席
425 篇文章
浏览 232.3K
麦哲思科技任甲林的其他文章
需求文档化的真理与谬误
如果是2个公司之间的供求关系,请将需求文档化; 如果是2个部门之间的供求关系,请将需求文档化; 如果是2个小组之间的供求关系,请将需求文档化; 如果是2个人之间的供求关系,请将需求文档化; 这是真理. 再好的合作关系,当发生分歧的时候,也会互相追究责任,在追究责任的时候,请拿出你的依据:文档. 道德是感性的,证据是理性的.道德是合作的基础,但并非有了良好的道德就一定能合作成功,因为分歧并非仅有道德
论情感的淡漠
这是一个沉重的话题，10年前曾经和朋友讨论过，当时的结论是：随着社会的发展，人与人之间的感情越来越淡漠，家庭趋向于解体。最近也有和朋友讨论起这个话题，结论依旧。 试想一下： 你现在和父母生活在一起吗？相距有多远？你每年和父母在一起的时间有多长？ 你父母会依赖你养老吗？ 你将来会让你的孩子养老吗？ 你的孩子将来会和你生活在一个城市里吗？ 如果你兄弟姐妹生病了，你一年挣10万元人民币，你会拿出多少钱来
需求访谈的18个注意事项
需求访谈的人员需要经过专门的训练，掌握需求访谈的技巧，才能在比较短的时间内，获取客户的真正需求，并且比较完备。那么，应该如何进行需求访谈呢，我根据需求访谈工作坊的练习结果及个人经验，整理了如下的18个注意事项。
过程改进：宽度优先还是深度优先？
在过程改进时有这样一种现象：在组织内有很多项目，但是只有参与正式评估的项目严格按照CMMI的体系在做，其他项目基本没有按此体系在做。企业在得到2级的评估时是这样，得到3级的评估时还是这样，得到4-5级的评估时仍然如此。体系在组织内根本就没有推广开来，而是限定在小范围内的一部分项目的一段时间内。 过程改进应该是一种企业文化的变革，仅仅限定在一段时间的局部项目项目的改进不可能形成企业的文化变更，这种
如何定义方针
方针定义了组织的中高层管理者对管理的期望，是执行过程的总体指导思想，是蕴涵在管理流程中的思想精髓。方针要传达到组织内的每位员工，并体现在质量体系中。在定义方针时要把握如下的原则： （1）简要 方针不需要描述实现步骤，它是对过程的抽象。如：方针可以定义为：每个项目必须估算项目规模,在方针中不需要定义具体如何实现估算（DELPHI，COCOMOII，FFP法等）。 尽量采用短句，每个方针
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线
