学Java好多年，也参与一次完整项目，觉得让自己写项目写不出来，总觉得缺了一部分。
在这方面愚笨，不知道缺在哪里。以前觉得是知识不够牢固，于是重复去学，发现就那些东西。如果没有业务来熟悉的话，不会明白那些内容为什么要那样做。
周围的人，在我看来都是按规矩办事的人，不会有太多思考。让做什么就去做了，没有多少人想这样做是否合适。像使用框架，都在背框架有哪些好处，怎么去使用。到工作中也是直接就可以拿来用，并没有人思考为什么会产生这个框架，为什么会产生那种需求和这种解决方案。明明很庞大和繁琐，思维不够紧密，还是那么多人在用着，不厌其头痛。
框架是个很大的迷宫，在迷宫中勉强凑合出功能。却没想过一开始就自己找路线，不去用那迷宫。
这些事说不清。对框架我也没有多深入的理解，觉得那些作用都很别扭。当然有一部分核心功能是很好用的，让人一看就明白为什么要那样做。可是一些拓展功能，就把框架本身弄得复杂而庞大。
想起，像玩魔兽时候用插件。国内用个大脚，把所有插件都打包，用到的、用不到的。可是其实可能想要的就一两个而已。如果说多了也不要紧，不伤大雅，我就没话说了。
不过框架的复杂不是做不成项目的直接原因。总觉得在这些类似的复杂背后，有什么是自己不懂的。于是不好承担项目这份责任。
其实写项目没有多大兴趣，不是对编程解决问题没兴趣，是对那些劣质的需求没兴趣。都是重复做的事，这件事很多公司已经做了，还要复制过来继续做。说着解决新问题，其实是在解决旧问题。别人做了百八十遍了，你再做出来有什么意思。有人说挣钱，这确实，可如果大部分人做的都是这种工作，那就不对劲了。
有种观点是环境是这样。以前需求过来，国外给设计，国内再编程。现在成APP了，好像直接自己就可以做出来。需求水平其实没什么变化，APP论实现路线要比电脑版简单的多，只是互动性增强。所以按照以前电脑版的解体水平，可以自行处理APP。只是程序设计水平还是没有变，需求水平没变以至于使用框架就可以解决所有问题，没听说哪个项目需要自行研发脱离框架。业务模式是从别人那里复制的，公司做的软件就是别人走过的路，使用框架就很容易满足需求。再臃肿也不要紧，有情愿受苦受累的搬运工。拿着高新其实不知道能成长多少。
觉得编程可能变成一件繁琐的事。如果说新功能，是有的；可是说实现套路，是没什么变化的。
这些事情是这样，可还是不明白自己缺少的那一部分是什么。总觉得自己独自写不出来项目。
第一份工作是在别人项目的基础上打打补丁，当时也觉得写不出来项目，可从数据库建表到后台，再到前台页面更改，都涉及到了。要说做项目还是做不出来。除了现有的公司软件编程方式和我的不一样以外，还有是自己知识不够全。并且不知道缺少了什么。
对软件思考那么多年，想来早应该做到游刃有余。不知道哪里困惑了自己，却觉得困惑是存在的，包下整个项目会没有底气。
想起PN结来，模拟电路课上遇到的，自己思考了很多遍，把思路一遍遍走通，可是走通之后，还是觉得不会。大体意思明白，大体思路知道，可是中间是迷雾的。这条路走了这么多变，按理说应该很容易走过来。可是自己知道走过之后就忘了，如果再走一遍需要重新做那些思考，一步一步核对着走通过来。热度在那里的时候还记得，热度过了之后又忘了。然后就到了晶体管，稍复杂一些的PN结，就不好走通了。知道结果，忘记了为什么会是这结果，久了结果也一并忘了。费那么大劲研究好几遍的思路，到头来什么都没了。给个电路不能理所当然就知道结果，这让人觉得好憋。
知识运用久了，或者理解透彻了，是可以有感觉的。下次再使用这份知识，用的就不是大脑，不用思考就自然知道结果，这才算是真的会。
编程久了，看一遍就知道运行结果是什么。运行一下只是确认没有疏漏。脑袋也是有容量的，像是胳膊上的肌肉。经常锻炼的话，承受的代码量就多，这里边的逻辑就很容易做到无误。代码量再多，更庞大起来，这里边就容易出现失误。个个环节搭连在一起，整个项目受到牵动。这时候先做框架设计，再写每一个小模块，先画树干再画叶，或许是不错的选择。容量够承受整个程序，应该就可以做项目设计。可是这里边的道道实现起来，并没有那么随心。
框架是个很大的阻碍。使用框架写程序使得事情要按固定的模式发展。而且框架有阴暗的地方，自己不被告知，没有去钻研底层的地方，这样用起来就不知道整体是怎么流通的，程序设计起来就头大了。可是，又不能不去用框架，因为别人都在用，不用框架的话要自行承担项目逾期的风险，用了框架的话即使逾期了也不要紧，因为都是使用框架后，同样的项目给别人做照样会逾期，这和自己没有主动关系。
程序设计的繁琐在使用别人的框架，是个很大的累赘。程序做不好不要紧，使用现在流行的框架了，你能很随便地打补丁。打到不行了，就找高人来解决，就打高级一点的补丁。这就是框架的好处，只要程序没有高级到一定程度，在框架承受的范围内就好。可是使用框架的话，就不要谈程序设计了，该怎么做别人已经给固定好了。也不要提软件的整体性，注定从一开始就是个补丁。
可真要脱离框架了，那些涉及底层或者熟练的业务处理方式都要自己手动写。这些都是非常棒的思考，作为一个学习着会很高兴接触到这部分。可是作为公司，很难有这么大的需求，如果流行框架给的业务处理就能满足，为什么还要花钱自己写？流行框架可是免费的。
即使是这样。还是觉得自己缺少了一部分。对框架的掌握我确实没有怎么熟练，也并不想去接触太多。可是这和整个项目的走通并没有太大关联。不知道自己缺少的是什么。
软件相关的计算机知识是一个很庞大的系统。即使在我而言不明白它庞大在哪里。照我的想法，理论的东西走通了明白了之后，不就什么都知道了吗？可真当想去走通，却发现并不那么容易。不是逻辑问题，自己觉得反倒是人情问题。猜测是这样。一些解决办法的产生，是在当时时代背景下酝酿的，可能解决方式还有很多种，相关的可能性还有很多种。只是在当时的资源环境下，就产生了那唯一的一种。以至于现在反过来都不怎么明白，为什么会那样去做，觉得很繁琐，不好背下来。这样想着，于是问自己，如果想去了解CPU的运行，难道还要去和生产CPU的人工资在一起，去明白其中包含的情感？ 呵呵呵。大概是知识对我来说太庞大，超出了可以消化吸收的范围，才产生了一些偏离的逻辑。
去研究底层遇到障碍，去弄明白需求市场觉得看不到更高层析的需求。而眼前的做项目，仍然一个人做不下来。
不懂框架，加上不懂业务需求，不敢肯定自己做出来的软件是符合需求的。是一条不知道结果的路。我倒觉得，做软件本身就应该是这个样子，本身就是融合自己的思考，抛开那些累赘的框架，做适合当前需求的系统，为当前系统量身打造。所有的处理都去自己写，每一步都有轻微的变动。这对程序员和公司来说，都可以得到良性的成长。
不用流行框架上的解决方案，自行设计思路，摸着石头过河，不适用再改。有什么公司能有这种需求？
觉得我缺少的，或许是耐心，却又不这样认为......
 的认知)
