模板里变量没填全，发出去就成半截话还得解释一遍
一封写得很顺的通知，收件人却回过来问是不是漏了东西，开头那句称呼空着，中间还留着一个没换掉的名字。查下来是那批数据里少了一项，发信那头照旧把模板拼出去，谁也没在发出前看一眼。一、先把要填的项列清
每份模板用到哪些变量、哪些能空、哪些空了就不该发，列成一张不长的表。不列这一下，拼的时候全靠程序里散着的几处判断，换个人改模板，很容易漏掉其中一处。培训里放两封当时拼坏的真实例子，比列十条正确写法管用，缺的是哪一项、后来怎么补的，讲透之后同类事会少很多。
表里也写清每项的来历，是从账号里取、从当次记录里取，还是按日子算出来。来历不明的时候，缺了值不知道该去哪头补，只能先把整批压着等。模板归哪个团队维护列成一行，改的人、用的人、看反馈的人未必是同一个，名字摆出来，问的时候不必先找一圈。
二、缺值在拼装时就停
变量没取到，别用一句空字符串顶过去，当场把这一封标成待补、退出这一批。空着发出去一时省事，事后却要花工夫解释一遍。归档目录按模板名分开，不按月份堆，找的人想的是那一份，不是那份文件是哪个月写的，顺着念头排才找得快。
停的时候把缺的是哪一项、属于哪一条记录写明白。只报一句拼装失败，值班的人还得从头把那批数据翻一遍，多半翻到一半才发现是同一个字段集体没带。样例那几组交给谁补定下来，用户替我们试出来的情形，正是自己试时没想到的，没人补就会在下版原样冒出来。
三、样例要覆盖到边界
试模板别只挑资料齐的那几条。名字很长的、带符号的、某项恰好没有的，都得拼一遍看看排成什么样，尤其换行和长度，顺手的那条往往显不出问题。复盘把那一回半截话的经过摆出来，不追谁的责任，只看当时缺了哪一步核验，补上那一步同类事就挡住了。
边界样例留成固定几组，模板一改就整套跑一次。这次改的是结尾一句话，结果开头称呼挤到了下一行，跑一遍就看见，等用户截屏过来才发现就晚了。成品留多久由谁定、按什么定，写进说明里，里面有收件人信息，为了查当次的事够用就行，不必长年攒着。
四、渲染和发送分两处看
拼出来的成品先落一份，发送那一步从成品里取。分成两处，出了状况能立刻分清是内容本来就拼错了，还是发出去那一路中间改了什么，不至于两拨人各查各的。归类那几档由谁拍板先定下来，值班的人半夜拿着一条没见过的写法，不该自己拿主意，翻一眼表就知道该问谁。
成品留多久按需要定，别一律长期存着。里面有收件人信息，留着是为了查当次的事，查完按日子收掉，既够用，也不至于攒下一大堆平时没人看的旧件。退回上一版的路子排进值班动作，谁都能点得到，改动前才敢多试那几组边界样例，不必担心一时收不回来。
五、改动要能退回上一版
模板改完发出去才发现少了一句，得有路子立刻退回上一版，别等重新走一遍排期。退回的动作简单，人才敢在改动前多试那几组边界样例。
每版存下改了哪几行、谁改的、什么时候起在用。几份模板同时在跑的时候，光看文件名分不清哪一份是当下生效的，有这份记录就不用挨个打开比对。模板每动一次留一条经办人和生效日子，几份并行的时候按这条排先后，谁也不用靠打开文件夹去猜哪份是眼下在跑的。
六、反馈按模板归回去
收到说看不懂、说漏了东西的回话，按用的是哪份模板归一下。集中在某一份，多半是那几处变量或排版的事；各份都有，才回头查共用的拼装环节。
归完顺手把那一处补进边界样例。用户替我们试出来的这种情形，往往正是自己试的时候没想到的，补进去之后下一版就不会再原样冒出来。反馈按用的是哪份归好之后交给谁跟，定个名字，不然每一条都有人看见，末了没有一个人是把它收掉的那个。
半截话不是文采问题，是拼装那一步没人替收件人把一眼。列清变量、缺值就停、试到边界、渲染发送分开、能退回、反馈归档，六件做齐，发出去的才是一封完整的话。 看完很有启发，也引发了我不少思考，有空也想分享下自己的看法。 讲得很透彻，把复杂的问题简单化，理解起来轻松了很多。 每一条都很实用，已经记下来了，以后遇到类似问题就能用上。
页:
[1]