软件必备模块-软件的哲学

最新推荐文章于 2024-10-09 16:20:31 发布

weixin_34306446

最新推荐文章于 2024-10-09 16:20:31 发布

阅读量73

点赞数

文章标签：测试设计模式

原文链接：https://juejin.im/post/5b08c1d06fb9a07a9e4daaac

版权

软件必备模块-软件的哲学

我一直觉得设计哲学这个东西是一个很虚的东西，直到我看了一个关于苏联暴力美学的帖子，里面有一段写ak-47，t34等等。虽然也有人说这是苏联的战略忽悠局。经过一年的工作发现确实生产中面临这样的问题，如果用苏军内幕这本书里面的思想确实是可以改进很多问题。

坦克！进攻！

战略进攻

不要用战术上的勤奋掩盖战略上的懒惰？虽然把一个产品做的精益求精是对的事情。但是如果说几家产品同质化的情况下，战略上超过竞争对手是更好的办法，抓住战略机会。比如说从pc到移动端这种机会，从pc直播到手游直播这种机会。我觉得应该维持团队中有一部分功能做一一些开创性产品，当然这种产品也是要盈利的。为什么反坦克武器再厉害也无法消灭坦克，因为坦克是一只机动力量，你可以在各个方向灵活的时候进攻，但是你无法在敌人的进攻方向上都部署反坦克武器。在产品同质化的情况下或者优略势情况下应该采取模仿学习，但是一味模仿是很被动的，应该寻求在其他平台或者形式上进行尝试。

解决问题

为什么这个写在前面。因为我觉得写代码本身有意义，但是纠结在代码的细枝末节是没有意义的事情。首先作为一个公司或者一个技术团队，他的意义是解决现实生活的实际问题，有稳定可靠的盈利。至于各种规范很重要，但是相对于解决问题有些其实也是扯淡。代码本身的意义在于在有限的时间和资源里解决问题。垃圾代码也是要上线的。我觉得公司大了就会有一些问题，另一个问题一些东西会流于形式，不能灵活的解决问题，一个明显的bug必须要抽出时间测试再上线，一个必要的需求需要各个部门互怼后才能上线。

结构简单和性能可靠为目标简单的优势结构简单易于生产。结构简单易于维护。结构简单的组合可以组合成性能可靠的巨大产品。

简单主义

技术正在发展，随着时间流逝，武器装备变得越来越复杂，但这并不与苏联设计师的总体思想矛盾。几址年以来，他们在其所设计的占车和飞机上使用了很多最新式的设备，这些设备确实是非常复杂的。但苏联设计师在成百甚至上千种可供选择的工具和技术方案面前，始终坚持着牢不可破的原则——选用最简单的一种。

产品设计简单可靠

产品设计本身简单可靠的情况下，技术才能保证简单可靠。不过产品花里胡哨的情况下，那也就只能尽量保持了。产品设计向简单可靠看齐，技术才能向简单可靠看齐。

简单的组合

由结构简单的组合组合成性能可靠的巨大产品由结构简单的组合组合成性能可靠的巨大产品由结构简单的组合组合成性能可靠的巨大产品这样组成的产品易于维护，喝一瓶二锅头也写不错的代码和加班熬夜几天还写不错的模块是好模块，要考虑到很多时候需求紧张，人疲惫会出错，简单的结构能让自己在不清醒的情况下尽量减少错误。这样组成的产品易于扩展，简单的组合易于重构和扩展，在紧急情况下可以很快的理解哪里是瓶颈或者重构。

不同口径，为了音乐学院的学生

显式调用盗取代码，删库跑路是一件很可怕的事情，不过更可怕的事情是写不可维护的代码，可读的结构简单的代码，就是战时的武器，在仓促的情况下，隐藏调用或者其他的修改会。苏联武器用不同的口径就是一种显式调用，防止在后勤混乱的情况下，生产或者提供错误的弹药。黑魔法代码可能会很神奇，但是团队应该想法在需要的情况下，可以让任何人读懂代码，尽量写出让菜鸟也能看懂的代码。我认为应该尽量写简单可读的代码，保持代码风格一致，拿项目练习黑魔法或者设计模式是一件很可怕的事情。（不过可能也不合适，这种东西就是另外一些政治问题了，就像古代讲拥兵自重，养寇自重。代码review是一个看似可有可无的事情，但是应该就是为了这种问题存在的。测试驱动开发tdd也可以尽量尝试。)战时音乐学院的学生都可以轻松拿起来上战场的武器，对应的时你喝一瓶二锅头也写不错的代码。

黑魔法和隐藏调用

用很多黑魔法，写新特性的隐式调用，让其他人无法维护，在关键的地方不写注释，或者写错误的注释，古代大一份不可维护的代码可能有很多原因构成的。

奇特产品逻辑

一个按钮有一些莫名奇妙的显示逻辑，今天塞一个东西，明天塞一个东西这种设计应该尽量避免。产品应该多面向整体功能设计，如果一些奇特的细节会耗费大量精力不如直接换成下一个整体功能。从产品设计的时候就应该保持简单可靠的设计，虽然产品经历体会不到这件事情，但是技术领导和产品领导应该共同推动这件事情。

不可度量的成本

cxo们可能并不在乎今天写的代码可不可维护上线就行，但是他们应该知道这样的成本是巨大的，一些不可维护的代码就像工厂的流水线，如果新加一点东西就需要拆了重建人力成本巨大。不过另一方面对于一个部门其实也不希望别人轻易看懂自己的代码，这种东西就是另外一些政治问题了，就像古代讲拥兵自重，养寇自重。代码review是一个看似可有可无的事情，但是应该就是为了这种问题存在的。测试驱动开发tdd也可以尽量尝试。上线的黑魔法就不好改动了，这样也牵扯到测试资源。

费效比

美国和法国都改进了迫击炮，他们在炮膛上加上膛线，使其拥有较高的命中精度。早在1944年初，苏联设计师沙维林也曾建议为迫击加上膛线，但遭到坚决拒绝，因为制造10门滑膛迫击炮比制造1门线膛迫击炮还节省工时。即使线膛迫击炮精度比滑膛迫击炮提高1倍，但如果其生产费用提高10倍的话，只能将它列为一种差劲的武器。用火炮，导弹，轰炸机都能炸毁一个目标，我们应该选费效比最小的。费效比高的功能优先。