上午在给新上的项目排期，之前在实验室做项目阶段，最怕的就是估时间，估多了甲方不同意，估少了自己做不完，但这个问题肯定要解决，从启蒙那学了估期的方法，将任务分解，分成小模块，感觉难度不大就 0.5 天，感觉比较复杂就 1 天，感觉非常复杂就继续划分模块，再将这些划分出的模块进行排期，用这种方式很容易就可以将任务拆解完，最后将每个模块的估期汇总，便可以得出整个项目需要的时间，联调的时间根据接口数量以及复杂度进行估算，最后再给自己两天 buffer 时间以防万一。
这样的方式使得项目排期变得不再无处下手，让整个流程清晰，不过对于开发的要求就相对严格，必须在规定的时间之前完成相关模块的开发，这就回到之前提到的，给自己一个合理的时间规划，并且严格执行。这应该是一个非常基础的习惯，但是之前没有养成，只能现在来补，亡羊补牢，为时未晚。
中午吃饭时，启蒙问我在公司的感觉如何，个人而言，对这家公司非常有好感，很幸运能加入，他鼓励我好好加油，说这段时间会是成长最快的时间，对此我深信不疑，这段时间我能感受到我的进步，接下来还有更多的挑战，希望通过这些挑战上升到一个新的境界，因此不能放松对自己的要求。面对未来，即紧张，又兴奋。
这段时间想清楚了一件事，技术没有非此即彼。没有最好，只有最合适。记得来公司面试，二面我问教主，为什么后台不统一用 JAVA 或者 PHP，前端没有统一使用框架，为什么不用 vue，而是用 react。现在看这个问题，大概因为一个人做项目做久了，太理想化，学校作业和实际项目工程差距很大。
学生时代，在项目里遇到很烂的代码，看不顺眼就想着重构，在百度实习期间也看过很多很烂的代码，但不敢碰，原因是因为不知道改了之后会出现什么问题，这就是问题关键所在，什么是好代码？什么又是烂代码？在生产环境中，首先需要确保的是项目的稳定性，保证项目的正常运行，所做的一切改动的前提都应该是项目的稳定运行。我时常吐槽烂代码都是以开发者的角度看问题，出于代码洁癖，并没有从项目的角度看待问题。从这个角度看，我可能是个好的编码者，但是不是一个合格的开发者，开发者应该以解决问题作为思考的方向，而不是为了编码而编码，只有编码者才会纠结编码方式，开发者只会考虑解决方案。但往往好的开发者都会养成好的编码方式。
前几天我在 less、sass、stylus 之间纠结，思考哪一个才是最佳的方案，最后发现这个问题本身就是个伪命题，因为作为一个合格的开发者，我应该三者都会，在处理问题的时候立刻上手解决问题，我可以选择一个作为个人偏好，语言之间没有最好，只有最合适，在需要的地方使用合适的语言，理解了这一点，顿时感觉视野开阔。
反思之前非此即彼的想法，实属懒惰的想法，学习好一门框架也好，构建工具也罢，难以掩盖的是我懒惰，不想学习新框架新工具的小心思。因此面对选择时，我会很自然的选择自己熟悉的框架或者工具，而不是出自于项目需要的考量。这样看来，我永远不可能成为一个好的开发者，
不应该局限一隅，哪有什么最优解，只有相对最合适的解。
网友评论