如何说服编程团队放弃旧方法？
这更像是一个面向业务的编程问题，我似乎不知道如何解决。 我和一个程序员团队一起工作，他们使用 BASIC 已经有 20 多年了。 我被请来帮助在 .NET 中编写相同的软件，只是进行了更新和现代实践。 问题是我似乎无法让其他 3 名团队成员（所有 BASIC 程序员，尽管现在也有 .NET）了解如何正确创建关系数据库。 他们不会理解的是：
我们基本上有一个跟踪客户标签信息的交易。 我们需要能够跟踪当前交易和过去的交易。 在旧系统中，使用平面文件数据库，其中一个表包含客户当前基本交易的记录，另一个表包含客户之前的所有交易以及重要的资金信息。 为了防止冗余，他们会用历史交易覆盖当前交易 - （历史文件首先更新，然后是当前的。）这是完全没有必要的，因为你只需要一个交易表，但我的主管或我的其他两个同事中的任何一个-工人们似乎无法理解这一点。 我究竟该如何说服他们看到光明，这样我们就不必做大量荒谬的工作并最终多次访问数据表？ 感谢您的投入！
This is more of a business-oriented programming question that I can't seem to figure out how to resolve. I work with a team of programmers who have been working with BASIC for over 20 years. I was brought in to help write the same software in .NET, only with updates and modern practices. The problem is that I can't seem to get any of the other 3 team members(all BASIC programmers, though one does .NET now as well) to understand how to correctly do a relational database. Here's the thing they won't understand:
We basically have a transaction that keeps track of a customer's tag information. We need to be able to track current transactions and past transactions. In the old system, a flat-file database was used that had one table that contained records with the basic current transaction of the customer, and another transaction that contained all the previous transactions of the customer along with important money information. To prevent redundancy, they would overwrite the current transaction with the history transactions-(the history file was updated first, then the current one.) It's totally unneccessary since you only need one transaction table, but my supervisor or any of my other two co-workers can't seem to understand this. How exactly can I convince them to see the light so that we won't have to do ridiculous amounts of work and end up hitting the datatabse too many times? Thanks for the input!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
首先，我必须承认，根据您的描述，我并不完全清楚现有结构中的数据结构和逻辑流实际上是什么。 对我来说，这确实意味着您可能也没有向同事明确说明自己的情况，因此您的首要任务之一必须是能够以口头方式或最好以书面和图表的方式解释当前情况和拟议的替代方案。 请将此视为一种观察，而不是对您的问题的任何批评。
其次，我确实发现有 20 年经验的程序员不理解关系数据库和事务是很值得注意的。 平面文件编码很久以前就不再成为主流了——我第一次在商业环境中处理关系数据库是在 1988 年，它们在 90 年代中期已经相当普遍了。 您从事什么行业和产品类型？ 在我看来，您可能正在处理某种嵌入式或其他“不寻常”的系统，在这种情况下，您确实需要确保您没有某种通信问题，并且您正在忽略一头大大象没有人向您指出这一点 - 您不会是第一个被带入团队的“顾问”，该团队是在没有获得适当信息的情况下以某种方式建立的。 也就是说，这种古老的商店确实仍然存在 - 我当前的一个客户系统与用 COBOL 编码的基于平面文件的系统接口，是的，管理起来很困难;-)
最后，如果你完全确定自己的立场并且你面对一个不会接受你的建议的团队 - 如果你能抽出时间，演示代码是一个好主意 - 那么你可能不得不优雅地接受这个决定并移动一个。 我自己在这个位置上会尝试抽象出这个问题 - 例如，数据库更新是否可以移动到存储过程中，以便更新两个表的代码位于 SP 中，并且可以在以后进行修改以移动到您的架构中，而无需相应的应用变化？ 确保您的论点被充分记录并记录下来，以便您以后有机会时可以重新审视它们。
您不会是第一个因为办公室政治而不得不实施次优解决方案的编码员 - 将其作为您个人发展的学习经验，以处理此类情况，并为自己获得额外报酬而感到同情工作。 通常，此类争论中的决定性因素不是逻辑，而是你自己带来的“声誉权重”——听起来你对你的团队没有太多这种影响力，所以你在您在后续案例中获得足够的声誉之前，可能必须通过出色地执行他们同意做的事情来努力获得声誉 - 您需要首先进行改装！
Firstly I must admit it's not absolutely clear to me from your description what the data structures and logic flows in the existing structures actually are. This does imply to me that perhaps you are not making yourself clear to your co-workers either, so one of your priorities must be to be able explain, either verbally or preferably in writing and diagrams, the current situation and the proposed replacement. Please take this as an observation rather than any criticism of your question.
Secondly I do find it quite remarkable that programmers of 20 years experience do not understand relational databases and transactions. Flat file coding went out of the mainstream a very long time ago - I first handled relational databases in a commercial setting back in 1988 and they were pretty commonplace by the mid-90s. What sector and product type are you working on? It sounds possible to me that you might be dealing with some sort of embedded or otherwise 'unusual' system, in which case you do need to make sure that you don't have some sort of communication issue and you're overlooking a large elephant that hasn't been pointed out to you - you wouldn't be the first 'consultant' brought into a team who has been set up in some manner by not being fed the appropriate information. That said such archaic shops do still exist - one of my current clients systems interfaces to a flat-file based system coded in COBOL, and yes, it is hell to manage ;-)
Finally, if you are completely sure of your ground and you are faced with a team who won't take on board your recommendations - and demonstration code is a good idea if you can spare the time -then you'll probably have to accept the decision gracefully and move one. Myself in this position I would attempt to abstract out the issue - can the database updates be moved into stored procedures for example so the code to update both tables is in the SP and can be modified at a later date to move to your schema without a corresponding application change? Make sure your arguments are well documented and recorded so you can revisit them later should the opportunity arise.
You will not be the first coder who's had to implement a sub-optimal solution because of office politics - use it as a learning experience for your own personal development about handling such situations and commiserate yourself with the thought you'll get paid for the additional work. Often the deciding factor in such arguments is not the logic, but the 'weight of reputation' you yourself bring to the table - it sounds like having been brought in you don't have much of that sort of leverage with your team, so you may have to work on gaining a reputation by exceling at implementing what they do agree to do before you have sufficient reputation in subsequent cases - you need to be modded up first!
有时你不能。
如果您读过一些 XP 书籍，他们经常会说您最大的障碍之一是说服您的团队放弃他们一直在做的事情。
一般来说，他们会建议让不能适应的人去其他项目（或者干脆让他们走）。
代码审查可能对您的情况有所帮助。 对每一行代码进行强制代码审查并非闻所未闻。
Sometimes you can't.
If you read some XP books, they often say that one of your biggest hurdles will be convincing your team to abandon what they have always done.
Generally they will recommend letting people who can't adapt go to other projects (Or just letting them go).
Code reviews might help in your case. Mandatory code reviews of every line of code is not unheard of.
有时最好的论据就是一个例子。 我会编写一个原型（或者如果工作量不大的话可以替换）。 通过一个例子来检查将更容易看出关系数据库的优缺点。
顺便说一句，平面文件数据库有其一席之地，因为它们比真正的关系数据库更容易“管理”。 保持开放的心态。 ;-)
Sometime the best argument is an example. I'd write a prototype (or a replacement if not too much work). With an example to examine it will be easier to see the pros and cons of a relational database.
As an aside, flat-file databases have their places since they are so much easier to "administer" than a true relational database. Keep an open mind. ;-)
我认为你可能必须以身作则——当人们看到“新”方式工作量更少时，他们就会采用它（只要你不对此嗤之以鼻）。
我还会问自己，旧的设计是否真的造成了问题，或者只是在美观上令人讨厌。 选择你的战斗很重要 - 如果旧的设计不会导致性能问题或使系统难以维护，你可能会想放弃旧的设计。
最后，如果您确实保留旧设计，请尝试抽象新代码和旧数据库之间的接口，这样，如果您确实说服同事稍后改进设计，则可以将新模式放入而无需更改还要别的吗。
I think you may have to lead by example - when people see that the "new" way is less work they will adopt it (as long as you don't rub their noses in it).
I would also ask yourself whether the old design is actually causing a problem or whether it is just aesthetically annoying. It's important to pick your battles - if the old design isn't causing a performance problem or making the system hard to maintain you may want to leave the old design alone.
Finally, if you do leave the old design in place, try and abstract the interface between your new code and the old database so if you do persuade your co-workers to improve the design later you can drop the new schema in without having to change anything else.
除了从原始问题中普遍感到沮丧之外，很难提取出全部内容。
是的，随着时间的推移，长期积累的许多技术和习惯可能毫无用处，甚至随着技术的变化而付出高昂的代价。 当处理能力、内存甚至磁盘都很昂贵时，一些有意义的事情现在可能是愚蠢的优化尝试。 人们也很可能随着时间的推移积累坏习惯和坏编程模式。
不过你必须小心。
有时，那些老前辈所做的事情是有充分理由的。 可悲的是，他们甚至可能无法用语言表达“为什么”——即使他们知道为什么。
当新手进入企业软件开发商店时，我看到很多这种挫败感。 即使环境都是相当现代的技术和工具，情况也可能很糟糕。 如果您的大部分经验都是编写小型社区桌面和 Web 应用程序，那么您“知道”的很多内容可能都是错误的。
通常，事务日志的要求高于 DBMS 的要求。 很多时候，为了确保时间序列正确性、一次且仅一次更新、弹性和不可否认性，可能有必要超越数据库事务语义。
这甚至还没有开始解决企业或企业间可扩展性所涉及的问题。 当您开始每天处理 50 万个复杂事务时，您会发现 RDBMS 技术让您失望。 由于关系数据库并不是为处理高事务量而设计的，因此您必须经常打破规范化和更新的标准范例。 无论您使用多少硬件来解决问题，传统的 RDBMS 锁定技术都会破坏可扩展性。
人们很容易将所有这些视为古板或普遍的错误头脑——甚至是无能。 但要小心，因为情况并非总是如此。
顺便说一句：除了 RDBMS 之外还有其他模型，并且 RDBMS 的替代品不一定是“平面文件”——这与当今大多数编码人员的经验相反。 事务性分层 DBMS 可以处理比 RDBMS 高得多的吞吐量。 例如，IMS 在大型 IBM 商店中仍然非常活跃。 其他供应商为不同平台提供类似的软件。
当然，在一家 4 人店里，这些可能都不适用。
It is difficult to extract a whole lot except general frustration from the original question.
Yes, there are a lot of techniques and habits long-timers pick up over time that can be useless and even costly in light of technology changes. Some things that made sense when processing power, memory, and even disk was expensive can be foolish attempts at optimization now. It is also very much the case that people accumulate bad habits and bad programming patterns over time.
You have to be careful though.
Sometimes there are good reasons for the things those old timers do. Sadly, they may not even be able to verbalize the "why" - if they even know why anymore.
I see a lot of this sort of frustration when newbies come into an enterprise software development shop. It can be bad even when the environment is all fairly modern technology and tools. If most of your experience is in writing small-community desktop and Web applications a lot of what you "know" may be wrong.
Often there are requirements for transaction journaling at a level above what your DBMS may do. Quite often it can be necessary to go beyond DB transaction semantics in order to ensure time-sequence correctness, once and only once updating, resiliancy, and non-repudiation.
And this doesn't even begin to address the issues involved in enterprise or inter-enterprise scalability. When you begin to approach half a million complex transactions a day you will find that RDBMS technology fails you. Because relational databases are not designed to handle high transaction volumes you must often break with standard paradigms for normalization and updating. Conventional RDBMS locking techniques can destroy scalability no matter how much hardware you throw at the problem.
It is easy to dismiss all of it as stodginess or general wrong-headedness - even incompetence. But be careful because this isn't always the case.
And by the way: There are other models besides the RDBMS, and the alternative to an RDBMS is not necessarily "flat files" - contrary to the experience of of most coders today. There are transactional hierarchical DBMSs that can handle much higher throughput than an RDBMS. IMS is still very much alive in large IBM shops, for example. Other vendors offer similar software for different platforms.
Of course in a 4-man shop maybe none of this applies.
为他们报名参加一些像样的培训，然后你就可以让他们相信，有了新技术，更多的事情是可能的（或者至少更容易！）。
但我认为这里最重要的是专业的、经过认证的培训师首先教他们基础知识。 他们会对这一点印象更深刻，而不是只有一位同事告诉他们：“嘿，为什么不使用这个呢？”
相关帖子
Sign them up for some decent trainings and then it's up to you to convince them that with new technologies a lot more is possible (or at least easier!).
But I think the most important thing here is that professional, certified trainers teach them the basics first. They will be more impressed by that instead of just one of their colleagues telling them: "hey, why not use this?"
Related post here.
以下内容可能不适用于您的情况，但您很少提及技术细节，所以我想我会提到它...
有时，如果当前数据的访问模式与历史数据的访问模式非常不同（我是举个例子，假设当前数据每秒被访问 1000 次，并且访问一小部分列，并且所有当前数据都小于 1 GB，而历史数据则使用 1000 GB 进行访问每天只有 100 次，并且可以访问所有列），
那么，您的同事正在做的事情对于性能优化来说是非常有意义的。 通过分离当前数据（尽管是冗余的），您可以优化该表中的索引和数据结构，以实现在历史表中无法实现的更高频率的访问模式。
从纯粹关系的角度来看，并非所有“学术上”或“技术上”正确的东西在应用于实际情况时都有意义。
The following may not apply in yr situation, but you make very little mention of technical details, so I thought I'd mention it...
Sometimes, if the access patterns are very different for current data than for historical data (I'm making this example up, but say that Current data is accessed 1000s of times per second, and accesses a small subset of columns, and all current data fits in less than 1 GB, whereas, say, historical data uses 1000s of GBs, is accessed only 100s of times per day, and access is to all columns),
then, what your co-workers are doing would make perfect sense, for performance optimization. By separating the current data (albiet redundantly) you can optimize the indices and data structures in that table, for the higher frequency access paterns that you could not do in the historical table.
Not everything that is "academically", or "technically" correct from a purely relational perspective makes sense when applied in an actual practical situation.