project thinking part.2

  • 方案是建立在合理的时间点、合理的资源分配前提下的,什么时间出什么方案。

  • 方案的评估应该考虑的不是人员的情绪,而是方案的可行性、可操作性、复杂度上。

  • 写代码不只是为了证明自己的能力,而更应该站在用户和产品化的角度来定方案、推翻不合理需求,好处:
    避免太多不必要的二次修改;
    错误的时间投入。

  • 代码上线前,一定经过自身严格测试再上线,以免导致一些莫名其妙的问题,以致需要投入另外的时间来修复。
    翻译:这个需求在6个小时内搞定,时间比较充裕。你用3个小时完成了这个需求。却带来了隐患问题,以致后期需要占用其他事情的时间,花4个或者5个小时的时间来定位和修复带来的问题,得不偿失。

  • 针对一些临时需要处理和解决的问题,摆正心态,冷静思考和面对,不应该急他人所急跟着瞎着急。
    翻译:领导要你临时处理一个问题,希望你能尽快解决掉这个问题顺便也考验你应对紧急情况的能力。你慌忙之中匆匆改动了一些东西,过了时间,发现问题没解决,orz。
    自我疗养法:代码出了问题,你只是一个程序员,这部分代码还不是你写的,关你屁事。上面要你修复,是给你表现的机会,而不是一个重担。就算原因在于你,发生都发生了。急一分钟,问题持续一分钟,于事无补。

  • 针对当前代码和架构所产生的系列问题以及产品的更新迭代的平衡点。
    假设:现在有20个人PC前端团队,在日常活动交由产品化TMS搭建的前提下,开个项目拉10个前端出去重写重构代码,10个人处理业务和产品需求,好,没问题。
    现状:现在只有5个人,业务需求堆积,活动TMS方案未出每月轮五六个活动的情况下,每次重复几遍各种各样已知的系列问题,何苦何苦。

  • 结构决定架构,数据结构决定算法。

  • 前期的技术选型以及目标确立,需要谨慎调研。选型的失败或者定位的错误,大部分情况会导致后期花十倍的人力物力去重构、去订正。

  • 聪明是你的优势,不应该成为你的短板。

  • 少说话多读书,为人谦逊低调,避免口舌是非。
    在所钻的领域内专业博学才能侃侃而谈;
    适当的场合和时间表达自己的看法、想法和立场。