构建之法，超越软件，不至于代码；

由于一直没有拿到书，又看不惯电子书，所以就一直没写阅读笔记，在对自己略感失望之余，我沉心静气地做出计划，安排时间，意外的是3天时间就读完了，略感欣喜之余，也越发深刻的感受到「阅读和思考」的重要性。

这本书有别于传统理论教材晦涩难懂，阅读性差的特点，通过一种活泼生动，别开生面的方式将「软件工程」这门学科讲得系统全面，令人印象深刻。因为是专业的学科类书籍，所以其中技术方面的知识的重要性不言自明。

开篇提到的现实世界中软件工程师的职业发展与教科书上经典的瀑布模型刚好相反的观点，让人眼前一亮。学校里教的开发流程是这样的：需求分析 —> 设计阶段 —> 实现阶段 —> 稳定阶段 —> 发布阶段 —> 维护阶段 。而实际工作中，你会发现是这么干活的：
 1.刚进入公司，开始学习维护一些已有的软件（维护阶段），当然会有个前辈带你
 2.能够在项目中改些Bug，发布小规模的更新版本（稳定/发布阶段）
 3.有机会重写或者开发一些较小的模块（实现阶段）
 4.表现好的员工，有机会设计较大的模块，写一些文档（设计阶段）
 5.逐渐成长为团队的骨干，有机会计划新的项目（需求分析）

本书提倡「做中学」的教学方法，目标是为了解决「软件工程」这个学科不好教的一个难题。顾名思义，它绝不仅仅是软件工程的学习方法，是可以延伸到学习生活中的方方面面。简而言之就是实践中发现问题，并努力解决问题，进而发现和解决更高层次的问题。这个过程就是学习的过程。 因为所有的高难度体系的共同特征就是第一章的内容需要在掌握后面某一章的内容之后才能深入了解。所以学习的过程中要学会接受一定的未知，你根本不可能一次性就搞懂所有内容，不要奢望在接近DeadLine时「毕其功于一役」，不过一个有用的建议就是努力记住（哪怕暂时不懂的）所有基础概念，随着后期的学习，你会逐渐发现对之前的内容有了全新或更深的认识。也正是这种发现和探索的过程才让学习这件事这么令人如痴如醉。

「技能的反面是什么？」，书中首先抛出了这个问题。要搞懂这个问题，首先要明确「技能」的定义。  

指掌握并能运用专门技术的能力，指技术、能力。 --百科   在掌握某项技能之前，我们肯定都是从解决低层次的问题开始，当我们无需动脑就能解决低层次问题后，我们就开始花脑力解决更高层次（中间层次的问题），它们层层递进，解决当前层次的问题才有机会进入下一层解决更高层次的问题，直到最高（可能没有）层次的时候才能称之为「技能」。

由此可见，技能的反面是解决（低层次）的问题。 书中对软件工程的各个领域（构建管理、设计、开发、测试、项目管理）都有详尽细致的探讨。

这本书详细的介绍了软件构建过程中的需求、设计、用户体验和产品发布，我所学到的，是一种团队协作与任务解决的思想。

在我的专业（这似乎是中国大学生的常态），团队合作简直是家常便饭了，无论是案例研究还是知识竞赛，无论是课堂展示还是社会实践，都需要组建团队，完成任务。囿于管理水平和相关知识的不完备性，好多团队较难实现1+1>2的效果，甚至会面临着1+0+0+……+0=1这种情况。
 
我认为推动任务流程有两种人，一种是技术推动，另外一种是管理推动。前者较强依赖于 chief programmer 的专业能力，这个人就像一头不知疲倦的领头羊，无需太多管理方面的知识，大伙跟着跑就可以。后者并不需要太强的技术能力，是通过合理的组织与控制，来使得任务流程框架化、结构化、清晰化和量化，也就是群策群力。以前我觉得前者很酷，后来我累了，有更简单的方法干嘛不用呢。
 
软件构建是一种非常精细化的过程，对于标准的要求可谓苛刻无比。任何一个环节的延滞都会导致整个项目的停工，任何一个字符的错误都会导致bug的诞生。个人理解，在所有任务中，码代码是犯错概率最大而且数量最多的，同时也是处理bug最多的。他山之石，可以攻玉，理解软件团队是如何工作的，小强们是如何死掉的，自然能够让我们在处理日常任务时更加得心应手。
 
不同于企业，软件团队往往人数较少，而这一特点也和我们大多数生活场景相符。传统管理学理论大多以成熟企业作为研究对象，而成熟的企业又大多有着几百甚至上千人。然而，大多数情况下，我们可能并不需要懂得如何管理上千人，如何统御一个大的部门，我们仅仅是需要了解，在一个部门或者项目组里，如何更高效的达成目标，就足够了。
 
因此我认为，相比于传统意义上 expanded 的理论，当我们日常生活只需要与几个人达成协调的时候，本书中提及的软件团队合作方法似乎更具有操作性。但这一结论需要进一步细化和研究，对于我这样的小白来说，可能需要了解更多该领域的知识。
 
这本书最大的特色就是生动，不同于教科书般的枯燥，也没有偏哲学的语言，就是具体、实用且代入感强。阿超、果冻、小飞和小李，猪、鸡和鹦鹉，萝卜和白菜，他们或者代表了一个公司中的几类人，或者代表了一个团队中的几个角色，任何曾经有过团队合作经历的人都可以在其中寻找到自己的影子，大部分遇到过的团队困境都可以在这本书中寻找答案。
 
构建之法，又不止于代码。一切管理的问题都是人的问题，没有通篇枯燥的技术讲解，这本书聚焦于软件团队中对人的本质的挖掘。讲了团队的发展阶段，讲了如何考核绩效，讲了如何推进任务，讲了流程的控制。剥离书中涉及技术的部分，关注对自己有独特价值的章节，能让我们从感受另一个世界（程序员的世界）是如何协调合作的。
 
就像不同的角度会画出不同的鸡蛋一样，我想，不同的人会在书中寻找到不一样的价值。也许程序员们发现了技能提升和职业进阶的宝典，也许教师们找到了培养未来花朵的良方，但对于一个局外人，我所收获的，是对团队协作与流程控制更深的体会。
 
与其说，我对这本书感慨颇深，更不如说，这本书恰到好处的写作，唤起了一段时间内我内心的思考与疑问，促使我关注如何从管理的层次让团队任务更简单。
 
所谓管理并不是leader的专利，所有的团队协作都有管理的影子，了解一种更新颖的管理思维，能够帮助我们以一种更清晰的视角去解决问题。当然，理论先行，实践跟上，下一步，就是在生活中去慢慢尝试，让自己的团队流程更加流畅，毕竟理论只有应用才能让生活更美好吖~

读《构建之法》有感