随笔分类 - 编程随想
工作经历，技术随笔，感悟想法
摘要：1、人生不是没有成功，而是缺少足够的勇气，只要我们敢于冒险，只要我们敢于行动，只要我们敢于拼搏，那么胜利的旗帜就在向我们飘摇了!最后让我们一起畅想那首动听的歌——《勇气》。 2、勇敢，是人类进步的阶梯，每一个人都会有自己所惧怕的事情或物品，每一个人也还会有极限，所谓极限，其实是我们以胆怯为名，给自己
阅读全文
摘要：背景 团队采用敏捷开发已经一年时间了，刚开始半年随着团队成员之间的磨合以及技术的熟悉，开发的效率确实逐渐在提升，所以自认为团队上路了只会原来越好，谁想到后面团队没有进步，反而退步得厉害。 一、何时发现产品质量这个问题？ 在指导对接监管平台的过程中突然发现产品质量已经下降得如此厉害，随便列出几项： 1
阅读全文
摘要：我带开发团队，喜欢把手底下成员分为4种类型。 1、逻辑思维厉害且理解能力好的人 2、逻辑思维厉害但理解能力差的人 3、逻辑思维一般但理解能力好的人 4、逻辑思维一般且理解能力差的人 这样分有助于更好的分配任务和控制风险，比如： 第一种逻辑思维厉害且理解能力好的人，这种一般都是高级程序员了，团队的骨干
阅读全文
摘要：有人说，测试者来自火星，开发者来自金星。这是因为软件测试员和软件开发者就好比一对冤家，里面的缘由说不清也道不明。开发代表着创造，而测试则代表着摧毁，因为测试的目的就是以各种方式不断地从开发出的产品中发现大大小小的Bug，长此以往，开发者认为测试者是在故意找茬，两者的矛盾慢慢就会产生。 敏捷之前项目中
阅读全文
摘要：静态代码检查工具StyleCode。 上一章我说了设计评审和测试用例评审都是为了提升产品质量问题，后来我们又做了代码评审，但是代码评审比设计评审难搞多了，对于开发来说最在意的就是自己的代码，让别人对自己的代码指指点点，虽然是好的建议但也会让人不爽。 准备搞代码评审之前以前就尝试过，搞着搞着最后的结果
阅读全文
摘要：敏捷开发系列文章目录 设计评审和测试用例评审我们都是迭代的第二天做，一般会给开发人员半天的时间思考一下他自己故事的设计，然后抽出1-2个小时进行设计评审，设计评审完后就做测试用例评审。设计评审就是让团队帮你查遗补漏完善你的设计，而测试用例是测试、PO、开发三者又一次落到实处的交流。 设计评审和测试用
阅读全文
摘要：敏捷开发系列文章目录 估点的意义不是为了得到精确的工作量这个数字，而是通过估点这个过程把这个故事的复杂度找出来。 1.估点的流程 PO在讲完故事后，SM让开发人员对这个故事有什么疑问没有，有疑问PO继续答疑，如果大家都没有疑问SM会要求大家出点，这时候每个人手上都有一副敏捷估点扑克牌，每个人会把自己
阅读全文
摘要：敏捷开发系列文章目录 讲出符合开发团队味口的故事。 上一章说了敏捷开发团队的构成与迭代过程，本章重点说一下迭代第一天的计划会议。熟话说“好的开始就成功了一半”，一个迭代的计划会议做得好不好确实直接注定着迭代的成功与失败。迭代开始之前，PO肯定都已经提前准备好了本次迭代的所有故事，并且提前都发给了团队
阅读全文
摘要：敏捷开发系列文章目录 在讨论PO如何给团队讲好故事这个问题之前，先给大家了解一些基本的敏捷概念，然后讲讲我们敏捷团队构成与整个敏捷开发的过程。 当初敏捷老师讲课的时候就跟我们所过，敏捷没有什么具体的形式，每个敏捷团队可能做法都不一样，表现出来的性格也不一样，比如有挑战型团队、有保守型团队等。但敏捷有
阅读全文
摘要：敏捷开发系列文章目录 敏捷开发在国内是不是只是一个理想化的工作环境？ 经常有人问，你们搞敏捷开发工作量是由开发人员自己估的，而不是由经验丰富的技术主管估的，他们自己肯定会把工作量估得非常大，那什么时候项目才做得完？你们每天开那么多会，怎么不把时间放在好好写代码上面？一个迭代这么短的时间既要做设计、又
阅读全文
摘要：敏捷开发在国内是不是只是一个理想化的工作环境？ 经常有人问，你们搞敏捷开发工作量是由开发人员自己估的，而不是由经验丰富的技术主管估的，他们自己肯定会把工作量估得非常大，那什么时候项目才做得完？你们每天开那么多会，怎么不把时间放在好好写代码上面？一个迭代这么短的时间既要做设计、又要编码、还要测试，这么
阅读全文
摘要：先看我对REST的一点认识，下面是《rest实战》 这本书的序言文字： 在我刚刚开始从事解决计算问题的时候，业界就有很多人有一个愿望：将系统设计为能够被自由组合的组件。互联网(Internet)无远弗届的广泛连接为这个愿望推波助澜，并且增加了一个新的愿望：使得组件在引入了延迟和不可靠性的网络...
阅读全文
摘要：讨论一背景：医技部门经理发现不同的实施人员多次询问相同问题，想在公司组织集体培训，由此在群里开始了讨论。A：刘总，建议公卫部人员升级了一两家医院PACS和LIS系统后内部之间做个互相学习和交流会由最熟的人员主持不然每个人都来问同样的问题B：好记性，不如难笔头，将升级步骤的文档和培训视频一次性做好。B...
阅读全文
摘要：三大特色一、 任务自己领取，无须分配，完成任务积分，成绩排名二、 自动提醒，方便团队成员及时查看任务三、 集成BUG捕捉，轻松完成任务录入BUG管理软件程序下载：http://pan.baidu.com/share/link?shareid=116790&uk=3307925829源代码下载：htt...
阅读全文
摘要：上篇《公司产品开发中遇到的一些问题？ 》对于工作的一些牢骚做了一些叙述，最近又认真思考了一番，觉得以目前我们公司的这种情况怎么实时求实的工作，使有所进步，改变的入口点在哪里？而不是好高骛远，一下子让公司的开发达到国际水准，太不现实了！
存在主要问题：
1.各种各样版本太多，没一个能完整的把整个流程跑通，拿不出一个演示版本？
2.代码混乱导致整合困难，需要增加一个公共功能时，发现有好几个版本的代码需要修改？
3.发布程序不稳定，经常是解决了某个bug却产生了其他的未知bug？
4.需求满天飞，都是各个模块开发人员自己获取自己的？
5.程序升级麻烦，开发员自己发自己程序出去，经常出现升级失败？
。。。
阅读全文
摘要：1.为了赶进度，无法拒绝客户提出的需求，需求修改后没有严格的测试，程序又不稳定，客户又照样拿程序做借口，这就像一个死循环。
2.改程序不怕，怕的就是不稳定。
阅读全文
摘要：又看到两篇关于30岁程序员的问题，程序员30过后关于程序员30/35岁以后就写不了代码（没前途）的问题。也有点自己的想法！这两篇文章都表达了对30过后对程序员的坚持，如： 一个优秀的程序员，他的气质是内实而外溢的。他基础扎实，多年的孜孜以求，使他的根须，又深又密，他可以汲取一切可以汲取的知识，来供给...
阅读全文
摘要：仅仅就编程序来说，实在是一件很简单的事，就是“程序 = 算法 + 结构”，但做出一个软件产品就没有这么简单的事了。
虽然“程序 = 算法 + 结构”没错，但随的市场的变化，需求的变更，这些算法和结构也是在时刻变动，有可能我们分析出这些算法和结构后，在投入到市场中却发现产品已经过时。所以我们有必要建立一个来管理分析这些影响算法和结构变化的需求的平台。已至于我们能够实时的把算法和结构对应的程序发布到市场中给客户使用。
阅读全文
