江苏龙网

  1. 首页 > 资讯 > 科技 > >

技术编程|我从编程写软件学到的 7 件事

编译：伯乐在线/tsteho
我正在一点一点的从一个工程师转型为管理者 。别弄错了 ， 虽然我在转管理 ， 但我仍然在每天写代码 。不过我发现自己在会议和电话中会花越来越多的时间去分析讨论 ， 试着去组织团队 ， 并且为全局部署而不是具体战术而烦恼 。
当然这不是一件坏事 。高层次的决策往往比单个的类和函数的细节更有影响 。让一个团队更有效率 ， 比仅仅让自己更有生产力有更高的杠杆作用 。但我想我已经从我多年来的编程中吸取到了一些经验 。我希望大部分经验可以应用于管理方面 。
技术编程|我从编程写软件学到的 7 件事
文章图片

文章图片

1、没有规定（rules） ， 只有公案（koans）
译注：公案（Koan）有五种重要的涵义：作悟禅的工具；作考验的方法；作权威的法范；作印证的符信；作究竟的指点 。）
举个例子：DRY ， 意思是「不要重复你自己」 。作为软件的基本规则这很好理解 ， 因为很多话可以证明：“我做 X 是因为它没有重复 。”这说得通 ， 不是吗？如果你有两个或者两个以上部分的代码在做相同的事情 ， 说明你正在浪费 。而且如果当你需要改变它们其中一个的时候 ， 你可能也需要改变其他的 ， 并且你很可能会忘记这么做 。当它们不同步时 ， 你会得到一个怪异的 bug 。因此很显然你不能重复你自己 。
然而 ， 在使用了几年之后 ， 人们开始怀疑它的普遍适用性 。假如你的两个方法中包含相同的代码块 ， 所以你将其拿出来形成一个单独的函数 。通常那些方法会开始朝不同的方向发展…接着你发现自己要在函数中加入更多的参数 ， 很可能为结果立了更多 flags……然后下一个接手的程序员会因为分离出来的函数以及它所带的特定的参数和结果 ， 而出现认知负载 。你会意识到如果当初允许自己重复 ， 并让两块代码自然的发展为不同的个体 ， 你生成的代码将会更简单直观 。
这意味着 DRY 不好吗？当然不是！通常在合适的环境下使用 DRY 是正确的…好吧 ， 也许 。我个人的经验是：“重复一次是可以的 ， 超过一次就不太好了…当然这取决于所处的环境 。”因为所有事都取决于环境 。DRY 的目的并不是为了 DRY 。如果你迷信于此 ， 小孩儿 ， 那你还有太多要学 。DRY 的目的为了让你了解 DRY 。那当然不是规定 ， 仅仅是公案 。
（让我重申一遍：我在讨论的是软件 。在我的经验中 ， 硬件规定的确更倾向于是我们所理解中的规定 。这就是我为什么要从电气工程转到软件的原因）
细想我最喜欢的两个计算机科学“定律” 。第一：“计算机科学中没有一个问题是不能通过添加另一层抽象来解决的！”这句话完全正确吗？当然不 。这在现象学上是正确的吗？实际上 ， 的确是 。这是否意味着抽象是解决任何问题的正确途径？不 ， 不是 。它是一个公案 ， 可以启发思想 。
还有我历来最喜欢的：“第一优化定律：不要这样做 。第二优化定律（对专家而言）：不要又这样做 。”这显然是一个公案 ， 却称自己为法规 。是时候让你的代码运行的更快吗？不 。是时候让你的代码运行的更快吗？还不是 。什么意思？意思是要考虑到时间 ， 复杂性 ， 认知负载 ， 具体结果 ， 生活意义 ， 人类存在的意义 。并且三思而后行 ， 小孩儿 。但不要花太长时间 ， 我们还有工作要做 。
2、要想得到他人的信任 ， 先信任他人
这不仅仅针对于管理者 。虽然它对管理者尤其重要 。信任是你真正拥有的唯一价值 。如果你的公正、判断、理解、诚实不被信任 。接下来你组织的成员将把你视为祸害并绕着你走 。然而 ， 如果你是个有能力但不被信赖的开发者 ， 你可能还有一些价值 。虽然你在每个决定上做的努力都会被大大消减 。
不过更重要的一点是：一个团队的成员需要互相信任 。当 Natascia 说：“我来解决那个问题单（ticket）” ， 你必须相信她会去做 。当你说：“Peter 能在截止时间前完成的 。” ， 你必须相信那会实现 。当某人说 ， “我有一个疯狂的点子” ， 他们必须信任他们会被尊重和认真对待 ， 尽管那点子的确很疯狂 。


推荐阅读


上一篇：|济南GRC构件产品那么多，厂家如何进行归类?

下一篇：行业互联网|18Xmm硅片横空出世，光伏产业链哪些厂商在布局？