《程序员修炼之道-从小工到专家》书札

相信大家在之前应该都把这本书前面的内容都稍作浏览了，而且说的应该都会大同小异，那么在时间不多的情况下看这本书，我就决定直接从后面几个章节开始看了。

全书分有8个大章节，分别是：

注重实践到哲学

注重实践的途径

基本工具

注重实践的偏执

弯曲、或折断

当你编码时

在项目开始之前

注重实践的项目

接下来我到选择是其中的1个章节——“在项目开始之前”。

在项目开始之前

需求之坑

完美，不是在没有什么需要增加、而是在没有什么需要去掉时达到的。

这句话是在本节一开头到时候出现到话语。

那么需求是什么？

书里面到说明是：其为需要完成的某件事情的陈述。然而作为前端，从字面上也就是我的理解了，这里我还没能力进行解读，书中还进行了一些需求文档的建立和规范，有空可以了解下。

---

解开不可能解开到谜题

解不开的谜题在书里有进行概念性的描述，而我的理解就是它分有两种：

其一，客观上绝对性的难题

比如前端方面的几个暂时还未发现解决方法的问题：

通过前端的html、js、css是没办法生成出一张带有格式的图片，类似jpg图片、png图片等，只能通过svg或data-img代码等方式进行绘图，真正生成需要借用其他语言进行处理。

通过前端上述语言也无法对文件进行写入，仅仅只能进行对文件读取。

比较大方面广泛所被认可的是在PC端上IE浏览器低版本的兼容性了，虽然有些兼容能够通过js和css的hacker进行处理，但是有些还是没办法实现的。

其二，主观上先入为主认为无法解决的难题

这里就得跟产品和设计进行沟通了，在公司也有几年了，然而在系统中心中部门与部门之间的沟通几乎没有，即使有也只能在产品审核时进行的一些讨论，以及每周甘特图进度描述上，还有出现问题进行的提问解答，但是这绝对不是所谓的技术上的沟通。

那么，怎么算是技术上的沟通？我认为以一个观点上引导出来的讨论才叫做技术上的沟通。这里有几个关键词：观点、讨论。

观点，首先是一个目的。

讨论，不是两个人之间的事。

产品和设计想要成就一个结果，主观上认为技术方面无法实现，那么就不会与技术沟通，那么也就不会就问题进行记录，这之间三者就不会存在一个值得并且能够进行的讨论，这也就无疾而终了，就像21集和22集中郑秋冬和熊青春身上所发生的事情了。

一定有更容易的方法

然后，有些时候产品和设计有自己的想法过来，从大的方向为了下技术能否实现，那么技术说ok，那么其认为已经有了结果，其中存在的问题就是你们想的定然比我想到的多了。

因为作为以想象为主的职位的3个职位——运营、产品、设计，道生一，一生二，三生万物，让想象的思维向外扩散，真正的结果往往让作为产品输出的职位——前端和后台吃惊不已，因为一个页面从内容到展现到功能往往比先前多了，或者相对复杂，对于公司现状——项目多、时间短而言，从五个职位上让项目到实现都是一个大大的问号。

那么，项目前期和中期的准备，为什么不在产品输出前将多个想法写下，实行3次以内为期不到1个钟从产品到后台/从产品到前端和后台/从设计到前端和后台的讨论，这不是产品到过审，仅仅是让双方进行前期的沟通，互相了解对方要做到什么程度以及能做到什么程度。

---

等你准备好

是良好到判断，还是拖延

这个标题让我有些难以理解，然后我这里再诠释一下这句话。

项目启动，那么首先我得去先全面的了解这次是要做什么吧。接着我会对这个项目中的难点进行代码构建，从我这边的说法就是demo，从产品说就是原形，从设计说就是草图，从后台说就是“我也不知道了……

挑战

从demo开始之后有好的结果，也有让自己觉得是在浪费时间，这里也有两种选择：

一种挑战——换另一种思维或方法继续进行，不能用这个html标签，那么换另一个标签；不能样式进行实现，那么换js实现；这种方法执行起来有些臃肿，尝试使用先进一点的css3代替实现。

另一种，即使合理的沟通，换另一种展现方式、能够让后台进行方法的提供。

---

规范陷阱

貌似我们并没有什么规范呢？呵呵……

这里有个我自己的看法，并不是一个要求，仅仅是一个建议，当然上一次我的建议让你们在我们开发的部落多了个“技术在线”板块，算是有利有弊，最终结果还是每个人的看法，这里不多说。

那么我想是否统一下代码格式？

· 到底是用空格还是用tab作为代码到缩进方式

· js代码最后面是否加入“；”

· 前端是否应该整理出部分模块（比如多种弹窗、toast的代码）的代码到后端？

· 设计是否做多处地方统一并尽量少的进行弹窗样式的修改

· 页面最终上线是否将js代码、css代码分离成文件形式在页面中进行调用

……

—— (｡ì _ í｡)