关于书写技术探讨性邮件的一点小小的建议
来源:互联网 发布:恐怖游戏知乎 编辑:程序博客网 时间:2024/05/22 01:51
周银辉
非常感谢DUDU为我们提供了一个这么好的平台,让我们能聚在一起如此广泛地交流,所以我也会收到许多朋友的技术探讨性邮件,当然大多仍以求助为主。收到此类邮件,我是很高兴的,这让我有更多的机会能与大家一起探讨技术难题。但,就此我想提一些不成熟的建议,若能为大家的交流提供一点参考价值,我将非常高兴。
值得声明的是:下面的文字所提到的一些小问题,仅仅是极少部分网友偶尔有所发生,但我仍然希望看到这些情况的尽可能的避免,所以写了下来。
1, 请提供一个小小的DEMO来说明问题,而不是贵公司的代码片段
这是一个让我很头疼的问题,不少朋友会在邮件中粘贴大片段的实际项目中的代码来呈现其所遇到的问题,然后问我应该怎么办。
我们知道,一个或多个大片段代码很可能很大程度上依赖于你的实际项目,而我是不具备这些上下文的,我为了搞清楚你所遇到的问题,而将这些代码从邮件中复制到一个临时的小项目中,显然,其会编译不过,那么我就不能重现其所遇到的问题,为此,我将花大量的时间来mock数据和上下文,而且我还不能保证这种mock的合理性,最后导致在我还没真正搞明白你所遇到的实际问题之前且被为你打造一个可以重现问题的DEMO而搞得头昏脑胀。
那么,如果你能花上5分钟,打造一个恰好能反映你的实际困难的小DEMO并放在邮件附件里面,我将不会迷失在混乱的代码片段中,并将节省下来的精力用于积极地为你出谋划策,你的邮件也能尽快地得到回复。
2, 大家都是兄弟,别太客气,但也请别太霸气
事实上,我有些犹豫是否将这一点写下来,因为这有可能是我这双鱼座的人平时太敏感而产生的错觉,但我始终认为“Hi,银辉,晚上好,我在开发中遇到这样一个问题XXX想请帮忙你看看”这样的语句会比“有一个问题XXX,请赐教”这中富有挑战性的语句更能让我愿意参与此次探讨。
3, 无论我是否给出了正确答案,我都想听听你的看法或更好的解决方案
我非常理解平时在项目中遇到难题时那种迫切地想得到完美解决方案的心情,但由于我的能力有限或者我不处于你的实际开发情景中而没能给你很好的解决方案或者是误解了你的实际问题,也请你不要生气,我很愿意听听你的看法或解决方案,这对我也很重要,而不是收到你“算了,我自己搞定了”或者“不过还是谢谢你”之类的回信。这可能会打击我回复你以后的邮件的积极性,当然你也可能从此不和我探讨问题了;但如此失败的探讨也会令我感到沮丧。
好了,这些文字虽然很不成熟,但仍算是有感而发吧,非常感谢大家长久以来的支持,祝大家周末愉快。
- 关于书写技术探讨性邮件的一点小小的建议
- 关于一点小小的技术分享
- 关于python发送邮件的一点建议
- 对于Magento发送邮件的一点探讨
- 关于变频器的一点探讨
- 关于delete的一点探讨
- 关于乱码的一点小小的心得
- 关于tasklet的一点小小的解释
- 关于MVP的一点小小的看法
- 关于建站的小小建议
- 给linux初学者的一点小小的建议
- 给linux初学者的一点小小的建议
- 给linux初学者的一点小小的建议
- 关于芯片选型的一点小小心得
- 关于芯片选型的一点小小心得
- 关于c++ stack一点小小的疑问
- 关于初学TP的一点小小感悟
- 关于Unity Camera的一点小小总结
- WPF FAQ (from Syncfusion)
- GE Healthcare Intern
- [文章推荐] 软件内容全球化与本地化 & 微软术语管理
- [Prism]Composite Application Guidance for WPF(3)——创建第一个Composite WPF Application
- [Prism]Composite Application Guidance for WPF(2)--Composite Application Library(CAL)
- 关于书写技术探讨性邮件的一点小小的建议
- [转] 依赖注入&控制反转 oC 容器和Dependency Injection 模式(中文版)
- [Prism]Composite Application Guidance for WPF(1)--概览
- 哈哈,成为MVP了
- [WPF疑难]如何禁用窗口上的关闭按钮
- [WPF疑难] 如何限定ListView列宽度
- [WPF疑难]ErrorTemplate显示与隐藏问题
- 关于WPF的ComboBox中Items太多而导致加载过慢的问题
- “我们应该在用户计算机上存储一个魔饼”?