https://fwhyy.com/tags/%E7%BB%8F%E9%AA%8C%E6%80%BB%E7%BB%93/Recent content in 经验总结 on 冯威的博客Hugozh-CNTue, 24 Oct 2023 08:27:49 +0800https://fwhyy.com/2023/10/talk-about-hexagonal-architecture/Tue, 24 Oct 2023 08:27:49 +0800https://fwhyy.com/2023/10/talk-about-hexagonal-architecture/<p>指导我们写出漂亮代码有一种方式是学习设计模式，自从 Gof 四人组的《设计模式》出版后，各类设计模式的书层出不穷。熟读这类书籍，对面试肯定是有帮助的，但代码能力是否有大的长进就不一定了，如果没能理解背后的思想，去生搬硬套，只会起反作用。</p>https://fwhyy.com/2021/02/what-you-see-is-not-necessarily-true/Mon, 08 Feb 2021 08:30:37 +0800https://fwhyy.com/2021/02/what-you-see-is-not-necessarily-true/<p>年末了，再说说加班的问题，其实加班这个话题之前已经写过两篇了：</p> <ul> <li>蹭个热度，也说说 996</li> <li>你的加班有价值吗？</li> </ul>https://fwhyy.com/2020/09/why-are-you-so-busy-and-still-cant-do-well/Wed, 30 Sep 2020 09:46:53 +0800https://fwhyy.com/2020/09/why-are-you-so-busy-and-still-cant-do-well/<p>一直都很喜欢《重来》系列，最近出了《重来3：跳出疯狂的忙碌》，第一时间在微信读书中阅读了，让我们印象比较深刻的就是「冷静」和「效率」，本文主要说说效率的问题。</p>https://fwhyy.com/2020/08/programmer-is-a-lifelong-learning-profession-how-should-i-learn/Mon, 24 Aug 2020 09:41:17 +0800https://fwhyy.com/2020/08/programmer-is-a-lifelong-learning-profession-how-should-i-learn/<p>在上一篇《一款用了就不想走的工具》中介绍了一款工具 Notion ，可以做学习的规划、时间的管理、学习的记录等，但学习本身还是需要一些方法的，本文谈谈我对学习的一些感悟。</p>https://fwhyy.com/2020/06/how-to-stimulate-team-potential/Sun, 28 Jun 2020 12:06:25 +0800https://fwhyy.com/2020/06/how-to-stimulate-team-potential/<p>每个技术人员最终可能都会走上管理岗位，从最初的开发 Leader、到部门负责人、甚至到 CTO,这每一个角色的转变，都需要付出巨大的努力去进行思维的转变。最近读的《授权》这本书可以让我们更好地胜任管理这个岗位。</p>https://fwhyy.com/2019/09/have-you-paid-your-technical-debt-yet/Mon, 09 Sep 2019 07:03:22 +0800https://fwhyy.com/2019/09/have-you-paid-your-technical-debt-yet/<h2 id="什么是技术债">什么是技术债？</h2> <p>技术债是由沃德·坎宁安在1992年提出，指我们在软件架构或代码编写过程中有意无意地做了错误的决策。随着时间的累积，这种错误会越来越多，就像背负了很多债务一样。</p>https://fwhyy.com/2019/07/practice-of-kpi-in-small-product-team/Mon, 29 Jul 2019 07:05:59 +0800https://fwhyy.com/2019/07/practice-of-kpi-in-small-product-team/<p>最近公司决定对所有技术人员实行KPI考核，曾经一度非常反感KPI的我也被要求制定产品团队的KPI指标。为什么要实行KPI考核，因为在项目团队和产品团队的管理中出现了问题：</p>https://fwhyy.com/2019/07/how-programmers-learn-english/Sun, 21 Jul 2019 09:57:50 +0800https://fwhyy.com/2019/07/how-programmers-learn-english/<p>首先，这不是一篇广告，虽然这个标题很像。</p> <p>其次，我的英语水平也很一般，所以更多的是谈谈一些失败的经历和思考，俗话说，成功的经验不可复制，失败的经验倒可以让我们少走弯路。</p> <!-- more --> <p>英语的重要性毋庸置疑，对于程序员来说更甚，一些最新的技术资料是英文的，很多开源软件的官方文档也是英文的，如果想进入外企英语是必备条件。我就是英文不好，连投递外企简历的勇气都没有。</p> <h2 id="我的英语水平">我的英语水平</h2> <ul> <li>学生时代四级最高分58</li> <li>工作后立过无数次Falg，到现在没有明显进步</li> <li>听说基本为零，读写凑活，技术相关文档能基本能读懂，借助翻译工具可以和老外书信交流</li> </ul> <h2 id="学英语目的是什么">学英语目的是什么</h2> <p>语言分为听说读写，我们在学习母语的的时候，通常是先听说后读写，而在学习英语时往往是相反的，像我就是，读写强于听说。很多的英语学习方法会建议要按照学习母语的方式来学习英语，我认为也不完全是对的。最重要的是要搞清楚学习的目的是什么，然后对症下药，比如：</p> <ul> <li>出国旅游或者想要面试外企，就要侧重于听说</li> <li>看英文技术书籍、网站、博客，在Github上参与开源项目，就要侧重于读写</li> </ul> <p>对我自己来说：</p> <ul> <li>需要阅读英文技术资料</li> <li>经常会在stackoverflow上找一些问题的答案</li> <li>使用了某个开源代码，需要在issues中寻求帮助</li> <li>在Linode购买了vps，在Tickets中需要和老外进行沟通</li> </ul> <p>所以我更偏重在读写上的提高，在读写搞定的情况下，再有针对性地去练习听说，YouTube这个庞大的资源库就是要学习好听力的强大动力。</p> <h2 id="量变到质变">量变到质变</h2> <p>我非常相信任何事物都能从量变到质变，如果质变没有发生那就是量不够。下面是我有深刻体会到两个从量变到质变的例子：</p> <h3 id="跑步">跑步</h3> <p>平常跑步，三五分钟就会大汗淋漓，之前从未想过在冬天的早晨，零下几度，还能跑到全身出汗。直到几年前的一个冬天早晨，出门跑步，10分钟的时候，身上还没发热，二十分钟的时候，也只是微微出汗，等到1个小时左右，完成了10公里时，全身已经汗透。</p> <h3 id="音乐">音乐</h3> <p>2017年春，同学在群里有人推荐了《成都》这首歌曲，非常喜欢，连续一个礼拜的上下班途中，单曲循环听，这一个礼拜的时间，我并没有刻意地练习怎么唱，就是因为不断的重复，使我学会了这首歌。</p> <p>英语的学习，不管是记单词，还是阅读，或是听说，如果有大量重复的训练，必然会产生一定的效果，但我们常常是三分钟热度就放弃，我也是如此，就像跑步，10分钟的时候，就已经停下了脚步，不管你跑了多少次，始终都感受不到大汗淋漓的畅快。</p> <p>今年年初，花99元报了一期水滴阅读，需要坚持100天，起初积极性很高，再加上老师在群里的督促和坚持打卡可以赠送书籍的诱惑，开始的一两个月每天都花固定时间去学习，做习题，后面随着难度的增加，间歇性的没有打卡，慢慢也就放弃了，要知道，坚持一件事情很难，放弃可是分分钟的事。</p> <h2 id="强烈的意愿">强烈的意愿</h2> <p>每个人都会有惰性，这个惰性体现在是不是你所关注的事情。我老婆经常说我，家里的买的拼装家具，小孩的拼装玩具，每次都要拖很久才去做，你自己买的健身器材的安装就非常积极。</p> <p>我反思了下，为什么我每次都没能够坚持呢？还是意愿不够强烈，对我来说，英语学习好学坏，对我的工作和生活不会造成什么影响：</p> <ul> <li>工作中查资料遇到有英文的，可以借助翻译工具</li> <li>生活中就更是更英语没什么交集</li> </ul> <p>什么时候会有强烈的意愿呢？</p> <ul> <li>当我们去准备面试时，我们必需精心地复习巩固面试所需要的专业编程技能，</li> <li>当在工作中遇到难题时，我们必需通过各种手段去解决，在这过程中，就会有很大的收获</li> </ul> <p>如果您像我一样，英语不是生活和工作中的必需品，而又想学好它时，就要想办法提高自己学习的意愿，我能想到下面一些方式，当然每个人都有自己的方式：</p> <ul> <li>在Github上参与开源项目，可以从提issues开始</li> <li>找到国外大神的系列技术文章，然后制定一个小计划，比如在1个月内翻译10篇</li> <li>以赚积分为目标，在stackoverflow上用英文去回答别人的问题</li> </ul> <h2 id="总结">总结</h2> <ul> <li>英语和编程一样，需要不断实践才能提高</li> <li>无所谓形式，是先记单词，还是直接就阅读，语法到底需不需要学习，我觉得不太重要，主动或被动地让自己有强烈的意愿是关键</li> <li>制定目标，剩下的就是行动了，就像池大说的，让正确的事情持续发生，这其实就是量变到质变的过程</li> </ul> <p>希望本文对您有所帮助。</p>https://fwhyy.com/2019/07/some-thoughts-on-product-quality/Mon, 01 Jul 2019 06:44:41 +0800https://fwhyy.com/2019/07/some-thoughts-on-product-quality/<p>不管是做产品还是做项目，也不管是采用瀑布模型还是敏捷开发，我们都有一个终极目标，就是能按时交付质量可靠的功能，其中质量尤为重要。</p> <p>本文是我对产品质量的一点思考，如果您所在的团队代码质量很高，很少出BUG，那么可以私信我，我们可以交流下关于代码质量的一些问题。</p>https://fwhyy.com/2019/06/how-to-learn-and-read-technical-books/Sun, 02 Jun 2019 15:08:16 +0800https://fwhyy.com/2019/06/how-to-learn-and-read-technical-books/<p>技术的更新换代非常的迅速，作为一个技术人，需要持续不断地学习才能不被淘汰。但是学习没有速成的方法，只可能有一些技巧让我们事半功倍，本文是我对学习和读书的一点思考。</p>https://fwhyy.com/2019/04/996-icu/Mon, 22 Apr 2019 22:19:10 +0800https://fwhyy.com/2019/04/996-icu/<p>最近996很火热，也来凑凑热闹，在文章的开始，先表明我的立场：坚决反对996。</p> <p>什么是996？</p>https://fwhyy.com/2019/02/summary-of-2018/Thu, 07 Feb 2019 23:51:42 +0800https://fwhyy.com/2019/02/summary-of-2018/<p>一直都有写总结的习惯，一方面思考下一年下来有哪些做的好的，哪些还需要改进。另一方面，若干年后再回过头看看，知道每年都发生了点什么。但写东西这事，不能耽搁，有了想法就要立即动笔记录，否则可能会不了了之。像我前两年的年终总结就是如此。</p>https://fwhyy.com/2018/10/is-your-overtime-worth/Sun, 21 Oct 2018 23:09:58 +0800https://fwhyy.com/2018/10/is-your-overtime-worth/<p>今年一直在忙公司产品的事情，压力比较大，工作强度也比较大，不夸张的说，今年加的班应该比整个职业生涯加起来还多，所以也有了些思考和想法。</p>https://fwhyy.com/2018/09/how-to-improve-development-efficiency-2018/Mon, 17 Sep 2018 22:49:03 +0800https://fwhyy.com/2018/09/how-to-improve-development-efficiency-2018/<p>开发效率可以从个人开发效率和团队开发效率来谈，抛开自由职业者，但凡在一个公司上班的程序员都必然是在一个团队中工作，所以每个人的个人效率最终都会转化为团队的效率。转化率有多大，取决于团队的凝聚力，每个人的劲是不是在往一处使。</p> <p>团队效率最重要的是沟通，我经常会碰到这样的情况：</p>https://fwhyy.com/2018/09/how-to-lead-a-technical-team/Mon, 03 Sep 2018 06:25:36 +0800https://fwhyy.com/2018/09/how-to-lead-a-technical-team/<p>从2012年的<code>Team Leader</code>到现在负责公司的产品团队，在技术管理的道路上也走了6年的时间，看过不少管理的书，也经历过从零开始组建一个团队，和团队成员的更替。下面谈谈我自己的一些感受和理解。</p>https://fwhyy.com/2018/08/do-we-really-need-kpi/Fri, 03 Aug 2018 22:51:21 +0800https://fwhyy.com/2018/08/do-we-really-need-kpi/<h2 id="前言">前言</h2> <p>工作十几年，经历过不少的公司，每个公司都有自己的管理方法，其中大公司比较偏爱使用KPI考核，小公司则直接靠人来管理。下面谈谈之前公司KPI考核制度和现在「松散」管理的对比。</p> <h2 id="严格的kpi制度">严格的KPI制度</h2> <p>之前的公司在武汉研发中心有大概五六百的技术人员，每个团队的项目经理只考虑需求沟通、任务分配和资源协调。完全不用管团队成员是否有认真干活，员工的管理依赖KPI制度。当时开发岗的考核制度大致如下：</p> <h3 id="工作量">工作量</h3> <p>任务系统的任务都会评估出一个工作量，以天为单位。计算方法为在季度末算出整个季度中完成的工作量和总出勤天数的一个比例。表明上看这个指标非常好，公司不用怕员工偷懒，相反员工还会主动去找事情做，因为担心工作量不够。当由于各种任务之间的衔接、各种内耗，往往会造成「忙」的假象。</p> <h3 id="bug量">bug量</h3> <p>bug量的计算方法是一个季度所做的任务的有效bug量和所做任务的工作量的一个比例，最终算出每天的平均bug量是多少，再根据这个bug量来打分。设置bug量这个指标的初衷是为了提高开发人员的开发质量，减少测试与开发之间往返的消耗。但这个指标至少会带来两个弊端：</p> <p>1、开发人员和测试人员的对立</p> <p>因为测试岗也有bug量的质量，他们是平均每日找到多少个bug，所以很多时候开发人员都在和测试人员纠结bug有效性的问题，其实开发 和测试的目标应该是一致的，都是为了软件能够高质量的交付。</p> <p>2、事不关己，高高挂起</p> <p>经常会在项目中发现一些不合理的代码，如果这些代码不是自己负责的，开发人员不会去进行重构，因为可能会带来更多的缺陷，而这些缺陷最终会记在修改者的头上，即便重构不会带来任何的风险，也没有人会关心这个，人们更多关心的是软件能不能正常的运行。正是由于这个指标的存在，随着时间的增长，项目中的坏味道会越来越多。</p> <h3 id="关键节点达成率">关键节点达成率</h3> <p>任务系统中的每个任务都会设置关键节点，对于开发来说关键节点就是某个任务提交测试的时间点。计算方法是未超时的任务数和总任务数的比例。这项指标的初衷是保证开发的效率，但也带来了一些问题：</p> <p>1、互帮互助少了</p> <p>虽然公司一直都强调同事之间要多沟通，多互相帮助，但正是有了这个指标当你的任务已经快到关键时间点的时候，你就没有多余的时间去顾及其他的事情了。</p> <p>2、多任务的处理</p> <p>当你正在处理设置了关键节点的任务的时候，突然来了紧急bug任务，正常逻辑应该是优先响应紧急bug，但也有了这个指标，开发人员就会先保证当前任务不超时，而不会去响应bug需求哦。</p> <h2 id="松散的管理模式">「松散」的管理模式</h2> <p>近些年在一个中小公司负责产品团队，团队规模很小，自然也就没有严格的KPI考核制度，开发人员都是有个性的，都不会喜欢被KPI所束缚。但没有KPI制度的管理也会碰到各种问题。</p> <h3 id="太理想化">太理想化</h3> <p>我一直想象的理想团队是每个成员都应该是自我驱动型的，当需要通过制度或是人来管的时候，自然是做不好事情的。现实情况是，人都是有惰性的，团队并不会了一个伟大的共同目标去努力奋斗，每天朝九晚九仅仅只是当成了一个工作。起初最典型的一个表现是，分配的任务总是在截至时间的最后时刻完成。</p> <h3 id="公平">公平</h3> <p>没有KPI这种量化的考核，对团队成员的考评就会偏主观，就可能带有感情色彩，就可能有失公平。做事快的人可能会被分配更多的任务；bug多的人可能会感觉一直都处于「忙碌」的状态；效率高的人可能会被认为不够努力。</p> <h2 id="总结">总结</h2> <p>任何管理方式都会各有利弊，包括最近两年比较火的OKR，相信在实践过程中一样会遇到各种问题。既然都会遇到困难和问题，我个人还是偏向松散的管理模式。</p> <p>松散的管理模式，并不是说不管理，而是要努力做到让每位团队成员从“要我做”到“我要做”的转变。我认为可以尝试以下一些方式：</p> <p>1、领导要对团队成员要有足够的信任，用人不疑，疑人不用； 2、技术人员普遍比较闷，不愿说出内心真实想法，需要经常和他们去沟通，了解他们内心真实想法，能力范围之内解除他们后顾之忧； 3、团队内部需要经常组织一些活动，提升团队凝聚力。比如一个开发阶段完成后，组织吃饭唱歌等； 4、定期给团队内部培训，要让每个成员都了解产品的思想，了解客户真实需求，了解公司的愿景。目的是让大家能够一起为了一个共同的目标努力，而不只是自己负责的一个功能模块。但同时也要阶段性让团队成员看到收益，而不只是画饼子； 5、建立奖惩制度，赏罚分明，公平、公正、公开； 6、如果公司领导允许，或许可以尝试下阿米巴的方式。</p>https://fwhyy.com/2018/07/modify-the-background-color-of-vs-code/Sat, 21 Jul 2018 23:04:03 +0800https://fwhyy.com/2018/07/modify-the-background-color-of-vs-code/<p>一直以来都是在<code>Windows</code>下进行开发，VS自定义的字体和背景色已经跟了我十来年了，最近已渐渐不使用<code>Mac</code>下的<code>Windows</code>虚拟机了，主力开发工具就变成了<code>VS Code For Mac</code>和<code>Visual Studio For Mac</code>。没有了之前的背景色还真不习惯，下面介绍怎样修改<code>Mac</code>下的<code>VS Code</code>和<code>VS</code>的背景色。</p>https://fwhyy.com/2018/07/how-can-we-stick-to-it/Tue, 10 Jul 2018 23:17:40 +0800https://fwhyy.com/2018/07/how-can-we-stick-to-it/<p>最近听到了很多关于坚持的话题。</p> <p>1、公司的年中会议上，几位领导人的讲话都提到了我们需要找准方向，坚持下去。 2、在dotNET 跨平台的群里，有群友问怎样才能成为像张善友这样的大牛？张善友的回答是：我做技术近20年，坚持每天学习新技术半小时，坚持晚上11点睡觉，早上6点起床。 3、在逻辑思维的公众号中，罗胖坚持每天早上6点半发布一条有价值的60秒语音，就这么一件事，他坚持了2000多天。</p>https://fwhyy.com/2016/09/talk-about-overtime/Thu, 08 Sep 2016 23:22:06 +0800https://fwhyy.com/2016/09/talk-about-overtime/<p>今天谈谈加班这个敏感的话题，相信大家在职场中都或多或少的经历过加班。特别是 IT 这个行业，加班更是家常便饭。加班通常有这么四类：</p>https://fwhyy.com/2012/10/how-to-improve-the-efficiency-of-development/Sun, 21 Oct 2012 00:00:00 +0800https://fwhyy.com/2012/10/how-to-improve-the-efficiency-of-development/<h2 id="前言">前言</h2> <p>给你一个任务,限定5天内完成,如果你实际用了6天,可以说是开发效率不高,或者同样的一个任务,你花了6天,而你的同事却只用了4天,也可以说是你的开发效率不高,影响开发效率的因素有很多,下面就我个人的理解来谈谈怎样提高开发效率.</p> <h2 id="工具">工具</h2> <p>俗话说，工欲善其事必先利其器，使用得心应手的工具必然会提高开发效率，做微软平台开发的肯定离不开VS，就VS本身来说，除了常用功能外一些常用的快捷键一定要能熟练运用，例如下面是我认为比较有用的几个快捷键：</p> <ul> <li>注释： Ctrl + K + C</li> <li>取消注释： Ctrl + K + U</li> <li>全屏： Shift + Alt + Ente</li> <li>设置标签： CTRL + K, CTRL + K</li> <li>下一个、上一个标签： CTRL + K, CTRL + P 、CTRL + K, CTRL + P</li> <li>列出成员： Ctrl + J</li> <li>显示参数信息： Ctrl + Shift + Space</li> <li>转到定义后返回： Ctrl + –</li> </ul> <p>熟练使用快捷键对于代码编写的速率和跟踪代码的速率会有大大的提高。</p> <p>有时候开发工具自身的功能受到了限制，这是就需要使用插件来丰富功能，这里推荐两款插件，VS中的ReSharper和SqlServer中的SQL prompt5，ReSharper是功能很强大的一个VS插件，但会拖慢VS的速度，就看怎么去权衡了，我在之前的博文《<a href="http://blog.fwhyy.com/2009/10/powerful-vs-plug-in-resharper/">强大的VS插件—Resharper</a>》做过简单介绍。SQL prompt5是SqlServer的一个插件，功能也非常强大，有很强的智能提示功能，所提供的SQL Search功能可以对数据库对象进行快速查找，还提供代码片段功能，在我之前的博文《<a href="http://blog.fwhyy.com/2012/10/using-sql-prompt5/">SqlServer开发利器—SQL Prompt5</a>》中也做过介绍。</p> <p>除了我们每天都离不开的VS和SqlServer之外还有一些辅助的开发工具也可以来帮助我们来提高效率，我经常使用的有以下几种：</p> <ul> <li>SqlDbx：很小巧的一款数据库管理工具，但功能非常强大，支持多种数据库，经常使用他的智能提示和生成脚本等功能，但也有缺点，对中文支持的不是很好；</li> <li>Aptana：该工具可以说是做Web开发的利器了，我有时写JS会用到该工具，有一个亮点之处是智能提示能够显示不同浏览器是否支持；</li> <li>Free Javascript Editor：可以很方便的写一些简单的HTML和JS代码并运行，可以直接选择JS的代码片段进行执行，对JS的调试也很方便。</li> </ul> <p>还有一些其他的工具也非常有用，比如我在平时的工作中会经常用到Total Commander和Everything：</p> <ul> <li>Total Commander：资源管理器的代替工具，支持多标签，可以很方便的对文件进行操作；</li> <li>Everything：一款搜索工具，速度奇快，以前也做过介绍《软件推荐：磁盘搜索软件Everything》。</li> </ul> <h2 id="代码沉淀">代码沉淀</h2> <p>有点规模的软件公司都会有自己的开发框架，这些框架都是多少年积累的产物，目的就是为了提高开发效率，作为一个开发人员平时对于一些常用的代码也应该有自己的沉淀，不光自己沉淀，在组内也应互相分享，记录这些沉淀的代码就可以根据自己的喜好了，记事本、Word、Excel、OneNote等都可以。沉淀的代码还可以使用VS的代码片段功能来进行管理，VS2010中对代码片段支持的很好，上面提到的SqlServer的插件SQL Prompt5也提供了数据库中的代码片段功能。</p> <p>VS中给我们提供了很多现成的代码片段，要使用自定义的代码片段最方便的就是使用代码片段制作工具，工具点击<a href="http://snippeteditor.codeplex.com/">此处</a>下载，当然也可以自己创建代码片段文件，然后在VS中导入即可，代码片段文件其实就是一个xml格式的文件，后缀为snippet。</p> <p>代码质量</p> <p>代码质量好了，产生的bug就少，和测试的交互也就少了，也就不会因为前面产生的bug而影响后面的进度，效率自然就高了。代码质量可以分三个方面来看：</p> <p>1 代码出错少，能够正常的运行；</p> <ul> <li>主动学习，提升自我的编程技能；</li> <li>勤思考，对干过的错要经常总结，一些规范性的原则要牢记，这些常常会出现一些低级错误；</li> <li>一个任务做完后需要进行充分的自测。</li> </ul> <p>2 代码的运行效率高，在大数据、高并发的时候能够高效运行；</p> <ul> <li>高性能的开发得从点滴做起，不放过每一个细节，可能一个小的细节点就是一个性能的瓶颈；</li> <li>要有重构代码的习惯，好的代码是重构出来的，高性能的代码也是重构出来的；</li> <li>多学习一些原理性的知识，不光要知其然还是知其所以然，基础扎实了，一些性能的问题就知道怎么去优化了；</li> <li>之前翻译过几篇关于C#代码简化的博文，参见《<a href="http://blog.fwhyy.com/2010/10/csharp-net-code-concise-optimization-techniques-1/">C#/Net代码精简优化技巧（1）</a>》、《<a href="http://blog.fwhyy.com/2010/10/csharp-net-code-concise-optimization-techniques-2/">C#/Net代码精简优化技巧（2）</a>》、《<a href="http://blog.fwhyy.com/2010/11/csharp-net-code-concise-optimization-techniques-c/">C#/Net代码精简优化技巧（3）</a>》</li> </ul> <p>3 代码最后的运行结果要和客户的要求一致；</p> <ul> <li>做需求之前把自己的理解跟需求分析进行沟通看是否能达成一致，如果是直接和客户进行沟通可以先做出小Demo，然后给客户演示，根据反馈不断改进；</li> <li>在做的过程中如果遇到有疑问的地方一定要和需求或客户进行沟通，不要根据自己的想法想当然的去进行代码编写；</li> <li>必要的时候可以引导客户，我们的主要目的能以最有效的方式帮客户解决问题，不能盲目的按照客户的要求来，有时客户说需要一双雨鞋，可能一把伞就可以解决问题。同样对于需求分析写的文档，开发也需要有质疑的精神。</li> </ul> <h2 id="业务知识学习">业务知识学习</h2> <p>做任何的系统都避免不了有业务背景，熟练的了解业务知识可以使我们更清楚的知道我们是在做什么。很多的开发人员可能只喜欢钻研技术，对业务往往没什么兴趣，代码写完了，可能还不知道做出的模块时做什么用的，这样写出来的代码的质量就可想而知了。</p> <ul> <li>学习业务可能很枯燥，但却是一劳永逸的事情，所以不管是否有兴趣，还是应该硬着头皮啃下来；</li> <li>小组内可以成立兴趣小组，探讨的方式来进行学习，互相分享各自的学习内容，关键是组内的氛围要搞起来；</li> <li>如果是直接跟客户沟通，需要用客户能听懂的语言，比如图文配合或是一些小Demo，否则当开发术语碰上领域术语就可能都是在对牛弹琴了。</li> </ul> <p>总之，作为一名开发人员，要时刻想着怎样来提高开发效率，开发效率的提高是你在工作中一个良性循环的开始。如果您有好的方法和建议，欢迎一起分享。</p>