我居然也有胆来想这个命题了。 困惑 - 换个视角看待公司 大部分年轻人都在一个商业组织（即公司）中工作。 我们似乎对这个商业组织的运作已经很熟悉： 接触公司并进行面试和岗位匹配，在特定的岗位里面工作，过程也许开心或沮丧，通过组织的种种管理手段（KPI / OKR）来完成上级分发的任务。 这个过程中，我们往往遇到不少困惑，有些朋友还经历过职场 PUA（Pick-Up Artist）；有些朋友可能感觉自己已经干的足够出色却无法得到晋升；有些朋友感慨合作的上下游太不专业了；总之，我们对公司不满是常态，而对公司满意则是反常。 ...
一个同事在知乎提了一个问题 如果把草帽海贼团比作一个创业团队,这个Team的组织架构是怎样的?有哪些优势,又有哪些不足? 这个话题很有趣，作为追了多年的 fans ，又是身处互联网创业团队的我要来强答一记。 海贼王的世界很大，富有个性的角色和团队也很多，恰好可以和显示世界中的互联网创业团队进行对比。 柳传志讲的好，做大事，要「建班子，定战略，带队伍」，我们就着金句来看看草帽这个团队怎么样。 产品和战略 我先讲产品和战略。 由于海贼王世界的设定，以及作为一个全年段漫画动画的原因。 海贼王世界的整体战略是较为简单，海贼团的目标都较为单一，即「找到 哥尔 D 罗杰 留下的宝藏」。 海贼团们实现目标的路径也较为单一，打斗增强战斗力，不断寻找线索，去伟大航道寻找宝藏。 ...
这是一天一本书的第二次执行，这次选了一本比较薄的书，上周的书看了一天，脑仁疼。 在我组织团队新兵训练营（入职之后一段时间内容集中的培训）时候， 经常和新同事聊到一个词：软实力。 我将其描述为专业技能之外的能力。每个人都这种能力的解读可能会不一样， 我将其拆解为：「对工作的热情；观察力和反思能力；做计划和决策是否周全」。 这种拆解是不全面的，「多年」以后，我意识到，硬实力考衡的是专业的能力， 而软实力则是考衡人的因素。这种晚来的意识让我在一段时间里面， 将自己的工作陷入困境，并且得不到解药。 ...
作为战斗民族的俄罗斯民族，不但能在热带风暴级的灿鸿中进行正常起降， 历来也盛产各种奇葩人物。 最近我有看到一本描述一个科学家的如何生活的书，叫「奇特的一生」。 让人拍案称奇。 主人公是一位名叫柳比歇夫的科学家，想必他在「回首往事时候没有因为虚度年华而悔恨」， 因为他将自己的一生都精确的奉献到分类学、地蚤研究上面。 他的工作投入，不是单纯激情洋溢投入，而是精确到分钟级别的投入， 是奉献完整一生的投入。 除了学术上面的成功，他的时间记录法也很牛逼，甚至让苏联科学院进行研究。怎么描述他的牛逼呢？如果他生活在今天，大致会这样写： ...
随着团队规模的变大，成员之间合作的模式逐渐由单打独斗变成协作开发。 这时候会遇到很多意想不到的问题，项目管理的重要性也就显现出来了。 项目管理修炼之道 是一本讲技术类项目管理方法和实践的书。 从业者可以从这本书获得了有益的指导。 我在 Kindle 上面翻了好几遍，感觉受益匪浅，就把读书笔记拿出来供大家参考。 内容 核心内容是项目管理的生命周期和每个阶段的交付物： 项目章程 日程规划 开发（控制节奏） 结束项目，项目回顾 其他内容： 如何和投资者沟通 管理会议 控制项目节奏 关键字 项目定义：一个独特的任务或是系统化的流程，其目的是创建新的产品或服务， 产品和服务交付完成标志着项目的结束。项目都有风险，并且受制于有限的资源。 关键（章程） 驱动因素：功能集合、发布时间、缺陷等级，只能有一个 约束：环境、流程、人力资源、预算等，决定了规模 浮动因素 规划：带有项目发布条件的项目计划 日程安排：对工作项目的有序描述 发布条件：S.M.A.R.T.，需要一起协商 仪表盘 定性或者定量的方式，将结果公布出来 保持项目节奏的方法 快速开发 持续集成 自动冒烟测试 功能拆分和日程排期 按功能实现，而非架构 优先实现高价值功能 通过用户故事、角色和场景来定义需求 分离需求和 GUI 质量控制 复查：Code Review，结对编程 重构 项目成员的角色构成 项目经理 架构师 开发人员 测试人员 业务分析师 运维 我的问题和部分解答 Q：项目经理的职责是什么？ ...
前段时间在将公司的 SVN 项目迁移到 Git 上面去，遇到一个很少见的问题： 有一个小伙伴使用 git-svn 做 rename 操作时候，将一个目录 svn mv 了， 导致新目录只存了最近几个月提交历史，丢失了历史信息。对团队开发而言， 历史提交是非常宝贵的财产，我们想了一些办法，把这些数据提取出来。 # 找出丢失之前的版本，列出丢失目录上层的操作记录。 svn log -l 2000 svn://log4d.com/trunk/apps/ios/ | less # 将重命名之前的版本拷贝到一个临时目录 svn copy svn://log4d.com/trunk/apps/ios/nami@43252 svn://log4d.com/trunk/apps/ios/nami_lost # 准备现有代码到 Git git svn clone svn://log4d.com/ -T trunk/apps/ios/nami -t tags -b branches -r 13532 nami # 修改 .git/config 来加入丢失的历史数据 Remote [svn-remote "svn-lost"] url = svn://log4d.com fetch = trunk/apps/ios/nami_lost:refs/remotes/trunk-lost # 并抓取 Remote 内容 git svn fetch # Rebase 新代码到恢复过来的历史记录上 git checkout master git rebase --committer-date-is-author-date trunk-lost 其中注意的是手动添加一个 svn-remote 地址为历史数据副本地址。 还有就是 rebase 时候参数 --committer-date-is-author-date 可以保证 rebase 不会造成提交时间被修改，方便回溯。 ...
事情起源于动态语言和静态语言之争，最后争论焦点转移到：「相信人本身的能力重要， 还是通过语言/工具来约束人重要」。 我认为项目开发中最重要的是个人能力和团队协作能力，工具只是加分项。 如果代码质量差、监控难、性能难以优化，解决根本问题的关键还是在人身上。 并不是静态编译和工具检查就能搞定了。 我愤愤的在 QQ 对话框中写道： 我工作第一年痛苦于开发流程，阅读了《人月神话》，就开始坚信软件工程的哲学 后来痛苦与代码质量，阅读了《重构》，开始坚信代码质量决定产品质量 现在痛苦于人和语言的冲突，动态和静态的冲突，我想读《人件》了 ...
说到软件开发的过程、环节等等，我印象里只剩下一大堆术语和一些流程的大概，但是因为缺乏正规开发的经验，所以并没有对软件开发中每个人的角色有深入理解，今天在周末 检查Delicious Temp标签时候，看到 圆木菠萝头 的这片文章，收获颇丰，现在转载与大家分享。 原文链接：[ 软件开发中的角色扮演 - 软件开发 - 圆木菠萝罐](http://blog.boluotou.com/Developer/2009/06/S oftware_Role) （我稍微调了一下格式，没有修改文章内容 ^_^） ××××××XXX分哥线XXX××××××× 商业软件开发并不是只有一个编程的人，而是可以分为不同的角色。 ...
问题 用户权限设计这一块，一直是一个我觉得比较难解决的问题。 以前我用了「伪继承」，虽然管理员继承了普通用户，但是数据库却是分开设计的。又或者压根没有继承关系，是两个不同的实体。 解决方案 这次在贴吧系统，有三个用户角色：普通用户、吧主、管理员，想设计的符合OO，但又要利于数据库的实现。就有几个问题需要解决：1.需要继承么；2.数据库怎么设计； 3.Hibernate怎么映射。最后参考几篇文章，设计成如下。 使用User类，Roll类，User具有一般用户属性，Roll负责角色，他们是1对1关系，最好在数据库有一张User- Roll的对应关系表。来标明这个User具有哪个Roll。 ...
在《用户界面设计要素》一书（1997）中，T.Mandel提出了3条「黄金」知道规则： 让用户驾驭软件，而不是软件驾驭用户。那种在给用户的操作加上许多约束和限制的界面虽然设计容易，却往往难学难用。 尽可能减少用户的记忆。为此可建立易记的快捷键（例如Ctrl+p启动「打印」）；采用演进形式显示「提示」信息，以免要用户一次记忆大量信息。 保持界面的一致性。例如在同类产品中使用相同的设计规则；尽可能不改变用户已熟悉的操作功能键（例如用Ctrl+S保存文件）；设定界面的缺省状态。 最近停下了贴吧的下一步开发，恶补软件工程，为下一步开发做理论基础。 一边啃Rober C.大人写的《敏捷软件开发》。白天都浪迹在考研自习室（很是安静啊），更新变慢，勿怪。 ...