还有更奇葩儿的，写的10页A4纸打印出来的代码70%是Kommentar，代码本身80%是抄来的。然后整个代码根本不能工作因为丫不知道怎么测试(不会用Eclipse直接Word里写的)。然后丫把这代码给了我隔几天问我代码是不是很棒。我还只能说不错(平时对我不错)。结果说完这厮很兴奋非扯着我一行行跟我讲解这代码怎么好(这哥们儿花了一礼拜鼓捣出来的代码，Leichtbau专业出身这半年因为一起做项目非让我给他个小玩意儿编编，号称计算机是第二爱好除了捣鼓车)。整个下午俩小时我都在虎躯一振霍然身起拿电话听筒抽丫嘴的念头里度过的。
一个非计算机出身的哥们，以业余爱好的劲头，在不知道如何测试的情况下，不使用编程环境，历经艰辛用Word尝试写程序。我真心佩服这个同事，而且会鼓励他而不是嘲笑他，无论是口头还是心里。
这就像，你是个专业音乐制作人，另一个人把写歌曲作为业余爱好，他在没有编曲软件的情况下，花上很多业余时间靠脑子和A4纸写出一首吉他贝斯鼓音轨俱全的歌曲。那你作为专业音乐人，去嘲笑这个人是奇葩，他的歌曲难听，副歌和Solo是抄袭的，心里恨不得“拿电话听筒抽丫嘴”……我觉得是你不够地道。
adgjl 发表于 2014-8-8 15:55
一个非计算机出身的哥们，以业余爱好的劲头，在不知道如何测试的情况下，不使用编程环境，历经艰辛用Word ...
你说的这，突然让我想起了安培在马车背后算题目的故事。{:8_492:}。 工具不重要，重要的是想法。。。{:8_475:} 对巴
chinapope 发表于 2014-8-8 15:54
LZ, 你工作这么用心。不得不服啊。
小弟我同是码工作3年不到，有点看透，不是自己的责任，不要去担 ...
问题是，在程序崩溃时，你有手段可以完全准确的定位到原因吗？
如果不能，怎么知道是谁的责任？
不知道是不是你自己的责任时，你要不要参与排查？
你会不会很矛盾？？ 和路雪 发表于 2014-8-8 16:04
问题是，在程序崩溃时，你有手段可以完全准确的定位到原因吗？
如果不能，怎么知道是谁的责任？
{:6_403:}
可能我在公司里位卑职低，没有什么责任。
不过你的资深同事，如果技术不如你好，那肯定就是责任担当要比你大得多。
厚黑点说，程序崩溃时，就是你的机会。 作为打工者最重要不是先保护好自己？身不在老板位，不可能做到事事以公司利益为先。认真负责是好事，但无必要为公司掏心掏肺吃力不讨好. exsd 发表于 2014-8-8 15:00
你说的这，突然让我想起了安培在马车背后算题目的故事。。 工具不重要，重要的是想法。。。{:8_ ...
术业有专攻，除了个别天才，其余每个人除了主业，其他都只能是业余爱好者。
当你兴高采烈地和别人分享你的Hobby成果，别人是专业人士心里却想着拿电话听筒抽你嘴。换位思考一下，这种状况怎么琢磨我都不舒服。 A自己恐怕都没有你这么着急吧 他不清楚自己的能力吗 老板不清楚他的能力？有些事不是只有你一个人明白，为什么要做明白这事的人里面切身利益最轻却最着急的一个 exsd 发表于 2014-8-8 15:55
我倒是见过有人在Notepad++里面写代码的。。。
那个写代码问题不大。习惯windows的人至少会觉得比vim之类的好用。 adgjl 发表于 2014-8-8 15:55
一个非计算机出身的哥们，以业余爱好的劲头，在不知道如何测试的情况下，不使用编程环境，历经艰辛用Word尝试写程序。我真心佩服这个同事，而且会鼓励他而不是嘲笑他，无论是口头还是心里。
这就像，你是个专业音乐制作人，另一个人把写歌曲作为业余爱好，他在没有编曲软件的情况下，花上很多业余时间靠脑子和A4纸写出一首吉他贝斯鼓音轨俱全的歌曲。那你作为专业音乐人，去嘲笑这个人是奇葩，他的歌曲难听，副歌和Solo是抄袭的，心里恨不得“拿电话听筒抽丫嘴”……我觉得是你不够地道。
LOL。
瞧着着急的劲儿，我都替你着急。 lz可以慢慢把自己变成项目负责人 不光要会程序 还有和老员工怎么和客户打交道 怎么给老板汇报工作 “一个人开发的内容，另一个人必须审核并且充分理解。不然一个人离职了或者休假了出了问题很难解决。这是公司要求的。”我们也是这么要求的。我们是小公司，我来之前只有一个人编程。结果她在以前的程序里一行注释都没有写，我想撞墙 而且我编程的底子也不好，一想到前途就。。唉。。 学Info的真好，可以鄙视德国人。
adgjl 发表于 2014-8-8 09:30static/image/common/back.gif
问题在于LZ太急于和过于表现自己能力。不在其位，不谋其政，他写的代码，他自己对其负责，你没必要“帮他改错，重新整理代码”。如果你技术水平高到可以轻松加愉快地做到这些，那做了也无所谓，问题是你看的“想吐...
+1.绝对经验之谈。句句在理。 本帖最后由 mandriva 于 2014-8-9 01:21 编辑
纯C写的
但通过代码和交流，看的出来他没有太多和底层相关的经验，对很多关键的东西了解不够。逻辑不够清晰，代码比较混乱，算法和设计能力都不过关（至少以我的标准看来）。
举一个具体例子他写的 ANSI C 代码出来看看。
A自测完的东西，往往一堆漏洞，到了我这里经常还有一堆Bug。而且由于代码混乱不堪，难以理解，看的让人想吐血。。
我个人比较反对那种写一行注释一行的 入门菜。
一个出色的程序员必须是一个出色的程序调试员，编程的最高境界是 调试和implement 交融的境界，这种级别的是不用再多的人手来碍手碍脚，而是能自动修正错误，然后每天又能又能解决一些问题，从而每天把整个项目推进到一个新的进度。
//具体的做法linux GNU 有gdbwin 的最出色的调试工具是微软自家的，逐模块断点调试，然后模块内部逐函数断点调试，然后函数内部逐行逐句断点调试，最终分而治之为变量错误，推导出逻辑错误，或者不是像他想象的那样能算出来。
(比如 用MFC.NETWinAPI 处理GUI 事件 和 进程调度 基本方法一致，但那些细小的地方就是要人不断的刻苦努力去研究它， 掌握的语言越难，越少人能掌握，说明你的方法论越充分，要处理实际问题的Alternative越多，能力就越强(win的WinAPI 难于 MFCMFC 又难于.NETLinux的 Kernel API 难于 X11 API 但 Linux 天生的优点就是程序调试 因为它的内核类型叫做 Monolithic，而 Monolithic 内核 的本质含义 是说整个OS 就是 一个凌驾在硬件之上的调试器。 )。 那些光会个QT 的就像 人会用office而不知道为什么人能用office，因为框架简化了操作，从而隔离了能提升技能，和从操作系统角度来观看更接近本质层面的 的核心部分。 )
如果项目相当庞大，那也不是每个程序员应当操心的事情，每个程序员仍然是整个软件大厦的基石，他应当做的中流砥柱是保证每个模块，每个函数的正确的输入输出，也就是从IO的角度来肩负使命。
那怎么把各个程序员的 心血合起来？ 通过项目管理。
能够担当这个角色的 是那种老屌角色的 架构师， 硬搞它就搞的通透的， 它们不但年轻时身经百战这种最艰难的攻坚阶段，而且也是春秋战国时期的那种纵横家，善于游说于不同的程序员之间，也就是人能做最艰难的事情，那种刷嘴皮的事情更是驾轻就熟。
为了照顾他的面子，每次开例会时，我也只是简单的说，程序有些不稳定，已经修正了之类的套话。。
你可以直接告诉他哪里是错的，如果它不信，抽那段代码出来做一个简单程序给他看，错就是错，不过你如果理解错了，你最后应该道歉。 LZ只要晓得他的系统、模块、功能设计，以及程序sequence就行了，也就是有一个全局观，这些大部分在沟通的时候就了解了，公司也没要求你去查看人家code. 以后出错，排查也快。如果都要互看代码，那证明开发日程还是不紧 楼主给人的感觉是太过急于表现了，所以对直接领导的缺点有点放大来看了，觉得不给力，是因为你觉得他妨碍你的表现了。
如果直接领导有什么不足，挺他而不是嫌弃他，日后他才会提携你。如果你打算踩他上位，那么要看你跟大老板的关系如何。如果关系特别铁，越级上位才有希望。如果不是，楼上几位的建议都是高招。
职场上适者生存，而不是能者生存。放大别人的优点，缩小自己的优点，才能跟同事更愉快地相处。
页:
1
[2]