Hackthon实战 ——经验与教训

当对自己的真实实力没有真正的认识，期望便成为了负担。本文是一篇随笔，记录与总结我个人在第一次参加hackthon之后的经验与教训。

纪实

本次参加了华师木犀举办的hackthon，本来是过去当监工的，突发奇想参加了华师木犀团队提出的项目。产品提出了一个游戏：使用pygame实现一个由计时器触发动画，点击事件的游戏。

项目本身理解上并没有多少困难，但在实际的开发过程中，绝大部分开发由我来完成，程序设计也由我来完成。没有具体的流程图，原型图之类的，这些也在后来开发时影响了效率，没能明确思路。

定义函数并不是一件难事，但难事在于数据的设计上。数据的设计最初是大量的硬编码变量名以及大量全局变量，函数设计极其不合理，参数基本不传递，通过类内成员传递。虽然在实际效率上可能有所提高，但对于开发而言则是折磨。事实上也是如此，在实际开发的过程中大批量复制粘贴代码，极其影响开发效率。这个问题让我在入夜时候决定重构一部分，至少将硬编码变量替换为字典键值对，节省了打字的时间。但对于总体逻辑，最后还没有很好地解决。代码没有很好地复用从而增加了工期，是这次hackthon给我带来的最深刻的印象。

体会

当24小时的限制在眼前逼近，最为煎熬的往往不是熬夜的身体，而是精神状态。“对未来正确的期望”是一项宝贵的能力，这需要的不仅是专业知识，更需要项目管理的经验。对工期正确评估是困难的，而这份困难在面临迫近的ddl时候会化为痛苦。

“软件项目平常看似单纯而率直，但很可能一转眼就变成一只时程延误，预算超支，产品充满瑕疵的怪兽。”《没有银弹》的这句话，往往需要实践才能理解，这需要不仅站在项目管理者的视角，还要站在软件开发者的视角上去看待。如何对项目进度进行评估，不仅是企业项目管理，也是个人开发者需要考虑的问题。

“进度”，最为简单的解释便是写完了多少，还剩多少没有写完。对于少量且逻辑明确的代码可以如此进行评估。但在实际项目中，还需要看已经完成的部分是否易于添加与扩展，未完成的部分是否与已完成的部分有着相同的逻辑，能否复用，这些是站在开发者角度才能认识到的。所谓“本质性工作”，就是将抽象理念实现完成设计。将设计用代码表达出来仅仅是“次要性工作”。前者需要良好的设计，而良好的设计需要丰富的经验来指导。在实际的开发中，“设计”是会存在缺陷的，最简单的比如少传了个数据功能无法完成，这时候需要对设计“打补丁”或者重新进行设计。毫无疑问，前者是代价较为低的拓展方法，但也是如此，补丁的积累会导致代码变得极其劣质不堪，从而降低开发效率。并非所有的补丁都能很好兼容，打补丁同样也需要对代码的设计有所经验，补丁也是代码，也需要考虑可扩展性，也需要考虑兼容性。当补丁多到最后不得不重新设计时候，噩梦才真正地开始。

人类的思维是抽象的，具象化是人类从古至今都没能很好解决的问题。人与人之间需要沟通，这诞生了语言，但语言同样也是抽象的，二人的知识含量不对等同样会引起误解。但对于人类而言，言语的不互通在小程度只会引起误解，大尺度上则会引起战争。编程语言也是如此。机器难以理解人类抽象的思维，人类难以将抽象的思维具象化，小尺度是瑕疵，大尺度则是怪兽，引起重大的经济损失。同样，就人类本质上来说，失误是难以清除的，只能够尽量回避。这诞生了软件工程学，以工程学的方法去应对，排查，解决人自身所犯过的错误，并且分析系统，设计系统，解耦系统，使得项目能够以更好地，失误更少的方法被开发。

但工程学本身就是较为反人性的。工程学意味着开发受到限制，人的创造性思维被限制，难以用自己喜欢的方法去开发，人成为了生产力。这一点我认为值得商讨。开发究竟是创造性工作还是重复性工作，我认为更加偏向后者，创造性开发容易陷入自身思维的陷阱，被自身的思维所害，例如意识当工作进展一半时候发现难以完成，认识到自身思维的缺陷，这时候在工程进度上则难以着落。工程化方法虽然限制，不少东西如UML，流程图，生命周期图，在小项目情况下显得颇为冗余，但对开发的实际指导作用还是起的到的。

万事万物都在追求着平衡，软件开发也是如此，从大尺度来讲需要调整经费，人员，工期来实现效率提升，从小尺度来讲比如重构还是补丁，可扩展性还是开发效率，人员精神状态与工作时长，这些都是需要考虑的。

敏捷开发快速迭代成为了最近相当常见的名词，但在实际意义上讲，快速迭代不一定效率更好。快速迭代意味着需要对业务进行很好地切分，减少迭代版本之间的相互影响，而不成熟的切分快意味着需要完成的部分勉强可行，而需要扩展的部分很难顾及到。虽然对于开发者而言，快速迭代能够带来成就感，对于前几个工期能够很好实现，增强信心，但还是和开发人员水平相关。

面向对象现在已经成为了最为基本的思想，但我自己在开发过程中却没有用到，这也是我需要反思的一部分。在实际写代码将面向对象抛在脑后，现在才想到在开发过程中可以用到。这在将来开发也是需要反思的一点。虽然我不知道用面向对象改写的效率是否会更高，这需要进一步的实践，但现在它成为了我设计系统与开发过程中的考虑。

这次hackthon主要感受就是如此，最后交付的产品并没有达到预期，拥有很多瑕疵，仅仅为可行的程度，我自己需要反思这一点。对于学习到的编程思想需要在将来进行更好地实践，这需要经验，需要代码量。这次也算是对“软件危机”有了自己的理解。

写了个随笔，观点不一定对，各位看官看个乐呵即可。