正规的软件工程总是遵循某些框架,以便于防止员工更换导致项目无人接手。几乎所有的框架都无法从根本上解决代码变乱的问题。其原因在于自顶向下的设计模式无法适应无限变更的工程。但总是一种让它越来越乱的方法能让代码继续维护下去。
当软件遵循公共框架的时候,反编译的代码就具有一定的技术价值,就产生了技术风险。
一些小工程和不正规的团队的工程或特殊工程没有按公共框架来做,这些代码即便开源也不会有人问津。因为即使看得懂,也无法简单地利用。
此外,还有无框架工程。为了各种目的,公司不允许工程师深入了解一个订单的需求,工程师在需求不明确的情况下,可能会使用无框架工程。无框架工程往往起于一个看起来像是小程序的需求。领导的命令是做一个小程序,解决一个简单问题。当项目完成后,又会有新的小功能被加进来,于是这个小程序越来越大,就变成了一个不得了的企业级工程。当然,此时再谈什么框架已经来不及了。
可见公共框架会有代码被泄漏的风险,定制框架的功能有局限性无法通用,无框架又会让事情变得一发不可收拾。
公共框架的技术风险有一种不完美但比较可行的做法就是代码混淆。代码混淆的工具多是收费的,免费工具功能不全或效果不理想。适合于资金充沛的大团队。
定制框架基本上就是没有重复利用的价值,只要保证产品不被破解就够了。适合于OEM敏捷开发。
无框架则不能有目标,一旦无框架项目有了目标,就会被目标带偏,产生难以维护的代码。无框架的项目一开始就必须做无限期计划,向着看不见的目标前进才能不走歪路。无框架对个人项目是一个非常好的选择,如果没有猪队友捣乱,一切都会进行得很顺利。