In my experience old designs always seem stale when dusted off. In the coming months the existing code will change, the requirements will change, and you'll change as a programmer. Maybe you should write up a brief explanation and assume that you'll need to completely rework it in the future anyway.
Don't get frustrated with specific projects, focus your energy on improving as a developer. And carry that experience with you.
It depends what works for you -- and how you like to learn. I like to use diagrams, so in the situation where I've designed a cool algorithm (albeit nothing as complex as this!) I do the following:
1) Draw the algorithm out on paper, or write it out whatever.
2) Add annotations to it so that it makes complete sense to you.
3) Describe the algorithm to someone else from only what you've drawn. This stops you from filling in blanks from your own knowledge of the algorithm.
4) If there are gaps in your description, add extra detail as you go, so that the document becomes a comprehensive record of your description.
5) Put the drawing away for a week and see if it still makes sense. At this point it should still be familiar enough to add missing detail.
Whether it will be clear enough in a year's time -- or whether you'll even want to use it -- remains to be seen.
In terms of the frustration - generally try to view a project as a journey rather than a destination.
If you've been paying attention you'll have got a lot out of the project to date - things you've learned about the technology and the business, created modules of code you can reuse, you'll have built relationships with team members or users, made mistakes you won't make again and so on. It might help you personally to write a list of what you know now that you didn't at the start of the project.
Ultimately the company may not have implemented the project but much of the benefit which accrues to you as a person and a developer is still there. Indeed, often you learn more on projects which go wrong and in companies which aren't great than when things are running like a dream.
As with the rest of life, the more satisfaction you can get from things day to day, and the less you focus on only the marquee achievements, the happier you'll be.
I'm not saying that delivering projects isn't good - it's obviously why we code - but it's not entirely inside our control so you need to be realistic and balanced about how much you let that impact you.
A detailed requirements document that describes all inputs and outputs is probably one of the best ways to get started. If its a very unique code design, metacode might be a good step. ie.
Make it look something similar to your language w/o testing or anything, just get the theoretical logc onto paper (notepad) that way you have a spring board when/if you ever have to go back to it... then document the daylights out of it.
If you have found the Solution once, chances are high you will find out solution even 4 months down the line for the same problem. What you MUST not miss is the actual problem.
You should pen-down all the optimization problems which are the problem-sources or the actual problems. You must neatly maintain notes of these problem issues.
Now, Next time [say 4 months down the line] when you want to come back to this again. You just need to read the problem issues from your notes, and your brain will start working in the straight direction as it did previously.
To make it even better, you can try going through the problem notes once in a month or two. This will train your brain towards the solution as you will every-time end up with the solution just as you did for the first time.
Also if you can pen-down the issue or concern which actually motivated you enough to struggle for the solution, it'd be great.
发布评论
评论（5）
根据我的经验，旧的设计在掸掉灰尘后总是显得陈旧。在接下来的几个月里，现有的代码将会改变，需求将会改变，作为一名程序员，你也会发生改变。也许你应该写一个简短的解释，并假设你将来无论如何都需要彻底修改它。
不要对特定项目感到沮丧，将精力集中在作为开发人员的改进上。并随身携带这种经验。
In my experience old designs always seem stale when dusted off. In the coming months the existing code will change, the requirements will change, and you'll change as a programmer. Maybe you should write up a brief explanation and assume that you'll need to completely rework it in the future anyway.
Don't get frustrated with specific projects, focus your energy on improving as a developer. And carry that experience with you.
这取决于什么对你有用——以及你喜欢如何学习。我喜欢使用图表，因此在我设计了一个很酷的算法的情况下（尽管没有像这样复杂的算法！），我会执行以下操作：
1）在纸上画出算法，或者将其写出来。
2) 为其添加注释，使其对您来说完整有意义。
3）仅根据您所绘制的内容向其他人描述该算法。这会阻止您用自己的算法知识来填补空白。
4) 如果您的描述中存在空白，请随时添加额外的细节，以便该文档成为您描述的全面记录。
5）把这幅画搁置一周，看看它是否仍然有意义。此时，它应该仍然足够熟悉，可以添加缺失的细节。
一年后它是否足够清晰——或者你是否愿意使用它——还有待观察。
希望有帮助！
It depends what works for you -- and how you like to learn. I like to use diagrams, so in the situation where I've designed a cool algorithm (albeit nothing as complex as this!) I do the following:
1) Draw the algorithm out on paper, or write it out whatever.
2) Add annotations to it so that it makes complete sense to you.
3) Describe the algorithm to someone else from only what you've drawn. This stops you from filling in blanks from your own knowledge of the algorithm.
4) If there are gaps in your description, add extra detail as you go, so that the document becomes a comprehensive record of your description.
5) Put the drawing away for a week and see if it still makes sense. At this point it should still be familiar enough to add missing detail.
Whether it will be clear enough in a year's time -- or whether you'll even want to use it -- remains to be seen.
Hope that helps!
就挫败感而言——通常尝试将项目视为一段旅程而不是目的地。
如果您一直在关注，那么您将从迄今为止的项目中获益匪浅 - 您学到了有关技术和业务的知识，创建了可以重用的代码模块，您将与团队成员建立了关系或者用户，犯了你不会再犯的错误等等。写下你现在知道但在项目开始时不知道的内容清单可能会对你个人有所帮助。
最终，公司可能没有实施该项目，但作为个人和开发人员所获得的大部分好处仍然存在。事实上，通常情况下，你在出错的项目和表现不佳的公司中学到的东西，往往比事情如梦般顺利时要多。
与生活的其他方面一样，您从日常事务中获得的满足感越多，并且您越少只关注显着的成就，您就会越快乐。
我并不是说交付项目不好——这显然是我们编码的原因——但它并不完全在我们的控制范围内，所以你需要现实和平衡地对待它对你的影响有多大。
（乔尔或杰夫所写内容的强制链接：http://www.codinghorror.com /blog/archives/001297.html）
In terms of the frustration - generally try to view a project as a journey rather than a destination.
If you've been paying attention you'll have got a lot out of the project to date - things you've learned about the technology and the business, created modules of code you can reuse, you'll have built relationships with team members or users, made mistakes you won't make again and so on. It might help you personally to write a list of what you know now that you didn't at the start of the project.
Ultimately the company may not have implemented the project but much of the benefit which accrues to you as a person and a developer is still there. Indeed, often you learn more on projects which go wrong and in companies which aren't great than when things are running like a dream.
As with the rest of life, the more satisfaction you can get from things day to day, and the less you focus on only the marquee achievements, the happier you'll be.
I'm not saying that delivering projects isn't good - it's obviously why we code - but it's not entirely inside our control so you need to be realistic and balanced about how much you let that impact you.
(The obligatory link to something Joel or Jeff wrote: http://www.codinghorror.com/blog/archives/001297.html)
描述所有输入和输出的详细需求文档可能是最好的入门方法之一。如果它是一个非常独特的代码设计，元代码可能是一个很好的步骤。 IE。
让它看起来与你的语言类似，无需测试或其他任何东西，只需将理论逻辑写在纸上（记事本），这样当/如果你必须返回它时你就有了一个跳板......然后记录日光出来了。
A detailed requirements document that describes all inputs and outputs is probably one of the best ways to get started. If its a very unique code design, metacode might be a good step. ie.
Make it look something similar to your language w/o testing or anything, just get the theoretical logc onto paper (notepad) that way you have a spring board when/if you ever have to go back to it... then document the daylights out of it.
如果您曾经找到过解决方案，那么即使 4 个月后您也很有可能针对同一问题找到解决方案。你绝对不能错过的是实际问题。
你应该记下所有优化问题，无论是问题根源还是实际问题。您必须整齐地保留这些问题的记录。
现在，下一次（比如 4 个月后）当你想再次回到这个问题时。你只需要从笔记中阅读问题，你的大脑就会开始像以前一样沿着直线方向工作。
为了让它变得更好，你可以尝试每隔一两个月浏览一次问题笔记。这将训练你的大脑寻找解决方案，因为你每次都会像第一次一样得到解决方案。
此外，如果您能记下真正激励您努力寻求解决方案的问题或担忧，那就太好了。
If you have found the Solution once, chances are high you will find out solution even 4 months down the line for the same problem. What you MUST not miss is the actual problem.
You should pen-down all the optimization problems which are the problem-sources or the actual problems. You must neatly maintain notes of these problem issues.
Now, Next time [say 4 months down the line] when you want to come back to this again. You just need to read the problem issues from your notes, and your brain will start working in the straight direction as it did previously.
To make it even better, you can try going through the problem notes once in a month or two. This will train your brain towards the solution as you will every-time end up with the solution just as you did for the first time.
Also if you can pen-down the issue or concern which actually motivated you enough to struggle for the solution, it'd be great.