成为最有效率的单人队
像许多人一样，我是一个独立的开发团队。 我负责收集项目需求，devise概念屏幕，规划和开发数据库以及编写所有代码。
成为一个人的团队是好的，但有其负面影响。 我没有能力快速与其他开发人员进行磋商，我很less会看到我的代码，我相信你们也可以提出许多其他的负面看法。
为了充分利用我的时间，并为自己的工作做出最大的贡献，我可以在日常工作中实施哪些技巧或做法，成为最好的单人团队？
-
我将要做的每日清单。
-
消除尽可能多的分心，专注于任务。 closures电子邮件，closures即时消息等…即使在一段时间，然后在rest期间检查他们。
-
花时间学习其他编码技术，工具和编程智慧。 我发现这对我的发展至关重要。 只需编码就可以了，并且感觉很高效。 如果你只是有一些更多的知识/武器在你的腰带上，那么下一个部件会是什么呢？ 我知道这个真的听起来反效果，但事实并非如此。 知识/知道我们的真实货币。 我们知道得越多，我们就越能做出更好的决定，应该如何做，做得更快。
-
rest一下，注意你的身体。 当我们疲倦的时候，我们不会那么想，会犯更多的错误，更容易感到沮丧，等等。
-
学习如何使用80/20法则。 我不是指吝啬或懒惰。 通常，虽然我们会在没有必要的情况下为20％的工作量做好准备。
-
为自己设定目标（每日，每周，每两周）。 确保目标也符合你所编码的目标，否则你可能会发现你浪费了一些时间。
从技术方面考虑：
- 考虑unit testing/ TDD。 我在自己的工作中发现，这确实节省了时间。 需要一段时间才能获得更好的结果。
- 关心你的代码。 重构它（特别是如果你开始unit testing）。 代码越好，维护越简单，所需时间越less。 理解速度越快越容易改变/实现function。
我正在学习比以前花更多时间计划我的一天。 这包括计划项目，直到编写我需要做的编程的伪代码。 我发现，在我的日程安排中，所有的中断都很难开始。 将所有事情细分成小任务使中断后启动变得更容易。
根据运营研究，最短的工作第一是最好的调度程序，以获得最多的事情。
我编写和运行集成和系统testing，但没有unit testing，因为我不需要进行早期（预集成）testing： 应该testing内部实现还是只testing公共行为？
康威法则的一个佐证就是你需要testing内部软件接口来分离开发人员，而“一个人的军队”不需要用这种方式明确地testing他的内部接口。
其他许多技巧都很好，但同样适用于团队开发人员和独立开发人员。
我觉得作为一个人的团队最难的是与公司其他人进行有效的沟通。 在任何关于如何最好地构build软件的会议或讨论中，你永远都是唯一的程序员的声音。
因此，我build议尽量提高谈判技巧，并专注于改善用非程序员可以理解的方式来描述技术概念的方式。 阅读“ 走向是” ，“ 如何赢得朋友，影响人们 ”等书籍是开始的好方法。
当有一个以上的人同意一个观点时，这个观点会自动获得你想要说服的人的可信度。 在没有这种可能性的情况下，你需要花费更多的精力来准备你的论点，并且有充分研究的证据和平衡的观点。
我处于同样的情况 上面已经有很多好的build议了，但是我要补充的一件事就是find最佳的编码时间，并确保在这段时间内编码。 我早上有几个小时，似乎在编码上是最好的。 我尽量保持这个时间没有任何分心。 计划会议，写文档，testing（至less是繁琐的，重复的东西），以及所有其他的东西，为您的生产效率较低。 保持这些编码时间，当你的编码效率提高2到5倍。
- 确保你经常及早重构。 这几乎就像第二套眼睛（至less对我来说）。
- 不要工作疯狂的小时（特别是如果你在家工作很棘手）。 事实上，工作时间的缩短通常可以提高工作效率，因为即将到来的工作压力可能会增加您的工作效率。
- 你可能要查找帕金森法进行工作/时间pipe理。
我使用一个文本文件来收集我每天所做的所有事情。 每次遇到问题或有问题或find解决scheme时，我都会将其添加到我的文件中。 它的技术含量很低，但它提供了大量的信息，比如“我在哪里花费大部分时间？ 或者“我之前是如何解决这个问题的？”。 还可以让您的客户在结算周期结束时获得一个小时的清单。
我还使用另一个文本文件（每个客户端），其中包含我的盘子上的所有工作项目，按优先顺序排列，并经常更新。 这有助于我和我的客户把注意力集中在我下一步应该做的事情上，因此泵总是处于启动状态。
最终，我将从平面文本文件移动到使用类似FogBugz的东西，但现在我无法打败价格，或者search多么容易，或者电子邮件是多么容易。
