不想当PM的DEV不是好QA
从我还是一个实习生的时候，我的mentor就告诉我：不会从产品的角度去思考问题，就永远成为不了一个优秀的开发。这句话，我一直铭记于心。
能够单纯从事自己份内的工作，沉浸于技术钻研、设计重构，不断追求代码的简洁和优美，自然是一种令人向往的体验。心无旁骛，不需要纠结各种corner case，不用操心用户的complaints，这是美好的梦想；现实是，作为dev，实现功能的同时，必须考虑方方面面的反馈和影响，也免不了频繁地和PM、QA，乃至PA，打交道。
DEV作为一整条开发流程的中间环节，既要和上游PM、Designer对接，充分了解项目的需求和功能细节；又要和下游的QA、PA沟通，根据实际使用中收集到的反馈，不断精雕细琢，使最终产品达到期望值。因此沟通与协作不仅不可避免，反而是DEV工作中非常重要的组成部分。这与其他人眼中，DEV通常沉默寡言、消极被动的形象大相径庭。对于一些初入职场的DEV新手来说，可能也有类似的误解。
良好的沟通，可以帮助我们的开发工作事半功倍，确保信息的正确传达；因为误解导致的无奈返工，相信各位在工作中已经见过很多，无疑对各方来说都是痛苦的折磨。所以反过来说，做好沟通，就是一本万利的事情；即使从公司的整体角度来说，也可以提升整体效率、充分缩短开发周期。但要真正做好这一点，也很难。难就难在，每个人思考问题的时候，总是习惯从自己的角度出发，各有各的重点关注，各有各的专业术语；你说A，我说B，正所谓鸡同鸭讲，争了半天根本不在一个频道上。看看下面几句话，是不是曾经从你口中说过？
“在我的机器上没有复现？🤔”
作为DEV可是太常遇见这种情况了。往往PM或者QA拿着测试机跑过来说：快看，这里有bug/这里看起来怪怪的！然后DEV拿起自己的测试机一看，一脸懵逼：没啊，我这里好好的。复现不了啊，没法修～🤷这时候的PM/QA就该着急上火了：这是bug呀，bug就得修！
实际上，双方的想法都没有错。尽管想修复bug的情绪可以理解，但有条件提供稳定、可重现的步骤也是相当合理的。找bug出处就像看病，表现出来的问题就像病症，相似的症状有时可能是完全不同的原因引起的。如果有能力提供复现的步骤，就像提供了病人身上跟疾病有关联的习惯特征，可以很大程度上缩小病因的范围。这其实跟医生的望闻问切一样，是帮助诊断疾病的一个不可缺少的重要步骤。
除了一些显而易见或一拍脑袋即可搞定的bug，大部分的问题都需要像探案一样漫无目的地仔细排查和推理，如果没有重现步骤，就只能碰运气，消耗大量时间去解决。所以向PM和QA好好解释重现步骤的重要性吧，下次再遇到这样的问题时，他们一定会深深滴理解和支持！
“这不是bug，这是需求🙅”
这句话常常在开发阶段的后期出现，当PM满怀欣喜准备验收成果时：却发现功能的很多细节和自己想象的对不上？然后冲过去一条条和DEV列bug，列的越多，DEV越委屈：这哪里是bug，这是需求呀！PM当然不会接受这样的说法，因为在他们看来，最终效果没有达到预期，那就是有问题，就等于bug；但DEV说错了吗，也没错，后加的细节是原计划外的，那就是新的工作量，也就是新需求。
那么问题到底出在哪里呢？表面上是产品的bug，本质是前期的文档细化不到位和沟通的不充分。每个PM在kick off前心里肯定都有一条完整的功能follow和用户使用场景，但是写到文档中可能就变成了一句话，再到DEV理解并技术实现，中间隔了千沟万壑。每个环节偏了一点点，最后就差了十万八千里。
要想避免这个问题，就得不怕沟通，反复确认。DEV从一开始的kick off阶段起，对任何PM有疏漏的或者描述模糊的地方，都应该尽早地主动提出来。PM不可能面面俱到，因为他们习惯从用户角度去考虑，常常想到的都是最普遍的应用场景；但是DEV可以主动补足，因为编写代码时不可避免都需要穷尽所有corner case。DEV不光是被动的执行者，多从PM角度看问题，结合自身的思维优势，可以成为主动的参与者。
“这个做不了 🤷”
这可能最让PM无法理解的一句话了。因为往往他们提出的功能，“XXX App 早就实现了呀”。确实，此“做不了”非彼“做不了”， 往往不是技术上做不到，而是往往受制于各种因素，没有可行方案罢了。比如说，做一个没有现成库的控件，得从零开始造轮子，花上几天时间才能做完，那当然不划算；比如说，有的受限于第三方库，现有的功能不足以支持PM的要求，那也只能退而求其次；再比如说，技术债欠的多了，要做就得全部推倒重来，排期又得超时。实际编程时，总会遇到各式各样的现实问题，路走不通，只能换一条路再走。
PM不可能像DEV一样去思考，所以简单粗暴的一句“这个做不了”，只会火上浇油，让项目进程走进死胡同。多用通俗易懂的话而非技术术语去描述实际施行遇到的障碍，会帮助PM更好理解我们开发的“难处”，重新审视整个项目的scope，合理取舍真正需要保留的功能需求。而且在以后的工作中，PM也会渐渐习惯把技术细节考虑在前期设计中，缩短预期和实际成果的差距。
DEV也可以多从PM的角度去思考，该功能需要达到的目的是什么？是更流畅的操作体验，还是更突出某一块页面区域，或者是引导用户去使用某个功能？理解了PM设计的用心，我们就可以尝试使用其他一些更简单可行的技术方案来达到同样的目的， 比如iOS的毛玻璃效果，android就可以使用图片高斯模糊+半透明遮罩达到类似的效果。比起简单的拒绝，提出一个合理的替代方案，一定更容易和PM达成一致。
项目的顺利进行很重要，产品的质量把控更重要
当开发完成以后，就要进入测试阶段。经过QA的层层把关，才能最终将产品推送至用户。不论是功能完整性的验证，还是逻辑正确性的检验，抑或是产品稳定性的保证，都需要在这一阶段完成，说是最关键的环节也不为过。那么如此重要的工作，仅仅只一股脑地扔给QA们去搞定，合理吗？当然不是，作为DEV，脑中同样也应该有QA这根弦，贯穿在整个开发测试的过程中，时时紧绷。最基础的，就是在每个功能模块开发完成以后，就应该安排一部分时间对该模块进行简单的测试，确保实现了应有的功能且没有崩溃。至于功能模块划分到多细，测试全部的分支还是主要分支，使用何种测试方式，都可以因人而异，合理调整。
设计测试用例时首先需要关注用户的需求和使用情况。代码不仅仅是实现功能，还要满足用户的期望。在条件允许的情况下，也可以和用户充分沟通。这样可以帮助我们编写更具用户友好性的代码，同时缩短测试时间和保证用户满意度。另一方面，用户的反馈有助于我们考虑边界条件和错误处理，以确保应用程序以最佳状态运作。
作为DEV， 还应该了解常见的测试方法和流程，以及测试过程中使用的工具，确保质量和效率。尽管不是每个DEV都需要经常进行测试，但了解不同层次的测试（如单元测试、集成测试、系统测试和验收测试）可以帮助我们在开发中正确实施代码。我们可以使用测试用例来指导自己在编写代码时使用逻辑清晰的方法，并保证代码能够通过测试。自动化测试工具和框架的使用也可以提高代码的可测试性和可维护性，并使测试过程更为简单和快捷。从单元测试中学会模拟和隔离应用程序的部分，也有助于更容易地进行测试和调试。
最好的学习方法，就是主动参与测试过程，以及向测试团队学习，能够更全面地了解所开发产品中存在的问题和缺陷，进而提高代码的质量和优化开发流程。在测试过程中，需要考虑各种情况下的应用行为和响应时间，可以弥补开发过程抽象思维引起的缺漏，提高产品在实际应用中的稳定性。学会从QA的角度思考问题，学会用QA的思维审视自己的代码，多考虑用户的需求和使用情况，多考虑性能、安全性、可扩展性和用户友好性，有助于全面优化我们的开发工作，提高代码质量，并以高效、准确和优质的方式进行代码编写。