绝大部分的程序员都喜欢沉浸在底层开发中,在这里受人员,社交等因素的影响小,而这不正是程序员所梦寐以求的吗?
在这里,可以按照自己的理解,"勤奋"地写代码,信心十足,一日千行甚至更多,如同行云流水...
在这里,可以考虑各种将来"可能遇到"的情况, 尽情打造心中完美的需求世界...
……
但是,别忘了,你的理解并非真实世界的概念,而很可能只是自己的臆想,你考虑的千百种可能 只有一两种会碰到,甚至没有,反过来,你遇到的真实的问题却很少被考虑到,这种情况下,每个真实的问题都会打击的到珍贵的"信心"!
你可能写出"具有1000多个方法的列表类",要记住,这是需要维护的啊,你为将来"可能的需求"背负了如此强大的包袱,确定还能走得下去?假设你的列表类真的考虑了所有的需求,你确定使用这个类的客户(很可能是你自己) ,有信心从如此庞大的数目中正确挑选出需要的方法?
这其实是典型的闭门造车，与此同义的说法还有"高层依赖底层"，"过程式编程"，"瀑布模型"等等，与此形成鲜明对比的说法比如"依赖倒置"，"单一职责"，"对象编程"，"迭代模型"等等，后者总是尽量站在概念的制高点进行观察，而避免陷入"底层实现"的陷阱，"底层实现"总是具有神秘的吸引力，你只有经常性地自省，问问自己目前的工作是从高层的真实概念细分下来的，而不是心里想的
多年来，我从一次一次的教训中意识到这个问题，也确实在改进，如今我无论分析，还是设计，甚至编码，都定时强迫自己自上往下，只有上层的问题，才是你真正要解决的问题，其它的都不是，假如你做了其它的不是上层直接引导出来的问题，你没有功劳，也没有苦劳，只有"麻烦"，每多写一句，就多一个麻烦！
尽快去除麻烦，轻装上阵才是正道！