您喜欢哪种编程方法?成功与自由

我喜欢把事情做好。这意味着使用已建立的开发工具和合理的过程,同时对我在该过程中所做的工作保持创造性。英国语言中最伟大的诗歌是以严格的韵律和韵律规则写成的,似乎对它的创造性丝毫没有减弱。

“不管自由与否”的态度是幼稚而烦人的,现实世界并不是这样的。

给我既定的程序。

经济学家。如果它能让我赚钱,而且不是不道德的,我完全赞成。

取决于你是否聪明。

如果你聪明,那么自由。你会成功的。

但问题是,没有人能诚实地说出他们自己是否聪明。

我不认为自由与无聊是有效的。一个定义的轻量级过程也是灵活的,当然是可行的。在有人告诉我他们擅长发展之前,我可能不会允许这么多的自由。

遵循一个坚忍的非弹性过程也可能是有害的。

需要很多常识,但这是一件困难的事情,这在开发人员和组织之间都是不同的。没有一种尺寸适合所有人。

就我个人而言,我更喜欢尝试新想法、新技术、新流程的自由,但我认为这应该是自我调节。也就是说,我认为技术、过程等需要证明自己是有益的。在团队环境中要求个人表达的自由可能不是构建团队的好方法,但我认为团队应该开放,通过新的想法进行改进。但是,一旦团队采用了一个过程/技术,如果团队不以与您相同的方式看待它,那么继续坚持自己的方式(即使更好)也会适得其反。

这不是一个有效的问题。你可以行使你遵循一个过程的自由,或者你可以行使你不遵循一个过程的自由。不管你是否遵循一个过程,你仍然有自由。

这是一种错误的二分法。强加的过程与成功无关。例如,在电话公司,有一个巨大的过程强加给软件开发人员(幼稚的阅读“瀑布式”开发),结果是浪费了大量的时间编写详细的设计文档,然后当软件交付时,客户突然发现他们要求的不是他们想要的。此时,资源几乎耗尽,每个人都会损失。强加的过程会扼杀项目。

另一方面,当amitabh srivastava对windows团队提出一些基本的分析和测试要求时,错误率下降了,至少在我在微软的朋友中,生产率和士气都上升了。我假设在kde项目上发生了类似的事情,当他们开始要求所有人使用 valgrind . 突然之间,不再有内存错误和混乱的核心转储。

总的来说,我认为把有用的 工具 比强加 过程 . 支持或反对工具实用性的证据可以很快积累起来。我所看到的唯一的“过程”是持续成功的,就是不止一双眼睛应该看到代码。实现这种观察的机制并不重要。

开发人员的自由是完全不同的问题。我很幸运,因为我有一份工作,在那里我几乎完全可以自由地选择关于我的开发环境的一切。(例如:我在一家Red Hat商店工作,但我有购买计算机和安装Debian的预算。)由于我有20多年的持续软件开发经验,我通常可以很好地选择要使用的语言和工具。但另一方面,我可以在任何语言或环境中合理地发挥作用。使用Perl或C++可能会使我慢到2或3倍,使用Lua或Haskell会加速我的某些问题,但我最终会到达那里。

但是,我与其他开发人员合作过,他们对于语言和工具的舒适度非常有限,如果有自由的话,他们会很乐意为工作选择一个非常错误的工具。有一次,我作为顾问被要求帮助一个小组加快编译程序的速度,编译小程序需要24小时。事实证明,编写它的人是专家系统人员,他们使用基于规则的推理引擎编写了一个编译器。他们让它工作了,但这是一项错误的技术。

我还看到,将开发人员约束到特定的环境或语言并不能保证成功。我认为自己是一个非常糟糕的Perl程序员;我基本上像对待类固醇的awk一样对待Perl。我是个十足的白痴。然而,我不得不处理其他人编写的Perl代码,这些代码比我所能编写的任何代码都糟糕得多,因为他们从未学会思考问题或如何组织代码。

我想我现在最好别再大喊大叫了。

在更大的团队中工作是既定的、记录在案的过程的价值观。

只要你是在一个小团队(2-4人)中工作,在这个团队中你很了解每个人,并且你们都有一个共同的目标,那么你可能在没有定义好的流程的情况下工作得很好。

一旦10个人必须在某件事情上合作,你至少需要一些基本的规则,这样每个人都站在同一边。

当你和100个人一起做一个项目时,你将一无所获,除非你有非常具体的规则和明确的过程。

就我个人而言,我更希望我能做我喜欢做的任何事,而其他人都是按照严格的流程工作的;—)

自由有不同的方面。当你被限制改变一半的代码库,因为它已经“测试过”(即使它的代码编写得很糟糕),我会说这是一个你需要自由的情况,但我不认为你在谈论这个。

黑客式的自由,使用任何必要的工具来解决问题,并且把解决问题作为主要目标,这几天让我很害怕。

我从来没有见过在某个时刻不需要调试/修复的代码,调试/修复似乎总是比最初的编码花费更多的时间,所以尽可能简单地进行第一轮调试/维护/增强需要成为您的主要目标。

这与“自由”相冲突,因为“自由”通常意味着你能够选择需要其他人更长时间来处理的机制——而且最有可能是其他人会进行第一轮维护。

如果你把对自由的焦虑放在新项目领域的创造性上,而不是发明另一个开发过程呢?

“成功与自由”意味着如果你可以自由地做决定,那么这个计划就不会成功。

我想你真的需要重新考虑一下。根据我的经验,开发人员需要自由地选择最佳的实现方法,如果在审查后比“尝试和测试”方法更好,那么它将被团队的其他人保留和使用。但是他们仍然需要确保他们编写的代码能够成功地完成他们要执行的任务。

在这种情况下,“自由”似乎只是一个与一个不愉快的概念联系在一起的情感上积极的词。它也可以很容易地被“顽固”或“粗心”所取代,甚至问题本身也被界定为“我想做什么”和“什么可能有效”。

当然,任何人都可以自由地走自己选择的任何道路。但我个人不会把我生命中的任何一刻都花在我不关心的事情上,如果我真的关心它,我会尽我所能最大限度地提高它成功的机会。我一点也不认为这是“限制性的”。

是坚持传统智慧还是“跳出框框思考”的问题在大多数学科中一直存在,而不仅仅是编程。我想这得根据具体情况来决定。

我参加过一些会议,最受欢迎的论文似乎是对事物的深入分析。与此不同的是,在流行的观点被投票否决的地方。

如果这个领域没有严重的问题,这是可以的。很多(如果不是大多数)软件仍然过于臃肿(imho),并且长期存在性能问题。事物本身是稳定的,但它们足够好吗?

我认为我们需要新的想法,而这些想法在一段时间内必然会不受欢迎、不合常规和冒险。

我很高兴这样允许非传统的想法被讨论,而不是像火焰一样,而是作为质疑现状的方式。

它是否也取决于你最终要建立什么?

这些人遵循既定的流程: http://www.fastcompany.com/magazine/06/writestuff.html