开发随笔（一）

 

现在回首望去，都是不堪路。想当年自己傻傻呼呼的，遇到问题不求甚解，到头来，除了问题解决了，最后什么都没明白，现在的经验告诉我，如果时间还够宽裕，最好找到问题原因。一直认为，发现问题及解决问题的过程中对自己才是最大的帮助。但是真正出现了问题，有时候却又是及其的纠结、烦闷，但是问题还是要解决的，不可能绕过这个问题，一旦这个问题是求助他人解决的，自己又失去了一个成长的机会，并且在他人的心中的印象又差了一分。所以说，遇到问题静下来多想想，想明白问题了，可能答案也就出来了。

现在总结开发中的一些问题。第一点，接口调用的问题，系统里面各个模块之间都讲究高内聚、低耦合，这样模块修改造成的影响会更小一点，但是很多时候更不做不到低耦合，而且耦合度非常高，如果模块的修改小点还好，如果修改太大，造成的影响也是非常大，所以具体来说，也要看具体情况，考虑下该接口是否可能会调整，这一点一定要想清楚，尽量不要耦合他人的东西，但是如果是同一个模块，在实现功能的情况下，改动尽可能要小，并不是代码越多越好，关键看代码质量及工期吧。

第二点，前端选择器方面，慎用id选择器，很多时候觉得这个元素可能一定是唯一的，但是说不定什么时候就可能出现了同名的id，如果非得用id，那就在前面加个限制域吧，比如formid之类的东西，前段时间改这方面的问题，改了许多许多，以前很多组件之间都是一对一的，所以用id没问题，但是后面改为了多对一，然后就悲剧了，“涉事”的组件全部需要修改。

第三点，学习方面，很多人可能不满足工作中的这么点技术，业务时间可能会去研究一些技术，这应该是非常好的方面，但是有时候你是否会感到技术停滞了呢，自己非常希望突破瓶颈，但是又有诸多限制。你是否有对工作中用的工具、开发的平台又非常深刻的认识呢，没有吧，其实我们平常吐槽的平台中融入了多代程序员大神的心血，虽然很多没有注释，但是多看看很是很容易懂的，然后呢，想想实现上有没有什么替代方法，且效果更好的方法，然后千万别去动，想想就好，然后记下来，什么时候，在某个技术会议上，全部说出来，这样的效果可能会非常好，然后之前业余时间学到的技术可能就派上用场了。研究了解平台还有一个非常大的利处，我们日常工作基本上离不开这个平台，一旦你完全了解这个平台，接下来的工作还不是如鱼得水么，可能接下来就是摆脱了具体的开发工作了。一般什么人在那编码呢，都是不太懂的人，懂的人都是看着那些不懂的人编码，反正我是这样认为的。

第四点，办公室生活方面，千万别私下里讨论他人，因为和你议论他人是否的人，可能平常就喜欢议论他人，今天你和他议论他人，明天可能就是他和你议论的那人在议论你了，并且在卖你，唉，血和泪的教训啊。

写的比较乱，先就这样吧，以后再回头看看吧。