bmqnc
- 浏览: 125963 次
- 性别:
- 来自: 上海
-
最新评论
-
lliiqiang：
最简单的显示 存储分离，有的时候错别字与错误数据存储兼容。还有 ...
关于软件可扩展性与代码防御性编程的一点思考 -
bmqnc：
cqh520llr 写道sb，不帖代码，以后人家搜索到了浪费人 ...
今天自己做了redo-undo功能 -
cqh520llr：
我也觉得，代码风格和不定性样式太多了，
编码风格不取决于自己，取决于领导班子和现有代码 -
cqh520llr：
sb，不帖代码，以后人家搜索到了浪费人家时间，而且这个代码贴出 ...
今天自己做了redo-undo功能 -
shiqicai：
太隐晦，看不懂。
康神与顿神
文章列表
好几次安装了公司的软件，但是还是感觉不好用，关键的地方在于很多时候操作失败了，比如安装过程的初始化数据库的时候，如果数据库初始化失败，但是在数据库中依然存留了之前脚本创建的表，这样很容易在数据库留下了垃圾数据。
另外一个感觉不好用的地方是软件的安装程序，windows based的安装软件做的好的，都有一个功能，比如之前已经安装了某个软件，但是这次你想添加某个软件的功能或重新做一遍初始化的操作（如向导类的操作），这种情形下，这种安装软件都能判断出系统之前已经安装了这个软件，而重新执行这个安装文件的时候，做的操作不是单单说要用户安装，而是会询问用户时候需要修复该软件或者添加一些功能部件，这种做法 ...
今天做TC，用到了TreeMap，用到了其中的一个方法pollFirstEntry(),但是发现这个方法是since 1.6的，而TC只支持到1.5的jdk，我试着改为先getFirstEntry().getKey(),然后对这个key做了一点操作，然后再remove(key),然后再put(key,value),结果发现pollFirstEntry能得到正确的结果，但用后一种却得不到正确的结果，结果分析了一下，是这样的：
关键出在对key做了一些操作后然后remove这个步骤上，实际上TreeMap中的R-B Tree在remove时会用key的自然排序查找这个key，而我在key中自己写了 ...
毕业的前几天一直和dirty同学谈过创业的问题，dirty说：要知耻，不能让人看不起，要不断的学习。
这半年来感觉没什么进展，有时候感觉大家都是在那混口饭吃，没有人和我有同样的想法，有时候如吴军研究员说的，找到一个志同道合的人还是蛮难的，stanford有那种环境，但我我没处在那种环境。
想想自己，还是先做打工仔的好，还是想做it farmer的好，但有时候，想做一个好的farmer也是如此之难。。。。。。。。不过话又说回来，自己还是要不断的学习以后才有机会，就像dirty说的:只要学习了，机会总是有的，不然机会来了，自己却没准备好那就迟了。。。
不知道有时候妥协是不是一种办法，我总感觉有 ...
有时候看bad code也是一件好事，至少能刺激自己多想一些问题，这几天最大的收获就是对工程中的数据有了比较深入的体会，其实组织数据模型还是需要很强的功力的。
数据模型的组织我觉得有以下几点比较重要：
1.模型的架构（这个很难，包括数据结构etc）
2.数据的缓存与备份。我感觉如果不是做分布式计算那种，或者cache那种为了提高性能，保存多份数据不是一个明智的做法，因为你得解决数据的同步问题，除非你能很smart的解决这个问题。
3.数据的更新，同步，以及数据与数据之间的通信。
这几天对API的design也有了一些更深的体会。以后有时间再写一篇文章。
首先我觉得GIT确实好用，二者之间有些概念是相似的，
GIT相比CVS来说，确实有很多优势。
不过GIT很多地方确实比CVS要快，首先体现在分支的快速建立上，确实快速很多。因为GIT建立的分支代价是相当的小。
代码的提交上GIT确实也快很多（抛开网速，服务器性能的原因），因为它是直接比较快照的，代码差异比较更快更容易，唯一疑惑的地方是它是基于SHA算法做摘要的，但是目前据说SHA能够做到同一份摘要SHA值是相同的，所以这地方有些潜在的问题的，不过这种概率是非常小的，除非专门做密码破解的人，否则没有人care这个。
CVS比较不好的地方就是分支太慢，因为它创建的代价是很高的。
但有时候我 ...
mar一下，给自己定格目标，很多书目前都没读，应该趁这段时间赶紧将其读完，然后徐图发展。
应该要读的有以下几种类型：
1.计算机基础书籍：算法，设计模式，计算机底层os，编译器的知识。
2.专攻某个方向的知识：如分布式系统，信息搜索这块的。我最近发现自己对信息搜索这块有一些天赋，O(∩_∩)O哈哈~、
3.工具的熟悉，现在的程序员不可能不用工具来做开发，既然有工具可以让事情变得更有效率，我们为什么不用呢？
另外最近很多时候突然间觉得自己写的程序很不严谨，有时候我觉得程序员不严谨是件很糟糕的习惯，很多人以为会写程序就行了，实际上把程序写法还是需要一定功力的，我现在的项目之前的程序员就是这 ...
之前和dirty同学聊过这个话题：开源世界的工具有时候多的我们无法选择，无从下手选择哪个工具好，有时候工具多了并不是件好事，并且每个公司的情况不同，有时候每个工具不是拿来就能用的，我们需要对他进行改造。
最近发现公司的测试用例库没有创建，积累太少了。想选一个测试用例管理工具，可是有些工具不是太复杂（需要增加学习成本，还有些可能是收费的），就是比较不适合公司本身的情景，自己想写一个，不过简单够用就好，后面有需求而的话可以慢慢的完善这个工具，还是百度的说的好：简单可依赖。经典！！！！！关于百度这句话我有很多想法，让我想起了google一个研究员说的关于google搜索算法的例子，复杂并不见得就是好 ...
自己感兴趣的有两个方向，一个是图形学，还有一个是信息搜索机器学习这块，但我不知道应该专注哪个，但肯定不能都专注，那我就没时间都学完这两门所有的东西并且将其贯通了。
当然计算机的基础课程还是要学的，比如继续加强coding能力，继续加强对软件工程的理解，继续加强算法能力，继续学习底层的技术，数据库，os等。
关于测试用例库我有几点想法:
1.首先我们代码库的代码经常是非常丑的（所以我才需要不断的重构）。
2.每次测试时如果我们能够保存一个测试用例将是非常好的一个习惯。首先从代码上看，应该说每个测试用例对应了代码的一处地方。
因此实际上就将代码与测试用例关联起来了。
3.如果我们坚持构建测试用例库，好处如下：
a.测试用例库对所有的组内成员开放，所以，不单是测试人员能够做测试。
开发人员每次添加一个特性，可以利用测试用例库自己先做一次单元测试。
b.使我们做测试更有条理-能够知道现在为止做了哪些测试，哪些没有测试，并且对应到代码上实际体现了代码的覆盖率。
c.可能的话我们可以开发自动测试脚 ...
这篇文章让我想起了软件工程中的一个重要原则：职责驱动设计。
对于架构师来说，可能是在架构层面做这种规划，在往下细分到程序员，对于程序员就是在代码层面做这种规划了。不同的人有不同的关注点，但本质都是一样的：简洁，有效，可靠，职责驱动。
代码之丑8这篇真经典，对于很多程序员来说很有价值。
实际上他谈的是程序中的不一致性导致的程序本身的含糊，这是非常危险的。
我最近比较大的体会就是软件中不一致性（如同软件工程中文档或规范的不明确）会导致大量的问题，这种代码中不一致性导致后期维护的程序员不能够快速的重用既有的代码。
郑老师也说由于本身前期项目的原因，有人会说改变这种现象代价很高，我觉得这是一种权衡，如果现在不做断臂的决定，以后可能会更痛苦，花的代价可能会更高！
我觉得重构中比较烦的就是这种，因为这种很多时候如果接口本身没变，只是内部细节做了改变这都没什么问题，如果接口变了，那重构起来时一件很痛苦的事情。
里面有句经典的话： ...
今天改了eclipse中的compiler level，发现原来在接口中的Override 注释都报错，原来是1.5与1.6在这个地方有区别，1.5不支持在interface的方法上加Override ，1.6修正了它改为了可以在实现interface的方法上加这个注解
今天刚看了中国的富豪排行榜
- 博客分类：
- 心情·心绪
看了今天的富豪排行，我觉得有点悲哀。
中国能上线的富豪很少有科技出身的（比如前十位），但美国就不同，盖茨和甲骨文的那个哥们排在前两位，咱们国家和人家比一比，确实层次差了太多。
我感觉目前中国发展实在不正常，房地产就是一群人吸血的工具。。。。
我不喜欢中国的上线中的几个人，尤其是gtm，整个一OEM大王，和huawei的rzf比起来骨气可差多了，不，应该说，这两个人不能放在一起比较，不是一个层次的！
不过福布斯也不完全可信，尤其对于中国，谁知道中国背地里还有多少富豪呢，只不过他们的钱不敢放在阳光下罢了。。。。。一个村书记都能有上千万的资产，只不过他们都是裸的。。。都不能将钱放在公众面前，所 ...
TreeMap代码也读了
- 博客分类：
- java
今天看TreeMap的代码，发现里面用的虽然是搜索二叉树，但又用到了平衡二叉树，是RB Tree！Cool！
LinkedList源代码我也看完了，我感觉还算比较简单，就是指针指来指去的有点绕，弄懂了就不难了。不过竟然还让我发现了1.6中还增加了一个降序的迭代器。cool。。。