资深程序员对整个软件生命周期很了解,他们可以经过培训成为架构师,但他们不等同于架构师。一个软件架构师首要的和最重要的是他的远见。如果一个架构师拥有一些软件开发经验,那会更好,但大多时候,他们面对的是一个多语言的复杂环境。在第一行代码开始编写之前,架构师需要制定出业务需求如何转变成解决方案。
我的同事朋友Chris Eargle写了一篇关于新年计划的有趣文章。他让我想到了,没有出现那场世界末日是我们多么大的幸运呀(还有其他我这45年中躲过的天灾),于是,我也有了一些我自己的以程序员为主题的新年计划。在你的职业生涯中,你能做的会给你带来最多麻烦的事就是成为屋里最聪明的人…..
你在兴奋的为你的客户实现一个新功能。这个功能在业务逻辑上超级的复杂,但页面上却是非常的简单。这需要做大量的工作。
在付出了巨大努力后,你刚好在用户要求的最后期限前完成了任务。开发出的新功能在业务逻辑上无懈可击,但界面没有来得急收拾,显得有些粗糙。这没什么,因为这是最容易处理的部分,也是最不容易出错的部分。
本文在作者Sam Stephenson是Prototype js框架的创始人。他从2006年开始一直在37signals工作做web开发。除了Prototype外,他还开发过很多开源软件,比如rbenv, sprockets 等。
我并不认为从开发Bootstrap框架中学到了任何东西。事实上,我非常确信,我不会学到任何东西。作为一个技术上的挑战,Bootstrap并不是特别有吸引力。这个框架就是提供一些组件——诸如模态框,提示框,表格等网上一直都有的组件
每次我遇到一个程序员——有时是相当高水的——总发现他会认为:你并不需要给你的代码加注释。我要说,这就是胡说八道。我很长时间以来一直这么表达。问题是,让事情改变要比你想象的难。虽然我们正处在努力编写那些讨厌的代码
Scott说的一点没错:我是个混蛋程序员。我不认真的注释我的代码。有时,我会违反DRY编程原则。我不喜欢使用奇妙的三重操作符表达式,也不太在意空格的使用。我的数据结构有时会弄的丑陋不堪。
“及早发布。频繁发布。听取客户的意见”是我们Pikacode公司的主导方针。开发中的技术选型必须认真的遵循这个指导原则。
重构代码很危险,它会给测试工作增加巨大的负担。除非你的程序需要重构,一定不要轻易重构代码。我这里所说的并不是把一个for循环改成while循环,或把一个StringBuffer改成StringBuilder,我说的是大动作,例如重写
我们经常听到人们宣扬说,在开发软件时写测试代码(单元测试,功能测试等)能有效的减少产品中的bug。如何验证这样的言论?通常,这些人都是已经在使用驱动测试开发(TDD)或行为驱动开发(BDD),而且,他们所在的公司在诞生第一天起就有着很强的测试文化。
把分析和编程分离开做。它们不是同类的事物,需要不同类型的劳力资源,需要在完全不同的时间和地点分开做。如果同时做它们,你一样都做不好。
大概是两年前吧,我做了个决定,要去学习编程。我买了本PHP书,开始一边阅读一边做里面的练习题。我把主要精力都放到PHP上,不理会任何其它的语言,