将快速开发与重构/优化分开
我在一个由 2 名前端开发人员组成的团队中工作，负责一个基于网络的后期启动项目。
该网站运行得很好，但在代码方面还有很大的改进空间，因为代码相当混乱和无序。
我想通过编写测试和仔细重构来逐渐清理事情，以避免破坏任何东西。 （使用《有效处理遗留代码》一书中的原则）
但是，与我一起工作的开发人员被赋予了很多高优先级的功能工作，我不想让他承担维护任务的负担。很多时候，他只是因为时间限制而不得不编写混乱的代码。
随着团队的成长，我关心如何管理不同的问题。
我正在考虑将团队分为两组：
- 快速开发新功能，不太关心代码质量。
- 编写单元测试，重构代码，通常进行优化。
我的目标是测试尽可能多的代码，同时仍然跟上新功能开发的步伐。
以前尝试过吗？有什么想法吗？
I'm working in a team of 2 front-end developers on a web-based late-stage startup project.
The site works quite well, but there's a lot of room for improvement code-wise, as the code is quite messy and disorganized.
I would like to clean things up gradually by writing tests and carefully refactoring to avoid breaking anything. (Using principles from the book 'Working Effectively with Legacy Code')
However, the developer I'm working with is being given a lot of high-priority feature work, and I don't want to burden him with maintenance tasks. A lot of the time he has to write messy code simply because of the time-constraints.
As the team grows I'm concerned about how to manage the different concerns.
I'm thinking of dividing the team into 2 groups:
- Does rapid development on new features, with less care on code quality.
- Writes unit tests, refactors code, generally optimizes things.
The result I'm aiming for is to bring as much of the code under test as possible, while still keeping up the pace of new-feature development.
Has this been tried before? Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
团队划分有问题。
快速开发新功能的团队将非常受销售人员和管理层的欢迎。他们将被认为更有成效、更注重解决方案，并且将参与更多重要的讨论。
担心质量的群体会被视为代价高昂、消极、效率低下、以问题为导向的抱怨者。
事实是，快速集团的“轻松获胜”会积累低质量的隐性成本。如果这种情况持续太久，代码将变得越来越混乱，因为新的快速代码建立在旧的快速代码之上，并且添加更多功能将变得越来越耗时和危险。当没有人可以再添加任何新功能时，这些隐藏成本就变得显而易见。
想想两年后的路。您的快速编码员可能会继续前进，从他们的许多“成功”中获利。销售人员将谈论他们，以及他们经营商店时是多么轻松。
就像花园里的杂草一样。尽早解决问题很容易，但当问题都杂草丛生时就困难得多。
工程现实是快速编码不应该是混乱的。把事情搞得乱七八糟并不能节省时间。如果看起来是这样，要么是技能问题，要么是框架问题。
因此，如果您划分组，请在每次迭代后旋转！
我怎么知道这个场景？我是在“成功”的程序员离开后才进来的……
There is a problem with dividing the team.
The group doing the rapid development of new features will be very popular with the sales force, and the management. They will be perceived as more productive, more solution-oriented and they will be included in more of the important discussions.
The group worrying about the quality will be perceived as costly, negative, unproductive, problem-oriented whiners.
The bean-counter reality of it is that the "easy wins" of the rapid group accumulates hidden costs of poor quality. If this goes on too long the code will become more and more messy as new rapid code builds on old rapid code and it will become more and more time-consuming and risky to add more features. Those hidden costs becomes visible when no one can add any new features anymore.
Think two years down the road. Your rapid coders will probably have moved on, cashing in on their many "successes". The sales force will be talking about them, and how easy it was when they were running the shop.
It's like weed in a garden. It's easy to solve the problem early, much harder when it's all weeds.
The engineering reality of it is that rapid coding shouldn't be messy. You don't save time by doing things messy. If it looks that way, there is either a skill problem or a framework problem.
So if you divide the group, rotate after every iteration!
And how do I know this, scenario so well? I came in after the "successful" coders had left...
你好，我认为你不能将团队分成两组。
@古格
涵盖了对这些团体成员的财务和政治影响。
还有更多：
1）速度组不会关心代码的质量。（他们不会为此付费！！）所以他们会产生丑陋的代码。
2）质量小组将重写一些代码以使其更好。速度组将向此代码添加一些新功能，并且代码将再次变得丑陋。
3）速度组即将添加新功能。未重构的代码。他们不进行重构（他们没有为此付费，因此如果他们这样做或工作速度变慢，管理层可能会生气），因此他们会以比先重构时更低的速度创建丑陋的^2代码。
4）没有新功能。意味着没有$$$ 意味着更少的工资意味着更差的开发人员分配意味着更低的速度和质量。
5) 更好的开发人员会找到一种方法来改变组速度或改变工作:)
5) 如果质量组将提高任何子系统速度组可能会拒绝对现有代码实施任何补丁，以免减慢速度。
好的，那么如何防止这种情况发生呢？
与您的管理层交谈，您需要在新功能之间保持平衡。和代码质量。只有好的代码才能引入快速更改或实现新功能。高速行驶。
好的论据是，编写糟糕的代码或架构演变成丑陋的东西是一种债务。当您不支付时，每月利息会迅速增长。您可能可以承受一个月不付款的情况，但不能承受更长的时间。
您可以随身携带信用卡以强调。
也许如果你的团队有太多工作要做，无法在截止日期前完成，那么大声说出来总是值得的。但要小心；）
所有程序员都应该重构并编写睾丸（如果相关）。也不例外。
今天重构一点，明天重构一点，等等。
信用卡技巧借鉴自福勒的“重构”<-伟大的书。
PS 有一些项目，比如“死亡行军”，只推动硬开发。具有经济意义（因为只有在费用有限的情况下在最后期限内取得成功，项目才会赚钱；症状是持续工作数小时，开发人员数量少于所需），我的建议不适用于它
Hi I think You Can not dive team into two groups.
@Guge
Have covered financial and political impact on members of those groups.
And there are more:
1) Speed group will not care about quality of code.(They wont be paid for it!!) So they will produce ugly code.
2) Quality group will rewrite some code to be better. Speed group will add to this code some new functionality and again code will be ugly.
3) Speed group is about to add new func. to code that was not refactored. They do no refactors (they are not paid for it so management may be anger if they do, or if they work slow down) so they will create ugly^2 code at lower speed than if they refactor first.
4) No new func. mean no $$$ mean smaller wages mean worse developers assigned mean lower speed and quality.
5) Better devs will find a way to change goup to speed or a way to change work :)
5) If quality group will improve any subsytem speed group may deny implementing any patches to existing code to not slow down.
Ok So what to do to prevent such situation?
Talk with your managment, You need to maintaing balance betwen new func. and quality of code. Only good code allow to introduce fast changes or implementing new func. at high speed.
Good argument is that badly written code or architecture that evolved into something ugly is a debt. When you wont pay it monthly interest grow rapidly. You can afford to not paid one month probably but not longer.
You can get you credit card with you to emphasize.
And maybe if your team get too much work to do it in deadline it is always worth to speak it loudly. But carefully ;)
And all programmers should refactor and write testes (if relevant). No exception.
Just refactor a bit today a bit tommorow etc.
Trick with credit card is borroved from Fowler "Refactoring" <- great book.
PS there are projects like "death march" where only pushing hard dev. make economic sense (because project will make money only if success in deadline with limited expenses; symptoms are constants work over hours with less dev than required) and my suggestions don't apply to it
我认为短期内，你投入一些人来进行新的开发，一些人来清理新的代码，这不是问题。然而，将这种模式保持为一种持续的模式是有缺陷的。您的目标应该是按时并以高标准交付代码，并且您的整个团队都应该朝着这个目标努力，如果您拆分团队，那么您将有一半的团队编写令人兴奋的新功能，而不关心代码质量，另一半则跟在他们后面清理。随着时间的推移，您可能会发现清理团队需要比新功能团队大得多。
您的第一步（您似乎已经取得了一些进展）是决定您的代码的质量以及如何衡量它（测试覆盖率、圈复杂度等）。然后，您可以将这些指标应用于当前的代码，并了解其中有多少不符合标准。该代码是已产生需要偿还的“技术债务”的代码。
接下来要做的就是偿还这笔技术债。这涉及使该代码符合您制定的标准。如果必须经常完成，那么这是一项乏味的任务，但是它需要完成，并且需要由任何有空的人来完成。
最后，将生成符合您的质量指标的代码作为您的主要目标。如果出现截止日期，那么您可能不得不暂时忽略它们，但是一旦达到截止日期，您的首要任务就是让代码恢复到您需要的质量。
I think that in the short term its not a problem for you to devote some people to new development, and some people to cleaning up the new code. However to keep this as an ongoing pattern is flawed. Your aim should be to get code delivered on time and to a high standard and your entire team should be working toward this goal, If you split the team then you have one half of the team writing exciting new features with no concern for code quality, and the other half cleaning up after them. Over time you may find that the cleanup team needs to be significantly bigger than the new features team.
Your first step (which you seem to have made some progress with) is to decide on what sort of quality your code is and how it is going to be measured (test coverage, cyclomatic complexity etc). You can then apply these metrics to your current code and understand how much of it doesn't come up to standard. This code is the code that has accrued 'Technical Debt' which needs repaying.
The next thing to do is to repay this technical debt. This involves bringing this code in line with the standards that you have put in place. This is a tedious task if it has to be done often, however it needs to be done, and to be done by anyone who is free to do it.
Finally make it your main goal to produce code that is in line with your quality measures. If a deadline shows up then you may have to ignore them for a while but once the deadline is met your priority is to get your code back up to the quality you need.