如何处理短编码会话?

时间:2009-04-24 08:53:48

标签: time

我正在做一些宠物项目,一般我会在22:30或23:00左右坐在我的个人电脑周围进行编码。但是因为我试着在24:00左右睡觉,所以我不会开始编码并最终阅读文章,玩一些游戏等。

我觉得我不能在一小时内写出不错的代码,因为这个项目很大,我不想随意或不小心破解它。即使我使用TDD,我正在做的大部分时间都不是直接的,这需要大量的测试才能做到正确。

您对这类问题的处理方法是什么?你是否只是在你有足够的时间进行编码,或者你有不同的方法,只允许你编码30分钟并继续以后?

8 个答案:

答案 0 :(得分:4)

在我有时间做之前,我通常不会写很多代码。原因在于,要让我获得有效的关注,需要花费一些时间才能正确地集中注意力。那就是那些30分钟的插槽很适合

  • 编写更多测试:没有什么比尝试获得100%的代码覆盖率更重要了,因为投资不是很大的浪费
  • 研究:我花了很多时间阅读博客,寻找可以使用的框架或工具。花30分钟找到一个框架,可以完成80%的功能,比花费数小时尝试编码要好得多。另一个因素是,如果你实施框架并且发现它不合适,你就会更好地接受教育,这意味着你的开发会更顺畅。

答案 1 :(得分:1)

我的第一个想法是“使用单元测试”,但后来我读到你已经在使用它了。但我仍然认为这是你的计划的解决方案。

尽量使您的测试尽可能小,并使用“每单元1断言测试”规则来创建小型原子测试。您应该能够在30分钟的会话中修复其中一些小测试。

答案 2 :(得分:1)

以下是您可以尝试的一些事项:

  • 不要坐在电脑旁边。相反,拿一大张纸去安静的地方。想想你想要完成什么。写下界面思路,详细实施。列出您需要解决的问题,然后才能继续。
  • 休息一周,然后开始编码。流入时间与流动时间的比例在30分钟内太差了。
  • 记录您的操作而不是编码。观察你的情绪状态。
  • 尽早上床睡觉,尽量在早上进行宠物编码。

答案 3 :(得分:1)

一个小技巧(我在工作中也使用)是在某些东西中间停止编码,等待明显的大红色编译错误。

下次开始工作时,错误实际上会帮助您记住您正在做的事情。

当你正在处理这个小问题时,大局会清除,然后你可以继续设计。

答案 4 :(得分:0)

在如此短的时间内进行开发很困难,但你仍然可以获得一些时间。单元测试就是一个。写下一个类的接口是另一个。虽然编写真实的东西需要花费更多的时间,但这些任务基本上是不费脑子的,而且它们只是一种打字练习。

所以,我的建议是:专注于不需要思考和专注的小任务,并且可以在你拥有的时间内完成。

答案 5 :(得分:0)

从来没有为我工作,宠物项目通常太有趣了,我最终工作到深夜或周末。

我建议重新考虑你的优先事项 - 如果你有可用的时间是深夜一小时,也许最好把它花在游戏,文章等上。或者只是闲逛。如果你有更多的时间,比如说一个懒惰的星期天,一次花费所有的时间,实际上可以获得宠物项目应该给予的感觉。

答案 6 :(得分:0)

以下是我在工作之外对个人项目所做的事情:

  • 1)我试图通过在纸上进行规划,给自己一个很好的地图。我绘制了所有对象,数据结构和/或SQL表,并确定这些组件之间的基本功能和交互是必要的。如果解决方案很明显,我可以在此阶段编写一些实际代码,但通常不会。
  • 2)一旦大局出现,我会优先考虑最基本和最关键的元素。我还试图弄清楚哪些部分比其他部分更容易编写。
  • 3)确定优先级后,我首先开始研究最简单,最关键的部分,然后逐步采用更复杂,更不重要的部分。将每项任务分解为较小的部分往往会有所帮助。例如,我可以先设计一个数据库表,第二天创建一个控制与该表交互的数据接口类。
  • 4)单元测试确实有助于我感受到成就感,即使30分钟的努力只能产生一些优质的代码。
  • 5)保留更改日志,即使它不是非常详细。我发现如果我在很长一段时间内在很多短暂的喷射中完成一个大项目,那么我的更改日志就非常宝贵。

那些步骤对我帮助最大。最后,我能够确定项目的小块,通常可以在大约30-60分钟内完成。当然,随着项目的发展,我通常不得不重新评估一些事情,并且当我发现我在规划阶段离开了某些东西时,我会回到开头一段时间。有时候我需要走得更远,给自己一个时间限制,并确保我以个人奖励庆祝里程碑。如果你有一种熬夜的倾向,那就是我挣扎的事情,我也建议给自己一个编码宵禁。我还试图确保我的“编码计算机”没有太多的干扰,比如游戏。

答案 7 :(得分:0)

还有一个bug。如果没有,你可以添加一个更简洁的功能,这将增加更多的错误。这就是为什么我认为在(或使用)IT中使用“你必须做的......”一词应该是一种悬而未决的罪行的原因之一。

我可以通过做琐碎的事情来减少我的编码会话持续多长时间,在远离键盘的情况下思考问题(淋浴是最好的 - 或者在凌晨4点睡觉时)以及使用脚本语言等轻量级环境但是,“快速”编码会议是我很久以前放弃希望的。

只是将精神齿轮转移到编码模式需要花费时间,在需要时间之前找到我所处的位置的线程,发现我的“快速简便的解决方案”既不需要花费时间。 修复我的“快速简便的解决方案需要时间,调试 - 更多时间,等等。