摘要：
一页纸项目管理方法(OOPM)背后的思想——选自《一页纸IT项目管理：大道至简的实用管理沟通工具》 设想一下，你的上司要求你快速提供一份项目报告，内容包括以下方面：项目的哪些部分是按进度进行的，哪些部分超前或落后于进度；项目的每个主要任务都由谁负责；项目执行预算和满足目标的情况如何，有哪些主要问题；目前的总体进展如何；此外还要求你提供未来三个月的预测。你可能会想这可是一件繁重的任务，它将耗费我和团队的很多时间去收集和组织大量信息，再将它们组织为易读的形式。由于这些时间并未直接花在项目工作上，因此可能会导致团队业绩下降。而且上司很有可能不会阅读所有信息，因为事情总在变化，上司也总是很忙。在参与了 阅读全文
摘要：
恭喜《软件随想录》得到了大家的一致认可！《软件随想录》自2009.12出版至今已近一个半月，首印5000册即将售罄，重印已经发出。此销量在现今计算机类图书中，可谓相当不错了。由此可见，这本书还是获得了读者的一致认可的。究其原因，看看下面的评论中就不难找出答案了。。。当当网jashy作者有想法，也非常懂表达；译者丝毫没给作者的光芒打折扣！非常难得！wolvever内容不错，给人感觉作者脑子很好使，书里面涉及的所有方面着笔上虽然有轻重，但是都很有意思，看了也是比较有启发的。翻译的也很好，读起来非常流畅，令人愉悦。vip19lang@***.***不错的书，对软件的认识有提高。tianshuangt 阅读全文
摘要：
好消息：本书今天互动网有货，当当网、卓越网也会陆续有货。及时通报进展与问题——高效程序员的45个习惯之习惯45 “管理层、项目团队以及业务所有方，都仰仗你来完成任务。如果他们想知道进展状况，会主动找你要的。还是埋头继续做事吧。”接受一个任务，也就意味着做出了要准时交付的承诺。不过，遇到各种问题从而导致延迟，这种情形并不少见。截止日期来临，大家都等着你在演示会议上展示工作成果。如果你到会后通知大家工作还没有完成，会有什么后果？除了感到窘迫，这对你的事业发展也没有什么好处。如果等到截止时间才发布坏消息，就等于是为经理和技术主管提供了对你进行微观管理（micromanagement）的机会。他们会担 阅读全文
摘要：
图灵推出每月书讯啦。。。 新年代，新气象。图灵决定自2010年起推出每月书讯。 欢迎图灵的新朋和旧友通过这个书讯来了解、熟悉图灵图书！ 下面是“图灵2010.01书讯”，详细信息请点击进入。 阅读全文
摘要：
允许大家自己想办法——高效程序员的45个习惯之习惯42 “你这么聪明，直接把干净利落的解决方案告诉团队其他人就好了。不用浪费时间告诉他们为什么这样做。”“授人以鱼，三餐之需；授人以渔，终生之用。”告诉团队成员解决问题的方法，也要让他们知道如何解决问题的思路，这也是成为指导者的一部分。 了解上个实践——成为指导者——之后，也许有人会倾向于直接给同事一个答案，以继续完成工作任务。要是只提供一些指引给他们，让他们自己想办法找到答案，又会如何？这并不是多么麻烦的事情；不要直接给出像“42”这样的答案，应该问你的队友：“你有没有查看在事务管理者与应用的锁处理程序之间的交互关系？” 这样做有下面几点好处。 阅读全文
摘要：
图灵再获得培生教育出版集团授权，即将出版《TCP/IP详解》（3卷）的影印版。此前，图灵在2006年先后出版了《Unix环境高级编程（第2版）》的影印版和翻译版。并于2009年11月推出了《UNIX网络编程》（2卷）的影印版。后者的翻译版正在翻译校订中，预计2010年5-6月出版。《TCP/IP详解》影印版将于2010年1-2月间出版上市。 阅读全文
摘要：
“光阴荏苒，从当年译完这本《重构》，到如今重新整理译稿，不知不觉已经过去六年了。……对于这本早已烂熟于心的书，也有了一些新的认识。”（摘自译者再版序）编辑已近尾声。。。 阅读全文
摘要：
架构师必须写代码——高效程序员的45个习惯之习惯39“我们的专家级架构师Fred会提供设计好的架构，供你编写代码。他经验丰富，拿的薪水很高，所以不要用一些愚蠢的问题或者实现上的难点，来浪费他的时间。” 软件开发业界中有许多挂着架构师称号的人。作为作者的我们，不喜欢这个称号，原因如下：架构师应该负责设计和指导，但是许多名片上印着“架构师”的人配不上这个称号。作为架构师，不应该只是画一些看起来很漂亮的设计图，说一些像“黑话”一样的词汇，使用一大堆设计模式——这样的设计通常不会有效的。不可能在PowerPoint幻灯片中进行编程 Youcan’t code in PowerPoint这些架构师通常在 阅读全文
摘要：
提供有用的错误信息 —— 高效程序员的 45 个习惯之习惯37 “不要吓着用户，吓程序员也不行。要提供给他们干净整洁的错误信息。要使用类似‘用户错误。替换，然后继续。’这样让人舒服的词句。” 当应用发布并且在真实世界中得到使用之后，仍然会发生这样那样的问题。比如计算模块可能出错，与数据库服务器之间的连接也可能丢失。当无法满足用户需求时，要以优雅的方式进行处理。 类似的错误发生时，是不是只要弹出一条优雅且带有歉意的信息给用户就足够了？并不尽然。当然了，显示通用的信息，告诉用户发生了问题，要好过由于系统崩溃造成应用执行错误的动作，或者直接关闭（用户会因此感到困惑，并希望知道问题所在）。然而，类似“ 阅读全文
摘要：
对问题各个击破——高效程序员的45个习惯之习惯35“逐行检查代码库中的代码确实很令人恐惧。但是要调试一个明显的错误，只有去查看整个系统的代码，而且要全部过一遍。毕竟你不知道问题可能发生在什么地方，这样做是找到它的唯一方式。”单元测试（在第76页，第5章）带来的积极效应之一，是它会强迫形成代码的分层。要保证代码可测试，就必须把它从周边代码中解脱出来。如果代码依赖其他模块，就应该使用mock对象，来将它从其他模块中分离开。这样做不但让代码更加健壮，且在发生问题时，也更容易定位来源。否则，发生问题时有可能无从下手。也许可以先使用调试器，逐行执行代码，并试图隔离问题。也许在进入到感兴趣的部分之前，要运 阅读全文