严格与松散

        在工作时经常要在严格与松散中进行抉择，严格的规则与松散的规则各有其优劣。这些感受来源于实际的程序开发经验，也能对应到大部分其他工作行业。比如程序中弱类型与强类型，强类型在编译阶段就会强制规定使用的类型，这样不必查阅相关程序就可以确定变量类型，弱类型在程序量大后则不能快速确定变量类型，因为没有类型定义可能需要查看具体实现代码才能确定义相关类型。而弱类型则更加灵活，开发速度相对强类型更快。

        严格的规则在初期往往更让人难以接受和适应，所以在不进行强制要求时往往难以推行。长期的工作中如果不按照一套严格的规则约束进行，可能会导致无规律或混乱，周期越长这种现象越明显，但是按照严格的方法可能需要的步骤更多，考虑的方面更多。如果按照一定的规则约束进行工作，在较长一段时间后再来维护旧的工作可以按照一定规律进行，更容易回忆更容易定位问题。

        多人团队合作的情况下，每个人的想法都不尽相同，对某一实现方式会有不同的理解。如果不按照一套固定的规则进行，其他团队成员将不能很好的理解创建人的思维，反之按规则实现可以让他人一目了然。

        松散的淡化规则的工作方式往往更容易让人接受，所以也是相对更多人使用的一种工作方法，因为人都不太喜欢强迫自己脱离舒适区。时间越长或工作成果越大则维护成本会越来越高、越来越难以维护，因为很多情况无法找出一个固定的规律可循，会有很多的无法确定性，导致处理一个问题时需要找到与此问题相关的很多关联性问题。但松散也有其优点，松散则更灵活，处理一个问题时相对严格的方法需要的步骤更少，需要的时间也就更少，可以快速按自己的想法来处理一些工作，往往一个想法都是随机性的，不可能一开始就能与严格的规则相匹配。

        所以如果一个项目不大的话不必要有非常严格的规则，比如一个周期一个月的项目，这样只需要敏捷开发快速出成果，就算乱也不大，后期维护也不会太难。如果一个项目超过半年则应该有强制按一定的规则约束进行，因为时间越长对之前的工作将不能很好的回忆，且时间长说明工作成果会相对更大，要查看所有的工作内容来确定某一个工作点的话会更难。

        这里只是记录一下自己当时当下的感受。