12 2012 档案
摘要：我以前说过，倘若你想提高人们的技能，那就阅读此书吧！ 基本问题是，人类不是合乎逻辑的生物，我们是情感生物。当然，我们喜欢为我们的推理能力而自豪，不过实际情况是，我们所做的大多数决策更多地受到情绪影响，而非理智。 作为软件开发者，此种技能对你的意义在于，除非你能妥善地处理与其他开发者、经理、甚至客户的关系，否则，即便你有许多好点子或很有用的技能，你还是会四处碰壁。 一般说来，积极参与到软件开发社区中去也会对你的职业生涯有很大帮助。不要仅限于人际交流，而要把你的名字传播出去，并广结善缘。 成功做到这一切直接取决于你待人接物的能力。（在学习如何待人接物时想走捷径？那很简单。请与人为善！）
阅读全文
摘要：要是你能够解决问题、快速学习事物、恰当命名事物、以及待人接物，那么与你专门从事任何特定技术相比，从长远来看，你将会取得更大的成功。 有这样一种说法，要深入学习一到两门编程语言，并从事某个通用的专业领域，这当然很重要，不过，只要你还没带着那些抉择在这条老路上走得太远，并把精力集中在提高这 4 种重要技能上，你
阅读全文
摘要：1.确实进行的前段设计。2.设计者的经验和素质（大师的作用）。3.在开发团队中保持清晰的观点（一致也重要，沟通）。4.授权团队负责软件的整体设计，而团队也承担起这一责任。5.不要害怕改变设计没有什么一程不变的，变化是永恒的，重构一直进行。6.让合适的人加入到团队中，包括设计者，程序员和经理，确保开发团队的规模合适。让他们合适合理的工作关系。这不可避免的影响代码的结构。7.在合适的时候做出设计决定，在知道所有必要的信息时在做出决定，延迟那些暂时不能做出的决定。8.好的项目管理，以及合适的最后期限。
阅读全文
摘要：1.将错误状态稳定下来。2.确定错误的来源。3.修补缺陷。4.对修补的地方进行测试。（Test）5.查找类似的错误。
阅读全文
摘要：1.如何做最小复杂度和最大创造性的设计。2.从协作式的开发中受益。3.应用防御式编程技术来减小并排查错误。4.发掘重构和改善代码的机会，并安全可靠的进行代码重构和改善。5.结合项目的规格选用恰当的构建技术。6.快速而有效地排除问题。7.尽早地正确解决构建关键问题。8.尽可能在早，中，晚期加强代码的质量。好像还是关于重构的比较过哈。架构做的好了，现在都好做。好架构不好做，但是质量的改善可以从小处坐起。重构就是在改善代码的好方法，在重构中可以发现更好的结构，并最终提升软件质量。
阅读全文
摘要：今天早上，来个之后，直接给昨天做的代码增加了段代码，增加功能。昨天，满怀信息的跟架构师说，弄完了，结果回家一想，还是差点。这个功能，目前也用不上。至少的年后才能用呢。一度想，先不处理，到用的时候在处理。后来，还是感觉这样不行，就今天早到了，处理了下。人不能被面子啊，虚荣啊等东西给蒙蔽了，一定要脚踏实地啊。不然，人生会在，拖延，胆怯中腐化的。
阅读全文
摘要：http://www.csdn.net/article/2012-06-21/2806814关于性能优化这是一个比较大的话题，在《由12306.cn谈谈网站性能技术》中我从业务和设计上说过一些可用的技术以及那些技术的优缺点，今天，想从一些技术细节上谈谈性能优化，主要是一些代码级别的技术和方法。本文的东西是我的一些经验和知识，并不一定全对，希望大家指正和补充。在开始这篇文章之前，大家可以移步去看一下以前发表的《代码优化概要》，这篇文章基本上告诉你——要进行优化，先得找到性能瓶颈！但是在讲如何定位系统性能瓶劲之前，请让我讲一下系统性能的定义和测试，因为没有这两件事，后面的定位和优化无从谈起。
阅读全文
摘要：数据要有唯一的标识啊。在众生皆平等，但是每个都有每个的不同。不同可以不被发现，但是一定都有。不然世界就混乱了。
阅读全文
摘要：今天，弄了个简单的问题。被那个问题困扰了好多天。说起来也简单那就是 数据集合绑定到控件时，有时提示Index=0 处，没有值，然后就是 空引用。这个弄了快1周了。前3天弄了，感觉是数据集合在处理的时候，查询和删除操作的集合索引错误。后来通过把操作分开。解决了，问题。试了下，没问题了。加多了数据在试就还有问题。又改了下代码。发现问题是有的集合索引弄错了，把不用的集合删掉。又处理了1次。昨天，经过测试发现，问题还是有。发生的很频繁。都不知所错了，今天新纪元开始，就又过来加班弄了，先弄了2个小时，发现不行，就开始急躁了，就去弄其他问题了。等其他问题弄好了，又来弄了，这个功能在3个地方用了，改了以后其
阅读全文
摘要：很多WINFORM的开发人员在DataGridView的开发当中，都会出现“索引 -1没有值”这个烦人的问题，其实较早之前，我已经大概知道问题的所在，也找到了解决方法，不过一直没有时间去深入研究一下，今日做了一个测试，发现问题 的所在，我不知道这个问题是否应为MS的BUG，但至少我个人认为这个问题不应该出现！下面先说说构成这个错误的现像。首先出面这个错误，绝大多数的开发人员都是进行数据绑定之后出现的，而且出现的情况基本上都只得一种，就是开始绑定的数据集是非空的，但数据集的 Count=0，在将这个非空的而元素个数为0的数据集绑定到DataGridView后，当更新DataGridView的数据
阅读全文
摘要：1.提取子程序或者方法。2.讲子程序的代码内联化。3.用简单的方法替换复杂的方法。4.增加参数。5.删除参数。6.将查询操作从修改中独立出来。7.合并相似的子程序，通过参数来区分。8.将行为取决于参数的子程序拆分开。9.传递整个对象而非特定成员。10.传递特定成员来取代传递整个对象。11.包装向下转型的操作（返回借口和抽象类）。
阅读全文
摘要：在DataGridView中,选择行无法隐藏的问题！当直接用程序中的 DataGridView.SelectRows[0].Visible = false; 程序会报出一个异常！异常错误如下：System.InvalidOperationException: 与货币管理器的位置关联的行不能设置为不可见。在这里可以看出明显是数据绑定问题，就是货币管理器的问题：这下问题好解决了；CurrencyManager：货币管理类,通过如下方法可以获取。在CurrencyManager中有2个方法SuspendBinding(),ResumeBinding()（详细资料可以查询MSDN）CurrencyMa
阅读全文
摘要：1.设计模式的使用，降低沟通的复杂性。2.精选开发过程。3.为人写程序。4.深入一门语言去编程，善事。5.借助规范。6.基于问题领域编程。7.不通层次的抽象。8.问题域的底层技术应用。9.当心落石。10.迭代，反复进行。11.分离信项。
阅读全文
摘要：登录|注册一样的世界，不一样的时间随手记点东西目录视图摘要视图订阅2016软考项目经理实战班学院周年礼-顶尖课程钜惠呈现微信公众平台应用开发CSDN 2015年度社区之星荣誉榜Mac & iOS开发常见错误代码对照表2013-01-08 16:4073882人阅读评论(0)收藏举报分类：iphone...
阅读全文
摘要：看代码大全有感。随便摘抄几句。不要对类的使用者做出任何假设（构造函数的作用：初始化）。避免使用友缘类。不要因为一个字程序里仅使用的公用子程序，就把它归入借口(发布的借口不好修改，重构的陷阱)。让阅读代码比编写代码更方便（让人读啊）。要格外警惕从语义上破坏封装（抽象借口的运用,限制访问关键字的运用）。留意过于紧密的耦合（提取，抽象）。重构啊。
阅读全文
摘要：重构要继续，臭豆腐要做。 这个重构中各种提取类，方法，字段，可以方便的理解，如果使用了设置模式就更加逻辑清晰了。切东西也要讲究刀法的。 重构可以方便的使用设计模式。设计模式为重构提供了目标。 比如多个if 可以switch case 也可以用多态来解决。 讨论设计架构，新奇的语法，不如多想想，代码中多用个策略，状态 ,工厂，适配器,单例模式。写出完美的代码，就是一个目标，重构就是实现的它的手法。 每次要一步修改并测试。
阅读全文
摘要：书接上回啊。上回已经把臭豆腐的成因分析了。现在该进行小范围个制作了。重构可以从很下的地方开始。高手可以直接从整体开始。但是臭豆腐处理大师太少了，还是照着方子慢慢来吧。1. 切小块。这个不限于类和方法的提取。也保护对同一变量的多次赋值的行为。一个表达式只复制1次，以后的复制可以在新建变量。保持简单统一。临时变量的使用可以用查询方法来读取。 块足够小了，就可以把它们很好的放在锅里了（方便重构）。2.使用工厂来替换构造函数。加点佐料就可以改变它的味道，就不必须每次重新开始做。可以做好了，在分成小块，分别加佐料。然后端出来就可以了。这样不用依赖每次做法了。只依赖配佐料 就好了。
阅读全文
摘要：上回分析了臭豆腐的生产原因。现在要开始做了。首先，发现臭豆腐要敢于动手。不能等风把味吹没了在动手，项目也就黄了，能力也没张，职业发展也就危机了。臭豆腐没买好。1.重命名。这个不限于类型名，方法名，变量名，项目名等。这个就是要把臭豆腐的杂质去掉，要是流程清晰起来，就是臭豆腐汤下的豆腐浮出来。这个很真要，不要因为小而不做。这个做多了，就能更清晰的做好下边的事。把汤弄出来，豆腐就出来了。2.抽取函数，类，变量。这个豆腐出来了，要做啊，就得切开，才好下油锅啊。这个切豆腐要是熟了，可以从大块，切到小块。要是不熟，可以先从边上来个小块。 慢慢切。且不好，就溅一身，就味了。切之前可以先比划1下，在切。毕竟比
阅读全文
摘要：代码重构可以在熏人的代码，项目编号，甚至脱胎换骨。臭豆腐也是，虽然臭了，但是，做好了，还是很好吃的。很需要手艺的。治大国，若烹小鲜。重构代码若炸臭豆腐。既然要做臭豆腐，就先要识别出臭豆腐。要先忍的住，外加好手艺（要有耐心和细心，和高超的手艺来做，重构代码）。现在先说识别吧。1.重复代码。2.过长函数。3.过大的类。4.发散式变化。5.散弹式修改。6.依恋情节。7.数据泥团。8.基本类型偏执。9.Switch惊魂。10.平行继承体系。11.冗与类。12.过分的超前。13.迷惑的暂时字段。14过度的耦合的消息练。15中间人。16.过分亲密。17过多的注视。
阅读全文
摘要：编辑器加载中...今天又一次看了重构的书。又了些小想法。重构的正面好出太多了，他牛都一一列举了。负面消息也有。我现在说说我的想法，重构会减低速度，是负效果，可能引入心错误，是负效果。又句老话，负负得正。那就是说，重构还是可以得到正确的效果，在大的前景下。所以，我这个懒惰，不聪明的人也开始重构了。虽然还没到不停重构的地步，但是现在已经可以又些小的进步了。人的习惯真可怕。不论好坏。08年就知道重构，期间也看了好多次重构。结果写代码还是不怎么样。现在要一步一步的写好了。重构也将讲究小步骤进行，正好适合我这逻辑思维不够强的人，可以写会，歇会，可以找个好借口了，还能提高代码水平。
阅读全文
浙公网安备 33010602011771号