问:
Introducing functional programming into your development environment
This is a long story but I will try to summarize it as best I can. We are a .NET shop that writes software for a variety of different types of funds. For example, we write health claims management software, pension management software, 401(k) software and some other financial-type things.

Now we are entering a new realm: derivatives and quantitative analytics type of work, which seems very exciting. This is something that is coming down in the next 8-12 months I've been told.

Now, I have learned some functional programming on my own, mainly just superficial glances at various languages via this book but never really dug deep into it. Now, since we are a .NET shop I was thinking F# might be a good choice, because we could potentially leverage some .NET libraries and existing knowledge possibly.

My question is, where to start? I am having an exceedingly difficult time trying to figure out if I should go with Haskell, Erlang, Scala, F#, etc. They all seem very interesting and capable and quite frankly this might be a good chance to break out being so Microsoft dependent.

Has anyone had a similar situation? If so, what was your experience making the jump to functional and what did you choose and why? I know this is kind of a big question but I don't know any developers that are using functional methods right now so I have nowhere else to turn other than Googling incessantly and finding flame wars everywhere on the best functional language.

答:
I certainly agree with the main thrust of the accepted answer, and given that you basically are diving into things headlong by giving Erlang a try it sounds like you likely have a pretty good understanding of how you learn and just needed a little nudge in the right direction, so clearly it was a good answer for you... But, I think I would approach the question a little differently, since I see that this answer wouldn't have helped me much at all; I always code to learn! So, here are my thoughts...

(BTW, I tend to go on in detail suited more for, say, chapters in a book, and I'm sure I can't stifle my instincts completely here, but I'm going to try a different tack; I'm going to just summarize my thoughts here, and in case someone would like more detail on anything, or thinks somethings I say is misleading in this format, I will do my best to remember to go through response reminders...)

To try to keep myself on task here's my understanding of the thrust questions asked in the OP; I'll keep sidelines to a minimum as necessary to explain....

First the quick answers:

was I in a similar situation? It was at least similar; I was in a lead position doing many varied projects that were nonetheless related... (CRM/Web/DB/Data Integration/etc.)

how/why did I make the jump to functional?" I saw some LINQ examples and although I had definitely dreamed of some sort of integrated, statically typed, query language [as I had primarily used statically typed languages (primarily C++, and later C#)] throughout my career... But, it was a fairly rapid-fire environment I was in, and although I had often managed to see what was coming in the past, I had never really thought it through so I never foreseen that it could/would allow operations on Plain Old Objects (lol!) just as easily; when I saw it I knew I had to have it... so, that's the why and the start of the how: I focused on learning to understand LINQ.

Four Thoughts ...errr, no that's not right... Forethoughts

When I read Martijn Verburg's answer, the mention of business functionality draws my mind immediately to starting to implement code for whatever I'm working on... Depending on exactly how shallow that initial experimentation was I might answer differently, but assuming it was just dipping your big toe in, I am not sure that I had anything directly for work (or soon-to-be work) that would have provided me the excitement/passion I think you should probably have for the first few problems you start to tackle...

I was grounded almost entirely in statically-typed languages + OOP metaphors and patterns + whatever I ended up wrapping my brain around accidentally while solving my actual problems over the years... Point being that, if you're at all like I was, you likely have a lot of brain dedicated to stuff that isn't going to help you that much with LINQ/FP.

I think of it kinda like pure procedural vs. OO programming: there's a lot of procedural stuff that you will end up using in OOP, but those who come to C++ from C without making it a priority to grok/ken/"get" OO end up being very very bad at C++. I actually have interviewed a hell of a lot (15+) long-time firmware and device driver developers who really thought they knew C++, but who, at most, had a terribly basic/textbook understanding of C++, with practically no understanding of or experience in OOP—because they never actually did OOP... They wrote singleton multi-purpose classes with static members and static functions with some amount of non-static/non-singleton classes that were used as structs.

And FP has some similarly mind-bending (for those not raised on the paradigm) concepts and other things that go along with it, and (although I have found the hybridization of lots of techniques to be ideal for me) I do understand more and more as time goes on exactly how limited my thinking was prior to getting real functional abilities into my toolset; I had managed to implement many things in the past in a way that was a bit more creative that perhaps most OO programmers, but as I use the concepts how stunted my thinking was prior... There are whole classes of problems that can be solved in a few lines that used to take a hell of a lot of contorting to do in C++/C#.

suddenly you find yourself...

In A "Too Long" Post

```
You are in a maze of twisty "didn't read"s, all alike.

You see a teleconference in the near future, rapidly approaching.
>terse
Uhhuh. Sure. Okay, we'll say "terse" mode is "on".

You see a teleconference in the near future, rapidly approaching.
>what's that supposed to mean?
Just sayin'. Didn't you have to do something this morning?

You see a teleconference in the near future, rapidly approaching.
>hey, is that a grue behind you?
What!? WHERE?! [runs away screaming]

>Sorry, I did not understand WHAT WHERE, rephrase?
[continued running and screaming, sarcasm unnoticed]
```

So... What should I learn, dear PSE, dear PSE?

I personally started in C# with LINQ. It allowed me to introduce a few concepts at a time, and while I was constantly reading about FP and its concepts, and more LINQ, and the relationship between the two, it gave me a way forward while still doing productive work. I added in a few things at a time, the data queries quickly became a useful tool to me without having to understand a ton.

Now, looking back on it, I kind of wish I had been able to do my next project (tackled about a year later) first; I got moderately familiar with F# (which, incidentally, gave me a great head start on learning ML (metalanguage) and it's other derivatives (e.g., OCaml as well.)

Basically, I think a decent answer to 'what' depends on finding a good pairing of some programming problem that interests you, but of course it must pair with a bit of FP that you want to learn... (and you can rinse/repeat/lather after knocking something off the list...) And, of course, you always end up learning a bit more than the main thing you set out to do; at first I took some baby steps, but then I ended up doing bigger things and letting the smaller stuff fall into place while I did those.

First, what floats your boat? Especially at first it's best to have something fun and exciting (to you) and that will keep your interest enough to make it worthwhile for you. So, IOW problems to work on, and techniques that address those problems... LINQ and inline data querying for me at first. Recursion was another one for me, including tail recursion, I dig the GodelEscherBach-ness of it; and I had been reading about tail recursion. Around this time, the things I was working on were put on hold, and I ended up having a large block of time, so I was able to keep at it for a good long while. It was easier with less interruptions, but because I chose things that I thought were fun, it wasn't all that hard even with the interruption of work. :)

And although I didn't come up with anything cool I can tell you about like self aware Crab Program, I managed to get pretty good at it.

And... With what shall I learn it, dear PSE, dear PSE, with what?

For this, I used various algorithms I just happened to be interested in anyway, plus various things I wondered if you could do in F#, and when I would run out of ideas I'd tackle things like 99 bottles of beer and the Project Euler problems...

I'm sure you can find lots of things that interest you that FP is relevant to; it offers everything from enhancements to OOP that help you state things a bit more succinctly all the way to twisting the way you would have thought about it before into a shape you don't recognize and likely didn't even have the mental model to express before.

But... There's a hole in my model, dear PSE a hole...

And this is why it's important that, especially at the beginning, but really throughout your time learning (and isn't it always true when you're learning something?) you at least take a bit of time between problems to read things unrelated but still FP and time to read source code written by experts, preferably solving the same or similar problems; as well as their explanations of things...

And all the while, you have to be straining your brain to understand it all, not from your old perspective but from within FP itself... At some point for me, it clicked, and ... the thing I can best relate it to is becoming more-or-less fluent in Dutch; at some point I managed to put myself enough in the mindset (I did it via immersion, which is basically what I've described here; immersing yourself in FP rather than trying to learn it solely through "book larnin'"...

And, eventually I did; I managed to internalize everything and twist my brain around until out started popping FP/LINQ without me even having to make an effort to translate it back into OOP. (Yes I did that; I had to have something to hang my skirt on. Hat. Whatever.)

Final thoughts...

```
My, my, it seems you're losing your ability to think of your signature clever
section titles. What a shame.

The teleconference is still rapidly approaching. It appears much larger now.
>yes, yes, well.. terse and all. I do see you managed to lose that grue.
 close call, that... well, yes, I am being ter... OH NO IT'S BACK!
AAAAAAAHHHHHH!! [runs away screaming, once again]

The teleconference is still rapidly approaching.
It somehow resembles Sir Lancyjohn Cleezewiz.
It is almost upon you.
>hey, hurry back! I have an experiment to try with you! (and a po-ta-to)
```

You can find a wealth of info online about FP, naturally. Main thing is to understand basic concepts, and then learn to apply them. For instance, learn about immutability, and why it's important/useful for FP. I highly recommend learning a little theory to go along with everything, like how pure FP can be much more amenable to formal proof. This was a driving force behind F#'s progenitor, ML. YMMV of course you may be someone bored to tears in which case, lots of examples, lots of trial and error to see exactly why the techniques used are what they are will help you have that 'Aha!' lightbulb moment.

So, I'll leave it at that for now. Hope this is of some use to someone. I wanted to get a bit more into specific things to learn but I'm out of time for the moment. I hopefully will find some time to get back to it soonish although it's looking to be a long week for me, so probably will be at least the weekend.

<3 "Introducing GRUEBOL, a stopgap; just until SnozzML is finished. It should be soon; I got a huge committee helping me this time." --Grace Hopperwit Egghead, Famous Last Words, XX97 G.U.E. <3

Body:
I certainly agree with the main thrust of the accepted answer, and given that you basically are diving into things headlong by giving Erlang a try it sounds like you likely have a pretty good understanding of how you learn and just needed a little nudge in the right direction, so clearly it was a good answer for you... But, I think I would approach the question a little differently, since I see that this answer wouldn't have helped me much at all; I always code to learn! So, here are my thoughts...

(BTW, I tend to go on in detail suited more for, say, chapters in a book, and I'm sure I can't stifle my instincts completely here, but I'm going to try a different tack; I'm going to just summarize my thoughts here, and in case someone would like more detail on anything, or thinks somethings I say is misleading in this format, I will do my best to remember to go through response reminders...)

To try to keep myself on task here's my understanding of the thrust questions asked in the OP; I'll keep sidelines to a minimum as necessary to explain....

First the quick answers:

was I in a similar situation? It was at least similar; I was in a lead position doing many varied projects that were nonetheless related... (CRM/Web/DB/Data Integration/etc.)

how/why did I make the jump to functional?" I saw some LINQ examples and although I had definitely dreamed of some sort of integrated, statically typed, query language [as I had primarily used statically typed languages (primarily C++, and later C#)] throughout my career... But, it was a fairly rapid-fire environment I was in, and although I had often managed to see what was coming in the past, I had never really thought it through so I never foreseen that it could/would allow operations on Plain Old Objects (lol!) just as easily; when I saw it I knew I had to have it... so, that's the why and the start of the how: I focused on learning to understand LINQ.

Four Thoughts ...errr, no that's not right... Forethoughts

When I read Martijn Verburg's answer, the mention of business functionality draws my mind immediately to starting to implement code for whatever I'm working on... Depending on exactly how shallow that initial experimentation was I might answer differently, but assuming it was just dipping your big toe in, I am not sure that I had anything directly for work (or soon-to-be work) that would have provided me the excitement/passion I think you should probably have for the first few problems you start to tackle...

I was grounded almost entirely in statically-typed languages + OOP metaphors and patterns + whatever I ended up wrapping my brain around accidentally while solving my actual problems over the years... Point being that, if you're at all like I was, you likely have a lot of brain dedicated to stuff that isn't going to help you that much with LINQ/FP.

I think of it kinda like pure procedural vs. OO programming: there's a lot of procedural stuff that you will end up using in OOP, but those who come to C++ from C without making it a priority to grok/ken/"get" OO end up being very very bad at C++. I actually have interviewed a hell of a lot (15+) long-time firmware and device driver developers who really thought they knew C++, but who, at most, had a terribly basic/textbook understanding of C++, with practically no understanding of or experience in OOP—because they never actually did OOP... They wrote singleton multi-purpose classes with static members and static functions with some amount of non-static/non-singleton classes that were used as structs.

And FP has some similarly mind-bending (for those not raised on the paradigm) concepts and other things that go along with it, and (although I have found the hybridization of lots of techniques to be ideal for me) I do understand more and more as time goes on exactly how limited my thinking was prior to getting real functional abilities into my toolset; I had managed to implement many things in the past in a way that was a bit more creative that perhaps most OO programmers, but as I use the concepts how stunted my thinking was prior... There are whole classes of problems that can be solved in a few lines that used to take a hell of a lot of contorting to do in C++/C#.

suddenly you find yourself...

In A "Too Long" Post

You are in a maze of twisty "didn't read"s, all alike.

You see a teleconference in the near future, rapidly approaching.
>terse
Uhhuh. Sure. Okay, we'll say "terse" mode is "on".

You see a teleconference in the near future, rapidly approaching.
>what's that supposed to mean?
Just sayin'. Didn't you have to do something this morning?

You see a teleconference in the near future, rapidly approaching.
>hey, is that a grue behind you?
What!? WHERE?! [runs away screaming]

>Sorry, I did not understand WHAT WHERE, rephrase?
[continued running and screaming, sarcasm unnoticed]

So... What should I learn, dear PSE, dear PSE?

I personally started in C# with LINQ. It allowed me to introduce a few concepts at a time, and while I was constantly reading about FP and its concepts, and more LINQ, and the relationship between the two, it gave me a way forward while still doing productive work. I added in a few things at a time, the data queries quickly became a useful tool to me without having to understand a ton.

Now, looking back on it, I kind of wish I had been able to do my next project (tackled about a year later) first; I got moderately familiar with F# (which, incidentally, gave me a great head start on learning ML (metalanguage) and it's other derivatives (e.g., OCaml as well.)

Basically, I think a decent answer to 'what' depends on finding a good pairing of some programming problem that interests you, but of course it must pair with a bit of FP that you want to learn... (and you can rinse/repeat/lather after knocking something off the list...) And, of course, you always end up learning a bit more than the main thing you set out to do; at first I took some baby steps, but then I ended up doing bigger things and letting the smaller stuff fall into place while I did those.

First, what floats your boat? Especially at first it's best to have something fun and exciting (to you) and that will keep your interest enough to make it worthwhile for you. So, IOW problems to work on, and techniques that address those problems... LINQ and inline data querying for me at first. Recursion was another one for me, including tail recursion, I dig the GodelEscherBach-ness of it; and I had been reading about tail recursion. Around this time, the things I was working on were put on hold, and I ended up having a large block of time, so I was able to keep at it for a good long while. It was easier with less interruptions, but because I chose things that I thought were fun, it wasn't all that hard even with the interruption of work. :)

And although I didn't come up with anything cool I can tell you about like self aware Crab Program, I managed to get pretty good at it.

And... With what shall I learn it, dear PSE, dear PSE, with what?

For this, I used various algorithms I just happened to be interested in anyway, plus various things I wondered if you could do in F#, and when I would run out of ideas I'd tackle things like 99 bottles of beer and the Project Euler problems...

I'm sure you can find lots of things that interest you that FP is relevant to; it offers everything from enhancements to OOP that help you state things a bit more succinctly all the way to twisting the way you would have thought about it before into a shape you don't recognize and likely didn't even have the mental model to express before.

But... There's a hole in my model, dear PSE a hole...

And this is why it's important that, especially at the beginning, but really throughout your time learning (and isn't it always true when you're learning something?) you at least take a bit of time between problems to read things unrelated but still FP and time to read source code written by experts, preferably solving the same or similar problems; as well as their explanations of things...

And all the while, you have to be straining your brain to understand it all, not from your old perspective but from within FP itself... At some point for me, it clicked, and ... the thing I can best relate it to is becoming more-or-less fluent in Dutch; at some point I managed to put myself enough in the mindset (I did it via immersion, which is basically what I've described here; immersing yourself in FP rather than trying to learn it solely through "book larnin'"...

And, eventually I did; I managed to internalize everything and twist my brain around until out started popping FP/LINQ without me even having to make an effort to translate it back into OOP. (Yes I did that; I had to have something to hang my skirt on. Hat. Whatever.)

Final thoughts...

My, my, it seems you're losing your ability to think of your signature clever
section titles. What a shame.

The teleconference is still rapidly approaching. It appears much larger now.
>yes, yes, well.. terse and all. I do see you managed to lose that grue.
 close call, that... well, yes, I am being ter... OH NO IT'S BACK!
AAAAAAAHHHHHH!! [runs away screaming, once again]

The teleconference is still rapidly approaching.
It somehow resembles Sir Lancyjohn Cleezewiz.
It is almost upon you.
>hey, hurry back! I have an experiment to try with you! (and a po-ta-to)

You can find a wealth of info online about FP, naturally. Main thing is to understand basic concepts, and then learn to apply them. For instance, learn about immutability, and why it's important/useful for FP. I highly recommend learning a little theory to go along with everything, like how pure FP can be much more amenable to formal proof. This was a driving force behind F#'s progenitor, ML. YMMV of course you may be someone bored to tears in which case, lots of examples, lots of trial and error to see exactly why the techniques used are what they are will help you have that 'Aha!' lightbulb moment.

So, I'll leave it at that for now. Hope this is of some use to someone. I wanted to get a bit more into specific things to learn but I'm out of time for the moment. I hopefully will find some time to get back to it soonish although it's looking to be a long week for me, so probably will be at least the weekend.

<3 "Introducing GRUEBOL, a stopgap; just until SnozzML is finished. It should be soon; I got a huge committee helping me this time." --Grace Hopperwit Egghead, Famous Last Words, XX97 G.U.E. <3


问:
How to address the concerns of the software architect but still maintain collective code ownership?
The quality of the code in our software is indeed lacking. When you change a line of code in one component it usually breaks code in other components.

Our software architect blames this on collective code ownership. He believes that if every developer was responsible for his own piece of code then he would tidy it up all the time because he would feel ownership over the component.

In the current situation, developers change code in multiple components and they break other components either because they don't understand how the component works (because they work with so many components) or because they don't care about how their changes will affect the other clients of the component (as long as they are not affected).

How can I address the concerns of the software architect but still maintain collective code ownership?

答:
This is more of a supplement/commentary to Doc Brown's answer.

IMHO - the software architect (SA) is looking for a way to pinpoint blame on someone else. I'm not hearing whether or not everyone is following the plan. Some companies may rely on a team lead or the team as a whole to be responsible for following the plan, so the architect is only involved when there is a question about the plan itself. Others may rely on the SA to decide if the plan is being followed.

Some plans are better than others. Imagine a head chef who has a very poor recipe for chicken and relies on one cook who is particularly good at it (basically, he has his own recipe). Some nights another cook has to step in and gets blamed for the poor quality, because he attempted to follow a bad recipe (no seasoning). Often there aren't enough good coders to bail-out a poor design or follow a plan if left on their own.

As Doc Brown indicated in his answer, a code review is the best way to make sure this is happening along with the following of other standards. There are those that think people will take responsibility for code if they have to fix their own bugs. The bottom line is, someone has to make sure code is shippable and if there is no review, you're just taking your chances.

ContentLicense: CC BY-SA 3.0


问:
Why a function returning by address can not be a lvalue?
Why is it not possible to set a function returning an address while it is possible to set a function that returns a reference.</p>

```<code>int* returnByAddress()
{
    int x = 20;
    return &x;
}

int& returnByReference()
{
    int x = 30;
    return x;
}

int main()
{
    returnByReference() = 23; // possible
    int x = 23;
    returnByAddress() = &x;   // not a lvalue error
    *returnByAddress() = 245; // possible

    return 0;
}
</code>```

答:
What you are trying in your examples is very dangerous.

Function results as lvalues can make sense, but you have to ensure that the objects exist after the function returns. Here an example that makes (kind of) sense:

```<code>#include <iostream>

/// get a R/W reference to a byte in a buffer
/// Warning: no range checking is performed
unsigned char& refByteOfBuffer(void* buf, const int offset)
{
    return reinterpret_cast<unsigned char*>(buf)[offset];
}

void testRefWrite()
{
    unsigned char buf[] = "Hello world!";
    refByteOfBuffer(buf, 1) = 'a';
    std::cout << buf << std::endl;
}
</code>```

The output will be Hallo world!, after the e in buf at offset 1 was changed to a.

Body:
What you are trying in your examples is very dangerous.

Function results as lvalues can make sense, but you have to ensure that the objects exist after the function returns. Here an example that makes (kind of) sense:

#include <iostream>

/// get a R/W reference to a byte in a buffer
/// Warning: no range checking is performed
unsigned char& refByteOfBuffer(void* buf, const int offset)
{
    return reinterpret_cast<unsigned char*>(buf)[offset];
}

void testRefWrite()
{
    unsigned char buf[] = "Hello world!";
    refByteOfBuffer(buf, 1) = 'a';
    std::cout << buf << std::endl;
}

The output will be Hallo world!, after the e in buf at offset 1 was changed to a.


答:
Ownership, collective or individual, isn't going to change the fact that changing things breaks code in other components.

Start adding unit tests for everything that gets touched. If possible, add tests for some (or all) of the callers of whatever you touch. This will (eventually) make it really hard for people to break other code without knowing it, which is probably what's going on right now (I'm assuming your team isn't deliberately committing broken code).

They'll also probably point out that there's a lot of weird inter-twining of your code, which is probably at least a part of the problem.

Title: How to address the concerns of the software architect but still maintain collective code ownership?

Body:
The quality of the code in our software is indeed lacking. When you change a line of code in one component it usually breaks code in other components.

Our software architect blames this on collective code ownership. He believes that if every developer was responsible for his own piece of code then he would tidy it up all the time because he would feel ownership over the component.

In the current situation, developers change code in multiple components and they break other components either because they don't understand how the component works (because they work with so many components) or because they don't care about how their changes will affect the other clients of the component (as long as they are not affected).

How can I address the concerns of the software architect but still maintain collective code ownership?


问:
can a software be an ERP and CMS simultaneously
I was reading about CMS and ERP. And got confused at this point that whether a system can both be an ERP and a CMS? is it possible?</p>

答: In most cases this would not make very much sense,ERP system generally use in business management.An CMS able to edit not only content but the entire design can be edited.Information that is not important for business prospective are edited by CMS.</p>


答:
If changes in components influence other components too often, it means the bad architecture. So, every such error has the cause in the architect himself.

After he acknowledges it, you could agree with the info on personal authorship, for easier finding WHO KNOWS the component better, not for any blaming. Together with code reviews made by owners of the neighbouring components, it could work.

This way no bad atmosphere is created.


答:
There is validity to his analysis, generally a programmer will 'load' a problem into their head and work on it as a whole.

Holding programs in one's head - pg essay

Don't have multiple people editing the same piece of code. You never understand other people's code as well as your own.

Some real life circumstances will dictate that programmers work with each other's code, but it should not be the standard operating procedure.

Incidentally, this is a big reason why TDD and code quality are popular.  They catch bugs when they are the cheapest to fix.  It costs a lot more to fix problems later than as the code is written and the information starts to fade away.

Part of the software architect's role should be to help migrate the architecture in this direction.

The software architect should be actively assisting in this process. Since I assume they have a deeper knowledge of the architecture, they should be able to help determine the specifics of this plan, what can be broken out into modules? how are dependencies managed? Who should start to take ownership of which part?  If the software architect is simply saying 'take ownership' and not helping to hash out all the details, they are a part of this problem as well.

One approach is to find the parts with the least amount of dependencies, and refactoring them.  Don't refactor just for the sake of it, but more often than not each module will have a feature request or two that would make it worthwhile to refactor.  Don't make it a rewrite!

If testing and code reviews are added to this process, the programmers will actually be better equipped to work with the modules other people create, because they will be writing more similar code that should be more easily tested and more debuggable, but code reviews and code ownership should be part of a plan to improve the software, not the entirety of the plan.


问:
Refactor or Concentrate on Completing App
Would you refactor your app as you go or focus on completing app first? Refactoring will mean progress of app app will slow down.

Completing app will mean you get a possibly very hard to maintain app later on?

The app is a personal project. I don't really know how to answer "What drives the functionality and design", but I guess it's to solve inefficiencies in current software out there. I like minimal easy to use software too. So I am removing some features and add some that I feel will help.

答:
Make it work.  Then make it fast. Finally, make it beautiful.

If you have good separation between your code (presentation, business, and data layers) using interfaces, and it's not a monolithic design, then refactoring should not be that difficult.

If you're having that much difficulty refactoring, that's probably a code-smell --  I suggest you look at Solid Principles

ContentLicense: CC BY-SA 2.5


答:
When you change a line of code in one component it usually breaks code in other components.

Ideal world scenario: You should have your APIs formalized and the API invariants tested in unit tests. If this is covered, when a developer makes a change that touches the invariants, tests will fail. When a developer makes a change that breaks unit tests, they should consider either updating the unit test, or updating the documentation of the API (and removing the unit test).

Our software architect blames this on collective code ownership.

No. Just no. As I understand it, it is more of a problem with everyone modifying code ad-hoc, across multiple components at the same time. This is not an issue with code ownership, but with the methodology of your team not formalizing/respecting API contracts and invariants.

He believes that if every developer was responsible for his own piece of code then he would tidy it up all the time because he would feel ownership over the component.

That's not realistic. If I wrote a piece of code and some other developer breaks it, I will not drop what I am doing to fix bugs introduced by said developer (as I have my own tasks and deadlines).

In current situation developers change code in multiple components and they break other components either because they don't understand how the component works (because they work with so many components) or because they don't care about how their changes will affect the other clients of the component (as long as they are not affected).

Developers changing multiple components (and breaking random stuff) to make their current code work, means lack of clear/formal definitions for your APIs (i.e. at this point there is no clear image of what the component should do), and lack of proper documentation for your APIs (i.e. developers entering functions to see what the implementation does, instead of reading the documentation for it).

What do you believe we should do to address the concerns of the software architect but still maintain collective code ownership?

Formalize your interfaces and document them. Ensure that the documentation of an API is always accurate (if your function states that a null value yields a MyException thrown, then you better have a unit test that calls the API with a null and catches the exception).

Give up cowboy coding and "five-minutes" fixes to any defect. There is no "quick fix" to anything. A defect fix should cover all of these:

API redesign (this is done on documentation, then API declaration)

unit test completion (add unit test for new behavior, remove and edit unit tests for modified behavior, only remote unit tests for behavior that is no longer actual)

API implementation changes

all tests passing

ensure clean code and clean diffs (no commented dead code, no code that is weirdly arranged, etc).

Most importantly, DO NOT ACCEPT public commits with failing tests or that have not gone through two rounds of code review (if a change causes failing tests, it is not a fix, it is one or more introduced defects). Two rounds of code review mean:

reviewer reviews changes and provides feedback to developer

developer performs changes according to review feedback

reviewer reviews changes again and gives approval/rejection

developer commits changes (after approval)

Ideally, each fixed defect will have a new unit test added to the system that checks exactly the behavior described in the defect.

When done like this, a one-liner "five minutes fix" becomes a "30 minutes or more" fix. Ultimately, this is not wasted time, it is time you will spend on implementing new features, instead of time spend in the debugger.


问:
Is there a web-specific reason for the design choices behind the JavaScript language?
With the advent of "the web is the platform", JavaScript is fast becoming the most widely used programming language in the world.

However, many tasks that are easy to accomplish in other modern languages are difficult or puzzling in JavaScript, because the language design is so "unique":

JavaScript has a prototype-based OOP system; most other modern languages have an inheritance-based one

JavaScript has such a weird typing system that it doesn't fall into any of the standard categories (plenty of examples on WTFJS)

JavaScript is extremely lenient in how it parses the syntax (semicolons are optional etc.)

From a developer's point of view, most of these design decisions make developing in JavaScript harder. Conceptually, the JavaScript language seems one step behind Java, and two steps behind Python and Ruby. But since I don't believe that the people behind JavaScript are striving to create a language that is difficult to use, I can only reason that those design points must have something to do with the intended use of JavaScript as a scripting language for web sites, deeply connected to the DOM.

How (if at all) do these design points cater to the intended use cases of JavaScript? What reasoning is behind those seemingly random design decisions?

答:
Prototypical inheritance

This appears to be because, despite what most claim, JavaScript is not a descendent of mostly Scheme, but Self. Self has prototypes and so does JavaScript.

Implicit Coercions

Neither Scheme nor Self had the invasive amount of implicit coercions that JavaScript has so we have to guess a little bit on why exactly they exist.

It's quite reasonable to suggest that Eich was looking at the web and noticed that everything was/is, a string. It makes some level of sense then to say "Hey I know, let's save the programmer lots of tedious typing and just implicitly turn strings into whatever we want".

Additionally, doing this rather than crashing means that while part of the page might render incorrectly because a string didn't hold a number, the page didn't crash. Which is arguably a much better UX. Occasionally doing something, even if wrong, is reassuring to the user.

Remember that JavaScript was rushed to the market and was frozen prematurely, no one knew how much weird stuff was lurking in JavaScript's implicit conversions until it was too late. I won't debate in this answer whether they're good though :)

Syntactic Sugar

I suspect this has nothing to do with JavaScript being a web language and everything to do with JavaScript trying to be easy to use. Allowing optional semicolons and other syntactic sugar is incredibly common nowadays. I'd say it's more common to find a language made in the last 10 years that omits semicolons than requires them.

This is all part of a trend towards JavaScript and other languages trying to optimize programmer time be making common patterns easy to type.

To wrap up, No, Kinda, No.


问:
Memoization Memory
Memoization is definitely a powerful technique.

But Dynamic Programming is slightly better IMO, since it does not involve the memory strain (in a recursive program, the parameters occupy memory and this memory increases as we go deeper into the recursion). But speed-wise, both are pretty equal.

But definitely memoization is a lot more straight-forward than Dynamic Programming.

My question: Is it somehow possible to use memoization without the memory constraint ?

答: You can reduce the amount of memory used for memoization by using a "Least Recently Used" cache (with limited maximum size) for the memoized values. How well this works depends heavily on the problem, the function you are going to memoize and the choice of the cache size. But I guess for a problem where DP works well, there is a good chance that function values needed in a first stage of a calculation won't be needed any more some stages later, so the LRU strategy will free the resources for these values automatically.</p>

Title: Memoization Memory


问:
MVC: What is the difference between a model and a service?
Why in some frameworks the logic layer is called "Model" whereas in some it is called "Service". Are they different from each other or just different by naming conventions?

UPDATE 1

The reason I'm asking is because in Zend Framework, a classical MVC framework, everybody uses the concept of Model. Now I'm learning AngularJS and it seems that the word Model disappeared and was replaced by the word service.

What I noticed is that a service is more like a singleton that can be reused again and again (example: a REST client) whereas a model is more related to the data manipulations coming from the controller in the MVC pattern.

答:
Model: Fields that belong to the object, methods that help to get/set data from the object (a fullname accessor that returns first + last name)

Service: Methods to perform operations with one or more models, see 'unit of work', transactions, etc...

Employee::create should just take a set of data, perform model validation if necessary, and return an Employee Object.

EmployeeService::hireEmployee might create the employee, send them a welcome email, create a mailbox, make them a sandwich, etc... it may return the set of data, or a result code, etc...

This can also affect validation:

Model Validation: Employee must have a id, first and last name, and birthday

Service Validation: Employees for the bartender position must be 21 or over, and approved by a manager.


问:
Is reinventing the wheel really all that bad?
Its common knowledge in programming that reinventing the wheel is bad or evil.

But why is that?

I am not suggesting that it's good. I believe it to be wrong. However, I once read an article that said, if someone is doing something wrong (programming wise) explain to them why its wrong, if you can't, then maybe you should be asking yourself if it is really wrong.

That leads me to this question:

If I see someone is clearly reinventing the wheel by building their own method of something that is already built into the language/framework. First, for arguments sake, lets assume that their method is just as efficient as the built in method. Also the developer, aware of the built in method, prefers his own method.

Why should he use the built in one over his own?

答:
I wrote a little article about this - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

In my experience, re-inventing has actually been great - although very lengthy and tedious. I would say, if you don't know exactly the programming models you are going to use, then write them yourself (if you have the time and energy). This will teach you about what exactly those programming models mean and you will become a better programmer ultimately. Of course, if you are working for a client and just need to get something up quickly, you will probably just want to do some research and find the right piece of software for you.


答:
How can I address the concerns of the software architect but still maintain collective code ownership?

I'm probably bikeshedding, but that's not your problem. The company owns the code, not a developer or an architect. Everyone works to better the whole. You have problems in your engineering process, and it's resulting in a blame game later.

You need to determine the cause of the failure (failed self test and broken components), and put policies and procedures in place to address the gaps. Once the policies and procedures are in place, there's no one to blame because "things just work".

In the current situation, developers change code in multiple components and they break other components either because they don't understand how the component works (because they work with so many components) or because they don't care about how their changes will affect the other clients of the component (as long as they are not affected).

Perhaps there's a third: the developers don't know they've nudged or broken code in other components.

That begs the question: what is in your engineering process to address the gaps? Are there policies and procedures in place to catch the problems early?

Process One

I can say for certain that liberal use of ASSERTs (as opposed to POSIX's useless assert) will ensure a developer knows about nearly every unexpected condition at development time. I call it "self-debugging" code, and I spend nearly no time under a debugger because the code tells me where the problems are.

When I say "liberal use of ASSERTs", I mean everything. You assert all parameters are expected when entering a function. You assert all program state used in a function. And you assert all return values from system calls. If there's an if to validate something, then there has to be a matching ASSERT. If there's an ASSERT to validate something, then there has to be a matching if. The code will not be able to fart or sneeze without a developer knowing about it.

Another way to look at it: why should you debug my code, and why should I debug your code? Let the code debug itself and tell you where the problems are.

Another way to look at it: why should you spend time debugging? Your time is better spent on adding features. Let the code debug itself and tell you where the problems are.

If you have not studied how to ASSERT, then it would a treat to read John Robbins. He is a master bug slayer. The book I learned from was Debugging Applications. His blog is at http://www.wintellect.com/blogs/jrobbins.

Process Two

There must be complete self tests for components. I don't waste a lot time on the positive self tests. I can hire a kid from India or Pakistan for US$10 a day to copy/paste code that works as expected under benign conditions. Rent-a-Coder is full of them.

I focus on the negative self test. I want to know how the program fails and ensure it recovers or fails gracefully. And when I say testing, I mean testing everything - even protected and private interfaces in a C++ class.

I don't buy into the arguments that "only public interfaces need testing". Hogwash until someone produces a program without bugs. I've got code in the field that goes years between bug reports because my engineering process requires 100% coverage with negative test cases.

Process Three

Continuous integration into a staging area. Every commit kicks off a build and self tests. Reject the check-in if it breaks a build.

The Real Gem

The real gem in the three processes above is you don't need expert coders. You can hire interns and junior developers to instrument code with ASSERTs and write test cases. I would even argue you need fewer expert programmers because the code is doing the heavy lift by debugging itself. That should make management happy.

And your expert developers will get pissed off when a junior starts breaking their code in obvious ways. I can't tell you how many times a guys with 10 or 15 years of experience complained to me about all the damn asserts that are firing. It's amazing what you find when you start looking for problems in code you thought was solid.


答:
I personally think your architect is correct.  I've never bought into this 'code ownership is bad' notion.  We're craftsmen.  Coders need to be responsible for what they create. And if they create a mess, they need to be the ones who clean it up.  Otherwise you end up with programmers making bugs, others fixing them, and the original coder never learning from their mistake.  Or worse, you end up with certain poor coders always being the ones making mistakes, and others always being stuck fixing them, carrying their weight.

Yes, code reviews will help that.  And its always good to have people familiar with other modules for the proverbial run over by a bus situation.  But nothing helps a coder code responsibly and defensively more than learning the hard way that if they screw something up, they'll be the ones stuck fixing it.

That said, with a dainty code base that breaks easily such as the one you describe, I doubt the lack of code ownership is the only problem in play here.  That indicates to me a lack of clear thought moving forward, and probably a lot of short term thinking on the part of everyone involved.


答: If you have the chance to add features or crush bugs to get your sales/customer satisfaction where you think it should be, do it. Once there are fewer new demands, you can balance with refactoring. At some point you have to make sure you're writing code people want. All things being equal, I'd rather throw away 100 hours of code than a 1000. Which is what you'll do if no one wants it.</p>

Title: Refactor or Concentrate on Completing App

Body:
Would you refactor your app as you go or focus on completing app first? Refactoring will mean progress of app app will slow down.

Completing app will mean you get a possibly very hard to maintain app later on?

The app is a personal project. I don't really know how to answer "What drives the functionality and design", but I guess it's to solve inefficiencies in current software out there. I like minimal easy to use software too. So I am removing some features and add some that I feel will help.


答:
I think the question should be rewritten along the lines of "how did the strengths/weaknesses of internet/web browsers/etc. influence the design and implementation of Javascript?" -- in which case, I will delete my post -- because most of the question is irrelevant/wrong/cherry-picked/superficial examples that don't really indicate anything about Javascript's design.

By learning more about Javascript -- especially using it to implement some applications -- you will find out that your points are really just traps for the unwary, but become non-issues for more experienced Javascript developers.  Understanding and taking advantage of Javascript's strengths, including this, lexical scoping, closures, higher-order functions, function literals turns out to be more important than getting tripped up by any of the weaknesses you mentioned.  OTOH, an actual problem that must be addressed is the lack of a standard module system.

The only interesting sub-question is:

JavaScript has a prototype-based OOP system; most other modern languages have an inheritance-based one

I suspect this has something to do with memory limitations, but I can't find a reference for that.  In addition, as @jozefg mentioned, there are other languages with prototype systems; it has different strengths/weaknesses than "mainstream" inheritance.  Prototype-based object systems have their own rich history that you should learn about before dismissing them as mistakes.

However, many tasks that are easy to accomplish in other modern languages are difficult or puzzling in JavaScript

Pick any language, and pose the reverse question -- how many tasks that are easy to accomplish in Javascript are difficult or puzzling in other languages?  What does the answer say about those other languages?  (IMHO, not much -- it's always easy to cherry-pick examples, but much harder to show how those examples prevent people from getting work done)

JavaScript has such a weird typing system that it doesn't fall into any of the standard categories (plenty of examples on WTFJS)

What is weird about it?  It's definitely not the only language that's dynamically-typed; neither is it the only one that allows coercions.  Perhaps the number of coercions and some unexpected behavior in certain corner cases are distracting you.

JavaScript is extremely lenient in how it parses the syntax (semicolons are optional etc.)

How so?  Do you have any other examples of leniency?  FWIW, semicolons are optional sometimes; it's actually well-specified and therefore not what I would call "lenient".

If this is a problem for you, use a linter.

From a developer's point of view, most of these design decisions make developing in JavaScript harder.

How so?  Can you provide examples?  This is very subjective.

Conceptually, the JavaScript language seems one step behind Java, and two steps behind Python and Ruby.

How so?  Can you provide examples?  This is very subjective.

What reasoning is behind those seemingly random design decisions?

Why do they seem random?

Title: Is there a web-specific reason for the design choices behind the JavaScript language?

Body:
With the advent of "the web is the platform", JavaScript is fast becoming the most widely used programming language in the world.

However, many tasks that are easy to accomplish in other modern languages are difficult or puzzling in JavaScript, because the language design is so "unique":

JavaScript has a prototype-based OOP system; most other modern languages have an inheritance-based one

JavaScript has such a weird typing system that it doesn't fall into any of the standard categories (plenty of examples on WTFJS)

JavaScript is extremely lenient in how it parses the syntax (semicolons are optional etc.)

From a developer's point of view, most of these design decisions make developing in JavaScript harder. Conceptually, the JavaScript language seems one step behind Java, and two steps behind Python and Ruby. But since I don't believe that the people behind JavaScript are striving to create a language that is difficult to use, I can only reason that those design points must have something to do with the intended use of JavaScript as a scripting language for web sites, deeply connected to the DOM.

How (if at all) do these design points cater to the intended use cases of JavaScript? What reasoning is behind those seemingly random design decisions?


答:
Structurally these base classes are the same, however they are used to classify a different concerns of the Service and Model tiers of the MVCS implementation

```<code>Service:- A concrete service class defines the API of an external Service.

Model :- Defines the API of the applications data model.
</code>```

So, whilst the base classes are alike, the concrete classes created by extending these base classes serve two entirely different purposes.

Title: MVC: What is the difference between a model and a service?

Body:
Why in some frameworks the logic layer is called "Model" whereas in some it is called "Service". Are they different from each other or just different by naming conventions?

UPDATE 1

The reason I'm asking is because in Zend Framework, a classical MVC framework, everybody uses the concept of Model. Now I'm learning AngularJS and it seems that the word Model disappeared and was replaced by the word service.

What I noticed is that a service is more like a singleton that can be reused again and again (example: a REST client) whereas a model is more related to the data manipulations coming from the controller in the MVC pattern.

Body:
Structurally these base classes are the same, however they are used to classify a different concerns of the Service and Model tiers of the MVCS implementation

Service:- A concrete service class defines the API of an external Service.

Model :- Defines the API of the applications data model.

So, whilst the base classes are alike, the concrete classes created by extending these base classes serve two entirely different purposes.


问:
How do you remember numerous API?
There are lots of other APIs I need to use besides the Selenium test tool to be able to get tests working. Not using them for just one week and the mind has lost all of them.

How is it possible to remember zillions of APIs?

答:
In the specific case of Java, which has been linked to here from another question, the answer is simple:  Do not bother memorizing the APIs.  Why?  Java SE has 3977 classes!

The Topmost / Leftmost / Most easy to reach bookmark on you web browser should be to the Java API docs, e.g. like this  They are very thorough and, in most cases, well written.  Between this and your IDE you can do most everything.

I am now learning node.js and Mongo, and have similar links to the node and mongoDB documentation, which isn't as nice but is still way better than nothing.

Title: How do you remember numerous API?


问:
Is it better to use already build plugins/extensions or code your own in programming projects
I am building a web app in  PHP and Symfony.

Basically if we search there are plugins / extensions / bundles for almost 60% of stuff.

The advantage of using them is that you can easily get your functionality and it will be maintained by the author
and we don't need to worry about compatibility.

But their downside is

Sometimes it's hard to do little bit customization if we want some extra behavior. In past I used some extension it work ok to start with.

Then I wanted to do something else which i was not able to figure out and in the end i had to code my own. It was not as efficient but I had full control.

Also if we depend on extension then we don't learn much as everything is done by the extension. Then if I need to switch the language or framework and that extension is not available in that environment then again I had to scratch my head and start from scratch.

But if I don't use them then I am thinking that I am wasting my time. I am confused what should be done?

答:
Another answer already listed a good pros/cons list, and comparatively my answer will probably seem a bit simplistic, but in my mind, the choice is really simple.

If it is a simple extension with almost no time investment, do it yourself.  If it is a big extension that will take one or more days to complete, then only build it yourself IF your requirements justify the expense of time.  I don't believe in pushing square plugins into a round-requirement :-p, so if the requirements of the project merit it...go custom.

Often existing plugins try to be everything to everyone and add a lot of bloat, complexity, and confusion...or it functions but is a mess programmatically and difficult to maintain, so I avoid them for anything simple.  However, in the JavaScript world, something like a datetimepicker is a complex plugin that I'm not going to do myself unless requirements mandate that the existing ones don't work for some reason, because that's too high of a time-investment to justify the cost.  Writing my own wouldn't produce a drastically different picker, so the only point in that case would be for the experience itself.

However, it's not always either/or.  You can also have the best of both worlds for any project that is on github or similar distributed repository.  Simply fork the project, configure it to meet your needs, and then pull updates from the main project into your fork when you can and your project can be dependent on the fork.  As long as you don't completely rewrite it, merges shouldn't be too hard.


答: As long as you are sure you can meet deadline sure you can refactor all you want. However even if there is a bit of uncertainty better to stick with development and may be refactor only in modest incremental step.


问:
Sending e-mails without using an e-mail server
JavaMail sends e-mails using an e-mail server, typically through the SMTP interface of an e-mail provider.  Is it necessary to use an e-mail server to send e-mails?

I have a web site that will send e-mails and if possible I'd like to send the e-mails directly from the web site code without using an e-mail server.  The JavaMail FAQ says that an e-mail server is required.

Is there a way to send e-mails without using an e-mail server, either with JavaMail or another API?

答:
If we have to send a mail to somebody from Java code, we need to have access on some mail server credentials. Well, not always.

Google has provided free access to one of its mail servers and you can use it in Java code.
Below written code if more like a note to my self. So, if I need it sometime, you can refer here: http://www.computerbuzz.in/2014/02/how-to-send-email-in-java-using-gmail.html

```<code>private void setMailServerProperties()
    {
        Properties emailProperties = System.getProperties();
        emailProperties.put("mail.smtp.port", "586");
        emailProperties.put("mail.smtp.auth", "true");
        emailProperties.put("mail.smtp.starttls.enable", "true");
        mailSession = Session.getDefaultInstance(emailProperties, null);
    }

    private MimeMessage draftEmailMessage() throws AddressException, MessagingException
    {
        String[] toEmails = { "computerbuzz@gmail.com" };
        String emailSubject = "Test email subject";
        String emailBody = "This is an email sent by http://www.computerbuzz.in.";
        MimeMessage emailMessage = new MimeMessage(mailSession);
        /**
         * Set the mail recipients
         * */
        for (int i = 0; i < toEmails.length; i++)
        {
            emailMessage.addRecipient(Message.RecipientType.TO, new InternetAddress(toEmails[i]));
        }
        emailMessage.setSubject(emailSubject);
        /**
         * If sending HTML mail
         * */
        emailMessage.setContent(emailBody, "text/html");
        /**
         * If sending only text mail
         * */
        //emailMessage.setText(emailBody);// for a text email
        return emailMessage;
    }

    private void sendEmail() throws AddressException, MessagingException
    {
        /**
         * Sender's credentials
         * */
        String fromUser = "user-email@gmail.com";
        String fromUserEmailPassword = "*******";

        String emailHost = "smtp.gmail.com";
        Transport transport = mailSession.getTransport("smtp");
        transport.connect(emailHost, fromUser, fromUserEmailPassword);
        /**
         * Draft the message
         * */
        MimeMessage emailMessage = draftEmailMessage();
        /**
         * Send the mail
         * */
        transport.sendMessage(emailMessage, emailMessage.getAllRecipients());
        transport.close();
        System.out.println("Email sent successfully.");
    }
}
</code>```

Body:
If we have to send a mail to somebody from Java code, we need to have access on some mail server credentials. Well, not always.

Google has provided free access to one of its mail servers and you can use it in Java code.
Below written code if more like a note to my self. So, if I need it sometime, you can refer here: http://www.computerbuzz.in/2014/02/how-to-send-email-in-java-using-gmail.html

private void setMailServerProperties()
    {
        Properties emailProperties = System.getProperties();
        emailProperties.put("mail.smtp.port", "586");
        emailProperties.put("mail.smtp.auth", "true");
        emailProperties.put("mail.smtp.starttls.enable", "true");
        mailSession = Session.getDefaultInstance(emailProperties, null);
    }

    private MimeMessage draftEmailMessage() throws AddressException, MessagingException
    {
        String[] toEmails = { "computerbuzz@gmail.com" };
        String emailSubject = "Test email subject";
        String emailBody = "This is an email sent by http://www.computerbuzz.in.";
        MimeMessage emailMessage = new MimeMessage(mailSession);
        /**
         * Set the mail recipients
         * */
        for (int i = 0; i < toEmails.length; i++)
        {
            emailMessage.addRecipient(Message.RecipientType.TO, new InternetAddress(toEmails[i]));
        }
        emailMessage.setSubject(emailSubject);
        /**
         * If sending HTML mail
         * */
        emailMessage.setContent(emailBody, "text/html");
        /**
         * If sending only text mail
         * */
        //emailMessage.setText(emailBody);// for a text email
        return emailMessage;
    }

    private void sendEmail() throws AddressException, MessagingException
    {
        /**
         * Sender's credentials
         * */
        String fromUser = "user-email@gmail.com";
        String fromUserEmailPassword = "*******";

        String emailHost = "smtp.gmail.com";
        Transport transport = mailSession.getTransport("smtp");
        transport.connect(emailHost, fromUser, fromUserEmailPassword);
        /**
         * Draft the message
         * */
        MimeMessage emailMessage = draftEmailMessage();
        /**
         * Send the mail
         * */
        transport.sendMessage(emailMessage, emailMessage.getAllRecipients());
        transport.close();
        System.out.println("Email sent successfully.");
    }
}


问:
is it considered plagiarism to comment out code I copied from elsewhere?
If the plagiarized code is commented out because I found another way to solve the problem, but I forgot to remove the comments, is that considered plagiarism?

I used the copied code to help me debug and compare the output between my own code and the copied code. In the final code, I commented out the copied code. Since comments don't affect how the code runs, can comments be considered plagiarism?

答:
School: They like you doing your own work.  Even if the code isn't used, it being there might be enough to get you in trouble based on the teacher/school

Work: Dead Code/Commented out Code can and has gotten people in trouble before in lawsuit cases (assuming the code was conflicting with someone's proprietary code).

If it's under most of the creative commons licenses, MIT licensing, BSD, etc... from the owners standpoint you should be good. Assuming you're following the license on usage (making the software free, only using for academic purposes, etc)

My gut feeling would be this:
Remove the code you're not using, it's good practice anyway (it adds nothing to the understanding of your live code), dump it into a "dead" file so that you still have all of the code, but don't have it in your distributed code.  Or better yet, if you're using a version control system, just remove the code and do a commit, you've got your commit history so you'll always have the code.


问:
Why do we study Java at university?
Java is often found in academia. What is the reason behind that? </p>

答:
I was in school when Java came out.  And my university almost changed overnight.  People were out right giddy at Java in academia.  I was a Jr when it came out, and by the time my senior year, almost all academia was quickly moving to change their curriculum.  Not just at my university but everywhere.  It was really that fast.  Our second intro course was Pascal, and that quickly converted to Java in less than a year.  Why did they convert so fast?  Two big reasons.

One academics want to teach the theory and algorithms.  Languages that facilitate you learning those algorithms that don't need a lot of experience to operate are best: Scheme, Python, Java, Smalltalk, etc.  The more the language gets in the way the more distracted you are from learning the real algorithms.  At the time scripting languages were second class citizens frowned upon by employers as cheap or quick and dirty.  Academics saw them as more copy cat, but what employers want has sway with academics too.

That brings us to the next reason.  Employers want certain language experience, and at the time that was C/C++.  But, C/C++ takes a lot of experience to learn, and has a lot of corner cases and if ands or buts that are distracting.  We learned courses in C/C++ but not at the lower levels.  At the time employers were mad at CS programs because students didn't come out being C/C++ gurus.

Java was sweeping through the industry too almost as fast as academia.  So finally academia was getting what they wanted.  High level language that was easier to learn, and a language employers wanted.  It was all too perfect.  I had a friend return to academia maybe 3 years after I left, and he said you could find a Java book in every CS subject.  That's how fast Java took over academia.

Personally I think Java hasn't dumbed down CS I think it's actually been a good thing because students can study CS, participate in Open Source, and find work even while their in school.  I still believe you should study lots of languages as a CS student, and that shouldn't just be Java.  But, if they all used python Joel would hate on python too.

Title: Why do we study Java at university?


问:
Big Data: Can it be pre-processed?
My question is about "big data". Basically, big data involves the analysis of a large amount of data to make meaningful insights from it.

I would like to know:

Whether or not large amounts of data can be pre-processed? (like say for example you are running some matching service for people, so you take all the information you have on the people and you process it at a certain point for use later on)

If pre-processing is possible, how would you normally go about doing this?

To help narrow the scope of my question, please look at this hypothetical scenario.

Say I have a customer database and my company is a global retailer
  that is using some type of points system to reward the shoppers (for
  arguments sake, the points are tallied up on a type of electronic card
  or mobile app).

So based on my rewards system, I am now able to fully aware of exactly
  what a shopper is purchasing and when they normally make purchases of
  recurring items.

My database is growing all the time with this information and I would
  now like to make recommendations (or send notifications) to shoppers
  about special offers of products they buy or related products that may
  interest them, when they enter 1 of the stores.

Instead of processing all the accumulated data when a shopper enters
  the store, I would like to continually process the data-stream as the
  data comes in (meaning from previous shopping experiences), so that
  when it comes time to make a recommendation (for the next time a
  shopper walks into the store), it is simply a matter of retrieving the
  recommendations and providing a list of it to the shopper.

With this method in mind, I can easily space out my CPU-intensive
  tasks, instead of say: processing all customer data on a busy day when
  foot-traffic is at peak volumes.

By asking how I would do this, I would be referring to common methods available for achieving this. This can include any special databases or programming techniques or even specialized software that can carry out these timed calculations that can "pre-process" the data at specific times, in order to balance out CPU-intensive tasks.

You can consider the customer-recommendation scenario as the "situation". It is the best example scenario I could think of that would explain why "pre-processing" (or calculating the recommendations at specific times) would make sense.

答:
Typically I've heard of this being handled via the OLTP vs. OLAP model.  Essentially the T in OLTP means "transactional", so this is the typical databased used for day-to-day operations.  Then you write some kind of translational logic that transforms the OLTP database into an OLAP database (the A stands for analytical).

Basically you're talking about the same data represented 2 different ways.  The OLTP database focuses on normalization but the OLAP database is structured in more of a "star" pattern with a lot more data repetition.  It's read-only and optimized for querying.

Then the engineering is in figuring out how to do the translation from OLTP to OLAP, how often to do it, and if you can do it incrementally so the OLAP database isn't too far behind "real-time".

Title: Big Data: Can it be pre-processed?


答:
If you use code from elsewhere, always make sure that you keep track of where you got it from, e.g. keep the URL next to the code you copied or even better, really state that some part of that code came from that source.

Plagiarism is the "wrongful appropriation" and "purloining and publication" of another author's "language, thoughts, ideas, or expressions," and the representation of them as one's own original work. So if you put a clear reference, it will not be plagiarism.

However, that doesn't put you in the clear: copyright (or licensing) may still be an issue. If the original code doesn't state a license, it is not safe to use it in production. IANAL, but I wouldn't worry too much about putting a piece of code for which there is no explicit license in the comments if you have your equivalent implementation that is clearly different (e.g. not just renaming all variables or porting to a different language).

If the original code has some kind of license, you will have to consult that to make a judgement call and abide by the license.

If this is for school work, then it really depends on the agreements you have with your teacher/school (e.g. honor codes). As a TA myself, I prefer students to be honest and write where they've got some parts of their solution (even if those sources happen to be other  students). If only a minor part of their result is their own work, then they have a problem.

Title: is it considered plagiarism to comment out code I copied from elsewhere?

Body:
If the plagiarized code is commented out because I found another way to solve the problem, but I forgot to remove the comments, is that considered plagiarism?

I used the copied code to help me debug and compare the output between my own code and the copied code. In the final code, I commented out the copied code. Since comments don't affect how the code runs, can comments be considered plagiarism?


问:
Layers and layers of SOAP
I am designing the back-end to a SOAP web-service and have a question about how I am thinking of doing it.

I am going to go with a simple layered design which consists of 3 separate layers.

```<code>Layer 1 -> Layer 2 -> Layer 3
</code>```

Layer 1 : Will implement the SOAP skeleton interface, so this will be the main entry point of my application. This layer will pull data from the SOAP request and pass it to the business logic layer as a business object. It will get back business objects from the business logic layer with which it will populate a SOAP response.

Layer 2 : Business logic layer that implements the business logic behind the web-service. It will be passed data from Layer 1 and interact with Layer 3, the DAO layer.

Layer 3 : DAO layer which will preform CRUD operations on my DB.

With populating SOAP response objects in my code, the implementation might be a bit messy in Layer 1, so I came up with the following 3 options.

Option 1 - Three layers is enough, any more layers would be overkill. SOAP objects are always going to be messy looking, just get over it.

Option 2 - Create an extra layer between Layers 1 and 2. This layer would take data from the SOAP request, populate a business object which it would then pass to the business logic layer. This would keep the methods in Layer 1 neat and tidy. It would look something like this :

```<code>Layer 1  ->  SOAP Request   ->  Layer 1.A  ->  Business Object  ->  Layer 2
Layer 1  <-  SOAP Response  <-  Layer 1.A  <-  Business Object  <-  Layer 2
</code>```

Option 3 - Do not create any more layers. Simply create a utility object with a method that takes a SOAP request and returns a business object. I could then pass the business object to Layer 2. The same utility object could then be used in Layer 2 to pass a SOAP response back to Layer 1. Or does this approach kind of blur the lines and make my design less modular?

答:
It depends on what you might potentially share layer 2 with. If most of your back end systems operate on business objects, it makes much more sense to have the data converted to a business object before passing it off to your other systems. Both conversion and simple pass-through will work, but in the absence of any strict requirements I would suggest whichever is more conceptually local to your current systems. This is primarily for maintainability reasons.

Including an extra layer depends on if you expect to include multiple operations/endpoints on a single call. The extra layer decouples the SOAP request from the operations, allowing flexible mix/match and request dispatch based on identification without putting that in the web service layer. It can be very useful if you can't treat all requests the same, for whatever reason(different source, load balancing, etc.). If you don't expect that at all, you should be fine to design for the limited per-call case and nix the extra layer.

 In either case, I would recommend making the transformation process into a utility object. It doesn't 'cost' you very much, and I find/use our front-end to xml utility all over the place. (We have a plethora of front end formats/channels we accept on, but consolidate to a single xml format for use internally.)

Title: Layers and layers of SOAP


问:
An alternative to an array of functions?
I'm programming an app (php) which requires a very long list of similar yet different functions, which are being called by a set of keys:

```<code>$functions = [
    "do this" => function() {
        // does this
    },
    "do that" => function() {
        // does that
    }
]
etc.
</code>```

I've chosen to place the similar functions in an array because they are not similar enough - getting the same result with one big function which is full of conditional statements isn't gonna work. And I do need to be able to call them only by key, for example:

```<code>$program = ["do this", "do that", "do this"];
foreach ($program as $k => $v) {
    $functions[$v]();
}
</code>```

Thing is this functions-array structure is causing many problems, for example I'm having a hard time calling one array function from within another array function, e.g. this doesn't work:

```<code>"do that" => function() {
    $functions["do this"]();
}
</code>```

nor this:

```<code>"do that" => function() {
    global $functions;
    $functions["do this"]();
}
</code>```

or this:

```<code>"do that" => function($functions) {
    $functions["do this"]();
}

$functions["do that"]($functions);
</code>```

I guess I could have one giant function with a long switch statement:

```<code>function similar_functions($key) {
    switch ($key) {
        case "do this":
            // does this
        break;
        case "do that":
            // does that
        break;
    }
}
</code>```

But that doens't really seem like good practice. Or maybe it is?

So, what are my alternatives? Should I go with the switch structure? Or is there another, better solution?

答:
You're essentially asking when and how to branch. My general suggestion would be to:

only write the code to branch once (DRY).

call the code-that-determines-how-the-code-branches once and then don't branch again.

consider using the Strategy Pattern or the Command Pattern.

With an Object-oriented approach (per the patterns), the branching decision might be controlled by a SomethingStrategyManager class, which would give you an instance of ISomethingStrategy. Then you would run the ISomethingStrategy's doTheThing method.

In very generic pseudo-code:

```<code>interface IMyStrategy:
  method doTheThing(string name); //returns a BOOLEAN value
  ... //maybe this interface can have more methods?

class MyStrategyManager:
  method getStrategyForSomeArgs(int a, string c) //returns IMyStrategy
     if (a % 2 == 0) return new EvenNumberStrategy();
     else if (a.isPrimeNumber) return new PrimeNumberStrategy();
     else if (c == "CustomSomething") return new CustomStrategy();
     else return new DefaultStrategy();

...

// Using the strategies:
IMyStrategy strategy = MyStrategyManager.getStrategyForSomeArgs(3, "foo");
BOOL success = strategy.doTheThing("john smith");
...
</code>```

Body:
You're essentially asking when and how to branch. My general suggestion would be to:

only write the code to branch once (DRY).

call the code-that-determines-how-the-code-branches once and then don't branch again.

consider using the Strategy Pattern or the Command Pattern.

With an Object-oriented approach (per the patterns), the branching decision might be controlled by a SomethingStrategyManager class, which would give you an instance of ISomethingStrategy. Then you would run the ISomethingStrategy's doTheThing method.

In very generic pseudo-code:

interface IMyStrategy:
  method doTheThing(string name); //returns a BOOLEAN value
  ... //maybe this interface can have more methods?

class MyStrategyManager:
  method getStrategyForSomeArgs(int a, string c) //returns IMyStrategy
     if (a % 2 == 0) return new EvenNumberStrategy();
     else if (a.isPrimeNumber) return new PrimeNumberStrategy();
     else if (c == "CustomSomething") return new CustomStrategy();
     else return new DefaultStrategy();

...

// Using the strategies:
IMyStrategy strategy = MyStrategyManager.getStrategyForSomeArgs(3, "foo");
BOOL success = strategy.doTheThing("john smith");
...


答:
Its plagiarism if you claim the copied code is your own work. But schools and businesses often prefer to have a bright line around what you wrote. If I copy (retyping, cutting and pasting, etc.) something that someone else wrote, remove their name, put in my name as 'author', and tell people I wrote it, that's plagiarism.

Its not like fair use or licensing. If I copy "main(int argc, char *argv[])" from a text book or web site, its not plagiarism unless I claim I invented it. If I implement DVD encryption/decryption or JPEG compression/decompression and give appropriate credit, its not plagiarism, but I'm still in trouble, because I'm not LICENSED to have them. Even if I envented it syself in a clean, white room.

If I put someone else's implementation of something inside my code to compare my version with their theirs, not indicating what I wrote and what I copied, that's ambiguous. If I have a comment that reads, "Compare to my code" then I'm clearly not claiming authorship, its not plagiarism. If someone asks me and I say, "that's a solution I found in a book, on the internet, etc", that's not plagiarism. Whether or not its in comments or live.

Plagiarism is knowingly copying someone else's work and claiming that its yours.

I hope that helps.

Bill


答:
According to my experience, the Model layer within the MVC design pattern refers to every software component involved with data manipulation (POJOs, DAO, all the way to SQL, JDBC, and so on).

Whereas the service layer is actually an addition to MVC:

We know that the Model layer components are invoked inside the Controller layer. Once the latter is built, you come to realize that it doesn't look concise (messy with dirty code); the Controller may not afford extra details (e.g. formatting request parameters before calling a DAO method that are going to consume them ...). Therefore, you might include this extra layer, namely the Service layer.

Eventually, you may encompass your dirty code inside static methods with a meaningful name, parameters and so forth, which would outcome a synthetic Controller layer.

Take a look at this link:

https://stackoverflow.com/questions/2762978/the-purpose-of-a-service-layer-and-asp-net-mvc-2


问:
outOfMemoryException in android emulator
I'm developing an Android application which is responsible for showing multimedia such as videos and photos to user.

I have a certain activity for a gallery of photos. In my phone where I'm developing the application everything works correctly. Currently I'm testing it in an emulator with a small screen for checking for layout mistakes and I noticed that the gallery activity crashes when scrolling through photographs by throwing an outOfMemoryException.

My phone where I was developing the application is a Samsung S Advance, which I think is average, not something really powerful, just a phone with normal specs.

Should I be worried about that exception I'm getting in the emulator or is it something that will never happen in real-world conditions?

答:
When Android was still a little boy, it's parents decided to give it each of its applications a memory limit. Seeing how the screens were relatively small phone-screens and the RAM and resolutions were low it made perfect sense to set this to 16MB per app.

What the parents didn't fully take into account was that the little boy would get bigger. Screens got bigger, resolutions got way bigger and it's RAM is now so big you could run Windows on it.

Many manufacturers such as Samsung have increased this per-app memory limit to 24MB or 32MB in their ROMs. I've seen tablets with per-app memory limits of 96 to 128MB.

You can find out how high the the memory limit on your device is by calling ActivityManager.getMemoryClass.

In real life, I've seen very few devices that have high resolution screens with the kind of low per-app memory limits as the emulator does, so I wouldn't worry about it too much.


问:
Unit Testing with an Optimization Problem
Suppose I'm making an algorithm that identifies the subject of a picture. It could be anything that a computer doesn't do that well, but I'm not expecting to get the right answer every time - 80% is fine. Suppose further, that the accuracy of the intermediate steps was also somewhat fuzzy. Is there a way to incorporate unit tests?

The option that immediately comes to mind is to add 1 to a tally and every time a 'test' passes, increment the tally. When that finishes, divide by the total and test 'passes/tests > 0.8', but that seems kludgey.

EDIT: Thank you all for your kind words and well-reasoned responses. My particular problem, while fuzzy, has nothing to do with pictures, and I'm currently getting about 80% pass. The short term value for me in a testing scheme would be knowing whether small adjustments were more globally beneficial or catastrophic. Long term testing value should be obvious.

答:
TDD is not a design technique.

While it can aid at producing an effective design (and validating the veracity of that design, and verifying that your software still works after refactoring), you still need to think about the structure of your programs and come up with some sort of algorithmic representation for the specific problems you are trying to solve.

You can't just expect a solution to a non-trivial computing problem to emerge organically from red-green-refactor, especially if that problem involves heuristics.  Naturally, if you have some idea about how the solution will emerge, you can model that idea with unit tests, but you can't expect to get pearls from sand if you don't even have a clam.

In any case, you can't have a test that passes 80% of the time and call that a successful unit test.  What you can have are five tests, four of which produce one result, and one of which produces the other, or a test that returns some metric (other than passes/fails) which you can assert to be 0.8.  That provides your 80% ratio, while still maintaining "go, no-go" states.


问:
System Programming & Object Oriented Design - what to look out for
Next semester (starts in just under 5 weeks), I'm taking System Programming and OOD concurrently.  Apparently SP centers on working in C on Linux, and I only have Java and Python experience, so I am a little nervous about this.

For those of you who've taken these at an university, what should I look out for?

I've already taken Computer Organization which included an overview of Assembly.  With the exception of implementing loops in assembly, I ranged from B+ to A- in the assembly projects.  Building circuitry was another story, however.

答: For Systems you have to go low. You have to understand how fundamental stuff pointers, memory management, registers, system calls, even assembly and system architecture etc work. OOPS is at higher level of abstraction. So you will have to continuously switch your perspective or rather frame of abstraction. As long as you keep this in mind, I don't think it should be that difficult.</p>


答:
TDD usually talks about unit tests, which can be white-box tests.  You are talking about a black-box integration test.

At some point you will have an actual algorithm.  If working properly it will pass some inputs, and fail others.  That's what you test.  Whether it gets 80% right will depend on the inputs you test.  Whether the result is acceptable for the ultimate real-world inputs you encounter won't be something your unit tests cover - though you could of course get a sample of real-world inputs and test those against the top level methods.

Title: Unit Testing with an Optimization Problem

Body:
Suppose I'm making an algorithm that identifies the subject of a picture. It could be anything that a computer doesn't do that well, but I'm not expecting to get the right answer every time - 80% is fine. Suppose further, that the accuracy of the intermediate steps was also somewhat fuzzy. Is there a way to incorporate unit tests?

The option that immediately comes to mind is to add 1 to a tally and every time a 'test' passes, increment the tally. When that finishes, divide by the total and test 'passes/tests > 0.8', but that seems kludgey.

EDIT: Thank you all for your kind words and well-reasoned responses. My particular problem, while fuzzy, has nothing to do with pictures, and I'm currently getting about 80% pass. The short term value for me in a testing scheme would be knowing whether small adjustments were more globally beneficial or catastrophic. Long term testing value should be obvious.


答:
For this type of problems perhaps a inside-out approach to TDD can be most effective. Probably you need different deterministic parts to build your complete solution, you can build those part with "normal" TDD.

Also you can make some complete test of your algorithm using a predefined set of images, with this you can check if the results reach some threshold. With this you can verify this threshold with every change, the most difficult parts its perhaps to select the collections of images that represent the different possible scenarios in which your algorithm is supposed to give good results.

With this second test you cannot go step-by-step for designing and algorithm, are really useful for verifying purposes but not real useful for designing and algorithm. TDD is not a technique for designing algorithms like the classical sudoko example from Ron Jeffries (one of the original members of the Kent Beck C3 team that popularize the TDD technique).

In resume, you can use TDD to build and perhaps design some of the multiple small parts that your complete algorithm needs, and you can use simple test for verify behavior, but use TDD for build a complete algorithm is not "magic", you need to study the different techniques for algorithms construction.


问:
Iteratively improve software architecture & quality in an agile process?
Or to put it another way how to ensure that architecture or quality doesn't suffer, doing agile.

Some of the understandings in handling architecture in agile are below(generally applies to testing as well)

* Do architecture until risks fall off your radar
* minimal design up front, so that you will not pay a horrible price for reasonable change requests.
* "just enough" architecture/infrastructure per each feature/requirement

(The above were found in searching other related StackOverflow questions)

A hypothetical example/scenario is that there is a requirement to develop a order processing module in the existing system. The below guidelines are negotiated and agreed upon.

The architecture for module should be able to handle processing of 10 orders in the span of a minute.

Time to market is 4 weeks, planning is done to handle 2 sprints of 2 weeks.

The Business is satisfied with average performance expectations.

Once the module is delivered, lets say the following improvements/changes are requested.

Improve the processing to 15 orders per minute.

Improve performance by 25%.

Time to market is 2 weeks.

So assuming the further requirements from the customer/business come and which are welcome, but in future as the iterations go on, the architecture needs to be overhauled, and testing the quality of the module also becomes more time consuming.

And the above is not a happy result, as estimations increase, and there is an understandable inability to meet further expectations or requirements quickly.
Even if it can be done in the given timeframe with sufficient quality, just wish that we could have done something about it well before and not face this situation at this point of time.

In hindsight, architecting to scale in the first iteration would be ideal, but that was not the goal and focus. The focus is always on Time to market, and on acheiving on meeting the business/customers expectations in a given timeframe. Unfortunately, in the long run
it does take a toll on development.

What can be done to avoid the mentioned pitfall in the example, in improving the architecture or testing process iteratively?

答:
Agile architecture is a running gunbattle.  I try to implement it in a just-in-time methodology, but ultimately, it is in direct opposition to agile methodologies.  That doesn't mean it's bad.  It is very important, it's just not something that fits into the agile process.

Up front architecture and design is really a hedge against the risks of agile development.  You have to balance your risk mitigation with your time to market.  In this case, it sounds like you came down a little on the wrong side of the risk/reward equation.  Next time you might do too much architecture, and waste a bunch of time.  Unfortunately, it just takes experience and wisdom to figure out how much is "too much" architecture for an agile process.

OwnerDisplayName: BST

OwnerDisplayName: Rob Conklin


答:
I think that mostly you are mixing the wrong levels of abstraction and thus, you are getting stuck.

First of all, there can be requirements to change the architecture, but they do not normally make good stories. Say for example you need to improve performance by x%. This is not a user story and it might not be achievable at all. There are systems that can't be improved, there are systems that can only be improved at very great cost, etc.

The first two missing bits that come to mind are:

What is the business value of improving performance by x%?

What are the correct boundaries in which we operate?

Can't we simply purchase a x% faster server, for example?

There are no "architectural" stories in agile development because architecture has no actual value to the user.

Architecture is a tool, it has practical value and it is useful in agile development, but it has nothing to do with architectural stories. Architecture is an activity, like design, refactoring, debugging, etc. None of these activities would ever make a good story, but all of these activities are typically part of the development of a story.

Another point to keep in mind, architectural qualities become part of the "definition of done". If you have a requirement that every web page should be delivered in less than 500ms, making this part of the DoD ensures that this applies to every story, and it becomes a criterion for its acceptance testing.

Furthermore, changing significantly the performance level set as "definition of done", is generally a risky move. Unless you simply made a mistake and set the wrong value, changing the performance profile of an application is difficult on many levels -- and it's especially difficult to estimate.

As an alternative you can limit the impact by specifying in which cases you want this change and why. This allows the team to be set for success, with results which are likely to be achievable. Nobody can be sure that you can change the performance of a complex application on a general level, however estimating a single page or feature is more feasible.

Regarding hardening stories: the only approach that I've seen work (and what we use at Stack Exchange) is having one person on bug duty every iteration. This ensures that there's always someone on the piece when problems arise, is fair in nature, and completely sidesteps the scheduling problems that arise when treating bugs as stories ("there's a new bug in the middle of an iteration, do we fix that or close the stories?").

Title: Iteratively improve software architecture & quality in an agile process?

Body:
Or to put it another way how to ensure that architecture or quality doesn't suffer, doing agile.

Some of the understandings in handling architecture in agile are below(generally applies to testing as well)

* Do architecture until risks fall off your radar
* minimal design up front, so that you will not pay a horrible price for reasonable change requests.
* "just enough" architecture/infrastructure per each feature/requirement

(The above were found in searching other related StackOverflow questions)

A hypothetical example/scenario is that there is a requirement to develop a order processing module in the existing system. The below guidelines are negotiated and agreed upon.

The architecture for module should be able to handle processing of 10 orders in the span of a minute.

Time to market is 4 weeks, planning is done to handle 2 sprints of 2 weeks.

The Business is satisfied with average performance expectations.

Once the module is delivered, lets say the following improvements/changes are requested.

Improve the processing to 15 orders per minute.

Improve performance by 25%.

Time to market is 2 weeks.

So assuming the further requirements from the customer/business come and which are welcome, but in future as the iterations go on, the architecture needs to be overhauled, and testing the quality of the module also becomes more time consuming.

And the above is not a happy result, as estimations increase, and there is an understandable inability to meet further expectations or requirements quickly.
Even if it can be done in the given timeframe with sufficient quality, just wish that we could have done something about it well before and not face this situation at this point of time.

In hindsight, architecting to scale in the first iteration would be ideal, but that was not the goal and focus. The focus is always on Time to market, and on acheiving on meeting the business/customers expectations in a given timeframe. Unfortunately, in the long run
it does take a toll on development.

What can be done to avoid the mentioned pitfall in the example, in improving the architecture or testing process iteratively?

OwnerDisplayName: Sklivvz


答:
It's a common question - and one that a lot of our customers ask when we discuss agile.

The key word in your question is "hindsight". For every time that I've encountered an "if only we had known" moment, I've encountered many "You Ain't Gonna Need It" moments (YAGNI). Trying to fix all current and future problems/requirements in a single release will drive you crazy, make the software complex, late and expensive, and generally slow you down.

On the whole, the rework required to improve performance for an existing, well-crafted feature is much less wasteful than investing in "architectural" solutions to hypothetical problems.

When explaining this to my clients and my teams, I generally say that the team's job is to optimize throughput and quality; the client's job is to make sure we're always working on the most valuable tasks. The whole point of agile is that "valuable" changes over time, and that the team responds to this quickly. As long as you achieve that, rework isn't a big deal, even if it feels inefficient.

OwnerDisplayName: Neville K