江苏龙网

  1. 首页 > 人文 > >

励志司机锐锐|高级软件工程师成长秘诀( 八 )


没有什么神圣的设计能够总是奏效
在设计系统时 ， 我注意到两个广泛的主题 。
首先 ， 我们发明的组件有限：队列、缓存、数据库和连接器（或者是让它们协同工作的代码） 。 每一个可能的设计都是这些组件的组合——每一个组件都表现出它们各自的权衡 。 有一些更快 ， 有一些更易于维护 ， 有一些扩展性更好 ， 都取决于你的用例 。
根据你的约束 ， 一种安排会比其它安排更好 。 你的目标就是寻找到那种最好的安排 。 有时候 ， 你可以通过一些绝妙的方法来降低复杂性 ， 或者让事情变得更快 。 但是 ， 基础设施不会变化 。
其次 ， 每个人都有一些快乐的主题可以回顾 ， 他们已经在过去看到了很好的效果 。 这些都是观察系统的不同视角 。 设计就是要搞清楚哪种排列符合这个视角 。
例如 ， 我喜欢简化状态并保持简单 。 简化状态有助于我更好地理解系统 ， 也有助于我更好地写测试代码 。 保持简单也是一样 。 两者都会导致更少的bug 。 当然 ， 不能太简单：这不能违反约束 。
正如我去年说的 ， 速度、本地化开发和测试都值得考虑 。 如果两种设计效果相同 ， 但其中一种设计更容易本地安装和编写测试 ， 那么我总是会选择更容易编写测试的设计 。
我喜欢找出其他人的视角 ， 并且尝试吸收我没有的视角 。 这也是我阅读技术博客的另外一个原因 。
在设计时 ， 保留上下文也是值得的 ， 就像写代码时候一样 。 很多时候 ， 我都会发现自己回顾很久时间之前的代码 ， 忘记了我们当时的假设 ， 然后想“卧槽 ， 我们是为什么要这样做的？！”明确我们的约束和权衡 ， 有助于保持正确的观点 ， 并有助于判断你是否做出了正确的决定 。
最后 ， 在设计取代现有系统的系统时 ， 我发现讨论迁移路径非常重要：我们将如何管理从旧系统迁移到新系统？
如果你曾经注意到一个系统 ， 一半的东西运行在新代码上 ， 另一半运行在旧代码上 ， 那就是一条有缺陷的迁移路径 。 不考虑迁移路径会导致技术债务高筑：你现在不得不同时管理和维护新系统和老系统 。 有时 ， 这是因为优先级切换 ， 而你还停留在中间状态 。 无论哪种情况 ， 这些异常都不会长久 。
好的迁移路径可能会花费比较长的时间 ， 考虑到它们留在系统内的状态的话 。 如果优先级改变 ， 我们是否会陷入到什么都不能做的状态？或者我们的迁移是增量的吗 ， 即使改变优先级也能保持稳定运行？当然 ， 增量迁移并不总是正确的解决方案 。 有时候 ， 彻底地迁移会更容易一些 。 其中重要的一点是沟通好：我们不能处理这种迁移的优先级变更 。
总结：
每个系统设计都关乎权衡 。
每个设计都有有限的技术组件 。
人们进行设计时都有明确的视角 ， 就像思维模型 。
在设计时保留上下文：写下你的约束和权衡 。
当取代老系统时 ， 有一个明确的迁移路径 。
收集需求
根据上述主题 ， 收集需求实际上就是收集约束 。 正如我们上面所见的 ， 需求有时是将约束转变成技术需求 ， 这并不总是正确的前进方向 。
在我的团队文化中 ， 团队和项目经理之间有充足的信任 ， 我们可以随意挑战彼此的意见 。 直接问问题就好了 。
问题清单在这里很有效 。 这里链接有一些我经常问的一些问题 。
最后一节将深入讨论一些问题 ， 一些我曾经做错的事情 ， 以及对所有做对的事情的总结 。
一些对我来说很好用的小诀窍
尽可能多地做代码审查 。 你错过的越多 ， 你对代码的心理模型就越错误 ， 你设计新东西时需要花费的时间就越多 。 斟词酌句：第二个问题一般就是问“你是怎么发现X的？” ， 而X就是你第一个问题的答案 。 第一个审核我的PR的人是我自己 。 而且总是这样 。 我很喜欢这样做 。 这是我从写作中学到的：第一阶段写明主旨要点 ， 第二阶段进行段落编辑 。 这和写代码很像 。 代码审核就是编辑阶段 ， 而且对我的代码进行代码审核也会让我更好地编写代码 ， 发现不一致的地方 ， 并知道其他人是如何进行代码审核的 。超能力


推荐阅读


上一篇：情感小布丁|你我是否都有个无悔的过去、现在、将来---致自己

下一篇：健康与财富|我还是进了养老院！太现实了，我俩儿子上清华和人大