很多程序员都在抱怨加班，认为自己该做的都做了，别人没做的自己都做了。为什么？为什么别人能拿到几万的工资，我却只能拿到零头？每个程序员在编程的时候都难免会犯错误，但是如果不从错误中吸取教训，那么习惯就会自然而然，就会经常犯错。不断从错误中吸取教训，养成良好的行为习惯，可以帮助你稳定事业。这是关于如何区分小麦和谷壳以及如何避免编程禁忌的重要一课。1.不提倡非技术技能我们认为非技术技能是项目成功的主要因素。这些非技术技能也可以称为“软技能”。一般来说，它已经被公司证明能够管理好企业与客户之间的长期业务关系，因此也能决定公司的成长和发展路径。一些关键的软技能指标包括：纪律——这是最重要的特质之一，缺乏纪律最终会让这个开发团队对开发能力“缺乏信心”。b.客户之声-未能将客户置于决策的中心只会与您业务的初衷发生冲突。C。沟通——尤其是当客户和供应商不在同一地点时，清晰及时的沟通是填补服务差距的绝佳措施。d.了解需求——成功与失败之间的关键区别将在整个开发生命周期中给人留下深刻印象。2.编码不合理。古人云：善泳者溺，善骑者坠。但是估计绝大多数程序员都认为自己的编程技术绝对牛逼。而且，由不同的程序员实现的每一段代码都不可避免地会发现它的缺陷，这也是事实。所以，只有在一个项目上合作，程序员之间不可避免的摩擦才能证明谁是最好的。健康的竞争是好的，但它不应该成为一个成功项目的负担。另一个创意障碍是无法在您的开发项目中使用预定义的模板来发挥您的优势。几乎所有的编程语言都有一个很好的在线/内置代码片段存储库，可以修补代码并防止重新编程。但是，如果是因为缺乏对需求的理解或缺乏对可用的各种库/模板的接触，则意味着程序员最终无意中丢弃了他们最初创建的代码。这不仅增加了开发时间，而且增加了总体成本。还有一点就是发布的代码已经通过了质检，所以只能作为模板来发挥其更大的价值。3.不是什么都得懂如果你是刚调到这个团队的程序员，对手头的工作还不是很熟悉，你该怎么办？你必须先阅读你的前任留下的一些工作计划。写的详细一点就好了。如果不写详细，估计会让你更加抓耳挠腮。因此，对于需要负责的工作，最好把任务写得尽可能详细。这样做还有很实际的原因：为了能够解决编程问题，最好保证变量是用解释性语言和英语发音来表示的。一些基本的指针可以让你的程序更容易理解。4.没有使用经过验证的工具和技术程序员的好坏要看他使用的编程工具和调试工具。在异常情况的跟踪中，以下是程序员常犯的常见错误。捕捉一些可能影响其他代码的常见情况，处理这些更常见的异常（而不是特殊异常）意味着不经意间去除了抑制整个程序的残留部分，因此不会影响其他人的代码。或许程序员可能怀有恶意，想把所有的异常情况都捕捉到，但即使捕捉到了，也不会采取任何措施。这通常被称为“假安全阀”。安全妥协。5.糟糕的版本控制在任何涉及多个团队的项目中，在版本控制方面不引入最佳实践绝对是一种罪过。版本控制的目的是确保一个人执行的编辑或修订不会影响另一个人的工作。6.最新信息的个人不能代表团队。这是一个比较有意思的点。所有的商业产品都想用自己敏捷的技术和产品文化来打动客户，但在现实中，很少有厂商会花时间去磨练员工在呈现产品特性上的技能。许多公司只是简单地提供一些基础培训，并希望在与员工的实际日常项目中学习更多技能。因此，部门经理和项目的直接领导可以通过以下两种方式来提高员工的绩效：一旦有新员工加入，立即安排他参加专业培训，让他知道自己的角色是做什么的，以及尽快产生创造力。力量。比如一个测试人员加入后，应该向他介绍编程的概念，然后把培训的重点放在测试实践上，而不是继续讲解编程的重要性。在这个阶段，技术的发展速度比以往任何时候都快，因此请记住，定期培训对于为团队创造价值至关重要。例如，网页设计师需要了解响应式设计，为设计师提供大量用户每天使用的不断扩展的移动设备样本，希望他们能从中得到启发。7、不恰当的测试作为整个系统开发生命周期（SystemsDevelopmentLifeCycle，简称SDLC）的重要组成部分，测试通常不需要开发团队给出太惊人的结果。但如果在测试过程中没有做出适当和相应的努力，这是没有道理的。以下一些方法可能对你的测试团队有用，至少你可以在交付产品时给用户一个很好的解释。单元测试mock-up综合测试8.注意安全漏洞在软件开发过程中有时会遇到以下安全漏洞：A.不同组件之间的意外交互：a．输入错误的验证信息；b.SQL数据隐藏代码攻击；C。跨站指令代码；d.命令植入攻击；e.跨站请求伪造（CSRF）；B.资源管理难以实施，包括：a．不尊重可用的内存缓冲区；b.外部控制;C。使用具有潜在危险的功能；9.与客户的沟通在最初的合同签订后，开发公司通常会忘记每天与客户进行产品信息的互动，以至于仍然需要升级。沟通的两个关键点可以帮助您与客户保持更好、更长久的关系：在客户提出要求之前，开发人员应该与客户进行沟通。与客户保持定期沟通。10.避免标准做法迫在眉睫的最后期限。项目出现进度延误的情况并不少见。然而，这并不是说你有理由在开发或测试阶段偷工减料或耍花招，未经测试的模块绝对是一个隐患，会损害你的开发团队的声誉。管理延误的更好方法是提前通知客户并积极执行延误计划。只要延迟的原因是正当的，客户应该理解并给你额外的时间来解决问题。显然，在项目工期之内，急于完成编程质量肯定不是特别安全，因此开发团队在交付后的跟踪维护上会花费更多的时间和精力，成本也是巨大的。最好的方法是从一开始就制定一个完美的执行计划。项目再造所消耗的资源可能是项目本身成本的数倍。任何一家公司都宁愿多花点时间在初期开发上，这样最终的产品肯定是符合SDLC标准的，有足够多的瑕疵和瑕疵。话语权。对于客户来说，及时性不能以牺牲质量为代价，而且永远不会。
