|
|
|
1.“我不知道是该删除还是重编写。”
回归历史源代码会诱使程序员重新产生更多的障碍集群。逻辑性差的冗余句法令人无法理解！
然而，如果它没有中断，请不要去修复。这是我经常挣扎的问题，相信也困扰了不少其他软件开发员。
2.“我应该在开始架构时检查Github版本控制系统。”
绝大多数开发员都应该知道Github版本控制系统及每天公布的开源项目。涉足所有计算机语言的程序员，
利用网络分解研究现有项目，进行维基论坛讨论或发表个人的代码报告。这些为很多项目的插件和模板提供了很多很好的资源。
3."为什么这个脚本需要如此多的库"
尤其是变得越来越重量级例如 java和Objective-C，库文件的数量日益增加。非常明显的是当建立一个框架时就需要许多的基础库。
甚至一些JavaScript的插件都需要大量额外的文件。有的时候杂七杂八的东西很招人烦 -但至少它能运行。
4“在互联网上移动一定会有解决方法”
遇到困难问题我的第一反应是在互联网上查找。许多的程序员会把他们遇到的问题发布到论坛上，问题最终得到解决并保存下来。
谷歌极好的挑选出你问题相 关的关 键字并且为你指出了正确的导向，这些都为讨论提供了有益的线索。不幸的是，有的时候对于一个特定的问题还没有过多的信息。
5.“有这个功能的插件么？“
为什么要重造轮子？插件是扩展任何程序或网站用户界面的一个很好的资源。另外他们可以为开发者使用的一些定制的独特的选项。如果不存在已有插件的话，为什么不自己创建一个呢？
6.“网站项目，我害怕Internet Explorer。”
使用Internet Explorer渲染网页时遇到的坑我就不提了。从5.5版本到IE9-IE10浏览器支持方面的争议一直不断。
Web开发人员可能害怕网页调试，使用IE6渲染更是噩梦。谢天谢地，那些日子已经慢慢成为了过去。
7.“逻辑语句——它本身就不是很有逻辑。”
现在有的逻辑语句有if/else循环、for循环、while循环、do循环……这个列表相当长。当查看一些旧示例代码时我尽力想弄明白我当时的使它运行的逻辑是什么。
NOT操作的跳转数及比较符让人头晕。以后我会经常回过头来更新自己好的逻辑实践。
8.“我花30分钟写一个函数，却要花2小时让它工作。”
这不是十年前的故事吗？你沿着以前的套路轻松构建，突然函数输出了一个致命的error，
因此你不得不回过头去清除代码块来试图找到故障的代码行。当你筋疲力尽最终找到了罪魁祸首后就像得到救赎一样。
9.“读了几个博客后我才意识到我之前的理解一直是错误的。”
我喜欢按自己的编程思想直奔主题，当事情没有按计划进行时这样做会导致麻烦。很多次我开始了一个项目后就陷入困境，然后便到博客或相关文章中寻求帮助。
之后我发现整个方法实际上是错误的，重新开始会更容易！开始时多一点研究在长远看来是在节省时间。
10.“编程社区上的好心人会帮助你。”
我已经数不清有多少次通过编程社区解决困难的问题了。勇敢迈出第一步的话社区里有很多聪明的热心人愿意帮你。
所有的在线论坛被定义为是软件开发者及前端/后端web工程师最全面的支持网。
11. “忘记关闭结束括号带来的麻烦”
你采取的所有步骤都是调试。向前两步，退回一步，或者向前更多。你会感觉花很多时间盯着代码，只为查找一些语法错误或者是变量的作用域，
最终却只找到一个失踪的括号，这是一种奇怪的感觉。所有的时间都花费在了一个小小的语法错误上。在同一时间会感觉自己即是一个天才又是一个傻子。
12. “停下来，喝一杯咖啡”
有时候你需要的是起身离开显示器，在键盘上工作几个小时后。这有助于打破惯例。大多数的健康指南建议休息30-60分钟。
但这一切都取决于你的需要，如果让你从编程过程中中断会使你苦恼，那最好还是不要中断。
13."是不是有人正在摆弄我的代码"
这听起来像是妄想和偏执，但有时你只是猜想谁在你正忙着睡觉的时候挖了这个坑。遍览过去几周或者几个月的项目能够给你留下一种病态的感觉。
有时候你 将会发 现你这从来都不记得是自己留下的坑——尽管上个星期你都捣腾过这个项目！我发了疯似得把它写下来，但是你从来不知道...
14.“我不知道这意味着什么。“
你能遇到的最糟糕的情况就是看一看代码，完全不知道所以然。这可能来自于你自己的项目，也可能是其他什么人的项目，
但都是同样的问题。现在你不得不去决定是否值得花更多的时间寻找替代方案，或者剖析代码以了解其工作原理。
15.“我在想花钱找人帮我修复这个问题得花费多少？”
铺天盖地的招聘额外开发者的想法是很诱人的，但很显然其可行性不及财务上的可行性。再加上如果不是你自己把手弄脏的，
那你怎么从所有这些错误中学到教训？当你在许多次失败以后，最终理解了一个编程的概念时将会很有成就感。但这种思想并不总是能在我的脑海闪过。
16. “这个 API 怎么能没有文档呢?!”
使用一个具有糟糕文档的插件或者框架时，最令人沮丧的事情是你不得不自己深入阅读源代码。我推崇的项目是，
那些开发人员花时间特别设计出一个有用文 档页的 项目。所有的参数与选项都被予以解释，可能甚至会在一些案例代码片段中使用出现。
但是遗憾的是事实并不总是如此。最简单的办法就是远离文档贫乏的作业，以 免你自己陷入不幸。
17. “我当然希望我留下了那个数据库的一份拷贝…”
在编写代码并进行调试的时候，我总是想不起备份。然而，数据备份提供了一个垫脚石，使我们可以回到我们实施了某种更改之前的时刻。对一个生产环境的 服务器 这个特别有用，在那个环境中变化总是在瞬间完成的。
记住保留网站文件和数据库的本地拷贝，以备不时之需！这或许是很烦人的任务，但这也没有比重新创建一个 被破坏的SQL数据库更烦人。
18. “能让这个正常工作的最快的解决方案是什么?”
在东跌西撞的寻找了几小时的自定义解决方法后，很明显你需要一个新的方案了。程序员们都是希望功能正常运转之后，再去考虑接口设计的优雅问题。
要确定最快最准确的解决方案，并应用它使之尽快的开始工作。然后，就可以放松心情去追求程序的美感了。
19.“放弃这个，从头开始。”
有时在尝试了长时间解决方案后，你需要把你的工作文件转移到归档目录（或删除），然后从头开始。
考虑到前一小时辛苦这确实是个艰难的决定。但当我谨记前车之鉴重新开始时这往往是项目走向完成所应该看到的。 |
|
发表于 2021-1-19 06:10:06
