【笔者感悟】笔者的学习心得【五】

个人经历

  今天笔者想来和大家讨论一下,首先给大家介绍一下笔者的个人特点,笔者自诩并不是一个耐得住性子的人,做一件事情如果长时间得不到回报,那对笔者来说是一种打击,笔者不是不能忍受十年磨一剑,但是在笔者看来十年磨一剑,我在磨的时候也应该能够感受到,剑正在越来越锋利,如果告诉我,十年磨一剑前9年364天都看不到效果,到最后一天会一下子爆发,这是笔者不能接受的。

  打一个不恰当的比喻,有些男生追妹子追到一半放弃了,别人问他为什么放弃了,很简单,因为他看不到希望,如果他能感受到两个人的感情越来越亲密,哪怕很慢,我相信他是不会放弃的,而如果每天都是热脸贴着冷屁股,谁的耐心都会被消磨干净。

  因此,相信很多同学和笔者一样,大家愿不愿意努力的前提,并不是这件事情容不容易做,而是大家是否能看到希望。

  当然,人生的事情我们以后再谈,笔者今天的重点是解决做项目遇到的困难,给大家介绍一下,用搭积木的思维去做项目

翻山越岭

  笔者在做项目的时候发现,抛开需求分析啥的这些不谈,哪怕是笔者面对一个学校课设,需求已经给好了,从头开始做的时候往往无从下手,笔者用仅有的项目经验总结了一下

  当我打开集成开发环境做的第一件事情是什么,不用说,肯定是新建项目,但是往往新建项目这看似简单的一件事情,有时候因为种种问题,有时候也要浪费掉一个小时,最后就为了输出一句Hello,World。没错,这虽然是成功了,但是这才是万里长征第一步,我花费了半天力气才运行出一句Hello,World,一想到后面还有一堆事情等着我去做,这让笔者实在是感到无力。

  笔者之前也提到自学前端做了一个前端项目,后来笔者发现,在做项目的时候项目里发现需要留一个页面叫TestPage.vue,而且写路由的时候也需要给一个路径,这个页面是干什么用的,没错就是遇到一个比较复杂的界面组件的时候,脱离项目单独做看效果的。

  配合上前面搭建环境输出Hello,World,做项目其实就是一步一个脚印,最后成型出完美的项目。

  这本来其实是一句废话,我相信看博客的同学们,每个人都懂,但是笔者在一开始就说了,笔者是一个需要正向反馈的人,做一个完整的项目并不等同于堆积功能数量,其中还包括模块划分,界面设计,结构优化种种内容,这些和功能设计全部累加到一起,困难就太多了,等到做出来笔者已经没有力气再去做下一个了。

  说句实话,做一个项目,大家千万要搞清楚我们最终的目的是什么,是比谁走的更远,而不是比谁走的更辛苦,因此,有更平坦的道路和方法尽管去走,没有必要整得像教科书上一样爬雪山,过草地,最后好不容易做出来了各种宣传自己有多不容易。翻过一座纵向距离很高,但是横向距离跨度很短的山,最后你走的路可能和平路的同学一样长,但是你还是得不到面试官的认可。

  基于以上的指导思想,笔者必须要想办法将困难拆分开,把翻山越岭变成跨过小石头,在整体工作量不变的情况下,把做事情的难度降低。

多玩零件

  那么比起做项目,只是做一个简单的功能,我们的工作量就大大降低了,同学们只需要设计一些功能需求啥的,最后把这一个部分去做完善就可以了,笔者一开始就提到了,我们要用搭积木的思维来做项目,积木大家还记得怎么玩的吗?事实上,我们拿到积木从来不是直接把所有的积木拼起来,而是干嘛,有时候是拿着积木在把玩

  除了搭建一个复杂的工程,某种程度上我们玩积木最开心也是最有用的时刻是什么,是对积木的熟练认知设计出来的创意,有的时候花几分钟把几块积木搭建起来做一把手枪这样的小创意,带来的乐趣往往不虚花一个礼拜搭建一个埃菲尔铁塔。

  那么回到项目中也一样,除了最后做出一个项目给出的完整的正向反馈,能够带来的正向反馈对各种小功能有非常熟练的认知,比方说我们要做一个导航app,那么最短路径问题就是我们必须要熟练认知的

  同学们想想如果你现在完全不懂什么是最短路径问题,当你学会的那一刻是不是觉得很开心也很有用。

  包括笔者在内,我相信大部分同学工作都很忙,很难有时间像在学校里一样抽出大量的时间和精力做个人项目,并且有些同学可能工作环境比较恶劣,有着上班如上坟的窘境,但是如果长期不改变,最后只有被优化的命,但是改变如果长时间没有正向反馈,相信同学们也很难坚持下去

  因此笔者一开始就提到的正向反馈的重要性,所以,如果同学们目前面临着窘境,不如用搭积木的思维,先放弃全局,看局部,实现一小部分功能,把积木放在手里把玩是不是会更加开心。

整合项目

  那么这个时候积木数量足够了,我们的对积木的了解也已经足够透彻了,现在就到了搭积木的时候,该怎么去做项目,笔者前面就提到,做一个完整的项目并不等同于堆积功能数量,其中还包括模块划分,界面设计,结构优化种种内容,这个时候你要做的事情就大幅减弱了,你只需要考虑怎么样把项目结构做的更合理就可以了,那么功能设计的部分怎么办呢。一句话,最简单的Ctrl C+Ctrl V,做一些小幅度改动保证贴合项目就可以了,那么肯定有同学要问了,我贴进去和项目不协调怎么办,笔者认为,这个概率不高,为什么?大家还记不记得软件开发的一大原则,高内聚,低耦合

高内聚和低耦合是软件设计中的两个重要原则,用于指导软件系统的设计和开发。

高内聚(High Cohesion)是指一个模块或一个类应该具有高度的功能相关性,即一个模块或一个类应该只负责完成一个特定的功能或任务。高内聚的模块或类内部的各个元素之间关联紧密,彼此依赖性强,共同完成一个明确的功能。高内聚的模块或类具有以下特点:

  1. 功能单一性:模块或类只负责完成一个特定的功能,不涉及其他无关的功能。
  2. 代码可读性高:由于功能单一,模块或类的代码逻辑清晰,易于理解和维护。
  3. 可重用性强:高内聚的模块或类可以被其他模块或类复用,提高了代码的可重用性。
  4. 测试和调试容易:由于功能单一,模块或类的测试和调试相对简单,容易定位和解决问题。

低耦合(Low Coupling)是指模块或类之间的依赖关系尽可能的弱化,即模块或类之间的相互影响和依赖性降到最低。低耦合的模块或类具有以下特点:

  1. 独立性高:模块或类之间的修改不会对其他模块或类产生影响,可以独立进行开发、测试和维护。
  2. 可扩展性好:由于模块或类之间的依赖关系弱化,当需要增加新的功能时,可以通过添加新的模块或类来实现,而不需要修改已有的模块或类。
  3. 代码复用性高:低耦合的模块或类可以被其他模块或类复用,提高了代码的复用性。
  4. 可测试性好:由于模块或类之间的依赖关系弱化,可以更容易地对模块或类进行单元测试。

高内聚和低耦合是相辅相成的,它们共同促进了软件系统的可维护性、可扩展性和可重用性。通过遵循高内聚和低耦合的原则,可以提高软件系统的质量,降低开发和维护的成本。

 

没错,如果你在开发的时候功能堆积进去发现牵一发动全身的现象,那么大概率你的软件设计并不够合理,这个时候同学们要记住:软件设计不合理,不能让功能开发来给你擦屁股,要分清楚责任,否则那就会出现大家经常挂在嘴上的屎山代码。

附注

  那么今天就和大家聊到这里,希望笔者可以给大家带来一些帮助,早日克服困难,做出属于自己的独家项目,笔者接下来会更加努力的工作,给大家带来更多的经验分享,希望同学们工作顺利,早日升职加薪、当上总经理、出任CEO、迎娶白富美、走上人生巅峰,想想是不是还有点小激动呢

热门相关:亿万盛宠只为你   修真界败类   戏精老公今天作死没   锦庭娇   万古至尊