Schillace 定律 背后的 Sam Schillace
微软semantic-kernel(SK)团队发布了一篇博客文章:Early Lessons From GPT-4: The Schillace Laws[1] ,微软的CVP , Deputy CTO Sam Schillace 根据他在GPT-4方面的经验制定了使用LLM创建软件的九项原则,称之为Schillace Laws of Semantic AI[2]https://learn.microsoft.com/zh-cn/semantic-kernel/howto/schillacelaws。
在大模型LLM 时代确定一个开发实践定律的人肯定是大有来头,因此我去找了他的资料学习了一下,他有着发现了不寻常的经历,早在2004-2006年他自己创业,使用c# 构建的产品叫 Writely,也就是Google docs的前身, 2006年被Google收购了,他们当时的团队有4人,从Writely到Google Docs的转换的故事 如何避免软件工程中最昂贵错误的发生[3]:
在今年初,我与Sam Schillace会面时也讨论过有关重写的问题,它是Box的技术副总裁,前Google Apps负责人。我向他提了一个问题,“你们工程团队曾遇到过的最昂贵的错误是什么?”
他的回答是,“尝试从零开始开展代码重写。”
Schillace的创业公司在2006年被Google收购了,他们当时的团队有4人,产品名字是Writely即Google Docs的前身。在他们发布了一个试验性的C#原型作品后,用户数很快就突破了50万。加入Google后,他们收到的第一个商业任务是进行项目迁移,从而充分利用Google的架构体系以实现高容量和高扩展性。每天用户数仍在快速增长,而他们也开始意识到之前所写代码的扩展瓶颈。
我还在Google工作时,我知道Google的软件堆栈是不支持C#的。所以当Schillace说到这里时,我很自然地问到,“当你们进行从Writely到Google Docs的转换时,你们是不是只能从零开始?”。
Schillace的回答是,“是的。”当他们开展重写工作时,有个合伙人提出边转换边重写,因为如果进行彻底推翻,将极大增加工作量。Schillace并不认同。最终,他说服团队只设置一个非常有限的重写目标,延后其它更多的目标工作。他们定下一个清晰的目标先把系统在Google数据中心运转起来,然后再整合12种不同的Google技术。他们花费了一个星期来调试并最终编译成功。调试过程中,很多错误是由于Java和C#不同的语义表达引起的,例如==双等号的不同含义。
“这真的真的非常痛苦。”Schillace说道。继续奋战12个星期后,他们最终完成了一个“令人惊讶的,奇怪的,晦涩难懂的”代码库。但它也最终在Google数据中心里成功运转了,这也创造了一项纪录——被收购后最快适应Google架构的转换项目。如果他们不是摒弃了过多的目标,也许还不能这么快就完成。同时如果他们把更多精力放在代码质量上,时间也会用得更多,因为需要修正一堆堆的正则表达式。相反地,他们的目标是使Writely先尽快运转起来。
这样的故事是不是很熟悉,这样的事情在中国也是不断的发生,将C# 写的软件翻成他们喜欢的语言来编写。 这是最昂贵的错误:尝试从零开始开展代码重写。
Sam Schillace 在微软领导创建了semantic-kernel项目,选择使用C# 构建。 当然以后肯定是会支持各种语言的,目前已经预览支持Python。
欢迎大家扫描下面二维码成为我的客户,扶你上云
![](https://images.cnblogs.com/cnblogs_com/shanyou/57459/o_220125090408_%E9%82%80%E8%AF%B7%E4%BA%8C%E7%BB%B4%E7%A0%81-258px.jpeg)