…当我1995年开始为公司™编程时，这与现在的工作生涯大不相同。你可以对那些管理混乱的人说三道四，但我们就是喜欢这样。工程师们了解他们的受众，了解技术栈，了解“行业”里发生了什么，最终他们掌握着决定权。你的代码是你的私人沙盒。想每隔一个版本就重写它？去吧。喜欢把大括号放在新的一行？喜欢用制表符（你真有眼光）？去吧。那是你的代码，你拥有它。（你弄坏了，就得自己修复。）没有单元测试（我们称之为参数检查）。没有代码审查（嗯，没有正式的流程——经常是在同事的办公室里，讨论方法，用白板画API…如果发现或知道有bug，你就会去修复它。可能有正式的流程开始出现，但对这些疯子来说，那只是可选的。你可以想象管理层的感受——他们必须基本上信任开发者来交付成果。最终，管理层赢了，当然。当有人问我是否后悔离开苹果公司时，我必须告诉他们，不。…
源讨论程序员的身份危机原帖 307 条评论 · 导入时统计把你的经验，加入这段讨论。
我是在同一时间开始的。没有单元测试，但由于ISO 9001的要求，我们有代码审查。这意味着把差异打印在激光打印机上，然后召集三个人到会议室里仔细查看，然后让他们在更改上亲笔签名。这是为一个运行在钢铁厂和海上石油平台等大型工业控制设备上的RTOS做的。 项目管理是一个40英尺长的甘特图，打印在激光打印机纸上并贴在墙上。那种瀑布式开发的美妙声音。
完整原文> 我很不情愿地说，我认为整个行业永远不会回到那些“牛仔式编程”的时代了。那段时光很有趣，但已经过去了。 我认为行业不会回到过去，但我怀疑会有一些孤立的环境允许牛仔式编程。当我2011-2019年在WhatsApp时，我们相当程度上处于这个谱系的牛仔侧……虽然我认为现在可能不同了。 我认为，什么做法是合适的，取决于在生产前检测错误的成本，以及在生产后检测错误的成本。我倾向于减少修复错误的成本，而不是试图更早地检测错误。另一方面，我也尽量避免造成尴尬的错误，所以我尽量测试那些合理可测试的内容。
完整原文在2000年代末我刚开始的时候，你的职业路径和专业领域要清晰得多。 系统管理员和程序员之间有明显的区别。现在，我需要同时成为自己的系统管理员-运维人员，同时还要交付功能。虽然我在业余时间自己学习系统知识，但我故意在工作上避免这方面的内容，我不太喜欢现实世界中供应商文档、培训等的糟糕程度。
完整原文不幸的是，牛仔式编程的问题在于，团队中只要有一个笨蛋就会让所有人都受影响。随着公司的发展，由于纯粹的偶然，会有越来越多的笨蛋，这意味着你需要越来越大的墙来限制影响范围。如果你有一支值得信赖的工程师团队，那么牛仔式编程非常高效，但它根本无法扩展，尤其是考虑到招聘时评估候选人质量的难度。 我相信牛仔式编程可能仍然在小公司或一些小的公司内部环境中被使用，因为这些地方的工程师数量不需要扩展。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。