简读:
- 确保实现需求的起源是来自自己或周围的人,只有这样才能保障这个想法能落地。
- 选择自己最熟悉的技术方案。
- 忘掉代码质量吧,只要没有 Bug,怎么开心怎么写。
- 专注,保持一个规律的代码提交频率。
确保实现需求的起源是来自自己或周围的人,只有这样才能保障这个想法能落地。
Side project 最大的阻力是开发者自己的放弃,前期构思猛如虎,开发阶段慢如狗。
随着开发时间的推移,去做一个自己没有的需求,那和上班有什么区别,这种心态会伴随着项目开始而埋下,到最后变成一个摧毁项目的恶魔。
最主要的是做出来的东西,要解决自己的实际需求。只有这样心态才能更平稳,将项目孵化出来,因为做的再差,还是有自己这位忠实的用户。
选择自己最熟悉的技术方案。
Side project 另一个不可取心态:顺便锻炼下技术,用一些新颖的还不会的框架。
一部分人容易走到这个误区,工作中重复的劳动已经限制了个人技术的成长,希望在新的项目中启用一些更好的技术来丰富自己的能力。
实际上若不是工作中使用的技术太过落伍和不稳定,我个人不建议更换技术栈,因为你无法预见新的技术带来的问题,导致项目在进行到一定进度后因为不熟悉或其他原因导致项目受限于技术瓶颈。
学习新东西是非常好的一个习惯和热情,但是 Side project 最重要的是将一个 idea 变成一个真实的可以帮助到你的软件。
忘掉代码质量吧,只要没有 Bug,怎么开心怎么写。
通过前文,选择了自己熟悉的框架,这里就要介绍下 Side project 的另外一个阻碍,代码质量。
追求代码质量是非常好的习惯,但是我希望在开发自己的 Side project 中以可阅读的标准来要求自己就足够了,不要太纠结于命名,方法抽象,面向对象思想等。
因为一个想法在构思阶段是最开心的,在开发阶段是很痛苦的,一切都规划好后,只是体力和时间上的付出,如果在代码质量上追求过度,开发进度的受限制,很容易打击开发的热情。
快速的产生一个可以用的版本才是关键。
专注,保持一个规律的代码提交频率。
我对自己的要求是,每天最少 1 个 commit。
你可以根据自己的时间和工作繁忙程度来调整。
Side project 考验的是耐心,前期需要快速的冲刺实现一个可用的版本,但是之后的细节打磨和维护也至关重要,养成一个持续且良好的 commit 习惯,可以保证自己在每天不论任何状态下,都去做一些推进。
心情不好,可以做一些很简单的修改,比如改改之前的错别字?修改下之前简写的变量名?…
心情好的时候,做一些 bug 修复,或者新功能的规划和开发。
”前期构思猛如虎,开发阶段慢如狗“一针见血,我GitHub里还躺着很多空仓库,阿里云里还躺着还几个域名😂
哈哈哈,不都是这样,项目没起来,最终手里多了好几个域名