• 公司规模
  • 后台人员
    • PM
    • RD
    • QA
    • OP
  • 福利待遇
  • 公司期望
    • 需求评审
    • 项目管理
    • 单元测试
    • 代码评审

员工能力

能力有很大差别。

代码质量

  • 已有代码质量不高。需要在后续过程中慢慢重构。
  • Python 代码是 C++ 风格，类以 C 开头。写法也比较随意，没有 pythonic。看书看代码，练习。
  • 另外代码中没有单元测试，如何保证质量? 在有限的资源下，要求高的测试覆盖率无疑是奢求。但是至少要保证核心逻辑单元测试。充分而且随着代码的更改而更改。
  • 关于测试，目前没有看到哪个功能有详尽的测试用例, 这样必然会导致功能点漏测。 本来人手不足，就需要每个人独当一面，也就意味着测试不充分，再没有测试用例，无疑雪上加霜。 还有，每个人基本都是自测，而自测往往很难发现问题。是不是可以写测试用例，然后交换测试？

代码评审

  • js 代码风格松散，代码评审经常有大量关于风格的更改，导致代码评审耗时，且容易引入 bug。需要强调代码风格。良好的习惯才能保证高的效率。
  • 代码提交过程中多个 story 的东西混合在一起，到时候出了问题都不知道是具体哪个 story 中引入的。严格执行 code review。不能为了一次的速度，而导致后边多次 exception。

架构设计

需要在初期进行慎重设计，要不后期要削足适履，要不推倒重写，无论哪种都对业务拓展有很大影响。

grpc 虽然有很多优秀地方，但毕竟还没有正式版，而且还不太成熟，不适合选来做核心业务。 需要一些已经在实践中证明了的框架来使用。

需求评审

需求不是非常明确。 只是大体上描述了一下想要做成什么样子，跟客户讲的需求差不多。 需要深挖和概括，体现出轻重缓急，并准确的表达出来。 然后才能进入需求评审。

项目排期

项目排期感觉还是不够明确。 并不是说 leader 不专业，或者不会排期，而是很多不可控因素的存在，导致了排期非常困难，而这种困难进一步导致了排期模糊。 CAE 专家还没有到公司来。另外 11 月底就要发版本的，从现在开始大概只有一个多月。还有很多东西要做。 OpenFOAM 的东西感觉已经有了 delay，更重要的是还没有弄清楚具体困难在哪里。 核心业务没有正常推进。

任务分配

目前是先大概按照人员水平完成初步分配，然后根据进度进行调配。 我觉得可能那种任务发出来，大家认领去完成更具有效率, 也能调动积极性。但是也有弊端。只适用于一些优先级较低的任务。 另外有些任务安排需要 leader 去亲自确认，看看实施情况，这样难以长期发展，而且劳心劳力，效率不高。

文化氛围

文化氛围感觉比较沉重。放假通知竟然用红头文件。