有哪些独立开发人员编程方法？
适用于小型项目的独立开发人员编程方法有哪些？
What are some solo developer programming methodologies for smaller projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
适用于小型项目的独立开发人员编程方法有哪些？
What are some solo developer programming methodologies for smaller projects?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（9）
几乎任何开发方法都可以在单独的环境中工作，除了那些明确需要团队的开发方法（例如并行编程）。 但即便如此，你也可以通过创造一些想象中的朋友/队友或发展出多重人格障碍来解决这个问题。
Just about any development methodology will work in a solo environment except for those that explicitly require a team (such as side-by-side programming). But even then you could get around that by just creating some imaginary friends/teammates or developing a multiple personality disorder.
即使作为独立开发人员，您也可以使用适用于大型开发团队的方法。
我一直在单独开发，这些实践使我与自己的工作保持一致，并为我的老板提供了一个很好的资源，让他们知道我做了什么以及我走了多远。 他们让我走上正轨，启动！
Even as a solo developer you can use methodologies applied to large development teams.
I solo develop all the time, and these practices keep me in line with my own work and give my bosses a great resource to know what I've done and how far along I am. And they keep me on track, to boot!
我想到了橡皮鸭方法：
http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
The rubber duck methodology comes to mind:
http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
许多敏捷技术单独使用时效果很好：
其他看起来只在大型项目中有意义的事情可以提供很大帮助：
希望这可以帮助！ 在大型项目上单独编程可能会非常令人畏惧。
Many agile techniques work great solo:
And other things that only seem like they make sense in big projects can help a lot:
Hope this helps! Solo programming on a large project can be very daunting.
请遵循 Stack Overflow 问题中的说明：
另外。 使用源代码管理。 你不会相信我在个人项目中被这个问题困扰过多少次。
Follow what is laid out in this Stack Overflow question:
Also. Use Source Control. You wouldn't believe how many times I've been bitten by that on personal projects.
有这样的：
http://en.wikipedia.org/wiki/Personal_Software_Process
这可能有点矫枉过正
There's this:
http://en.wikipedia.org/wiki/Personal_Software_Process
It's probably overkill
问题更多的是你对什么感到满意以及你希望解决什么问题。 大多数方法都是由独立开发人员在某些时候使用的（结对编程是一个值得注意的例外）。 问题是你真的是一个人吗，还是只是一个人工作？ 我发现能够向我提出想法的人是非常宝贵的。 此外，让其他人查看您的代码（同行评审）是发现您无法“看到”的问题的好方法。 因此，同意 Aiden Bell 的观点“在你的设备上编程并不酷。”
我会尝试连接到一个社区（比如SO），在那里你可以向其他人征求想法。 然后，你需要以这样的方式构建你的方法，以便在你发出想法时允许中断。
那有意义吗？ 为什么你一个人编程？
帕特奥
The issue is more a question of what you are comfortable with and what problems you hope to solve. Most methodologies are used by a solo developer at some point (pair programming is a notable exception). The issue is are you actually alone, or just working by yourself? I have found that it is invaluable to have people I can bounce ideas off of. Furthermore having someone else to look at you code (peer review) is a great way to find issues that you just cannot "see". So to agree with Aiden Bell "Programming on your oen is uncool."
I would try and connect to a community (like SO) where you can bounce ideas off of others. Then you need to build your methodology in such a way as to allow for interruptions when you send an idea out.
Does that make sense? Why are you programming alone?
Pat O
并不是真正的官方方法，但我已经做了很多独立开发（独立顾问和 ISV），以下是我发现重要的事情：
oisv.com）分享想法和
确保
与现实世界中的实际人员一起
里程碑
设计和项目规划
他们
没有
对于有效的好代码，而不是
完美
Not really an official methodology, but I have done a lot of solo development (independent consultant and ISV), and here are the things I have found to be important:
oisv.com) to share thoughts and
ideas
with actual people in the real world
milestones
design and project planning
them
out
for good code that works, not
perfection
这与其说是一种方法，不如说是一种技巧。 当您进行调试时，请向自己大声解释错误，就像您试图向同事解释一样。 这感觉很愚蠢，但强迫自己大声说出问题通常会揭示问题所在。
This is more of trick than a methodology. When you're debugging, explain the bugs out loud to yourself as though you were trying to explain it to a co-worker. It feels silly, but forcing yourself to articulate the problem out loud often reveals what the problem is.