Fourty Two

云拿转正小节

以下是原文章《近来新工作,及喝饮料时的一些思考》的节选,因为类似目前正在更新的《四十二篇系列》,所以放到这儿啦。

以下是原文章《近来新工作,及喝饮料时的一些思考》的节选,因为类似目前正在更新的《四十二篇系列》,所以放到这儿啦。

有关问题解决

过去我沉迷与解决代码问题不能自拔,自恃在代码中前进了一步,忽略了多做一些思考。新工作进行的第四天,我就接手了一个编写多语言组件的任务。新工作带来的热情之火,使得我开发过程三下五除二就完结了。只是,其后在处理一个代码逻辑疏漏时,没有进一步思考,随意给了一个浅显、只顾及眼前的修复,最终导致线上出现用户交互问题。在我印象中感觉这像是第一次直面线上问题,让我很是担心。它让我回想起大三那会儿刚开始学习 JavaScript 时我有过的一种“我都不知道代码怎么就跑起来了”的感觉。这种“知其然不知所以然”的态度,在某种程度上还是映射到解决问题时的目光短浅上。

能不能根据现有情况做更深一步的思考,是类似事件给我带来的经验与教训。前端,尽管是一个综合、宽泛的定义,但还是脱离不了脚本逻辑和用户界面两个核心。能否站在代码的角度,考虑更多边界情况,考虑更多代码运行原理;能否站在用户的角度上,考虑需求与交互的合理性,考虑产品的使用体验...这些都是从页面仔成为攻城狮所要承担的必要责任。

代码与需求

我始终记得我在乘云时和产品撕扯需求的情景。当时就好像感觉技术和需求站在天平的两侧,一个对立面上。现在看来却不然,除了某些由于制度原因导致开发或者产品任意一方占有压倒性的话语权情况的公司,大部分实际开发工作应是更需要技术开发做到如何平衡技术与需求。换言之,不论是站在技术或者站在业务的角度完成需求,都不算绝对正确的做法。我们不妨站在公司的角度考虑问题,其实所有需求的完成都是在尽可能优雅满足客户的同时减少内耗。开发若是能朝这个方向靠拢,才能算作做到了平衡。《阴翳礼赞》中有句话讲明暗关系如何早就东方建筑美学,放在这也倒颇有番意味:“美不存在于物体之中,而存在于物与物产生的阴翳的波纹和明暗之中”。如同没有明暗变换也就没有夜明珠的闪耀,没有技术与业务之间的互相拉扯,也就体现不了开发的闪烁之处。这是我充满憧憬且不断学习的方向。这不仅仅要求了编码速度,还隐形地包含了如编码质量、团队协作等各方面的问题。希望我能够在接下来的编程实践中更加深刻地体会到这些东西。

项目与协作

团队协作绝对不止管理好项目代码这么简单。如何与团队成员沟通,如何推动项目等等都是我进来实际碰到的问题。尤其在推动需求的完成中我所遇到的难点——需求本身并不是一块圆滚滚的石头,也许是方形三角形或其它形状,总是若是脱离了人力的推动,他就坐在地上不动了。前端作为一个和后端、设计、测试都走得比较近的角色,似乎被隐形要求它与人协作的能力要高,这意味着它有着天然地推动项目向前的潜能。有关这点我还在实践中不断反思,目前倒是没什么成型的定论。


Copyright © 2024 Lionad - CC-BY-NC-CD-4.0