笔记暂存8

2012-11-15 08:40:04 1.2k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

从零到一：基于Docker与Gewechat协议，打造高可用微信AI助手本文提供了一份从零开始的实战指南，详细讲解如何利用Docker容器化技术与Gewechat协议，构建一个高可用、低风险的微信AI助手。通过整合Dify AI平台，您可以为微信机器人注入大语言模型的智能，实现自动问答、知识库查询等高级功能，显著提升个人或团队在微信场景下的沟通与信息处理效率。阅读详情

Free Mind map 是我最喜欢的思维导图工具。它是一款轻量级的免费桌面软件。我喜欢它，因为它是我用过的最简单的思维导图工具。Free Mind map也遵守GPL协议，对于每个人都是免费的。你可以使用它的键盘快捷键快速创建导图。文件的扩展名是.mm，你也可以把你的扩展名为.mm的文件和Free Mind map软件一起和其他人共享你的导图，并且每个人都可以编辑它。

...全文

从零到一：基于STM32F103C8T6与HAL库的磁悬浮电赛装置实战解析本文详细解析了基于STM32F103C8T6微控制器与HAL库，从零构建磁悬浮装置的完整实战方案。文章深入剖析了硬件设计中的线圈布局与“反向串联”巧思，以节省PWM资源；并阐述了采用三闭环PID控制算法的软件实现，结合Keil开发环境与HAL库进行工程搭建与调试。该方案为电子设计竞赛（电赛）提供了高可行性的参考，是嵌入式软硬件综合实践的优秀范例。阅读详情

cphj

非技术类 1,663 成员 58,947 内容

+ 关注 + 加入社区

切换为时间正序

cphj 2013-10-10

打赏
举报

keewa 2013-10-10

打赏
举报

cphj 2013-10-09

打赏
举报

创新者早期采用者早期大众后期大众落后者技术狂热者有远见者实用主义者保守主义者怀疑者 Enthusiasts Visionaries Pragmatists Conservatives Skeptics Visionaries Pragmatists 依据直觉判断依据分析判断支持变革支持演变革故鼎新循规蹈矩愿做出头鸟甘当平凡人根据自己的意志愿与同事商议甘冒风险避免风险为未来的机会所鼓舞被当下的问题所驱使寻求一切可以寻到的追求能够达到的共同解决问题，完善新技术因问题而等待和否定技术水平联系垂直联系

keewa 2013-09-27

打赏
举报

疲于业务交付，如何提升能力？分工过细，如何促进技术讨论？持续学习，如何形成群体行为？微博，利用碎片化时间开发量1天，初赛持续1个月中国好声音，滚动直播吸引关注每周采访，发布报道共同进化，竞争压力引发持续性改进开发赛区交付的程序交由测试赛区验证建立eSpace群讨论需求开源社区，合作产生最佳设计，产生技术交流全员参与，可以仅围观，至少5人成团初赛结束后，附加决赛1小时决赛指定部分成员参加后续想法产品重点模块，开源重构产品接口模块，交叉开源重构

keewa 2013-09-27

打赏
举报

人造与天生的联姻正是本书的主题。技术人员归纳总结了生命体和机器之间的逻辑规律，并一一应用于建造极度复杂的系统；他们正在如魔法师一般召唤出制造物和生命体并存的新奇装置。从某种程度上来说，是现有技术的局限性迫使生命与机械联姻，为我们提供有益的帮助。由于我们自己创造的这个世界变得过于复杂，我们不得不求助于自然世界以了解管理它的方法。这也就意味着，要想保证一切正常运转，我们最终制造出来的环境越机械化，可能越需要生物化。我们的未来是技术性的，但这并不意味着未来的世界一定会是灰色冰冷的钢铁世界。相反，我们的技术所引导的未来，朝向的正是一种新生物文明。没有强制性的中心控制次级单位具有自治的特质次级单位之间彼此高度连接点对点间的影响通过网络形成了非线性因果关系对于必须绝对控制的工作，仍然采用可靠的老式钟控系统。在需要终极适应性的地方，你所需要的是失控的群件。网络不断孕育着小的故障，以此来避免大故障的频繁发生。正是其容纳错误而非杜绝错误的能力，使分布式存在成为学习、适应和进化的沃土。网络是唯一有能力无偏见地发展或无引导地学习的组织形式。所有其它的拓扑结构都会限制可能发生的事物。普适分布式控制方法：先做简单的事。学会准确无误地做简单的事。在简单任务的成果之上添加新的活动层级。不要改变简单事物。让新层级像简单层级那样准确无误地工作。重复以上步骤，无限类推。这套办法也可以作为管理任何一种复杂性的诀窍，事实上它也就是用作这个的。浴火重生的种子：某些硬壳类植物种子，非火烧去外壳不能发芽。比如澳洲桉树的种子有厚厚的木质外壳，借助大火把它的木质外壳烤裂，便于生根发芽。因此桉树林就像凤凰，大火过后不仅能获得新生，而且会长得更好。混成一堆的北美草原种子是干燥的、绒毛似的草籽。而逐渐多起来的稀树大草原的种子则是「一把把色彩斑斓、凹凸不平、粘糊糊的软胶质」，成熟后的种子包有果肉。这些种子不是靠风而是靠动物和鸟类传播。那个他一直试图恢复的东西——共同进化系统，联锁的有机体系——不是单纯的北美大草原，而是有树的大草原：稀树大草原。通过在杂草丛生的土地，而不是像利奥波德那样在新开垦的土地上播种北美草原的种子，能够获得更接近真实的北美草原。利奥波德曾经担心争强好胜的杂草会扼杀野花，但是，杂草丛生的土地比耕种过的土地更像北美大草原。在杂草丛生的陈年地块上，有一些杂草是后来者，而它们中有些又是大草原的成员。它们的提早到来能加速向草原系统的转变。而在耕耘过的祼地上，迅速抽芽的杂草极具侵略性，那些有益的「后来者们」加入这个集体的时间过晚。这好比在盖房子时先灌注了水泥地基，然后钢筋才到。因而，次序很重要。要想得到一块湿地，不能只是灌入大量的水就指望万事大吉了。你所面对的是一个已经历经了千万年的系统。仅仅开列一份丰富多样的物种清单也是不够的。你还必须有组合指南。不仅要有合适的物种按恰当的顺序出现，而且还要有合适的物种在恰当的时间消失。

cphj 2013-09-27

打赏
举报

11 71 8 46

keewa 2013-09-24

打赏
举报

124 49 36 39

cphj 2013-09-16

打赏
举报

5 31 HA DK 25 SA SQ 07 C9 S9 18 D8 CQ 42 DT D4 CT D3 SJ D9 DA 2 01 CA HK 02 SA SK CK S2 DQ ST SJ 3 09 D4 DJ 04 DT ST 21 H4 CJ C4 SJ HJ S4 HT 1 00 SK H9 HQ HT SQ HJ H8 2 99 H9 D8 98 C9 S6 D9 S9 S8 C8 H8

cphj 2013-09-06

打赏
举报

31 HA DK 25 SA SQ 07 C9 S9 18 D8 CQ 42 DT D4 CT D3 SJ D9 DA

cphj 2013-08-27

打赏
举报

对现有代码了解不够，不知道存在已有的公共函数，没有调用又自行手写一套。或者虽然了解，但不放心不敢使用，于是再写一套。模块交接，接手人代码能力不足时，就会产生浪费型的代码。或者模块由多个人负责，但互相协作不足，也会出现浪费。能力不够，只掌握了初级的语法和基本的设计手段，对待复杂的问题，无法利用高级语言特性和高级设计手段去降低复杂度，只能单调地堆砌大量代码。这是编码新手的常见问题。知识面不够，不了解业界现成的标准库，一些基础性的算法，数据结构仍然手工编码，导致代码浪费，并且引入质量风险。一些只关注业务不关注编码技术的老手往往容易出现这种问题。时间不够，这看起来非常自相矛盾，时间不够，应该是要增快开发速度，怎么反而产生了浪费？其实是因为在时间的压力下，头脑发热，慌不择路，选择了一条南辕北辙的路。这属于心理问题，人在紧迫的压力下有可能做出低于平时水准的表现。过度设计，在设计阶段针对各种变化做了预先设计，却不考虑这些变化是否真的会发生，有多大概率发生，不计成本地一股脑设计。这种情况多数出现在中级技术人员中，他们具备基本的设计能力，却不具备策略能力，不知道如何计算设计的收益和成本。还有一种更加有害的过度设计，设计者试图把自己掌握的设计手段和编码技巧，尽可能多地塞入代码中。那些正在成长道路上的人，对设计手段和编码技巧有较高热情，但还没有透彻理解它们，最容易产生此种问题。设计的高级境界，是知道什么时候应该停止设计。

keewa 2013-08-27

打赏
举报

三个维度的解决方案，事件、行为、结构编码浪费、工作效率低、缺乏技术合作与交流机制编码浪费对现有代码了解不够设计能力不够知识面不够时间不够（心理素质不够）过度设计工作效率偏低不了解心流不了解思维的心智模式敏捷技能不足（代码评审、重构、结对、测试驱动开发、每日提交）缺乏技术合作与交流机制技术能力提升与交流指望专门的活动和时间（组织培训、经验分享）高手没有起到弥补团队短板的作用低手没有向高手学习的机制引入新技术感性的体验对人的影响超越理性人是天生的模仿者知识靠自学，知识的实际应用靠指导建立编码规范、军规、基线人们更关注动态的规范规则无法替代信任以无法为有法，以无限为有限建立可复用的代码库（造轮子）不造轮子浪费，造轮子也可能浪费造轮子难，用轮子也并不简单轮子晋级表人员搭配、技术分工脱离木桶原理师徒制搭档 L型编码分工利用碎片化的生产力第一阶段，编程小比赛第二阶段，产品代码单个模块重构第三阶段，产品代码接口梳理和重构系统化思维，中数系统根因是对职业的热爱和认同

keewa 2013-08-15

打赏
举报

1 错误的“重构”是双倍的浪费课堂上案例是以“重构前”“重构后”的形式展示出来的，但绝对不是推荐这样的“重构”！先快速完成功能，然后整理代码，这是合理地重构。由于需求变化，引入更多的设计元素，这也是合理地重构。为提升性能，引入复杂的编程技巧，这也算是合理地重构。但是，以浪费时间、低效地方式编写不必要的代码，再花更多的时间重写一遍，这是双倍的浪费。 2 美是不可定义的哲学系专门有个美学专业。如果要为难一个美学专业的人，最好的方式就是问他，“什么是美？”，他真是说不出来。美，最神秘的地方，就在于它无法被定义，但却可以被感知。美的实际案例可以展示，但是美的做法却无法明确说出。反过来说，凡是可以被具体定义出来的东西，那么它就已经被工程化了。不是说工程化不好，而是说已经工程化的东西，我们就不需要把它放到美的范畴来讨论，直接按照工程化的方法去实施就好了。但是总有很多东西是无法被工程化的。 3 彻底去除显而易见的东西如何做到优雅，没有捷径，但是有几个原则：优雅，就是彻底去除显而易见的东西结构，使得复杂系统呈现优雅节省时间，会让人感觉优雅知识和经验，让事情更优雅记住，总有些事情与优雅无缘…… 4 人是天生的模仿者这次仅仅介绍了“心流”以及“大脑模式”中最最基础的理论，也初步分析了软件设计、结对编程、测试驱动开发中常常问题的原因，但是没有详细讨论怎么解决这些问题。其实主要不是时间问题，因为这里面很多东西不是知识而是技能，技能是说不清楚的。就像学游泳，你无法对一个不懂游泳的人，通过讲述让他学会游泳。你只能通过带领、指导他去游，才有可能学会。如果让一个不懂游泳的人拿着一本游泳指导书独自去学游泳，那更是非常危险的事情。所以在缺乏教练的情况下，甚至不建议大家自行尝试结对编程和测试驱动开发。 5 感性的体验对人的影响超越理性关于STL，我们在课前故意不给大家资料，也不通知大家需要准备什么，这是有所考虑的。传统的培训，总是讲授知识，这有两个问题，知识的讲授需要巨量的时间，而纯知识的讲授也容易使课堂枯燥。如果要完整地讲授STL的知识，估计得十几次课。另外，其实大家想一想，我们在大学都逃过课，但是每门课程一样自学过关，可见大家对知识的自学并没有问题，用不着培训来讲。这次课程的目标是给大家创造一个有指导的、方便安全的体验环境。如果大家体验好，就自然会去自学。 6 只有透彻地理解细节，才能放心地忽略细节关于C++，课堂的实战围绕构造器、运算符重载、引用、常量、自动类型转换、友元展开，这些都是非常底层的知识点。完整的面向对象包括封装、继承、多态，这次仅仅涉及封装，并且只是封装的一小部分。但是大家在练习中应该能感觉到，就这些很基础的知识点，细节却是层出不穷。而且一些技术书籍中，仅仅讲解单个细节，却很少分析各个细节之间的关系，于是很多看完整本手册的人也还是用不好C++。实际上，如果不了解这些细节，很难写出良好的代码，甚至编译都没法通过。软件工程推崇面向对象，推崇设计模式，强调抽象，要求忽略细节，但这是建立在细节已经被吃透，细节已经不是问题的基础上。只有透彻地理解细节，才能放心地忽略细节。否则只能是空中楼阁。 7 最容易获得财富的方式是继承 The easiest way to obtain wealth is to inherit it; the second best way is to make it off the labor of others; marrying wealth is too much like work. 最容易获得财富的方式是继承，面对继承下来的财富，有的人视而不见，有的人挥霍，有的人珍惜。视而不见的人只能终日苦苦地劳作，挥霍的人变得比以前更加一贫如洗，只有珍惜的人不仅仅用财富实现了自己的愿望，同时还让财富在不断增值。其实以上说的不仅是金钱财富，也包括业界前辈大师的代码宝库。 8 以无法为有法，以无限为有限初学者比较喜欢军规，甚至很多时候，如果没有军规，他们还会主动要求团队给他们一些军规，因为军规可以确保他们不会犯常见的错误。所以说在起始阶段，军规是必要的。但是对于技术骨干来说，他们必须学会有条件地打破军规，否则很难突破自己的技术瓶颈，他们需要知道，此时此刻，此种方式的违规恰恰是最好的。如果一个程序员不懂得遵守军规，那么他无法成为一个合格的程序员，如果他不懂得打破军规，那么他无法成为一个优秀的程序员。 9 影响力的武器一个技术骨干，仅仅依靠自己的技术水平，是否就能建立技术影响力？这是需要思考的。能够有力地影响人的方式分为：互惠承诺和一致社会认同喜好权威稀缺大多数技术人员看到了提高技术水平，建立权威的影响力，但对其他方式的影响力却基本忽视掉了。

keewa 2013-08-15

打赏
举报

1 以无法为有法，以无限为有限初学者比较喜欢军规，甚至很多时候，如果没有军规，他们还会主动要求团队给他们一些军规，因为军规可以确保他们不会犯常见的错误。所以说在起始阶段，军规是必要的。但是对于技术骨干来说，他们必须学会有条件地打破军规，否则很难突破自己的技术瓶颈，他们需要知道，此时此刻，此种方式的违规恰恰是最好的。如果一个程序员不懂得遵守军规，那么他无法成为一个合格的程序员，如果他不懂得打破军规，那么他无法成为一个优秀的程序员。 2 人是天生的模仿者这次仅仅介绍了“心流”以及“大脑模式”中最最基础的理论，也初步分析了结对编程、测试驱动开发中常常问题的原因，但是没有详细讨论怎么解决这些问题。其实主要不是时间问题，因为这里面很多东西不是知识而是技能，技能是说不清楚的。就像学游泳，你无法对一个不懂游泳的人，通过讲述让他学会游泳。你只能通过带领、指导他去游，才有可能学会。如果让一个不懂游泳的人拿着一本游泳指导书独自去学游泳，那更是非常危险的事情。所以在缺乏教练的情况下，甚至不建议大家自行尝试结对编程和测试驱动开发。 3 规则无法替代信任讨论好代码的标准，其实是检验团队的技术凝聚力。如果一个团队有很强的技术凝聚力，那么好代码的标准是很容易达成一致的。就像一个盟约一样，盟约的有效性不在于细节，而盟约的双方是否在缔结盟约的过程中达到了互信。同样，一个代码的规范，其有效性不来自于其细节是否完美，而在于团队的每个成员是否从心底里互相信任。 4 美是不可定义的哲学系专门有个美学专业。如果要为难一个美学专业的人，最好的方式就是问他，“什么是美？”，他真是说不出来的。美，最神秘的地方，就在于它无法被定义，但却可以被感知。美的实际案例可以展示，但是美的做法却无法明确说出。反过来说，凡是可以被具体定义出来的东西，那么它就已经被工程化了。不是说工程化不好，而是说已经工程化的东西，我们就不需要把它放到美的范畴来讨论，直接按照工程化的方法去实施就好了。但是总有很多东西是无法被工程化的。 5 错误的“重构”是双倍的浪费课堂上案例是以“重构前”“重构后”的形式展示出来的，但绝对不是推荐这样的“重构”！先快速完成功能，然后整理代码，这是合理地重构。由于需求变化，引入更多的设计元素，这也是合理地重构。为提升性能，引入复杂的编程技巧，这也算是合理地重构。但是，以浪费时间、低效地方式编写不必要的代码，再花更多的时间重写一遍，这是双倍的浪费。 6 潜龙勿用实际项目中到底该不该用STL？如果要用的话，应该怎么用？我们来看看《易经》。《易经》中的乾卦，第一爻：初九，潜龙勿用。乾卦是讲变化的道理，乾代表天，天的变化力是最大的，天气在短时间内就能剧烈地变化。STL的引入也意味着一系列不小的变动，所以要好好参一参这一卦。初九中的“初”代表时间刚开始，或者说变化的第一个阶段，“九”代表阳，表示主动。乾是纯阳的，以纯阳的变化力，在第一个阶段依然要潜龙勿用。潜龙勿用中的“勿”很关键，“勿”并不等于“不”，“勿用”也不等于“不用”。“勿用”是要站在不用的立场上用，心里想着用，但表面上不用。“潜龙”是在发动变化前好好积攒能量，此时的“勿用”，是为了第二个阶段的“用”，所以才有第二爻的见龙在田。如果没有潜龙勿用也就没有见龙在田了。 7 感性的体验对人的影响超越理性我们在课前故意不给大家资料，也不通知大家需要准备什么，这是有所考虑的。传统的培训，总是讲授知识，这有两个问题，知识的讲授需要巨量的时间，而纯知识的讲授也容易使课堂枯燥。如果要完整地讲授STL的知识，估计得十几次课。另外，其实大家想一想，我们在大学都逃过课，但是每门课程一样自学过关，可见大家对知识的自学并没有问题，用不着培训来讲。这次课程的目标是给大家创造一个有指导的、方便安全的体验环境。如果大家体验好，就自然会去自学。 8 影响力的武器一个技术骨干，仅仅依靠自己的技术水平，是否就能建立技术影响力？这是需要思考的。能够有力地影响人的方式分为：互惠、承诺和一致、社会认同、喜好、权威、稀缺。大多数技术人员看到了提高技术水平，建立权威的影响力，但对其他方式的影响力却基本忽视掉了。

cphj 2013-08-15

打赏
举报

1 关于培训 1.1 感性的体验对人的影响超越理性关于STL的培训，我们在课前故意不给学员资料，也不通知学员需要准备什么，这是有所考虑的。传统的培训，总是讲授知识，这有两个问题，知识的讲授需要巨量的时间，而纯知识的讲授也容易使课堂枯燥。如果要完整地讲授STL的知识，估计得十几次课。另外，其实想一想，我们在大学都逃过课，但是每门课程一样自学过关，可见我们对知识的自学并没有问题，用不着培训来讲。这次课程的目标是给大家创造一个有指导的、方便安全的体验环境。如果大家体验好，就自然会去自学。最终各组实际体验之后，对STL的兴趣都有较大的提升，也愿意在条件允许的情况下，应用到实际项目中去。 1.2 人是天生的模仿者这次培训介绍了“心流”以及“大脑模式”中最最基础的理论，也初步分析了软件设计、结对编程、测试驱动开发中常常问题的原因，但是没有详细讨论怎么解决这些问题。其实主要不是时间问题，因为这里面很多东西不是知识而是技能，而技能是说不清楚的。就像学游泳，你无法对一个不懂游泳的人，通过讲述让他学会游泳。你只能通过带领、指导他去游，才有可能学会。如果让一个不懂游泳的人拿着一本游泳指导书独自去学游泳，那更是非常危险的事情。与新知识、新工具不同，一门新技能，如果缺乏有实际经验的教练的指导，则不建议自行引入。 1.3 知识靠自学，知识的实际应用靠指导考虑培训效率以及能力提升效果，比较好的方式是：通过体验激发兴趣各人自学基础知识通过实际指导知识的应用来提升技能 2 关于开发速度 2.1 唯速度的开发方式架构设计不足，短期上是追求速度，并没有直接的浪费，但是从长期看，多个版本的累计工作量是有浪费。当模块发生特性变更和特性扩展时，就会产生一个拐点。因为前期没有针对需求变化的设计，而新特性设计时，主要精力和时间都在分析特性功能上，基本忽略了代码结构的设计，导致新特性复制粘贴，产生烟囱式代码，架构逐渐臃肿庞大。另外，一旦涉及工作交接，则会产生另一个拐点，因为旧代码的设计蓝图没有完整体现在代码或者文档中，还有一些关键部分是在原作者的脑袋里，交接之后，新作者的修改维护就会逐渐脱离原有设计，正确修改一行代码所花费的时间越来越长。一般到第3、4个新维护人员时，代码就完全没有脉络可循，也没法再维护了，甚至出现改1个旧缺陷，出现2个新问题的情况。此时一旦出现较大的特性扩展，研发人员就会主动提出“重构”，其实基本就是重写或者局部重写了。唯速度论的开发方式并不是全无可取之处，甚至大部分时候，我们仍然需要这样的开发手段。而软件工程，特别是敏捷开发，倡导的是，除非已经清晰预见到特性变化，否则不去做预先的设计，就使用最直接的方式完成代码。而在出现拐点时，则必须针对拐点去做设计，或者做轻量级的重构，维持架构的健康度。 2.2 唯速度代码是怎么产生的技能单一，具备编码能力，却不具备重构能力，不具备代码测试能力。一般来说第一版写出来的代码还是可以的，但在拐点出现时，因为不具备重构能力，无法有效利用老代码，结果是要么复制粘贴，要么重写。这两种做法都是不可取的，复制粘贴导致架构腐烂，而重写所需的时间项目上也不能接受。所有的重构都需要测试，特别是自动化单元测试，作为前提条件，每本重构书籍都会强调此点，但是有些重构书籍因为专注于介绍重构方法而没有特别介绍测试方法，导致有些人不了解重构与测试的关系。大多数研发人员写不出来黑盒的单元测试用例，这也导致重构无法自发进行。 2.3 反速度的开发方式大量代码并不是由于复制粘贴产生的，也不是由于需求变更多次修改导致，纯粹就是手工写成，并且是全新代码，但是其复杂度远远超过其功能需要。这种代码短期来说拖慢了版本开发速度，长期来说更是无法维护。唯速度的开发方式牺牲了长期利益至少还满足了短期利益，而此种反速度的开发方式纯粹是一种浪费，既牺牲了长期利益又牺牲了短期利益。软件工程，包括敏捷，没有讨论对此种问题，因为这不是开发模式，或者开发流程的问题。 2.4 反速度代码是怎么产生的对现有代码不了解，不知道存在已有的公共函数，没有调用又自行手写一套。或者虽然了解，但不放心不敢使用，于是再写一套。能力不够，只掌握了初级的语法和基本的设计手段，对待复杂的问题，无法利用高级语言特性和高级设计手段去降低复杂度，只能单调地堆砌大量代码。编码新手，甚至一些只关注业务不关注编码设计的老手，都容易出现这种问题。时间不够，这看起来非常自相矛盾，时间不够，应该是要增快开发速度，怎么反而产生了浪费？其实是因为在时间的压力下，头脑发热，慌不择路，选择了一条南辕北辙的路。这属于心理问题，人在紧迫的压力下有可能做出低于平时水准的表现。过度设计，在设计阶段针对各种变化做了预先设计，却不考虑这些变化是否真的会发生，有多大概率发生，不计成本地一股脑设计。这种情况多数出现在中级技术人员中，他们具备基本的设计能力，却不具备策略能力，不知道如何计算设计的收益和成本。还有一种更加有害的过度设计，设计者试图把自己掌握的设计手段和编码技巧，尽可能多地塞入代码中。那些正在成长道路上的人，对设计手段和编码技巧有较高热情，但还没有透彻理解它们，最容易产生此种问题。设计的高级境界，是知道什么时候应该停止设计。 2.5 错误的“重构”是双倍的浪费课堂上案例是以“重构前”“重构后”的形式展示出来的，但绝对不是推荐这样的“重构”！先快速完成功能，然后整理代码，这是合理地重构。由于需求变化，引入更多的设计元素，这也是合理地重构。为提升性能，引入复杂的编程技巧，这也算是合理地重构。但是，以浪费时间、低效地方式编写不必要的代码，再花更多的时间重写一遍，这是双倍的浪费。 2.6 站在个体的角度是无解的能力问题，心理问题，策略问题，如果仅仅考虑单个个体，那么是无解的。 3 关于军规 3.1 规则无法替代信任讨论好代码的标准，其实是检验团队的技术凝聚力。如果一个团队有很强的技术凝聚力，那么好代码的标准是很容易达成一致的。就像一个盟约一样，盟约的有效性不在于细节，而盟约的双方是否在缔结盟约的过程中达到了互信。同样，一个代码的规范，其有效性不来自于其细节是否完美，而在于团队的每个成员是否从心底里互相信任。 3.2 以无法为有法，以无限为有限初学者比较喜欢军规，甚至很多时候，如果没有军规，他们还会主动要求团队给他们一些军规，因为军规可以确保他们不会犯常见的错误。所以说在起始阶段，军规是必要的。但是对于技术骨干来说，他们必须学会有条件地打破军规，否则很难突破自己的技术瓶颈，他们需要知道，此时此刻，此种方式的违规恰恰是最好的。如果一个程序员不懂得遵守军规，那么他无法成为一个合格的程序员，如果他不懂得打破军规，那么他无法成为一个优秀的程序员。 4 关于造轮子 4.1 不造轮子浪费，造轮子也可能浪费公司内部积累程序库，相当于造公司内部的专用轮子，在此之前要充分学习业界已有的通用轮子，看看轮子是怎么造的，像Google那些公司内部的一些专用轮子，也是在通用轮子的基础上建起来的，并且最终会推广到业界成为通用轮子，比如gtest。不造轮子浪费，造轮子也可能浪费，以下是常见的造轮子出现浪费的情况：造出不好用的、成为闲置品的专用轮子造出与通用轮子重复的专用轮子把通用轮子劣化为更差的专用轮子 4.2 造轮子难，用轮子也并不简单成都的课程扩充到1天，加入了两个额外的实战环节。第一个是让大家造一个轮子，要求轮子的功能多，用起来方便，使用安全，分4次完成，每次都公布阶段性答案，最终代码量29行。实际6个组只有2个组能在提示的基础上造出基本符合要求的轮子。第二个是提供了一些轮子，要求用轮子组装完成3个类似的功能，分3次完成，每次都公布阶段性答案，每个功能都是3行代码，一共9行。实际6个组只有1个组能全部完成。 4.3 轮子晋级表想成为一个轮子大师，并不是一件简单的事情，也没有捷径，以下是我认为的轮子晋级表：入门，会使用通用轮子初级，会做适配和组装，拓展通用轮子的原有用途中级，会仿照通用轮子，编写一些近似的专用轮子高级，会识别通用轮子的缺陷，并修复神级，会自己造出新的通用轮子 4.4 站在均匀化群体的角度也是无解的如何有效地造轮子，如果秉持均匀化对待群体中的每一个个体，要么大家都不造轮子，要么大家都来造轮子，那么也是无解的。 5 关于敏捷实践敏捷开发过程虽然在公司层面推行过，但敏捷的一些实践，例如重构、结对、测试驱动开发，多数研发人员并没有熟练掌握。几个原因，首先是前面说过的技能不容易直接通过培训掌握。第二点，是研发人员之间的合作并不容易，我们平时工作更多的是个人分工，领导协调，真正让两个研发人员平等配合的情况并不多，研发人员对合作技巧也没有太多了解。最后，这些实践需要互相配合，才能真正取得比传统方式更好的效果，孤立地推行单个实践很困难。 “XP中没有一样概念是新的，大多数概念和编程一样老……几十年前这些实践，常常被视为不切实际或天真而遭摒弃……XP的创新之处在于，把所有这些实践组合在一起，让一种实践的弱点可以由其他实践的优点来弥补” ——摘自《Extreme Programming Explained》 6 关于技术影响力一个技术骨干，仅仅依靠自己的技术水平，是否就能建立技术影响力？这是需要思考的。能够有力地影响人的方式分为：互惠承诺和一致社会认同喜好权威稀缺从培训心得体会中可以看到，大多数技术人员认为只有提高技术水平，建立权威，才能对团队的产生影响力。实际上，权威只是影响力的一种，还有5种其他方式的影响力。如果缺乏影响力，那么优秀的技术骨干并不能对团队产生整体的提升作用。 7 关于人员搭配、技术分工 7.1 脱离木桶原理在一个团队中，有些人没有足够的知识和技术，有些人没有时间思考，有些人不擅长设计。但有些人是掌握技术的，有些人是有时间思考的，有些人擅长设计。通常前一类人，他们更关注业务能力，更偏重实施，擅长左脑思维模式，而后一类人更关注软件能力，更偏重思考，擅长右脑思维模式。对差异性的团队成员，如果进行均匀化管理，结果就落入木桶原理，整个团队表现是以最差的那一个人决定。代码也是这样，整个软件的代码质量往往也是由最差的那个模块决定的。如果采用策略思维，对差异性的团队成员，进行差异化组合，就能摆脱木桶原理。举个例子，让团队里面的高手来进行整体的代码审查，的确会占用时间导致最好的部分变差，但却使最差的地方变得好得多，整体质量因此而得以提高。 7.2 师徒制搭档技术层次分为需指导的（徒弟）/可免于指导的（也是徒弟）/可提供指导的（师傅）/可提供培训的（最高级别的师傅）。1个师傅带1~3个徒弟。师傅要整体负责。首先是一个生产团队，其次才是学习团队。共同估算。通过估算差距，让徒弟学习师傅的设计思路。通过估算差距，发现对需求理解的不一致。使整个系统都在比较高的设计档次，而不是参差不齐。轻量设计。事先由徒弟和师傅之间在设计要点上达成一致。实现完毕后，写出简明的设计文档。前检查点，就是在做某功能的最初一段时间，师傅与徒弟结对编程，完成最初最重要的设计。剩余的功能由徒弟独自完成。完成过程中，如果一切按照之前的设计进行，徒弟可以继续独立工作，如果有偏离，要询问师傅。师傅要经常过问徒弟的工作，但以保证自己的产出为前提。不能因为已经进行了共同设计和估算，或开了例会就放弃日常跟踪，问题往往出在小处。后检查点，就是某事做完后，师傅检查一下徒弟的结果，保证达到验收标准。 7.3 L型编码分工实际上一个高手，无论是否告知其要编写底层库，几个功能下来，都会发现他积累了几个可以重复使用的东西。这种工作习惯是一旦养成，用可复用的方法还是不可复用的方法，编程花费的时间相差不大。这个时候，最好的方法把他的可复用库与大家分享，让别人必要的时候调用这些库来工作，而不是让大家以老死不相往来的方式形成“川”型代码结构。这和“三”型代码结构相比有何差异？差异在于，不要让高手专注于底层库的研究，而是要参与到业务功能的开发中，这可以有效地防止造出多余轮子的现象。在139团队中，师傅是负责编写核心业务+底层库的人，他们在编程时会随时告知大家有新的可用的库产生，请大家必要时引用。而徒弟们想要编写某些潜在的可复用库之前，都要先问问师傅是否已经存在了类似的东西。 7.4 收益对项目，提高交付效率，提高交付质量。对组织，积累有效的基础代码库，提供技能传递渠道。对管理者，拓展自身领导力，增强团队凝聚力，实现人员备份。对技术骨干，扩大技术影响力，提升自身能力，减少厌倦感。对普通技术人员，获得技术指导和帮助，获得成长空间，降低焦虑感。 7.5 条件管理者，愿意用实际行动推动团队成长，有尝试改变的愿望。团队成员，互相信任，愿意承担责任，有自我改进的愿望。

cphj 2013-08-08

打赏
举报

▁▂▃▄▅▆▇↖↗↙↘

cphj 2013-07-29

打赏
举报

±⊙∫∮∝∞∧∨∈⊿⌒∟￠⊥℃℉〒¤○µ┌┬┐├┼┤└┴┘─│┄┆┈┊△▽○◇□☆▷◁▲▼●◆■★▶◀█▉▊▋▌▍▎▏╭╮╳╰╯◤◥◣◢↑←→↓āáǎà⌒╲╱

keewa 2013-07-03

打赏
举报

抽象数据类型设计实例任务：支持复数运算设计一个复数类，支持复数的常规运算初始化加法运算+ 复合加法运算+= 用C如何设计？用C++如何设计？水印C 水印C++ C++语法糖构造器.........................可选的强制初始化运算符重载.................直观的表达式引用.............................兼顾效率和安全函数体可以简化吗？深入函数调用函数返回一个局部对象/变量包含哪些开销? 例如：a = f(); 调用函数前对返回值地址压栈在栈上构造一个局部对象（可能有构造器开销）给该对象填入合适的值 return语句复制该对象到调用前压栈的地址把返回地址里面的对象复制给接受该值的对象简化 vs. 优化去除源代码信息熵提高源代码表达力自动获得编译器优化提高机器码效率通常导致源代码更复杂通常人为控制编译器优化任务：支持const复数对象的运算第二袋C++语法糖常量....................................增加代码可读性 ....................................侦测出错误用法 ....................................获得编译优化任务：支持实数、复数混合运算第三袋C++语法糖缺省参数.............................简化函数调用自动类型转换构造器.........简化类型适配全局运算符重载.................提供全局匹配友元.....................................特殊访问授权参考资料 C++ Primer 4th Edition 中文版.pdf Thinking In C++ 2nd Edition vol 1 中文版.pdf The C++ Programming Language Special Edition 中文版.pdf Effective C++ 3rd Edition 中文版.pdf The Design and Evolution of C++ 中文版.pdf 理解的越多所写的代码越少面向对象某种程度上与语言无关但语法糖能够让面向对象的表达更方便 C++不能解决所有问题但它确实可以解决某些问题 C无可替代但……也请热爱C++！

keewa 2013-07-03

打赏
举报

complex_construct0 complex_construct complex_add complex_add_to void construct0(Complex * a) c1 = add(add(&c1, &c2), add(&c3, &c4)); /* 加法必须返回一个全新的对象，它既不是a，也不是b 因为是新对象，所以只能返回副本，而不能返回指针 */ /* 复合加法不产生新对象，它改变已有的对象a 带有赋值性质的表达式都会返回被改变的对象本体，以支持链式调用返回对象本体不能使用副本，只能是指针 */ // 构造器能确保对象一定被初始化 // 运算符重载使调用者能以自然的方式使用抽象数据类型 // 引用使调用者更方便，提供者也不再需要考虑指针的安全性 // 节省一次对象构造，并且这么写的话，大部分编译器可以把剩下的一次对象复制也优化掉 // 此语法为调用构造器构造匿名对象 // 大于一个CPU字的内建类型用const引用传递，效率较高 // 第一个const不能省略，当返回值为自定义类型时，编译器不保证const，此const能确保结果不被篡改 // 第二个const能确保函数体不修改参数对象，另外有了它，才能支持右侧const加数 // 第三个const能确保函数体不修改本体对象，另外有了它，才能支持左侧const加数 // 复合加法因为要修改自身，所以返回值和本体都不能设定为const，这也意味着const对象不能进行该运算 // 参数const能确保函数体不修改参数对象，另外有了它，才能支持右侧const加数 // 对称形式的二元运算符使得左侧加数可以由构造器自动转换出来 // 注意该运算符重载不是成员函数，所以需要friend权限来访问私有成员 // 语法上看，全局函数形式的第一个参数const，等价于成员函数形式尾部的const // 对一个数进行+=没有意义，另外对自动转换出来的对象进行修改也很危险，故复合运算符都应该保留成员形式

keewa 2013-07-02

打赏
举报

cphj 2013-07-02

打赏
举报

你怎么看待浪费型的编码？业界的技术经验，你是如何学习的？好代码的标准，业界有哪些著作和理论？除了技术知识的提升，工作效率如何提升？技术骨干如何发挥自身的技术优势，能够带动整个团队提升能力？程序员的能力提升，业界有哪些著作和理论？议题时长时间点简介：议程、热身、分组 0:05 9:05 讲解 1：《两个真实的重构案例》 0:15 9:20 分组讨论：优雅编码 0:15 9:35 讲解 2：《不假思索地思考》 0:40 10:15 分组讨论：能力提升 0:15 10:30 休息 0:10 10:40 实战练习：类的设计 0:40 11:20 讲解 3：《Code never finished》 0:30 11:50 中午 1:40 13:30 讲解 4：《Mastering STL》 0:30 14:00 实战练习：泛型编程 1:30 15:30 休息 0:10 15:40 讲解 5：《Function Zen》 0:30 16:10 实战练习：函数式编程 1:30 17:40 总结 0:05 17:45

加载更多回复（24）

笔记暂存8

相关推荐