离线下载
PDF版 ePub版

梦里风林 · 更新于 2018-11-18 07:00:35

评判

如何在开发质量与开发时间权衡

软件开发总是在工程该做什么与完成工程间妥协。但你可能被要求以牺牲你的工程适用性或商业适用性的方式,去交换工程的开发速度。例如,你可能被要求做一些糟糕的可能导致大量维护问题的软件工程实践。

如果这发生了,你的首要任务是通知你的团队,然后清楚地解释降低质量的代价。在这之后,你对这个问题的理解会比你的 boss 的理解还要更清晰。明白将会失去什么以及将要得到什么,以及在这次失去的东西,能在下一轮中得到什么。在这个过程中,由一个好工程提供的可见性应该会很有用。如果质量交换影响了质量保证工作,(向你的 boss 和质量保证部分)指出这个问题。如果质量交换会导致在之后的质量保证周期中出现更多的 bug,指出来。

如果她仍然坚持,你应该把劣质部分隔离到特殊的你可以在下一个开发周期计划重写或优化的组件中。向你的团队解释这个问题,这样他们可以为此做些计划。

忍者程序员在 Slashdot 写下了这样的格言:

记住,一个好的设计会被糟糕的代码实现弹回。如果好的接口和抽象在代码中到处存在,最后的重写会更加痛苦。如果写难以修复的清晰代码很困难,考虑是什么与核心设计冲突的东西导致了这个问题。

如何管理软件系统依赖

现代软件系统趋向于依赖大量的非直接可控的组件。通过协同与重用,这增加了生产效率。然而,每个组件会带来一些问题:

  • 你该如何修复组件中的 bug?
  • 组件限制你使用特殊的硬件或软件系统了吗?
  • 如果组件完全坏掉了,你该做什么?

某些程度上解耦组件,让它独立可以被移除,总是最好的。如果组件被证明完全不可用,你可能能够使用不同的组件,但你可能必须自己写一个组件。解耦不是可移植性,但这让移植变得简单,这大多数时候是好事。

拥有组件源代码可以把风险降到 1/4.有了源代码,你可以更容易地评估它,调试它,找到避免踩坑的方法,并且使得修复更容易。如果你进行修复,你必须把修复的内容提交给组件的拥有者,并且让修改合并到官方发布版中,否则你将不适地必须维护一个非官方版本。

如何判断软件是否太不成熟了

使用其他人写的软件是一种最有效率的构建一个坚实的系统的方法之一。这本不该被排斥,但与此相关的危机必须被检验。最大的一种风险在于,它通过使用变成一个可用产品成熟前的,bug 周期和与软件相关的故障时期。在你考虑将软件系统集成前,不论是你自己写的还是第三方的,考虑它是否足够成熟以使用是非常重要的。这里有十个你应该自问的相关问题:

  1. 它是蒸汽吗?(那肯定是不成熟的)
  2. 有可用的懂这个软件的人吗?
  3. 你是第一使用者吗?
  4. 有持续使用的强烈动机吗?
  5. 有维护负担吗?
  6. 没有当前的维护者的话,它还能用吗?
  7. 有至少和它的一半那样好的经验丰富的其他可用途径?
  8. 你的团队或公司了解它吗?
  9. 你的团队或公司对它满意吗?
  10. 即使它不好,你可以雇人在它上面工作吗?

对这些标准的一点考虑论证了良好构建的自由软件和开源软件在减小企业家风险上的巨大价值

如何做购买还是构建的决定

一个尝试用软件完成一些任务的企业级公司或工程必须不断做所谓的buy vs. build的决定。这个问题的不幸在两个方面:似乎忽视了不必被购买的开源软件和自由软件。更重要的是,这可能应该被称作获取与集成 vs. 购买与集成决定,因为集成的代价需要被考虑。这需要商业上,管理上,工程理解上的大量结合。

  • 你的需要与它的设计意图有多接近?
  • 对于你购买的软件,你想要怎样的可移植性?
  • 评估集成的代价是什么?
  • 集成的代价是什么?
  • 购买会增加还是减少长期维护代价?
  • 构建会把你放在一个你不想要的商业位置吗?

三思,如果你想要购买一些大到足够成为另一整个商品的基础的东西。这样的想法通常是乐观积极的将会对你的团队做出许多贡献的人提出来的。如果他们的想法很引人注目,你可能会想要改变你的商业计划,但不要在没有周全考虑前就投资一个比你自己的商业还大的解决方案。

在考虑了这些问题后,你可能应当准备两个工程计划草案,一个给购买,一个给构建。这会强迫你考虑集成代价。你也应当考虑两种措施的长期维护代价。为了评估集成代价,你必须在购买软件前对它做一个彻底的评估。如果你不能评估好它,你可以假设购买它会有一个不可预料的风险,你应该以此决定是否购买特定的产品。如果考虑后有几个购买决定,需要花一些精力去评估每个决定。

如何专业地成长

承担超过你的权威的责任。扮演你想要扮演的角色。对人们对更大组织的成功的贡献以及对你个人的帮助表示感谢与欣赏。

如果你想成为团队的领导,去激励与团结。如果你想成为一个经理,担起规划的责任。你通常可以在和领导或经理在一起时,舒服地完成这些事情,因为这使得他们可以抽空去承担更大的责任。如果这太多了以至于你不能尝试,一次只做一点点。

评估你自己。如果你想要变成一个好的程序员,询问一些你欣赏的人你怎样才能变成他们那样。你也可以问你的 boss,他可以告诉你的东西会少一些,但对你的事业会有更大的影响。

计划学习新技能的方式,包括琐碎的技术类型,比如学习一个新的软件系统,和困难的社交类型,像漂亮的写作,把它们集成到你的工作中。

如何评估面试者

评估可能的员工,却没有得到它应得的能量。一个糟糕的雇佣,就像糟糕的婚姻,是非常糟糕的。每个人的能量的一个重要的部分应该用于补充,尽管这很少发生。

有不同的面试风格。有的是折磨人的,设计用来把候选人放在巨大压力下。这是为了这样一个有用的目的:在压力下折射出性格缺陷和弱点。候选人不会对他们自己之外的其他面试官更诚实,而且,人的自欺能力是令人惊奇的。

你应当,最少,对候选人进行两个小时的与口头考核等价的技术技能考核。实践后,你会能够快速了解他们知道什么,快速收缩他们不知道的来标明边界。面试者会尊重这件事请。我有几次听面试者说面试的质量是他们选择公司的一个动机。聪明人会因他们的技能而被雇佣,而非他们之前工作过的地方或他们上了哪个学校或者一些无关紧要的特征。

做这些事情,你也应当评估他们的学习能力,这比他们所知道的要更加重要得多。你也应当不同的人散发出来的硫磺味。你可能能够在面试后通过比较笔记来识别这一点,但在面试的热烈环境中这很难分辨。人们交流的能力以及与人合作的能力比在最新的编程语言上领先更为重要。

一个读者有“在家”测验面试的经验。这有一个优点是揭露了一些面试者能良好地自我表现但不能写代码的缺点 - 这样的人是很多的。我个人没有尝试过这种技术,但这听起来挺合适的。

最后,面试也是一个销售的过程。你应该把你的公司或工程销售给候选人。然而,你是在与程序员谈话,所以不要尝试改变事实。从没有坏员工开始,到与好员工一起强大而结束。

如何决定什么时候使用奇妙的计算机科学

有这样一些,算法,数据结构,数学,还有其他极客范的大多数程序员知道但很少了解的东西。实践中,这种奇妙的东西太复杂了,通常是不需要的。例如,当你花费大多数时间在低效的数据库调用上时,提高算法是没有什么用的。不幸的大量编程由让系统相互交流以及使用非常简单的数据结构去构建漂亮的用户界面组成。

高科技什么时候是合适的科技?你什么时候应当打开一本书去找一些东西而非一个毫秒级算法?做这些有时候是有用的,但这需要被小心评估。

对于潜在的计算机技术三个最重要的考虑是:

  • 它是否充分封装所以其他低级系统风险和复杂度过量增加以及维护代价很低?
  • 好处是否是令人惊奇的(例如,成熟系统的两倍或新系统的十倍?)
  • 你能够高效测试和评估它吗?

如果一个充分独立算法使用了些许奇妙的可以减少硬件消耗或增加整个系统的两倍性能表现的算法,不考虑它可能是有罪的。争论这样一个方法的一个关键是,证明风险确实是相当的低,因为目标技术可能被充分研究过了,唯一的话题是集成的风险。在这里一个程序员的经验和评估可以真的与奇妙的算法协作使得集成变得容易。

如何与非工程师交谈

工程师和程序员(尤其是)通常被主流文化认为与他人不同。这意味着其他人与我们不同。与非工程师交流时,这是值得记在心里的,你应该时刻去理解观众。

非工程师聪明,但在创造技术类的东西不像我们那样踏实。我们制造东西。他们销售,处理,统计,管理,但他们在制造上不是专家。他们不像工程师那样擅长团队合作(毫无疑问会有例外。)他们的社交技能在非团队环境里通常像工程师那样,甚至比工程师要好,但他们的工作不总要求他们像我们那样进行亲密,珍贵的交流,以及细致的任务划分。

非工程师可能太渴望以至于不能被取悦和与你亲近,他们可能在不是真的对你满意的时候却对你说“是”,或者是因为他们有点怕你,然后不会对你说实话。

非工程师可以理解技术的东西,但他们不会做那件甚至对我们来讲都很困难的事情 - 技术评审。他们确实理解技术是如何工作的,但他们不能理解为什么一个特定的方法需要花三个月而另一种方法要花三天。(毕竟,程序员对这种估计也感到事多得可怕。)这代表了一个巨大的和他们协作的机会。

与你的团队交谈时,你会,不假思索的,使用一种捷径的形式,一种简单的语言更有效率,因为你通常对技术或者特别是你的产品会有许多的共享经验。

与你的团队一起,基本的假设和目标不需要经常重申,大多数谈话集中于细节。与外人一起,就是另一回事了。他们可能不理解你认为理所当然的东西。由于你把这当做理所当然,并且没有重申它们,使得你们的谈话陷入这样一种情况:你可能认为你们相互理解,但事实上有一个巨大的误解。你应当假设你会有错误的交流,并且仔细观察去找出这样的误解。试着总结或将你说的东西分点,来确保他们能够理解。如果你有机会经常与他们见面,花一点时间询问你是否在有效地交流,以及你可以怎样把它做得更好。如果交流有问题,在对他们失望前,寻找方法去提高你自己的实践。

我喜欢与非工程师工作。这提供了绝大的机会来学习与传授。你可以经常由实例得到关于你的交流的阐述的指引。工程师被训练于从混乱中梳理秩序,从困惑中得到解释,非工程师会因此喜欢我们。因为我们有技术评审,并且通常可以理解商业话题,我们经常发现一个简单的方法来解决问题。

很多时候非工程师会出于好意以及一种正确做事情的欲望去规划他们认为会让我们更容易的事情,事实上存在一个仅能通过借助你的技术评审协助外人的观点看到的好得多的方法。我个人喜欢极限编程因为它处理了这种低效,通过将估计快速与主意结合,使得发现成本与好处最佳结合的方法更加容易。

上一篇: 团队技能 下一篇: 技术评判