个人经历
今天笔者想来和大家讨论一下，首先给大家介绍一下笔者的个人特点，笔者自诩并不是一个耐得住性子的人，做一件事情如果长时间得不到回报，那对笔者来说是一种打击，笔者不是不能忍受十年磨一剑，但是在笔者看来十年磨一剑，我在磨的时候也应该能够感受到，剑正在越来越锋利，如果告诉我，十年磨一剑前9年364天都看不到效果，到最后一天会一下子爆发，这是笔者不能接受的。
打一个不恰当的比喻，有些男生追妹子追到一半放弃了，别人问他为什么放弃了，很简单，因为他看不到希望，如果他能感受到两个人的感情越来越亲密，哪怕很慢，我相信他是不会放弃的，而如果每天都是热脸贴着冷屁股，谁的耐心都会被消磨干净。
因此，相信很多同学和笔者一样，大家愿不愿意努力的前提，并不是这件事情容不容易做，而是大家是否能看到希望。
当然，人生的事情我们以后再谈，笔者今天的重点是解决做项目遇到的困难，给大家介绍一下，用搭积木的思维去做项目
翻山越岭
笔者在做项目的时候发现，抛开需求分析啥的这些不谈，哪怕是笔者面对一个学校课设，需求已经给好了，从头开始做的时候往往无从下手，笔者用仅有的项目经验总结了一下
当我打开集成开发环境做的第一件事情是什么，不用说，肯定是新建项目，但是往往新建项目这看似简单的一件事情，有时候因为种种问题，有时候也要浪费掉一个小时，最后就为了输出一句Hello，World。没错，这虽然是成功了，但是这才是万里长征第一步，我花费了半天力气才运行出一句Hello，World，一想到后面还有一堆事情等着我去做，这让笔者实在是感到无力。
笔者之前也提到自学前端做了一个前端项目，后来笔者发现，在做项目的时候项目里发现需要留一个页面叫TestPage.vue，而且写路由的时候也需要给一个路径，这个页面是干什么用的，没错就是遇到一个比较复杂的界面组件的时候，脱离项目单独做看效果的。
配合上前面搭建环境输出Hello，World，做项目其实就是一步一个脚印，最后成型出完美的项目。
这本来其实是一句废话，我相信看博客的同学们，每个人都懂，但是笔者在一开始就说了，笔者是一个需要正向反馈的人，做一个完整的项目并不等同于堆积功能数量，其中还包括模块划分，界面设计，结构优化种种内容，这些和功能设计全部累加到一起，困难就太多了，等到做出来笔者已经没有力气再去做下一个了。
说句实话，做一个项目，大家千万要搞清楚我们最终的目的是什么，是比谁走的更远，而不是比谁走的更辛苦，因此，有更平坦的道路和方法尽管去走，没有必要整得像教科书上一样爬雪山，过草地，最后好不容易做出来了各种宣传自己有多不容易。翻过一座纵向距离很高，但是横向距离跨度很短的山，最后你走的路可能和平路的同学一样长，但是你还是得不到面试官的认可。
基于以上的指导思想，笔者必须要想办法将困难拆分开，把翻山越岭变成跨过小石头，在整体工作量不变的情况下，把做事情的难度降低。
多玩零件
那么比起做项目，只是做一个简单的功能，我们的工作量就大大降低了，同学们只需要设计一些功能需求啥的，最后把这一个部分去做完善就可以了，笔者一开始就提到了，我们要用搭积木的思维来做项目，积木大家还记得怎么玩的吗？事实上，我们拿到积木从来不是直接把所有的积木拼起来，而是干嘛，有时候是拿着积木在把玩
除了搭建一个复杂的工程，某种程度上我们玩积木最开心也是最有用的时刻是什么，是对积木的熟练认知设计出来的创意，有的时候花几分钟把几块积木搭建起来做一把手枪这样的小创意，带来的乐趣往往不虚花一个礼拜搭建一个埃菲尔铁塔。
那么回到项目中也一样，除了最后做出一个项目给出的完整的正向反馈，能够带来的正向反馈对各种小功能有非常熟练的认知，比方说我们要做一个导航app，那么最短路径问题就是我们必须要熟练认知的
同学们想想如果你现在完全不懂什么事最短路径问题，当你学会的那一刻是不是觉得很开心也很有用。
包括笔者在内，我相信大部分同学工作都很忙，很难有时间像在学校里一样抽出大量的时间和精力做个人项目，并且有些同学可能工作环境比较恶劣，有着上班如上坟的窘境，但是如果长期不改变，最后只有被优化的命，但是改变如果长时间没有正向反馈，相信同学们也很难坚持下去
因此笔者一开始就提到的正向反馈的重要性，所以，如果同学们目前面临着窘境，不如用搭积木的思维，先放弃全局，看局部，实现一小部分功能，把积木放在手里把玩是不是会更加开心。
整合项目
那么这个时候积木数量足够了，我们的对积木的了解也已经足够透彻了，现在就到了搭积木的时候，该怎么去做项目，笔者前面就提到，做一个完整的项目并不等同于堆积功能数量，其中还包括模块划分，界面设计，结构优化种种内容，这个时候你要做的事情就大幅减弱了，你只需要考虑怎么样把项目结构做的更合理就可以了，那么功能设计的部分怎么办呢。一句话，最简单的Ctrl C+Ctrl V，做一些小幅度改动保证贴合项目就可以了，那么肯定有同学要问了，我贴进去和项目不协调怎么办，笔者认为，这个概率不高，为什么？大家还记不记得软件开发的一大原则，高内聚，低耦合
高内聚和低耦合是软件设计中的两个重要原则，用于指导软件系统的设计和开发。
高内聚（High Cohesion）是指一个模块或一个类应该具有高度的功能相关性，即一个模块或一个类应该只负责完成一个特定的功能或任务。高内聚的模块或类内部的各个元素之间关联紧密，彼此依赖性强，共同完成一个明确的功能。高内聚的模块或类具有以下特点：
- 功能单一性：模块或类只负责完成一个特定的功能，不涉及其他无关的功能。
- 代码可读性高：由于功能单一，模块或类的代码逻辑清晰，易于理解和维护。
- 可重用性强：高内聚的模块或类可以被其他模块或类复用，提高了代码的可重用性。
- 测试和调试容易：由于功能单一，模块或类的测试和调试相对简单，容易定位和解决问题。
低耦合（Low Coupling）是指模块或类之间的依赖关系尽可能的弱化，即模块或类之间的相互影响和依赖性降到最低。低耦合的模块或类具有以下特点：
- 独立性高：模块或类之间的修改不会对其他模块或类产生影响，可以独立进行开发、测试和维护。
- 可扩展性好：由于模块或类之间的依赖关系弱化，当需要增加新的功能时，可以通过添加新的模块或类来实现，而不需要修改已有的模块或类。
- 代码复用性高：低耦合的模块或类可以被其他模块或类复用，提高了代码的复用性。
- 可测试性好：由于模块或类之间的依赖关系弱化，可以更容易地对模块或类进行单元测试。
高内聚和低耦合是相辅相成的，它们共同促进了软件系统的可维护性、可扩展性和可重用性。通过遵循高内聚和低耦合的原则，可以提高软件系统的质量，降低开发和维护的成本。
没错，如果你在开发的时候功能堆积进去发现牵一发动全身的现象，那么大概率你的软件设计并不够合理，这个时候同学们要记住：软件设计不合理，不能让功能开发来给你擦屁股，要分清楚责任，否则那就会出现大家经常挂在嘴上的屎山代码。
附注
那么今天就和大家聊到这里，希望笔者可以给大家带来一些帮助，早日克服困难，做出属于自己的独家项目，笔者接下来会更加努力的工作，给大家带来更多的经验分享，希望同学们工作顺利，早日升职加薪、当上总经理、出任CEO、迎娶白富美、走上人生巅峰，想想是不是还有点小激动呢