ITPub博客

[@more@]又一次open discussion. 记录之这次open discussion 的人并不多，但大家也都是带着问题来，也不枉费时间。主要设计到这些话题1. performance 问题。Thougthworks项目多以OO为主，devs的思维常局限于此领域，以至于系统上线，performance让人感到众人切肤之痛。长期以来，此类问题成为达摩克斯之剑悬于头顶，不掉皆大欢喜，落则痛苦难当。老大的问题是：是否每个项目做了performance评估，回答皆是”没有或做了，但很少“。尤其是wsgn是个特别案例，当初麦罗做的方案和承诺，现在摇身成为了客户，居然指责Thougthworks.的best

续借上篇文章。 我把感慨写下并发给范同学看，随后他也回复给我的他的真实想法。基本相同的观点，也在这里贴出来。---------------------------赞同。我也聊些我的想法：教科书上的方法是前辈们在他们所处的背景下，基于他们的经历、认识和思考总结出的经验，为我们提供了一个巨人的肩膀。我们应该站在上面并充分利用这些知识，但却不应该把其做为教条；我们应该以它们为指导，来探索适合我们特定背景和情况的方法，而不应该局限其中。到这个层次，“瀑布”、“敏捷”不过是一个称谓而已，怎么称谓不重要，重要的是我们找到针对我们所处

敏捷需求分析 今天与范同学偶然聊到点感触 Master story list. 在随后的迭代过程中，需求被逐步细化，直至精确的描述用户商业价值。迭代分析过程也是不断帮助用户探索商业模式，寻求商业价值的过程。用户基于已经发布的系统提出反馈，变更需求成为了可能。 但在实践过程中，我们也看到被很多团队滥用。这并不意味着迭代式需求分析存在问题，迭代分析的前提是，假设需求是无法一次并且准确的确定，为规避前端预测型分析思路带来的风险而不得不采用这种模式。一些密切结合实际商业环境的项目多是满足这样的前提，例如商业网站

庆祝Toronto office的第5次technical session 成功举办。很凑巧，在周四准备上床睡觉的时候顺便查了email， 发现sean 居然给我回信了，通知我周五早上Toronto office有一个关于legacy system 的session，是否能按时赶到。活动之所以安排这么早是因为还要考虑到听众要上班的因素，因为大多数人都在附近上班。首先得承认，西方人在学习这方面还是比较勤奋的，不少人愿意早起来听听新的技术和思路。相比国内，把会议安排在早上8点基本上是不可想像的。此次参会人数还是不少，大概超过30人，不大的会议室也基本上坐满。会议内容是关于历史遗留

自从开始工作起,就不断听到身边的同事谈论UI设计的问题,林林总总,各种论调.大家之所以热衷于谈论这个话题,根本原因在于UI设计本身是一件和用户交互的活动,从满意性质量角度考虑,它的设计就不存到唯一的答案,因此这里没有最好,只有更好.不同的用户,不同的行为方法,不同的思考方法都将决定不同的UI设计.我一直没有过多思考什么是好的UI设计,毕竟做了这么长时间的数据库后台工作.长期的后台设计经历让我养成了寻求简单,直击根本的习惯,所以我认为的UI设计应当是简约,直接,能够实现展示价值.从我的第一个项目,我就这么认为,然而,这样的认识确实

准备起身去Pune了，同事建议多带点方便面和榨菜，否则后果自负。有点怀疑，但建议还是要听的，今天特意去了沃尔马搞了一大包方便食品，榨菜也不少，呵呵， 有备无患。EOF[@more@]

一位软件工程师的6年总结 作者：成晓旭 (声明：欢迎转载，请保证文章的完整性) “又 是一年毕业时”，看到一批批学子离开人生的象牙塔，走上各自的工作岗位；想想自己也曾经意气风发、踌躇满志，不觉感叹万千……本文是自己工作6年的经历沉 淀或者经验提炼，希望对所有的软件工程师们有所帮助，早日实现自己的人生目标。本文主要是关于软件开发人员如何提高自己的软件专业技术方面的具体建议，前 面几点旨在确定大的方向，算是废话吧。 谨以此文献给那个自己为你奉献3年青春与激情的开发团队。还有团队成员：PPL、YT、YK 、TYF、LGL、