笔记暂存8

cphj 2012-11-15 08:40:04
Free Mind map 是我最喜欢的思维导图工具。它是一款轻量级的免费桌面软件。我喜欢它,因为它是我用过的最简单的思维导图工具。Free Mind map也遵守GPL协议,对于每个人都是免费的。你可以使用它的键盘快捷键快速创建导图。文件的扩展名是.mm,你也可以把你的扩展名为.mm的文件和Free Mind map软件一起和其他人共享你的导图,并且每个人都可以编辑它。
...全文
1197 44 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
44 条回复
切换为时间正序
请发表友善的回复…
发表回复
cphj 2013-10-10
  • 打赏
  • 举报
回复
<map version="0.9.0"> <!-- To view this file, download free mind mapping software FreeMind from http://freemind.sourceforge.net --> <node CREATED="1381366501351" ID="ID_1198170236" MODIFIED="1381366541612" TEXT="书籍全景图"> <font NAME="微软雅黑" SIZE="20"/> <node CREATED="1381366786056" HGAP="98" ID="ID_666202660" MODIFIED="1381370525238" POSITION="left" TEXT="系统论" VSHIFT="-12"> <node CREATED="1381366789666" HGAP="58" ID="ID_1560363949" MODIFIED="1381369784208" TEXT="第五项修炼"/> <node CREATED="1381366905252" HGAP="58" ID="ID_89639208" MODIFIED="1381369790890" TEXT="失控" VSHIFT="2"/> <node CREATED="1381368546035" HGAP="58" ID="ID_1764985964" MODIFIED="1381371737639" TEXT="系统化思维导论"/> <node CREATED="1381368563641" HGAP="57" ID="ID_1943301757" MODIFIED="1381369793420" TEXT="你的灯亮着吗" VSHIFT="1"/> <node CREATED="1381368572958" HGAP="57" ID="ID_114356884" MODIFIED="1381369798541" TEXT="复杂" VSHIFT="2"/> </node> <node CREATED="1381366740655" HGAP="85" ID="ID_839401844" MODIFIED="1381371707281" POSITION="right" TEXT="认知科学" VSHIFT="-6"> <node CREATED="1381366747239" HGAP="50" ID="ID_1121714289" MODIFIED="1381366823232" TEXT="程序员的思维修炼" VSHIFT="-3"/> <node CREATED="1381366883345" HGAP="52" ID="ID_1027391911" MODIFIED="1381366890151" TEXT="决断2秒间"/> <node CREATED="1381369652468" HGAP="51" ID="ID_840280136" MODIFIED="1381369661741" TEXT="像艺术家一样思考"/> </node> <node CREATED="1381366604991" HGAP="99" ID="ID_1308830768" MODIFIED="1381369869220" POSITION="left" TEXT="变革" VSHIFT="-11"> <node CREATED="1381368647106" HGAP="70" ID="ID_982122920" MODIFIED="1381369771733" TEXT="跨越鸿沟" VSHIFT="2"/> <node CREATED="1381366608744" HGAP="69" ID="ID_1476650556" MODIFIED="1381369774278" TEXT="冰山在融化" VSHIFT="-2"/> <node CREATED="1381368439371" HGAP="69" ID="ID_1817847585" MODIFIED="1381369776698" TEXT="鱼"/> </node> <node CREATED="1381366865141" HGAP="86" ID="ID_939323739" MODIFIED="1381371701206" POSITION="right" TEXT="心理学" VSHIFT="9"> <node CREATED="1381370432521" HGAP="65" ID="ID_1070485202" MODIFIED="1381370572423" TEXT="生命的心流"/> <node CREATED="1381368911728" HGAP="64" ID="ID_1532153275" MODIFIED="1381368921526" TEXT="影响力" VSHIFT="-1"/> <node CREATED="1381370741071" HGAP="64" ID="ID_448895530" MODIFIED="1381370750985" TEXT="乌合之众"/> <node CREATED="1381368927189" HGAP="65" ID="ID_74262461" MODIFIED="1381369721678" TEXT="进化心理学"/> </node> <node CREATED="1381366567857" HGAP="98" ID="ID_56701001" MODIFIED="1381370530328" POSITION="left" TEXT="设计" VSHIFT="4"> <node CREATED="1381366576824" HGAP="71" ID="ID_839124679" MODIFIED="1381369885692" TEXT="UNIX编程艺术" VSHIFT="-5"/> <node CREATED="1381369118375" HGAP="72" ID="ID_1575695599" MODIFIED="1381369889751" TEXT="程序员修炼之道"/> <node CREATED="1381369138387" HGAP="73" ID="ID_1778752326" MODIFIED="1381369895185" TEXT="编程之道" VSHIFT="2"/> </node> <node CREATED="1381366672183" HGAP="88" ID="ID_1191103800" MODIFIED="1381371692304" POSITION="right" TEXT="心灵" VSHIFT="24"> <node CREATED="1381366694391" HGAP="74" ID="ID_478606156" MODIFIED="1381369712451" TEXT="菜根谭"/> <node CREATED="1381369690343" HGAP="74" ID="ID_1277451538" MODIFIED="1381369703240" TEXT="智慧书"/> <node CREATED="1381366718149" HGAP="73" ID="ID_1262380943" MODIFIED="1381369708532" TEXT="禅者的初心" VSHIFT="1"/> <node CREATED="1381366837397" HGAP="73" ID="ID_1511820959" MODIFIED="1381366844371" TEXT="箭术与禅心"/> <node CREATED="1381368412946" HGAP="73" ID="ID_150387552" MODIFIED="1381368424367" TEXT="少有人走的路" VSHIFT="1"/> </node> <node CREATED="1381369191431" HGAP="98" ID="ID_1230777456" MODIFIED="1381370535449" POSITION="left" TEXT="软件工程" VSHIFT="15"> <node CREATED="1381369229021" HGAP="48" ID="ID_972189845" MODIFIED="1381370543163" TEXT="解析极限编程"/> <node CREATED="1381369239839" HGAP="48" ID="ID_1059970588" MODIFIED="1381369270310" TEXT="人件"/> <node CREATED="1381369253701" HGAP="48" ID="ID_792670712" MODIFIED="1381369767206" TEXT="快速软件开发"/> </node> </node> </map>
keewa 2013-10-10
  • 打赏
  • 举报
回复
<map version="0.9.0"> <!-- To view this file, download free mind mapping software FreeMind from http://freemind.sourceforge.net --> <node CREATED="1377496440267" ID="ID_1644309688" MODIFIED="1377496472374" TEXT="第五项修炼"> <font NAME="微软雅黑" SIZE="20"/> <node CREATED="1377049272170" HGAP="91" ID="ID_1161158315" MODIFIED="1377496491625" POSITION="right" TEXT="结构的特点" VSHIFT="-15"> <node CREATED="1377049288342" ID="ID_1465867263" MODIFIED="1377049298560" TEXT="结构影响行为"/> <node CREATED="1377049298951" ID="ID_1757556206" MODIFIED="1377049337857" TEXT="人类系统中的结构是微妙而错综复杂的"/> <node CREATED="1377049344654" ID="ID_1879139546" MODIFIED="1377049362748" TEXT="有效的创意常出自新的思考方式"/> </node> <node CREATED="1377049630223" HGAP="92" ID="ID_683238961" MODIFIED="1377053357102" POSITION="right" TEXT="洞察力的深度" VSHIFT="-27"> <node CREATED="1377049642002" ID="ID_1474786026" MODIFIED="1377049667669" TEXT="事件反应"/> <node CREATED="1377049646720" ID="ID_658150794" MODIFIED="1377049672434" TEXT="行为变化"/> <node CREATED="1377049650235" ID="ID_1323962940" MODIFIED="1377049731766" TEXT="系统结构"/> </node> <node CREATED="1377049874468" HGAP="95" ID="ID_13057675" MODIFIED="1377053361711" POSITION="right" TEXT="动态系统的困难" VSHIFT="8"> <node CREATED="1377049909521" ID="ID_279902057" MODIFIED="1377049925345" TEXT="今日的问题来自昨日的解"/> <node CREATED="1377049944752" ID="ID_63975844" MODIFIED="1377053467395" TEXT="愈用力推,系统反弹力量愈大"/> <node CREATED="1377050512994" ID="ID_1140996107" MODIFIED="1377050540790" TEXT="渐糟之前先渐好"/> <node CREATED="1377050766256" ID="ID_1543456227" MODIFIED="1377050774676" TEXT="显而易见的解往往无效"/> <node CREATED="1377050803641" ID="ID_1288610896" MODIFIED="1377050813092" TEXT="对策可能比问题更糟"/> <node CREATED="1377050962244" ID="ID_353476910" MODIFIED="1377050966449" TEXT="欲速则不达"/> <node CREATED="1377051038993" ID="ID_586771104" MODIFIED="1377051063424" TEXT="因与果在时空上并不紧密相连"/> <node CREATED="1377486196528" ID="ID_1135227461" MODIFIED="1377486203231" TEXT="不可分割的整体性"/> <node CREATED="1377486215386" ID="ID_1441158427" MODIFIED="1377486221526" TEXT="没有绝对的内外"/> </node> <node CREATED="1377051145971" HGAP="101" ID="ID_1818852805" MODIFIED="1377053354103" POSITION="right" TEXT="动态系统的好处" VSHIFT="27"> <node CREATED="1377051159195" ID="ID_1858743570" MODIFIED="1377051204759" TEXT="小而专注的解产生杠杆效果"/> <node CREATED="1377051529829" ID="ID_1712366085" MODIFIED="1377051539267" TEXT="鱼和熊掌可以兼得"/> </node> <node CREATED="1377051870465" HGAP="99" ID="ID_1664543710" MODIFIED="1377496535257" POSITION="left" TEXT="系统动力学术语" VSHIFT="-42"> <node CREATED="1377051888056" ID="ID_803896983" MODIFIED="1377052127300" TEXT="时间滞延"/> <node CREATED="1377053415482" ID="ID_1273232699" MODIFIED="1377053416529" TEXT="补偿性回馈"/> <node CREATED="1377053573579" ID="ID_1089701522" MODIFIED="1377053577750" TEXT="系统边界原理"/> <node CREATED="1377486439872" ID="ID_1506558217" MODIFIED="1377486444090" TEXT="整体性故障"/> <node CREATED="1377055205642" ID="ID_90842658" MODIFIED="1377055217755" TEXT="细节性复杂与动态性复杂"/> <node CREATED="1377487476883" ID="ID_1826540131" MODIFIED="1377499061499" TEXT="增强环路、调节环路和环路时延"/> <node CREATED="1377496567513" ID="ID_1584095134" MODIFIED="1377496573358" TEXT="系统基模"/> <node CREATED="1377496597237" ID="ID_1796997069" MODIFIED="1377496606441" TEXT="过度分工与知识的片段化"/> </node> <node CREATED="1377496722429" ID="ID_1973278836" MODIFIED="1377496725367" POSITION="left" TEXT="系统基模"> <node CREATED="1377499031219" ID="ID_529383688" MODIFIED="1377506868207" TEXT="反应迟缓"> <node CREATED="1377500375534" ID="ID_1673170147" MODIFIED="1377501719641" TEXT="调节环路(好)+环路时延(坏)"/> </node> <node CREATED="1377500189073" ID="ID_1321387203" MODIFIED="1377501781859" TEXT="饮鸩止渴"> <node CREATED="1377501435250" ID="ID_1735622771" MODIFIED="1377502555479" TEXT="短期环路(好)考虑到时延其实是相反的长期环路(坏)"/> </node> <node CREATED="1377497435832" ID="ID_629056699" MODIFIED="1377501783546" TEXT="舍本逐末"> <node CREATED="1377500493497" ID="ID_380202500" MODIFIED="1377502821283" TEXT="反应迟缓的环路(好)+反应快速的环路(坏)"/> </node> <node CREATED="1377499617864" ID="ID_1410176739" MODIFIED="1377502793424" TEXT="目标侵蚀"> <node CREATED="1377502172240" ID="ID_1436599085" MODIFIED="1377502878343" TEXT="舍本逐末中反应快速的环路(坏)还会破坏反应迟缓的环路(好)"/> </node> <node CREATED="1377496732931" ID="ID_885709929" MODIFIED="1377496736869" TEXT="成长上限"> <node CREATED="1377500399017" ID="ID_1281617856" MODIFIED="1377501726344" TEXT="增强环路(好)+调节环路(坏)"/> </node> <node CREATED="1377499984676" ID="ID_1215843543" MODIFIED="1377503077228" TEXT="共同悲剧"> <node CREATED="1377502983356" ID="ID_652732583" MODIFIED="1377503308658" TEXT="成长上限中的增强环路(好)遇到调节环路的限制后(坏)变成反向的增强环路(坏)"/> </node> <node CREATED="1377500276835" ID="ID_1560812265" MODIFIED="1377506971497" TEXT="未雨绸缪"> <node CREATED="1377503222114" ID="ID_1067666055" MODIFIED="1377503344469" TEXT="成长上限中的调节环路(坏)必须在生效前就提前清除"/> </node> <node CREATED="1377499611443" ID="ID_1901443337" MODIFIED="1377499616708" TEXT="恶性竞争"> <node CREATED="1377502307783" ID="ID_825509922" MODIFIED="1377502426795" TEXT="对立双方联合产生了增强环路(坏)"/> </node> <node CREATED="1377499814856" ID="ID_27746902" MODIFIED="1377499823324" TEXT="富者愈富"> <node CREATED="1377502400546" ID="ID_1819773354" MODIFIED="1377502924607" TEXT="一个正向增强环路(好)导致另一个负向增强环路(坏)"/> </node> </node> </node> </map>
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
  • 打赏
  • 举报
回复
1 以无法为有法,以无限为有限 初学者比较喜欢军规,甚至很多时候,如果没有军规,他们还会主动要求团队给他们一些军规,因为军规可以确保他们不会犯常见的错误。所以说在起始阶段,军规是必要的。但是对于技术骨干来说,他们必须学会有条件地打破军规,否则很难突破自己的技术瓶颈,他们需要知道,此时此刻,此种方式的违规恰恰是最好的。如果一个程序员不懂得遵守军规,那么他无法成为一个合格的程序员,如果他不懂得打破军规,那么他无法成为一个优秀的程序员。 2 人是天生的模仿者 这次仅仅介绍了“心流”以及“大脑模式”中最最基础的理论,也初步分析了结对编程、测试驱动开发中常常问题的原因,但是没有详细讨论怎么解决这些问题。其实主要不是时间问题,因为这里面很多东西不是知识而是技能,技能是说不清楚的。就像学游泳,你无法对一个不懂游泳的人,通过讲述让他学会游泳。你只能通过带领、指导他去游,才有可能学会。如果让一个不懂游泳的人拿着一本游泳指导书独自去学游泳,那更是非常危险的事情。所以在缺乏教练的情况下,甚至不建议大家自行尝试结对编程和测试驱动开发。 3 规则无法替代信任 讨论好代码的标准,其实是检验团队的技术凝聚力。如果一个团队有很强的技术凝聚力,那么好代码的标准是很容易达成一致的。就像一个盟约一样,盟约的有效性不在于细节,而盟约的双方是否在缔结盟约的过程中达到了互信。同样,一个代码的规范,其有效性不来自于其细节是否完美,而在于团队的每个成员是否从心底里互相信任。 4 美是不可定义的 哲学系专门有个美学专业。如果要为难一个美学专业的人,最好的方式就是问他,“什么是美?”,他真是说不出来的。美,最神秘的地方,就在于它无法被定义,但却可以被感知。美的实际案例可以展示,但是美的做法却无法明确说出。反过来说,凡是可以被具体定义出来的东西,那么它就已经被工程化了。不是说工程化不好,而是说已经工程化的东西,我们就不需要把它放到美的范畴来讨论,直接按照工程化的方法去实施就好了。但是总有很多东西是无法被工程化的。 5 错误的“重构”是双倍的浪费 课堂上案例是以“重构前”“重构后”的形式展示出来的,但绝对不是推荐这样的“重构”!先快速完成功能,然后整理代码,这是合理地重构。由于需求变化,引入更多的设计元素,这也是合理地重构。为提升性能,引入复杂的编程技巧,这也算是合理地重构。但是,以浪费时间、低效地方式编写不必要的代码,再花更多的时间重写一遍,这是双倍的浪费。 6 潜龙勿用 实际项目中到底该不该用STL?如果要用的话,应该怎么用?我们来看看《易经》。 《易经》中的乾卦,第一爻:初九,潜龙勿用。 乾卦是讲变化的道理,乾代表天,天的变化力是最大的,天气在短时间内就能剧烈地变化。STL的引入也意味着一系列不小的变动,所以要好好参一参这一卦。初九中的“初”代表时间刚开始,或者说变化的第一个阶段,“九”代表阳,表示主动。乾是纯阳的,以纯阳的变化力,在第一个阶段依然要潜龙勿用。潜龙勿用中的“勿”很关键,“勿”并不等于“不”,“勿用”也不等于“不用”。“勿用”是要站在不用的立场上用,心里想着用,但表面上不用。“潜龙”是在发动变化前好好积攒能量,此时的“勿用”,是为了第二个阶段的“用”,所以才有第二爻的见龙在田。如果没有潜龙勿用也就没有见龙在田了。 7 感性的体验对人的影响超越理性 我们在课前故意不给大家资料,也不通知大家需要准备什么,这是有所考虑的。传统的培训,总是讲授知识,这有两个问题,知识的讲授需要巨量的时间,而纯知识的讲授也容易使课堂枯燥。如果要完整地讲授STL的知识,估计得十几次课。另外,其实大家想一想,我们在大学都逃过课,但是每门课程一样自学过关,可见大家对知识的自学并没有问题,用不着培训来讲。这次课程的目标是给大家创造一个有指导的、方便安全的体验环境。如果大家体验好,就自然会去自学。 8 影响力的武器 一个技术骨干,仅仅依靠自己的技术水平,是否就能建立技术影响力?这是需要思考的。能够有力地影响人的方式分为:互惠、承诺和一致、社会认同、喜好、权威、稀缺。大多数技术人员看到了提高技术水平,建立权威的影响力,但对其他方式的影响力却基本忽视掉了。
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)

1,658

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC 非技术类
社区管理员
  • 非技术类社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧