码农学习分析(知乎).docx

码农学习分析(知乎)

第一篇：码农学习分析(知乎)我写了一篇码农入门的文章，希望对一些学生，或者想转业的人有帮助。这篇文章是我原创的，并且已经先发到了另外一个论坛，这个论坛同学比较多，如果有兴趣要当码农了可以来瞧瞧。昨天看到有一位铁路工作的工程师说想要放弃现在稳定的职业，投入码农的怀抱，我觉得很多人把码农这个职业看得太高，也许是社会浮躁的气氛造成的，我作为一名大漩涡的坚定捍卫者，入行也快8年了，有义务进行一番科普，让漩涡众找准自己的定位。申明一点，我说得一切都是站在我自己的角度，周围的环境进行阐述，可能有坐井观天的情况，其他码农不认同也希望说出您的观点，大家互补。自我介绍：我以前得帖子介绍我自己不少了....还是简单介绍一下，我自己毕业于某渣985的计算机学院，从毕业到现在工作接近8年的时间。标题说了我自认为是一名乞丐版的全栈工程师，所以我身上的技能包很多，有的比较精，有的比较浅，后面再介绍。因为我接触的东西很多，所以对码农的各个方面都略知一二，各种文档，各种语言，各种主流的设计模式都略知一二。我下面就把整个码农的框架以及里面细项写出来，不敢保证非常准确，但是至少是有实践过的。1.码农的角色1.1编码人员编码人员会收到需求文档或者设计文档，被要求要实现什么样什么样的功能，然后进行编码实现和需求文档，设计文档要求一致的东西。编码问题具体后面说。1.2设计人员(我们所说的系统架构师其实就是高阶的设计人员)设计人员分2类，一类是UI设计人员，一类是系统设计人员会收到需求文档，被要求要做一个什么功能，要实现什么为目的，设计文档包含系统架构，语言，数据结构，数据流向，安全性评估，可行性评估等等等，产出一份设计文档交给开发进行开发。1.3需求人员需求人员会和用户或者产品经理进行需求访谈，引导用户交出合理并且准确的需求，准确的逻辑，然后产生一份需求文档，并将需求文档交于设计，进行可行性分析。可行性分析通过则设计人员会开发进行设计，编写设计文档。需求人员要求必须能够拿到准确的需求并且传达给设计，因为一旦需求错了，整个设计和开发都要重新来过，浪费的人力物力可不是一点半点。用户或者产品经理提出问题，需求人员根据需求问题找到可以实施的解决方案或者优化现有的作业流程。在完全需求的同时，提出的解决方案要尽可能的为设计开发考虑，降低设计开发成本。1.4产品经理(创意团队)考察市面上的产品，针对自己的产品进行规划，要做哪些功能，什么样的功能受众大，什么样的功能可能能打击到竞争对手等等情况进行分析，然后发展产品，对产品周期进行规划。产出为产品规划书，产品生命周期，产品介绍等等相关文档，并且和需求人员合作产生需求文档。1.5测试人员当然了就是对开发的功能，模块，产品根据需求文档进行测试，有猴子测试，白盒测试，灰盒测试，黑盒测试，压力测试，测试工具测试，自己编写代码测试等等等.....产生的文档就是测试计划，buglist文档回馈给开发人员。补充一句，所谓的bug是指凡是和需求文档不一致的结果都是bug，并不是代码出了问题才叫bug。1.6运维人员运维人员就是有管理员权限，可以操控产品，功能的一些参数来管控，对产品和功能使用是非常熟练，并且会一些简单的编码和数据库原理，第一线对系统产生的问题进行处理并且修复数据，如果能找出根源的问题就是优秀的运维。产出的东西有troubleshooting文档，问题反馈文档，另外很多运维也会写用户说明书，因为他们对系统是最熟的。1.7项目经理(PM,PMA)这部分人不是严格意义上的码农角色，只是管理项目的进度，风险，人员，成本，协调资源(和建楼房的项目经理没有本质区别)。这里就不写了。2工作流程所以整个工作流程大概就是这样用户/产品经理--->需求人员--->设计人员---->编码人员----->测试人员----->运维人员。不是指等级越高的人员编码能力越强，只是在上流的人员的容错率很低，所谓差之毫厘谬以千里，上游错了一点点，下游必定错得很惨。人员越多，也会导致流程越长，耗费在沟通上的时间就越多，沟通上容易出错的风险就越大。所以很多公司基本是设计/编码或者需求/设计是同一个人。或者一个人身兼数职，比如我，就是兼了所有角色.....3码农的基本素养3.1逻辑能力逻辑能力一定要强。逻辑能力可能有天赋的原因，可能也有后天学习的原因。逻辑能力强的人一般体现为数学，化学，物理等方面比较出众，所以理科生转码农会容易很多(比如码农里面有大量的自动化，物理系，数学系的学生)，因为理科生在逻辑方面被训练得很多。虽然我大学是混过来的，但是高等数学上和下我都拿了90多分.....逻辑能力强会让你在写代码的时候看到推算，各种算法，加减乘除的时候不会紧张，操作链表，堆栈，数组的时候得心应手。做需求分析的时候能够抓到矛盾点，能够分析出流程，功能是否合理，