On Monday, 8 December 2014 at 16:04:31 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Mon, Dec 08, 2014 at 11:22:45AM +0000, Chris via
Digitalmars-d wrote:
[...]
What I gather from all the posts about code reviews and
testing is
that it's a solid mess out there, and the bigger the company
the
bigger the mess. I'm pretty much the only guy who works on the
code at
the moment and sometimes feel a bit bad about failing to
update this
or that (unit) test (simply because I lack the time). On the
other
hand the code and the programs are constantly being tested in
the real
world and are very stable.
Sounds like you're actually in a pretty good state, compared
with the
rest of the industry out there! :-P
Well, I don't have to meet deadlines all the time and deal with
customers who've been promised by someone in the management that
you can turn straw into gold. I don't need feature X until
tomorrow (or yesterday), but can think about a proper
implementation first. Thankfully we have someone on the team who
can test the software immediately and thoroughly before we give
it out (or use it internally).
This might be due to the fact, that I "unit test" a lot during
development (code a little, test a little). It is also down to
the
fact that the D compiler often helps me and warns me
immediately. It's
not so easy to get away with dodgy code in D.
Yeah, D does fix a lot of the flaws with C/C++ that allow you
to shoot
yourself in the foot and then erase all evidence of it. While D
does
have its own share of dark corners, it's generally very
pleasant to work
with, and does encourage good coding style.
D does have dark corners, but only if you care to go there, and
sooner or later (rather sooner than later) your house of cards
will collapse, because the dodgy code is often "found out" by the
proper code. I've always had to rewrite any dodgy, highly unsafe
code I introduced to save a nanosecond - and the dodgy code is
usually due to some interaction with C!
Regarding the working hours, it is hard to measure efficiency
in
working hours when it comes to software development. Sometimes
a major
improvement takes only one or two hours of highly concentrated
work
(after which the brain is wrecked). Sometimes a stupid little
problem
takes a whole day to sort out. And let's not forget that
programmers
often tend to think about how to solve a certain problem after
work. I
often found it more efficient to shut down the computer and go
home
than to keep on trying to find a bug when I'm already tired and
annoyed. The next morning (with a fresh head) I often spot the
bug
immediately. Or I think of the right solution on my way home.
Mere
working hours don't count.
Yep. I have experienced this many times. Sometimes repeatedly
trying to
attack a problem eventually gets to a point where my brain is
just
overwhelmed and cannot make any further progress, but when I
take a walk
and relax for a few minutes, my subconscious brain clears up and
suddenly the solution pops into my head seemingly out of
nowhere. I've
had occasions where I wake up in the middle of the night with
the
solution in my head -- at least once, I actually got up at 6am
and drove
to work just to implement what I became convinced was the fix,
and found
that it in fact was, whereas many hours of intense
concentration the day
before got me nowhere.
T
