我刚开始工作，但我工作的公司聘请了很多非科学的人，他们足够聪明，可以完成工作（复杂），但缺乏应该帮助其他人阅读代码的风格和做法
例如，他们采用C ++但仍然使用类似C的3页函数，这些函数在尝试阅读时会驱使新人疯狂。我们也觉得改变风险非常危险，因为要确保我们不会破坏某些东西并不容易。
现在，我参与了这些人的项目，我无法自行更改整个代码库或设计代码，以便代码看起来很好，在这种情况下我该怎么办？
PS＆GT;我们 实际上 有3个页面功能＆amp;因为我们没有设计概念，我们所能做的就是假设他们可能想到的东西，因为没有办法知道为什么它的设计方式如此。
我不是在抱怨。我在寻求建议，已经阅读了一些书来解决问题 实用程序员 ; B.Stroustrup的设计部分 ; B.Stroustrup的编程和原则 ;
答案 0 :(得分：43)
您可以做的最好也是最重要的事情是以身作则。以正确的方式做事并尝试慢慢改进。你不会在一夜之间解决任何问题。
确保完成后，您负责的每一段代码都会更好。随着时间的推移，由于你的努力，系统将明显变得更好。
在与同事建立良好声誉后，请尝试开始一些代码审查或午餐培训课程，以便让每个人都能更快地了解更好的工作方式。
简而言之：这将是困难和令人沮丧的，但它是可能的。祝你好运。
答案 1 :(得分：20)
你最好的选择是不要处理它。如果您尝试以下是潜在的问题：
专注于使自己的代码变得更好。编写糟糕的代码是成为软件工程师的一部分。如果你不支持，你就是错误的职业。
稍微有点但很重要 - 一旦经济复苏，你可能需要转换工作或团队。与一大堆不喜欢更新知识和做法的坏程序员混在一起会使你自己的编程技巧变得迟钝，并削弱你的市场竞争力。
答案 2 :(得分：12)
如果您是初级开发人员，那么您唯一能做的就是尽可能优雅地编写代码。
如果你的风格确实更好，其他人可能会注意到并说“嘿，我们应该采用这个公式”
行动胜于抱怨，这是我注意到的。
答案 3 :(得分：9)
现在体现在Hexagram 47 - K'un（压迫）：尽管疲惫不堪，但可能还有进步和成功。对于坚定和正确，真正伟大的人，将会有好运。他不会犯任何错误。 如果他发言，他的话语就不能很好。
未来体现在六芒星6 - 宋（冲突）：虽然在一个人的争论中有诚意，但他仍会遇到反对和阻挠。如果他怀有谨慎的谨慎，那将会有好运。如果他起诉争夺痛苦的结局，就会有邪恶。看到伟人是有利的。穿越大河是没有利的。
答案 4 :(得分：7)
之前我穿的是同样的鞋子。我被聘为C ++程序员，以“引导团队”如何由热心的经理使用C ++。那是大约十年前的事了。一些较新的工程师爱我，老人们鄙视我。我们的系统基本上是一个伪C ++系统。这就像C和类一样，但似乎人们甚至不了解构造函数之类的有用性，因为它们几乎不会出现。
你抱怨长达3页的功能;我们有8000行长的函数，包括长跳，函数指针转换等。其中一个老人甚至用2空格缩进格式化代码，这样就可以在不使用太多水平空间的情况下编写超深嵌套块，因为前辈似乎一般来说，对写作函数和程序编程过敏。有人甚至将2000线功能概述为可以使事情变得更快。你可能正在处理一些不好的代码，但我正在处理可以想象的最可怕的复制和粘贴代码。
不幸的是，我很年轻，自大。我与前辈不相处，我在代码的领土争斗中与他们作战。他们通过创建编码标准做出了回应，而C ++程序员无法遵循这些标准（例如：可以使用operator new，但不要使用异常处理，不要使用构造函数或析构函数等）。因此，我编写了最奇怪和最愚蠢的标准 - 解决方案C ++代码只是为了反对那些标准，因为我拒绝编写C风格的代码，因为我被雇用的原因（我没有那么讨厌C，但写作C代码不是工作描述的一部分：我基本上被聘用为C ++顾问），尽管标准使C风格编码成为唯一可行的实用方法。我只保留了我的工作，因为我加入了很多加班工作，以确保我的代码尽管有这些荒谬的编码标准，仍能很好地工作。
直到几年后，当其他人开始以我的方式看待事物时，我们提升了愚蠢的标准并开始编写更自然，易于阅读的C ++代码，完成STL并提升好东西，RAII，异常处理，那些拒绝以更加理智的方式编写代码的老年人，他们最终被迫适应。
回想起来，我本可以做得更好。老年人不打算让我被安排到教学岗位，但我想我会低下头来更快地得到我的观点。我最大的遗憾是试图叛逆地解决不可能的编码标准，而不是通过明确和理性的讨论来纠正它们。结果，我在系统中真的很愚蠢和混淆了C ++代码，人们把它归于我，即使这不是我通常编写C ++代码的方式。我工作的常规开发人员理解这一点，但老年人仍然指出它为什么C ++是坏的一个例子。
简而言之，我建议你专注于结交更多朋友而不是敌人。你的朋友会支持你，如果你的方式更好，你可以清楚地证明它，你就可以隔绝那些永远不会同意的人。
答案 5 :(得分：6)
热衷于以正确的方式编写代码是一个很好的特性，在软件行业中，我们总会遇到其他开发人员，他们编写的代码与我们的“完美编码方式”不完全一致。这永远不应该被解释为 rubbish 代码或 inept 编码器，因为我们都是以某种形式或形式开始的。
始终尊重您周围的同伴，因为您希望他们尊重您。在一个高度关注自我的环境中做这当然不容易，但试图接近这样的话题绝非易事。
这是您的沟通方式
尝试不同的方法角度，记住你在那里学习和渲染服务一样多。
因此，在“面对面”的方法中评论“差”代码风格可能不是您正在寻找的结果。所以然后稍微备份并尝试使用“我正在考虑使用的代码风格并提出一些建议......”来查看主题并查看给出的差异。
我现在工作的地方，我学到的一件事就是可以评论质量可能不高的东西，但最好能有更好的解决方案。
换句话说，准备好用有用的解决方案备份你的话，而不是因为你感觉如此。
答案 6 :(得分：3)
这是建立编码标准和代码审查流程是个好主意的最基本原因。
无论编码标准和流程是什么，我都不会写三页功能，但有些人会这样做。它们将在开头创建20个局部变量，而不会初始化任何变量。你将有指向未指定值的指针和整数。您不会知道每个变量的确切含义和范围。等等。
尝试用坚实的论据说服你的经理以及后来的团队。也许你可以从有效C ++或C++ Coding Standards的共享阅读开始。试着强调一点，当以这种方式工作并创建更好的代码时，每个人都会获胜。如果他们认为这是一个双赢的局面，他们将对变革更加开放。
答案 7 :(得分：3)
我可以同情。
我低于两位有着非常独特风格的高级程序员，我感到很沮丧。我们的代码包含一个1000行长的主函数。 （这不是一个错字。）我们的编码标准不鼓励全局，所以我们使每个程序都成为一个App对象。现在我们的全局变量是成员变量！当我们需要C ++类的迭代接口时，为什么我们应该在begin，end和{operator++时使用First，AtLast和Next约定可以使用{1}}代替。我们已经在自定义界面中包装了第三方库，这是没有充分理由的。 （我们无缘无故地包装了log4cxx和丢失的功能，我们的一个日期类包含一个指向boost :: date对象的共享指针，只有一小部分功能。）
这就是我如何保持理智。我专注于新的语言和工具。这是我们公司的第一个涉及Python的项目，我花了很多时间在那里编写实用程序和程序。虽然高级程序员用他们熟悉的代码编写代码，但我几乎可以自由地使用所有Python代码。我无法忍受我们使用的C ++ API，因此我以更加友好的方式复制了Python中的大部分相同功能，而其他开发人员也更喜欢它。
同样地，我们对log4cxx并不熟悉boost-build，这两方面我都花时间深入研究并且知道人们有问题来找我。我在wiki上写了一些资源，给出了log4cxx和numpy以及其他工具的使用技巧。
答案 8 :(得分：2)
就是这样，习惯它或退出并找到一个不那样的地方。如果你批评他们的努力，你将被边缘化，如果你确实编写了自己的，更好的代码或改进他们的代码，他们可能会感到受到威胁。在一天结束时，他们提供代码和管理，看到一个有效的黑匣子，这一切都很重要。另外，你将成为另一个大学生，他认为自己对某个企业的发展有所了解，并且在不在身边时会被嘲笑和排斥。老实说，很多时候这些系统都是这样构建的，因为需求不稳定，随着时间和管理的不断增加，许多功能都缺乏对稳定软件开发过程的尊重。
并非所有公司都是这样的。说实话，我会开始寻找新工作。
答案 9 :(得分：2)
我热切地希望，这是面对挑战的最佳成长机会。正如罗伯特所说，试着以身作则。如果可能的话，让他们采用你的模式。
答案 10 :(得分：1)
你并不孤单。我最近也面临过，幸运的是我们得到了高级管理层对代码评审的支持。 1.即使是针对Bug修复的单行更改也应在线查看。
对代码的评论可分为CodingStandard / Suggestion / Clarification / Major / Minor等
在向老年人发表评论时，您可以从Clarification / CodingStandard开始，而不是主要
答案 11 :(得分：1)
你可以通过编写大量的单元测试来解决“我们害怕触及它而害怕破坏它”的问题。一旦你完成了单元测试，你就可以随意自由重构。如果你的单元测试在重构后仍然通过，你可以确信你没有破坏任何东西。
答案 12 :(得分：1)
只需在办公室的某处放置一份“清洁代码”（Martin），“重构：改进现有代码的设计”（Fowler）或“Effective C ++”，人们可以开始浏览这些书籍。从现在开始，这个词将会传播开来。说真的，它永远不会太晚学习！ ;）