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


你是如何建立和得到信任的?答案很简单:你去信任他人 。你相信那个说他可以学会这个新库并且在周一前会整合完的人 。你相信那个说他需要提前离开 , 因为家里有事而会错过明天工作的人 。你相信那些想在截止日期前一个月休假的人 , 因为他们觉得自己已经开始筋疲力尽了 。你相信说想要解决难题的初级程序员 。
但你不总是正确的 。有些时候人在工作上存了坏心 。你需要揭露这些人的真面目 , 让他们尽早离开 。有时候你要信任那些真心想成功的人 , 虽然他们会失败 。但违反常识的是 , 长远来看这通常是个胜利 。因为那些人会记住你的信任 , 他们会尽一切努力来报答你 。
3、简单比优雅重要的多
我也喜欢紧凑优雅的代码 。我喜欢灵活的框架 , 有如此多抽象层次随时待命 , 无论抛出什么改变的需求都能解决 。我喜欢使用位向量、位位移、略微复杂的数据结构和不太流行且古怪的小语言特性 , 但在特定环境下十分实用 。
然而你并不只是为了你自己写代码 。即使它只是个“原型” 。(我已经记不清我有多少“原型”在多次对层操作和润色的过程中出现问题 。)而且你不仅仅是为了解决当前的问题编写它 。你正在为了下一个接手的开发者可以使用它来解决下一个问题而编写 。把你写到那五行代码扩充为十行可以增强其可读性 , 你知道吗 , 也许扩展为十五行效果会更好 。
你可以提前尝试并用灵活且充满抽象的框架解决它们 。但是也许预言不是你的强项 , 也许你关于下一个问题的概念的想法完全是错误的 。也许仅仅编写足够简单的代码才是最佳选择 。有一个命名约定和一个编码风格 , 让它读起来像英语一样 。也许不是添加一个类 , 而是下一个开发者在试图跟随你的控制流程时必须保持另一个文件的开放 。你应该用愚蠢的方式 , 不雅的方式 , 简单的方式 。
4、动力比大多数事都重要
我们都曾见过这种情况 。一周里每个人都在检查代码 , 构建显而易见的雏形 , 每天不断增加特性 , 测试覆盖率越来越高 。疏忽也随着生产的想法和解决方案而出现 。不知怎么的下一周所有事都变得缓慢起来 。关于 A 的决定 , 会影响到 B、C和 D 。当人们可以运行D、E 和 F 时 , 它们不是逻辑序列发展上的一部分 。于是需要做更多的假设 , 认知负载加重 , 你不得不模拟出一堆东西来写出非模仿代码 。一些人需要做这个决定 。
或许不是决定会瘫痪 , 是你上周所做的一切都在错误的基础上 , 是一个“地震多发区”的技术负债 。你需要停止所有事返回并重构它 。而且你必须马上开始 , 因为等的时间越长 , 事情会变得越糟糕 。没人想看到这种事发生。但他们宁愿现在面对也比下个月知道的好 。让暴风雨来的更猛烈些吧 。
也许上周每个人都拼劲全力 , 现在实在撑不住了 。你知道该怎样吗?得让他们休息一下 , 每个人 , 休息一整天 。我保证 , 这会给你接下来的“长跑”节省时间 。
I我们很难定义、衡量以及说明动力 。但它在软件开发中是真实存在的东西 。而且它的缺失会成为造成首要影响 , 导致我们需要去解决很多根本问题 。别忽略它 , 也别期望或假装它会神奇地回来 。察觉警报并迅速采取行动 。
5、与和你互补而不是像你一样的人一起工作
每当我看到人们根据“文化契合度”来找人的时候 , 我就会拼命翻白眼 。你知道大多单一栽培会发生什么吗?他们遭遇了他们不知如何解决的病原体 , 然后嗝屁死翘翘了 。
你不会希望你的所有开发者、设计者、 QA人员、产品人员、销售人员和执行官是彼此的克隆人 。你肯定不想 。每个人都有自己的长处和短处、优点和缺点 。你想要雇佣的是他们的长处 , 让其他人的长处弥补他们的短处 。
比如说我 , 写代码非常快 , 擅于沟通 , 读写文章都奇快 。我在任何时候都能熟悉很多编程语言和框架 。我理解东西透彻且迅速 , 有丰富的经验 。然而我还是一个在特定领域、框架和语言缺乏深刻专研、精通掌握的全才 。我是一个真正从别人身上获益的建筑师 , 跟踪所有需要 , 在骨骼构建好之后添加肉体和润色 。我还是个 UX 盲(等一下 , 你说那些还没对齐?) , 这一直被当作同事之间的玩笑 。


推荐阅读