ACM通信
Kode恶性
森林为树木
生成插图由Leander Herzog
亲爱的KV,
我注意到您对人们代码的整洁性、注释、版本号和其他编码习惯进行了大量的评论，但您从来没有提到过我最讨厌的一件事:人们似乎不能正确地命名他们的源树。如果有人告诉你:“哦，那个文件在~my-name/project-foobar中”，你不会生气吗?我无法想象他们不会。
被树木挫败
亲爱的沮丧,
有太多的事情让我沮丧，这些专栏已经很清楚地表明，所以，是的，你是对的。那些不把结帐的东西放得整齐、不合理的人让我很生气。
我经常认为，许多程序员看到自己的结帐时就像他们小时候看到自己的房间一样:这是一个私人领域，在那里他们可以随心所欲，直到父母告诉他们把东西清理干净。随着现代程序员可用的磁盘空间的数量，以及大多数工作场所缺乏父母的监督，“打扫你的房间!”的时间永远不会到来。因此，他们的结帐增长和积累文件，他们称之为临时的，但真的应该给一个良好的家园，或删除，在很久以前。
接下来发生的是，在与上述程序员开会或交谈时，您会问:“嘿，您制作图表的源数据来自哪里?”或“您是否检查了上个月编写的有用脚本?”这些人总是会说:“哦，我是想说，但这并不那么重要。你可以直接从我的树里复制。它在我的主目录my-latest-work-17下面的某个地方。”“17”是他们尝试的版本号，但不要期望他们有任何标签为1到16的目录——真的，不要。现在你需要找到文件，你可以通过优秀的，通常是缓慢的，发现(1)命令。希望他们记得文件的名字否则你就得进行多次搜索，这一点都不好玩。唯一使这种马虎的情况变得更糟的是，它完全是在公开的、开源的项目中完成的。
大多数(如果不是全部的话)开源项目允许您使用当前泛滥的源代码控制系统中的一种，将它们的软件检查到您的本地机器上，从而遵循它们。虽然提供这样的服务是一件好事，但提供得不好就像在城市中心建了一座图书馆，把所有的书都扔到空中，让它们随便掉到什么地方，然后用便利贴给其中一些贴上标签。虽然大多数项目都没有这么可怕，但我注意到有一些草率的倾向，因此令人抓狂。我把这种趋势归咎于最近引入的分布式版本控制系统，比如Mercurial和Git。
KV维护公共资源树的首要原则是把所有东西都标清楚。即使您认为一棵树不会持续很长时间，也要给它贴上标签:给它一个新项目的人很容易理解的含义，这样他们就能知道这棵树是否真的对他们感兴趣。
我的第二个原则是，不要把个人开发人员树和发布树混在一起。一个网页有100个不同的签出目标，你可能会笑，但我经常看到这不是一个向用户展示你的项目的好方法;它也不是使代码可用的好方法。将开发人员私有源代码树与您想要作为真正发行版的树隔离开来，是增加健全和减少混乱的一个好方法。如果人们真的需要查看开发人员的私有树，他们很可能会找到它，不过您可以通过设置一个标签为“开发人员树”的页面来帮助他们。
如果开发人员树中的代码足够好，可以发布一个版本，那么让开发人员检入它，创建一个分支，然后发布它。
最后，不要使用开发人员树作为发布树。如果开发人员树中的代码足够好，可以发布一个版本，那么让开发人员检入它，创建一个分支，然后发布它。懒得这样做的开发人员不应该成为项目的一部分。没有一个开发人员足够重要或聪明，他或她的树可以成为发布树。
KV
亲爱的KV,
在我的业余工作时间，我一直在我们的一些工具中添加一种嵌入式语言，这样我的团队中的其他人就可以更容易地为他们的部分工作编写脚本。在花了几周时间做这件事之后，我向我的团队展示了我所做的事情，他们的反应从漠不关心到充满敌意，而不是高兴和欢迎额外的工作。我甚至使用了一种流行的、开源的、可嵌入的语言，而不是我自己编造的东西。我让他们的工作更容易了。他们为什么会不高兴呢?
被低估了
亲爱的,
你确定你让他们的工作更容易了吗?你确定你了解他们的工作吗?工程师们普遍认为，他们编写的每一段代码在某种程度上都是对人类的恩惠，有助于推动整个人类向前发展，推动我们所有人进入一个勇敢的新世界。另一件需要考虑的事情是，大多数人不喜欢惊喜，即使是好的惊喜。试试这个实验。如果你在欧洲，拿一张20亿美元的10欧元纸币，冲到同事的隔间里，声嘶竭力地喊道:“早上好!!”，然后大声地把钞票拍在桌子上。你刚刚给了你的同事钱，所以他肯定会很高兴见到你。请把结果报告回来。
更有可能的是，你发现了一种你自己希望满足的需求，并且你花了一些愉快的时间来满足这种需求。在那里是为了满足技术需求而工作并没有错;一些最好的创新就来自于这样做的工程师。相信一群不知道你在过去的一个月里做了什么的人会突然看着你创造的东西说:“哦，快乐!这正是我想要的!”除了最明显的创造物之外，所有的创造物都需要社会化。(是的,我用社会化在技术专栏中。)
如果你想要你的想法被接受，你首先要明白除了你自己，是否还有其他人需要它。偷偷观察你的同事并做笔记，这是一个让自己被HR列入某种心理观察名单的好方法，所以我建议你采取比这更巧妙的做法:通过询问他们。询问一两个您认为会使用您的新软件的人，如果他们真的对您正在考虑构建的东西感兴趣的话。如果他们说“不”，那就不是停下来的理由;它只是告诉你，当你完成时，你必须做更多的工作，让他们看到你的创造是多么伟大。郑重声明，在会议上对他们大吼大叫，告诉他们他们有多蠢，竟然不知道你有多聪明，这也是一个失败的策略。
最好的办法是考虑新系统的一个简单部分，它非常有用，而且对他们的日常生活无可争议地有好处，他们会立即找到它的用途。集中精力为他们提供有用的信息，你就有可能赢得他们的支持。或者，你可以成为管理层，强迫他们都听从你的命令。无论哪种方式。
KV
相关文章
在queue.acm.org
专用语言
迈克·夏皮罗
http://queue.acm.org/detail.cfm?id=1508217
破碎的构建
Kode恶性
http://queue.acm.org/detail.cfm?id=1740550
数字图书馆是由计算机协会出版的。版权所有©2011 ACM股份有限公司
没有发现记录