其实应该要说说前两个月发案的状况和心得，不过我实在太忙， 就一直拖到现在。 那一阵子发了许多案子，最後实际有用到的程式，可以说几乎是 没有，不过有做完的，我也都照样发钱了。 当然其中状况颇多，并不是说大家都做得不好，只是有一些现象 应该要说一说，希望提供给大家一些经验之谈。 我想，核心问题还是源自於台湾资讯教育所造成的错误概念。 软体的主要功能，在软体使用上或许很重要，但是在软体制作上 其实是非常次要的部分，任何的资工系学生都会规划演算法，却 只有大软体公司才能完成精美的软体，就是因为那些「其他」的 东西，才是软体制作的关键成份。 而这些被台湾资讯教育界视为「其他」的部分，首要的就是错误 处理，没有好的错误处理，软体一旦有任何问题，在没办法有效 检查的状况下，往往只能舍弃重写。 所以，程式的错误处理一定要加强，特别是任何系统资源的取得 开启处理等等，还有指标的使用，都得要十分小心并作好检查， 这是十分基本而且重要的工夫，千万不要以为将主流程、主功能 完成就好，那样是不会合格合用的。 并且，请重视软体细节的份量，不要认为软体功能就这麽一点， 於是以自己的能力一定可以在多少时间内完成。 一个软体的细节，往往占了全部软体工作的八成以上，对於细节 能有多少掌握程度，正是软体工程师的真正能力所在。 千万不要看轻细节的份量，否则再简单的案子都会做不好，并且 不要轻易采用自己不熟悉的技术，以求简化细节，那样只会愈弄 愈糟，有一组就是这样失败的，很单纯的案子搞到後来变成谁都 无法掌握。 最後，请重视细节的组织，请尽量提高其可重用性，不管是做成 模组、类别、程式库或什麽的都好，就是不要因为它是细节，就 全都写在主程式当中，这样子程式码的长度很容易失控的。 所谓的软体工程，其实就是对於软体复杂性的管理，软体的制作 不是写作业，把问题解答出来就好，软体真正的解答是在细节上 是在介面上，能够多大程度减少他人对於软体细节的要求，也就 代表自己在软体制作上有多大的价值。 台湾的软体业，一般对於外包合作有两种概念，一种是从资策会 或政府单位训练出来的，透过大量的分析设计文件，规制软体的 各个制作细节，於是程式设计只是最底层的单调工作，就可以找 一些低薪的程式设计师甚或外包的学生来做。 另一种是从国外回来或是黑客出身的，要求的是专业合作，於是 即使最资浅的程式设计助理，所负责的部分也是软体当中的重要 螺丝钉，自己要处理好自己这部分的一切事务，大家依照能力和 兴趣分配不等份量的软体工作，相互协助，而没有层层规制。 这两种思维的差异，决定程式设计工作是软体产业的底层工作， 还是软体产业的核心工作。 我和大家的合作，不是那种我把作业交给你去做，然後你把作业 交回来给我打分数，及格就发钱的状况，而是我把你愿意、喜欢 做的部分交给你做，有问题我可以帮忙，大家一起把事情做好。 有几组的状况，我认为就是在这方面的认识有所偏差导致的，但 这应该不是我没有把概念传达出去，而是太习惯被权威管束了， 对於交作业打分数的模式太熟悉，於是总希望把问题遮掩过去， 而不是一起面对问题、解决问题。 爱玩、偷懒、有别的事在忙、心情不好、不会、写不好什麽的， 其实都没有关系，我也都能理解，都可以想办法，看要怎麽解决 或重新分配工作都可以，就是一直拖时间不把问题摊开来讲最为 糟糕。 这一次有两组的状况颇不好，让整个案子几乎搞砸，也影响其他 部分，让我到现在还在收拾，其间损失的信用和其他东西，远比 案子的费用都还要高出许多，但这明明是可以避免的，我发案时 就做好必要时自己重写的打算，却拖到我连重写的时间都没有， 那样才糟。 短期内我大概不会再做公开发包，可能要等我比较有余裕了，再 考虑发包一些我自己要用的小工具程式，就算再出问题，也比较 不会影响到自己的信用。 -- ※ 编辑: reader 来自: 61.222.173.29 (09/01 18:58)