blocks|key|4861523|text|过早的泛化是我的大麻烦；我不是先解决手头的问题，然后等到有实际需要解决一般情况时，我总是先研究一般情况，最后编写一堆比它所需要的更复杂的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4861524|更新：|4861525|有关深度描述，请参见"Sin+#1+-过早泛化“。|offset|length|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/b/ericgu/archive/2006/08/03/687962.aspx^0|0|0|B|C|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@$F|R|G|S|1|T]]|A|$]]]|H|$I|$5|J|K|L|A|$M|N]]]]

Premature generalization is my big bugaboo; instead of solving the problem at hand first and waiting until there's an actual need to solve for the general case, I always go after the general case up front and wind up writing a ton of code that's more complex than it needs to be. 

Update:

See "<a href="http://blogs.msdn.com/b/ericgu/archive/2006/08/03/687962.aspx">Sin #1 - Premature Generalization</a>" for an in depth descripztion.

blocks|key|4860820|text|“我们以后再来解决这个问题。我们现在就需要它工作！”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

"We will come back to this and fix it later. We just need it working now!"

blocks|key|4860913|text|最后期限太远了，我有足够的时间去做，为什么不花点时间上网呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

The deadline is soooooo far away, I have more than enough time to do it, so why not spend a little time surfing the web?

blocks|key|4860838|text|“这只是一种丢弃的概念代码。一旦他们喜欢，我就会把它做好的。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

"This is just throw-away proof-of-concept code. Once they like it, I'll really make it good."

blocks|key|4861012|text|在发布前几天重构部分代码。|type|ordered-list-item|depth|inlineStyleRanges|entityRanges|data|4861013|互联网:最大的干扰。|4861014|新技术:不能让我的手远离新技术。|4861015|优化:优化，优化。。。以及更多的优化|4861016|完美:从来不满足于代码。|4861017|TODO:没有时间去做永远做不到的事情。|4861018|时间估计:许多PM不认为这是“估计”。他们视事实为事实。|4861019|承诺:承诺太多了。|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|W|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|X|8|@]|9|@]|A|$]]]|P|$]]

<ol>
<li>Refactoring part of the code a few day before the release.</li>
<li>Internet: The biggest distraction of all.</li>
<li>New technology: Can't keep my hands off new technology.</li>
<li>Optimize: Optimize, Optimize. .. and more Optimize</li>
<li>Perfection: Never been satisfied with the code.</li>
<li>TODO: Lack of time todos that never will be done.</li>
<li>Time estimation: Many PMs doesn't take this as "estimate". They take as fact.</li>
<li>Promises: Giving too many promises.</li>
</ol>

blocks|key|4860929|text|当有现有的框架和库的时候，尝试构建内部的一切成为牺牲品。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Falling prey to trying to build everything in-house, when there are existing frameworks and libraries.

blocks|key|4860854|text|我反复出现的恶魔:过早优化和过度设计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4860855|但我还是不能百分之百地避开他们..。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

My recurrent demons: Premature optimization and overengineering.

And I still can't avoid them 100%...

blocks|key|4861474|text|过度乐观地估计|type|header-two|depth|inlineStyleRanges|entityRanges|data|4861475|当你的经理盯着你看的时候，你感觉到了一种强烈的感觉，那就是给出比你直觉告诉你的更低的估计。别这么做！|unstyled|4861476|毕竟，你的直觉是可能已经太低了！|offset|length|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Hofstadter%2527s_law^0|0|0|8|8|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Q|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|R|8|@]|9|@$G|S|H|T|1|U]]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

<h2>Overly optimistic estimates</h2>
When your manager is staring you down, and you feel the burning feeling to give a lower estimate than your gut is telling you... don't do it!
After all, your gut is <a href="http://en.wikipedia.org/wiki/Hofstadter%27s_law" rel="noreferrer">probably too low already!</a>

blocks|key|1119041|text|在您的项目中使用一种技术/工具/语言纯粹是因为您刚刚学会了它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1119042|试图证明你是一个多么优秀的开发人员。|1119043|考虑你写的代码是属于你的。|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|I|8|@]|9|@]|A|$]]]|F|$]]

To use a technology/tool/language in your project purely because you had just learned it.

To try to prove how good a developer you are.

To consider code you've written to be yours.

blocks|key|4861370|text|我先休息一下，看看stackoverflow.com+;)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

I'll just take a break and look at stackoverflow.com ;)

blocks|key|1118914|text|最糟糕的诱惑是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1118915|哦，好吧..。我想一个肮脏的小把戏/黑客/修复不会有什么害处。|blockquote|1118916|你猜怎么着，确实很疼。:)|1118917|📷|atomic|offset|length|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://imgs.xkcd.com/comics/goto.png|imageAlt^0|0|0|0|0|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|U|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|V|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|W|8|@]|9|@$J|X|K|Y|1|Z]]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R|S|-4]]]]

The very worst temptation:

<blockquote>
 <blockquote>
 Oh, well.. I guess one dirty little trick/hack/fix isn't gonna hurt.
 </blockquote>
</blockquote>

Guess what, it does hurt. :)

<a href="http://xkcd.com/292/" rel="nofollow noreferrer" title="Neal Stephenson thinks it's cute to name his labels 'dengo'"><img src="https://imgs.xkcd.com/comics/goto.png" alt="goto"/></a>

blocks|key|1119489|text|忘了那个编写代码是解决问题的最后手段。。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|entityMap|0|LINK|mutability|MUTABLE|url|http://teddziuba.com/2010/12/the-3-basic-tools-of-systems-engineering.html^0|4|F|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@$A|L|B|M|1|N]]|C|$]]]|D|$E|$5|F|G|H|C|$I|J]]]]

Forgetting that <a href="http://teddziuba.com/2010/12/the-3-basic-tools-of-systems-engineering.html" rel="nofollow">writing code is the last resort for solving a problem</a>.

blocks|key|4861755|text|特征蠕变|type|header-two|depth|inlineStyleRanges|entityRanges|data|4861756|制定一个计划，坚持下去，然后部署。然后回去把人们想要的东西加进去。|unstyled|4861757|我一遍又一遍地看到这件事。你坐下来，制定设计，然后开始编码。用户听到一些混乱的废话，他们最喜欢的功能是“失踪”，他们开始游说它。你的老板要求你在最后一刻添加它，它会污染部署，它到处都会引入bug，3个月后，一旦每个人都安定下来，你就被要求删除它，因为没有人能弄清楚你为什么把这个蹩脚的复古功能放在第一位！你看不出其余的设计都是毫无意义的吗？|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|J|8|@]|9|@]|A|$]]]|G|$]]

<h2>Feature Creep</h2>

Make a plan, stick to it, and deploy. And then go back and add the stuff that people are asking for.

I have seen this over and over. You sit down, work out the design, and start coding. The users hear some confused nonsense about their favorite feature being "missing" and they start lobbying for it. Your boss demands that you add it at the 11th hour, it fouls the deployment, it introduces bugs everywhere, and 3 months later, once everyone has settled down, you're asked to remove it, because no one can figure out why you put that crappy retro feature in in the first place! Couldn't you tell that the rest of the design made it pointless?

blocks|key|1119407|text|添加更多功能|type|ordered-list-item|depth|inlineStyleRanges|entityRanges|data|1119408|比赛有这样的特点。因此，这是一个必须具备的特性，因此比分析策略、定位等更多的编程。|1119409|竞争对手没有这个特点。因此，这是一个不同的特点，因此更多的编程，而不是分析战略，定位等。|1119410|用更多的编程来解决业务问题。更好的管理您的网站托管的linux服务器的专业知识无法通过编程获得更多的功能。有时，您只需要学习如何解决问题，而不是将整件事情重新编码为C#.Net。|1119411|用更多的程序来解决营销问题。滥用赛斯戈丁的紫色奶牛的概念，你间接地解决了一个营销问题，在你的产品中规划更多的功能，使它成为“紫色奶牛”。有时候，它只是一个变种人的怪物。|1119412|用更多的编程来解决生产力问题，自己认为编写这个脚本所花费的时间将在未来几个小时内节省下来，而不是实际编写真正重要的东西。|1119413|计划编码，但还没有编码，因为你想“做对”|1119414|编写一个肮脏的版本，并承诺你将“以后做得更好”，但再也不回去“让它变得更好”。|1119415|不做模拟或站点地图，因为它是“太麻烦”。我只需截图竞争对手的网页模型和徒手绘制站点地图“以后”，这是永远不会。然后直接进入编程，我脑海中想象的第一页。|1119416|忏悔:我个人犯过错误1，3，7，8。我也犯过2，4，5，6次错误，但我经常自欺欺人地认为我没有。|unstyled|1119417|我目前正在对第9件事进行补救。|1119418|编辑没有意识到这个问题需要我们提出解决方案。|1119419|1)增加更多的功能-不要这样做。与你的业务，市场营销，创始人，顾问等工作，并剥夺你的申请只有一件事。|1119420|去阅读推特，团购等，关于他们如何把事情简化成一件导致他们成功的事情。|offset|length|1119421|如果你认为只有当你想要建立大公司的时候，它才能奏效，那就再考虑一下。这句话的Ctrl%2BF是“我在软件中添加的功能越多，它的销量就越差。(不用说，对于大多数软件开发人员来说，这是非常不直观的。)在此链接中|1119422|2)竞争具有这一特点。所以这是一个必须具备的特性|1119423|见解决方案1|1119424|3)竞争不具备这一特征。所以这是一个与众不同的特性|1119425|1119426|4)用更多的编程来解决业务问题。|1119427|如果你需要雇人教你，给你咨询，或者帮你做，然后记录下他是如何做到的，这样你下次就可以自己做了。就这么做！！不重写代码，不过关，不收200美元。|1119428|5)多编程解决营销问题。|1119429|如果人们不明白你在卖什么，那就是营销问题。回到解决方案1和支点。|1119430|6)用更多的程序来解决生产力问题|1119431|等。|1119432|等到你觉得你的生产力问题已经困扰了一个超过2周的时间，它将合理地发生在另外两个星期。|1119433|现在，评估用于编写解决此问题的脚本所花费的时间。记得把你最坏的估计值乘以2。|1119434|把你的估计值乘以你的时薪。|1119435|现在回顾其他的解决方案:外包，购买现成的解决方案，不要做任何事情，等等。|1119436|选择最具成本效益的解决方案。|1119437|坚持下去。|1119438|7)计划编码，但尚未编码，因为你想“做对”|1119439|去锻炼吧。你会感觉到一股内啡肽，这将激励你的屁股，使你计划采取行动。我知道这一点，因为我只是做了5x5长凳和5x5蹲。|1119440|8)编写一个肮脏的版本，并承诺你将“以后做得更好”，但再也不会“做得更好”。|1119441|在GTD中设置一个tickler文件系统。并积极跟进。履行对自己和其他人的所有承诺。|1119442|9)不要做模拟或站点地图，因为它“太麻烦了”。|1119443|把USD75花在balsamiq桌面版上。我知道这是因为我三个星期前买的。它让我重做我的模型，因为我觉得自己是一个艺术家，建筑师和幻想家，尽管我在现实世界中的画很烂。balsamiq中使用的字体不自觉地提醒您，这只是一个模型，而不是固定在RAD中帮助您。|1119444|端编辑|header-two|entityMap|0|LINK|mutability|MUTABLE|url|http://mixergy.com/andrew-mason-groupon-interview/|1|http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-apps/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|6|2|0|0|2P|3|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|2R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|2S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|2T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|2U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|2V|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|2W|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|2X|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|2Y|8|@]|9|@]|A|$]]|$1|U|3|V|5|T|7|2Z|8|@]|9|@]|A|$]]|$1|W|3|X|5|T|7|30|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|T|7|31|8|@]|9|@]|A|$]]|$1|10|3|11|5|T|7|32|8|@]|9|@$12|33|13|34|1|35]]|A|$]]|$1|14|3|15|5|T|7|36|8|@]|9|@$12|37|13|38|1|39]]|A|$]]|$1|16|3|17|5|T|7|3A|8|@]|9|@]|A|$]]|$1|18|3|19|5|T|7|3B|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|T|7|3C|8|@]|9|@]|A|$]]|$1|1C|3|19|5|T|7|3D|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|T|7|3E|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|T|7|3F|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|T|7|3G|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|T|7|3H|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|T|7|3I|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|T|7|3J|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|T|7|3K|8|@]|9|@]|A|$]]|$1|1R|3|1S|5|T|7|3L|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|T|7|3M|8|@]|9|@]|A|$]]|$1|1V|3|1W|5|T|7|3N|8|@]|9|@]|A|$]]|$1|1X|3|1Y|5|T|7|3O|8|@]|9|@]|A|$]]|$1|1Z|3|20|5|T|7|3P|8|@]|9|@]|A|$]]|$1|21|3|22|5|T|7|3Q|8|@]|9|@]|A|$]]|$1|23|3|24|5|T|7|3R|8|@]|9|@]|A|$]]|$1|25|3|26|5|T|7|3S|8|@]|9|@]|A|$]]|$1|27|3|28|5|T|7|3T|8|@]|9|@]|A|$]]|$1|29|3|2A|5|T|7|3U|8|@]|9|@]|A|$]]|$1|2B|3|2C|5|T|7|3V|8|@]|9|@]|A|$]]|$1|2D|3|2E|5|2F|7|3W|8|@]|9|@]|A|$]]]|2G|$2H|$5|2I|2J|2K|A|$2L|2M]]|2N|$5|2I|2J|2K|A|$2L|2O]]]]

<ol>
<li>Add more features</li>
<li>The competition has this feature. So this is a must have feature hence more programming than analyze strategy, positioning, etc.</li>
<li>The competition does NOT have this feature. So this is a differentiating feature hence more programming than analyze strategy, positioning, etc.</li>
<li>Solving a business problem with more programming. eg, better expertise in administering the linux server your website is hosted on cannot be gained via programming more features. Sometimes you just have to learn how to fix the problem rather than re-coding the whole thing into C#.Net</li>
<li>Solving a marketing problem with more programming. eg, abusing Seth Godin's purple cow concept that you are indirectly solving a marketing problem by programming more features into your product to make it a "purple cow". Sometimes, its just a mutant monster.</li>
<li>Solving a productivity problem with more programming arguing to yourself that the time spent writing this script will be saved back in hours in future instead of actually programming real important stuff</li>
<li>Planning to code but not yet coding because you want to "get it right"</li>
<li>Coding a dirty version and promising that you will "make it better later" but never went back to "make it better"</li>
<li>Not doing a mockup or a sitemap because it is "so troublesome". I can just screenshot competitor's pages for mockups and freehand draw sitemap "later" which is never. And then just go straight into programming the first page i visualize in my mind.</li>
</ol>

Confession: I have personally made mistakes 1, 3, 7, 8. I have also made 2, 4, 5, 6 but often deluded to myself that i did not.

I am currently remedying 9.

EDIT
Didn't realise the question requires us to put in solutions.

1) Add more features
Just don't do it. Work with your business, marketing, founders, advisors, etc and strip your application to just 1 thing. 

Go read about twitter, <a href="http://mixergy.com/andrew-mason-groupon-interview/">Groupon</a>, etc about how they just strip things down to just 1 thing which led to their success. 

If you think it only works if you want to build big companies, think again. Ctrl+F for this line "The more features I add to the software, the worse it sells. (This is, needless to say, highly unintuitive to most software developers.)" in <a href="http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-apps/">this link</a>

2) The competition has this feature. So this is a must have feature

See solution 1

3) The competition does NOT have this feature. So this is a differentiating feature

See solution 1

4)Solving a business problem with more programming.

If you need to hire someone to teach you, give consultation, or do it for you and then document how he did it, so that you can do it yourself next time. JUST DO IT!! Do not rewrite code, do not pass GO, do not collect $200.

5) Solving a marketing problem with more programming.

If people don't understand what you are selling, it IS a marketing problem. Go back to solution 1 and pivot.

6) Solving a productivity problem with more programming

Wait. 

Wait until you feel that your productivity has suffered from a particular productivity problem for a period longer than 2 weeks and it reasonably will happen for another 2 weeks.

Now, evaluate the amount of time spent to program a script to solve this problem. Remember to take your worst estimate and multiply by 2.

Multiply your estimate by your hourly rate.

Now review alternate solutions: outsource, buy a solution off-the-shelf, don't do anything about it, etc

Choose the most cost-effective solution. 

Stick to it.

7) Planning to code but not yet coding because you want to "get it right"

Go exercise. You will feel a rush of endorphins that will motivate your ass and make you plan to act. I know this because I just did 5x5 benchpresses and 5x5 squats.

8) Coding a dirty version and promising that you will "make it better later" but never went back to "make it better"

Set up a tickler file system in GTD. and aggressively follow up. Follow up all promises to yourself and others.

9) Not doing a mockup or a sitemap because it is "so troublesome".

Go spend USD75 on a balsamiq mockups desktop edition. I know this because i bought it 3 weeks ago. It has made me redo my mockups because i feel like an artist, architect and visionary all in 1 even though my drawing in real world sucks. The font used in balsamiq unconsciously reminds you that this is just a mockup, not set in stone which helps you in RAD.

End EDIT

blocks|key|1119124|text|喝几杯啤酒会让我工作得越来越好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

A couple of beers will help me work better and longer.

blocks|key|1119181|text|“是的，我可以在一天内把这2000多行意大利面重组成一团.”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

"Yeah, I can refactor this gigantic mess of 2000 lines spaghetti in one day..."

blocks|key|4861328|text|“我不用考试就能过得去。这太难了。”|type|blockquote|depth|inlineStyleRanges|entityRanges|data|4861329|是邪恶的兄弟，|unstyled|4861330|“我必须为此进行一次考试，不管考试有多难写或理解。”|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|J|8|@]|9|@]|A|$]]]|G|$]]

<blockquote>
 "I can get by without a test for that.
 It's too hard to test."
</blockquote>

and it's evil brother,

<blockquote>
 "I must have a test for that, no
 matter how hard the test is to write
 or understand."
</blockquote>

blocks|key|1119612|text|拖延和乐观的任务估计是我最大的罪过。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1119613|第一次伸展、俯卧撑或仰卧起坐(或任何其他体育锻炼)和悲观情绪之前，给第二次评估。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Procrastination and optimistic task estimation are my biggest sins.

Stretching, push-ups or pull-ups (or any other physical exercise) for the first one and pessimistic mood before giving estimation for the second.

blocks|key|1119977|text|“从头开始重新实现功能要比理解现有代码容易得多。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

"It is much 'easier' to reimplement the functionality from the scratch than to understand the existing code."

blocks|key|1119193|text|我所从事的项目所遭受的一个巨大的有害诱惑是“内部平台效应”。这是建筑师们早已过时的一种方法，他们以其无穷的智慧创造了一个每年产生约2+000万美元的项目，但更新和维护却花费了6+000万美元(很明显，这是问题的严重性)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

One massively harmful temptation that the project I am on has suffered from is the 'Inner Platform Effect'. This is an approach that Architects, who have now long gone, have set down in their infinite wisdom which has created a project that generates around 20 million dollars per year but costs 60 million to update and maintain (rough figures obviously but this is the magnitude of the problem).

blocks|key|4861421|text|NIH+-不是在这里发明的|type|header-two|depth|inlineStyleRanges|entityRanges|offset|length|data|4861422|我真的很难给第三方解决方案一个公平的机会。每个人都应该自然地怀疑不是为他们量身定做的第三方解决方案，但我很难做到100%25的客观。|unstyled|4861423|节省的时间是如此之多，以至于即使10次中有9次应该避免第三方解决方案，我也需要客观地认识到这一解决方案是可行的。|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Not_Invented_Here^0|0|3|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|F|7|T|8|@]|9|@]|C|$]]|$1|G|3|H|5|F|7|U|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

<h2><a href="http://en.wikipedia.org/wiki/Not_Invented_Here" rel="nofollow noreferrer">NIH</a> - Not Invented Here</h2>
I have a really hard time giving third-party solutions a fair chance. Everyone should be naturally skeptical of third-party solutions that weren't tailor-made for them, but I have a hard time being 100% objective about it.
The time savings can be so huge that even if 9 times out of 10 the third-party solution should be avoided, I need to be objective enough to realize the one that will work.

blocks|key|4861609|text|根据提供的“样本数据”进行设计、编码和或单元测试，而不是分析客户实际数据库的副本。最后期限很短，他们不停地说，它即将到来，但从来没有。当它被部署时，爆炸是壮观的。真的，谁会期望一个客户有3个父客户。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4861610|我将永远不会再开始一个项目，除非我有一个真实的数据副本。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Designing, coding and or unit testing against supplied "sample data" instead of analyzing a copy of the customers actual database. The deadline was short and they kept saying it's coming but it never did. When it was deployed the explosion was spectacular. Really, who would have expected a customer to have 3 parent customers.

I will never again start a project until I have a copy of the real data.

blocks|key|1119870|text|肯定有个图书馆能在某个地方做那种病。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1119871|密切相关的|1119872|插件狂热的|header-two|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|J|8|@]|9|@]|A|$]]]|G|$]]

The There is gotta be a library that does that somewhere syndrome.

closely related to 

The Plugin Fetish

blocks|key|4861622|text|完美主义扼杀；可能是项目没有成功的最大原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Perfectionism kills; probably the greatest reason projects don't succeed.

blocks|key|1119102|text|嗯，有时候编程会把我逼到瓶子里。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Well, sometimes programming drives me to the bottle.

blocks|key|1119625|text|重写而不是重构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Rewriting instead of refactoring.

blocks|key|4861085|text|认为一定有更好的方法来做这件事。我不会满足于可能是“足够好”的东西。我要的就是完美！通常，通过与其他对问题有不同看法的人交谈，或者从不同的角度看到解决方案，就可以避免这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Thinking there has to be a better way to do this. I'm not going to settle for something that may be "good enough." I'm taking nothing less than perfection! Usually this is avoided by talking to others that may have a different perspective on a problem or seeing a solution from a different angle.

blocks|key|1119684|text|在维护工具上花费的时间比在实际工作上花费的时间更多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1119685|解决方案:与代码优化一样，首先找到生产力瓶颈，只有在发现这些瓶颈之后，才能通过一些良好的自动化来解决这些瓶颈。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Automating everything to the point more time is spent on maintaining the tools than on actual work.

Solution: just like with code optimization, first find productivity bottlenecks and only after they are discovered, cure them with some good automation.

blocks|key|4862204|text|你的编程恶魔是什么？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|4862205|除了其他一些人提到的。|unstyled|4862206|轻重缓急:忽略与项目相关的高优先级工作，而先处理项目中的其他事情，因为它们更有趣！|4862207|你怎么避开他们？|4862208|多一点自律。认真地说，自律和做正确事情的自我动机有助于避免大多数这些“恶魔”。|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|M|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$]]]|K|$]]

<blockquote>
 What are your programming demons?
</blockquote>

Apart from what some of others have mentioned.

Prioritization : Ignoring the high priority work with respect to project and working on other things in the project first because, they are more interesting! 

<blockquote>
 How do you avoid them?
</blockquote>

With a little more self discipline. Seriously, self discipline and self motivation to do the right thing helps to avoid most of these "demons".

blocks|key|4861557|text|我们还没有得到客户的批准，但截止日期快到了，所以这里有一些初步的建议，让你可以开始。|type|blockquote|depth|inlineStyleRanges|entityRanges|data|4861558|稍后，在你完成了与公司匹配的项目后.|unstyled|4861559|哦，这是客户的修订，他们只是想改变一些小事情*|4861560|(*主要功能完全不同)|4861561|然后，您继续重构您的原始代码，基于原始的有缺陷的模型，而不是从零开始，因为您面临的压力很短的最后期限，并假设这些是最后的修订。|4861562|我总是被这个咬。作为一名web开发人员，这是很难避免的。我最好的建议是争取更多的时间，这样你才能做出正确的改变。|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|O|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|P|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|S|8|@]|9|@]|A|$]]]|M|$]]

<blockquote>
 We haven't gotten approval from the client yet but the deadline is approaching so here are some preliminary comps so that you can get started...
</blockquote>

Later, after you've finished building the project to match the comps...

<blockquote>
 Oh, here's the client's revisions, they just want to change a few minor things*
</blockquote>

(* major functionality is entirely different)

Then you keep refactoring your original code, based on the original flawed model instead of just starting from scratch because you're under the pressure of a short deadline and assume that those were the last revisions.

I get bit by this one all the time. It's hard to avoid as a web developer. My best advice is to push for more time so that you can make the changes the correct way.

blocks|key|1119738|text|要回答关于避免他们的问题:熟悉反模式，这样当你认出他们时，你就可以把他们叫出来。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Anti-pattern^0|F|3|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@$A|L|B|M|1|N]]|C|$]]]|D|$E|$5|F|G|H|C|$I|J]]]]

To answer the question about avoiding them: Familiarise yourself with <a href="http://en.wikipedia.org/wiki/Anti-pattern" rel="nofollow">Anti-Patterns</a> so you can call them out when you recognise them.

blocks|key|1119847|text|聪明。当然，不总是这样。一些聪明和简洁将使您的代码看起来非常好和可维护。但仅仅因为你能做到|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1119848|x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;|code-block|syntax|javascript|1119849|而不是几行if语句，并不意味着你应该这么做。|1119850|顺便说一句，是的，我知道我的例子有点多余.如果你自己抓到的话:)|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|M|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|N|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|O|8|@]|9|@]|A|$]]]|K|$]]

Cleverness. Of course, not always. Some cleverness and conciseness will make your code look very nice and maintainable. But just because you can do

<pre><code>x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;
</code></pre>

instead of a couple of lines of if statements, doesn't mean you should. 

Btw, yes I know there is a bit of redundancy in my example... If you even caught it yourself :)

blocks|key|4861786|text|这个项目让我的大脑疲惫不堪。我只想在这个简短的项目上休息一下，让它恢复活力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

My brain's worn out from this project. I'll just take a quick break on this short side project to rejuvenate it.

blocks|key|1120100|text|在代码冻结日期后编写新代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1120101|代码冻结日期必须用石头设置。任何在它之后编写的新代码都必须移到将来的版本，因为它可能需要各种类型的回归测试。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Writing new code after code-freeze date.

Code freeze date must be set in stone. Any new code written after it must be moved to the future release, as it may require all kinds of regression testing.

blocks|key|4862317|text|"There+must+be+a+better+solution+to+this."|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4862318|最后，你会思考和思考，让你的头脑飘向遥远的土地，直到你意识到你已经离开了太久。应该没事的，但不是在你有最后期限的时候。|entityMap^0|0|16|0^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|L|8|@]|D|@]|E|$]]]|H|$]]

<code>"There must be a better solution to this."</code>

And you end up thinking and thinking, and letting your mind drift off to a far away land until you realized you were gone for too long. It should be fine, but not when you have a deadline.

blocks|key|1119217|text|所有其他的附加特性爬行：“如果它这样做了，它将是非常酷的，我知道客户会喜欢它，如果他们想到它，会把它放在规范中”。我试图通过询问真正的规范中对于这个真正的酷特性的需求在哪里来避免这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1119218|再说一遍，我不经常收到书面说明。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

All of the others plus feature creep: "It would be really cool if it did this, and I know the customer will love it and would have put it in the spec if they'd thought of it". I try to avoid this by asking where in the real spec the requirement exists for this real cool feature.

Then again, I don't often get written specs.

blocks|key|4861684|text|“我被分配了一个与软件/例如:+sharepoint接口的特性。我可能应该知道所有关于该软件的信息。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4861685|然后你花了几个星期的时间研究这个产品，而这个功能可以在一两天内编写和测试。对知识的渴望有一个黑暗的下腹。拉沃尔|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

"I have been assigned a feature that interfaces with [software/eg: sharepoint]. I should probably know everything there is to know about that software."

Then you spend weeks researching that product, when the feature could have been written and tested in a day or two. The hunger for knowledge has a dark underbelly. rawr

blocks|key|1120066|text|它只是飞行员，所以没有必要使它易于维护或扩展。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1120067|在我的经验中，更常见的情况是看到试点进入生产和产品，它应该是一个试点被取消，而不是试点被取消和实际产品发展到生产准备状态。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

"it's only the pilot, so there's no need to make it easy to maintain or expand".

In my experience it's more common to see the pilot enter production and the product it's supposed to be a pilot for to be scrapped than for the pilot to be scrapped and the actual product developed to production ready status.

blocks|key|4861935|text|花了太长时间来调整编辑。试图为编程找到最佳的字体和颜色方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Spending too long tweaking the editor. Trying to find the best font and colorscheme for programming.

blocks|key|1120212|text|“我以后再评论/记录这件事”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1120213|这从来没有发生过，作者继续前进，然后你会发现当任务被分配给你时，他们不会对他们的代码进行注释。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

"I'll comment/document this later"

it never happens, the author moves on, and then you find out that they don't comment their code when the job has been assigned to you.

blocks|key|1119810|text|你的编程恶魔是什么，|type|blockquote|depth|inlineStyleRanges|entityRanges|data|1119811|所有已经提到的东西，特别是像疯狂一样进行重构的冲动。|unstyled|1119812|你怎么才能避开他们？|1119813|在开始任何重要的编辑之前，把我的手从键盘上拿开5秒，然后快速权衡改变和离开键盘的可能结果。在犯罪之前，再一次权衡同样的后果大约一分钟。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|K|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|L|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|M|8|@]|9|@]|A|$]]]|I|$]]

<blockquote>
 What are your programming demons, 
</blockquote>

Everything that's already been mentioned, particularly the urge to refactor like mad.

<blockquote>
 and how do you avoid them?
</blockquote>

Before starting any nontrivial edit, take my hands off the keyboard for 5 seconds and quickly weigh possible outcomes of changing vs. leaving it. Then again before committing, weigh the same consequences for about a minute.

blocks|key|4861802|text|开始攻击一个新的项目，却不了解它，我通常会避免这一点，在我真正开始使用它之前，先研究一下这个项目域，这样就有了一个好的起点，并证明这个项目比我最初通过它时要复杂得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4861803|我也有一个问题，我喜欢移动按钮，他们是如此酷！但也许是因为我在做多媒体系统和用户界面设计..。所以对我来说，解决这个问题的办法，就是把它列入我的课程，并研究一些关于它的东西，这样，如果有人看到我经常玩UI，我就有了一个有效的借口。(这包括将背景绿色、文本橙色和大量黄色图标放在一起。)|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

To start attacking a new project, without understanding it, and I usually avoid this by researching a little about the project domain before I actually begin to work with it, just to have a good starting point, and to prove the project is more complex than I initially through it was.

I also have the problem that I like to move around with buttons, they are so cool!! But maybe that's because I'm doing multimedia systems and user interface design... So for me the solution to this problem, was to actually include that in my curriculum and study something about it, so that I have a valid excuse if anyone sees me playing with the UI a lot. (And that includes putting the background green, the text orange, and the icons with a lot of yellow.)

blocks|key|1119989|text|非常完整的列表：反模式。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Anti-pattern^0|8|3|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@$A|L|B|M|1|N]]|C|$]]]|D|$E|$5|F|G|H|C|$I|J]]]]

Very complete list: <a href="http://en.wikipedia.org/wiki/Anti-pattern" rel="nofollow">anti-patterns</a>.

blocks|key|4861841|text|我想我脑子里想的是枚举比Java更有用。我倾向于对它们做得太多，然后陷入困境，因为它们并不真正支持多态性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

I think I have it in my head that enums are a lot more useful than they really are in Java. I tend to try and do too much with them, and then get bogged down because they don't really support polymorphism.

blocks|key|1120044|text|为了避免内部开发，90%25的车轮并不比发明车轮更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

over committing yourself to avoid in-house development, 90% of a wheel is not better than inventing one.

blocks|key|4861958|text|有人说，过早的概括，但过早的专门化可能同样糟糕。通过过早的泛化，您可以得到一个软件，它可以工作在50%25的情况下，但是过早的专门化可以工作5%25，或者根本不起作用。最后，管理层宁愿拥有50%25，也不愿拥有5%25。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Someone said premature generalization, but premature specialization can be just as bad. With premature generalization, you can get a software that works for 50% of the cases, but premature specialization can work for 5%, or none. In the end, management would rather have 50% than 5%.

blocks|key|4862021|text|在我的业余时间里为公司做了无数个小时的额外工作，结果却发现“这不是他们想要的方向”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Doing countless hours of extra work for the company in my off time only to find out "that wasn't the direction they were looking for."

blocks|key|4862055|text|找个舒适的沙发工作或躺在床上工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

To find a comfortable sofa to work or work lying in bed.

blocks|key|1120196|text|使用一个框架，但不完全理解它。不过，再说一遍。一个框架只有它的创建者才能完全理解(大多数情况下)。对于这个项目，我没有一个真正的解决方案，但我试图从一个框架中尽可能多地理解。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Using a framework while not fully understanding it.
But then again. a framework is only fully understood by it's creators (most of teh cases).
I don't have a real solution for that item but trying to understand as much as possible from a framework.

blocks|key|1120273|text|/**
*+Calculates+the+return+value+for+humptyDumpty
*
*+return+int+modifiedHumptyDumpty
*/
function+awesomeWayToCalculateSomething(int+humptyDumpty)+{
..+
}|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1120274|东藤:我需要正确地记录这件事。|unstyled|1120275|_never_会发生吗？|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|K|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|L|8|@]|9|@]|A|$]]]|I|$]]

<pre><code>/**
* Calculates the return value for humptyDumpty
*
* return int modifiedHumptyDumpty
*/
function awesomeWayToCalculateSomething(int humptyDumpty) {
.. 
}
</code></pre>

TODO: I need to document this properly.

Will _never_ happen

blocks|key|1120304|text|使用语言特性、成语或设计模式并不是因为它是解决问题的最佳方法，而纯粹是为了使用它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Using a language feature, an idiom, or a design pattern not because it is the best solution to the problem, but purely for the sake of using it.

blocks|key|1120380|text|修复一个一直困扰您的bug，因为它“非常简单”，但从不告诉QC和/或客户。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1120381|这些修复总是会使生产崩溃。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Fixing a bug that's been bothering you because it is "so simple", but never telling QC and/or the customer.

These fixes always crash production.

blocks|key|1120291|text|是“完美的”|type|header-two|depth|inlineStyleRanges|entityRanges|data|1120292|虽然避免第一次做对是个问题，但它并不像永远关注完美一样糟糕。只要把它做完，就没有完美的东西，如果有的话，纯粹是暂时的，或者已经做了，不值得再做一次。|unstyled|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|G|8|@]|9|@]|A|$]]]|E|$]]

<h2>Being "Perfect"</h2>

While avoiding getting it right the first time is a problem, it's not near as bad as an undying focus on perfection. Just get it done, there is no such thing as perfect, and if there is, it's purely temporal, or already been done and not worth the time to do again.

Just curious, what kinds of temptations in programming turned out to be really harmful in your projects? 

Like when you really feel the urge to do something and you believe it's going to benefit the project or else you just trick yourself into believing it is, and after a week you realize you haven't solved any real problems but instead created new ones or, in the best case, pleased your inner beast with no visible impact.

Personally, I find it very hard to not refactor bad code. I work with a lot of bad legacy code, and it takes some deep breaths to not touch it when I have no tests to prove my refactoring doesn't break anything. 

Another demon for me in user interface, I can literally spend hours changing UI layout just because I enjoy doing it. Sometimes I tell myself I'm working on usability, but the truth is just I love moving buttons around.

What are your programming demons, and how do you avoid them?

Harmful temptations in programming

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

只是好奇，在编程中什么样的诱惑在你的项目中被证明是真正有害的？比如当你真的感觉到做某件事的冲动，你相信它会使你的项目受益，或者你只是欺骗自己相信它是的，一周后你意识到你并没有解决任何真正的问题，而是创造了新的问题，或者，在最好的情况下，让你内心的野兽满意，却没有明显的影响。就我个人而言，我发现很难不重构坏代码。我处理了很多糟糕的遗留代码，当我没有测试来证明重构没有破坏任何东西时，需要做一些深呼吸才

问编程中的有害诱惑
EN

您的编程恶魔是什么，以及如何避免它们？

回答 53

Software Engineering用户

Software Engineering用户

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编程中的有害诱惑EN

您的编程恶魔是什么，以及如何避免它们？

回答 53

Software Engineering用户

Software Engineering用户

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编程中的有害诱惑
EN