Unconditional Code • Michael Feathers • GOTO 2018
ฝัง
- เผยแพร่เมื่อ 8 พ.ค. 2018
- This presentation was recorded at GOTO Chicago 2018. #gotocon #gotochgo
gotochgo.com
Michael Feathers - Working Effectively with Legacy Code
ABSTRACT
Many systems are full of error checks and conditional logic. They introduce discontinuities that make reasoning difficult. In this talk, Michael Feathers will present a conceptual framework for dealing with errors, conditionality and decision making at the level of code, architecture [...]
Download slides and read the full abstract here:
gotochgo.com/2018/sessions/358
/ gotochgo
/ gotoconference
gotocon.com
#SoftwareArchitecture #RobustCode #ErrorHandling #Patterns
Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
th-cam.com/users/GotoConf... - วิทยาศาสตร์และเทคโนโลยี
![The Forgotten Art of Structured Programming - Kevlin Henney [C++ on Sea 2019]](/img/n.gif)
A sad set of raging comments focusing on tiny details instead of reading between the lines and understanding the bigger picture presented here. Quite a nice talk, hopefully as time passes by, people will realise how important is to remove implicit intentions away from the codebase. Expanding the domain by including them was subtle but essential advice.
One thing I do is to convert everything to types at the boundary, so that the code inside the boundary cannot have invalid strings, for example. Nice to see Michael suggesting a similar path.
"Parse, don't validate" on display.
That means, at the entry point of your application, whatever the form of your data, parse the data into only valid inputs to your business logic, freeing the business logic to be pure and clean with no fuss.
Just like he was shocked to see out of bounds error as he's never seen one, I've also never used traditional or baked in error handling because I've never needed it.
I like the idea of extending errors into the domain. I feel like toward the end he was really differentiating between “faults” vs. “errors” but never quite used that terminology.
I’ve never seen the negative index’s before but I think it makes so much sense. I can imagine you just mod the index with the size and that would make it looping.
23:26 just looks like introducing "null" into the tablature language. If you're going to do what's expected, then you ought to spend some time empirically finding out what's expected.
I was experimenting with the lambda idea for a while now. In some cases I use two lambdas, one to return results and one to return the exception (failed) condition, there are cases I wanted to do something else if a value is absent. The other option is to return Optional or similar construct. any thoughts?
I love these guys. If they don't like something, they always say it's breaking the single responsibility principle.
to be fair, most code violates this principle, as it isn't clearly defined. This is the issue with the term "best practices", it's mostly a way to alleviate the burden that comes with the responsibility for making tough decisions.
some very nice points.. the reference to write APIs that are command(s) rather than gives/retrieves something is very gray.. I appreciate the Erlang example but at some level these command APIs hurt composibility or adds unnecessary model awareness in the lower levels.. would be good to mention both or disclaimer when to use what
This is basically the either/result monad. Look up Scott Wlaschin's talk about railroad oriented programming.
it's way more than that. railroad is just one of the strategies
I think his example in Ruby of counting the "spans of ones" as edgy is bad, only because it is trying to see the problem as null (zero-length array) or not null. The count of "spans of ones" doesn't need this check, and the null is on an input--not an output, which is different from what he covers.
The code can actually be simplified to this:
def span_count ary
count = (ary.size > 0&& ary[0] == 1) ? 1 : 0
i = 0
while i < ary.size - 1
if (i == 0 && ary[i] == 1) || (ary[1] == 0 && ary[i+1] !=0)
count = count + 1
end
i = i + 1
end
return count
end
The count is set to 1 if the first element is 1 (which is a span of ones), and covers the case of the array length being one. The while loop won't execute if the length is less than 2.
Overall, I do like the presentation.
if (item != null) {
return item;
} else {
return null;
}
… why?
Stefan Schenk just in case...
Stefan Schenk : Because sometimes many things are equivalent to null, but you don't want to leak them; or perhaps it's a promise/future and your non-null case actually does some processing, so you don't want to risk the possibility that it will be non-null when investigated later; or perhaps !value, null == value, and !( null !=value ) all produce different values (perhaps !value reverses a previous not operation, == does the same as PHP's ===, and !( != ) does the same as PHP's ==), so you feel the need to force better predictability for the sake of the caller.
Don't know, but saw this too often to laugh...
@Jared Maddox Your reply ignores the specific example and question. Please have a look at the given code. Your reply does not make sense in the given context. The given code is equivalent to simply returning `item`, the if() does nothing at all.Maybe you confuse the if condition with a Javascript "falsy value" check (but even then it would not have a right hand side, and checking against null is specific whether you use !== or != even in JS)?
Michael Hasenstein : If you review my initial response, you'll notice that I was _intentionally_ talking about the generic (specifically, language-agnostic) case.
It was not an accident, nor oversight.
Sound is too low.
17:40, in C++, from i = 0 to end, it would take 3 lines only. Awful while, btw.
At about 31 minutes you talk about shullfing a playlist. The way it is implemented at first is "grab a random track from a list". Now there is a problem, the same track that´s currently playing can be grabbed by the algorithm. You solve it by redefining the problem from "get a random track" to " make a randomized tracklist and play the tracks". These are two different results.
The randomized playlist is probably what your customer wanted.
The "grab a random song" version is something an engineer (with limited social skills) might come up with.
I hate bad examples.
My point was that it is presented as the "correct" solution is to grab random tracks, but is might have problems. By redefining the problem you end up with the solution to generate a shuffled playlist. But that was the original problem. The "grab a random track" is not a solution to the original problem "shuffle". I just don't like the example.
Not necessarily, you're assuming too much and constricting the behavior unnecessarily. If the playlist is extended or modified during playback such as track or artist deletion, this approach would fail, and require a recalculation of the full list for each modification, which would also include the already played tracks.
Instead keep 2 lists, one for songs already played, and one containing the rest of the playlist.
Get a random song not in the already played list.
I agree. My point was that the example was bad. It didn't solve he problem explained. Your solution with 2 lists also adheres to the original spec. @@guitargym4161
Smalltalk by Example was not a recent book lol
Bugged me with this talk that I like the idea. But he said not to set a default if there was a product item error in a method. Then when got to the music said if we have an error of missing value let’s set it to a value to “help user”
These are different and could argue for both though error for error usually better then people don’t learn to use a fail state as default. Unless you can find a supper clean default.
I'd argue it's the same with negative index values. He mentions that it's one fewer error that can occur, but unless you actually design your code to use negative indexes, you are still making the same error, but now it's invisible, and can lead to data corruption elsewhere (and terminating is usually the preferable option). It's good to think about reducing conditional where it reduces complexity, but to also be aware that going too far can do the opposite.
Error handling has always been on case by case.
On user input it can indeed help to define missing fields and fill in default values.
On the other hand it's a bad feature if a search for some item adds a default. It could however be reasonable to return a pre-created missing item streamlining intermediary layers by avoiding special cases.
@@defeqel6537 Indeed unsigned index simplified C bound checking, but IIRC the arr[ -1] appeared in perl to avoid needing to look up the number of items to access the last or maintain a count. As you could push/pop on arrays just peeking at the last was reasonable.
I cannot remember ever using other negative values.
It is a matter of extending the domain to include a proper default value.
Sigh. This entire talk was is merely a demonstration of hiding null checking and conditions. They still exist, in the abstraction. Null as a type absolutely makes sense, it represents “no thing”, i.e. absence, and there are situations where you want to have a representation of “some thing” or “no thing”. Also, golang has nil, and tuples as a return over exceptions is a mistake imho
Incorrect. They don't exist when there is a value of the correct type.
At the entry point of your application, translate the data, which can possibly be invalid, to only valid input to your application, no nulls, in your business logic. Ever.
it was only convenient in the sales receipt example that the customer should be notified of the null. it was no different from saying "null" compared to "Item not found". if you have to process the null object before then, it would run into the Alan Perlis quote earlier about strings being passed to hide implicit information.
Talk is good but that depends on the language. That’s why he is using different languages for example.
You can often take concepts from a language and apply or reimplement them in another. Of course you won't have the syntactic sugar of the original language, but if the concept is what you need, it may be worth.
godd.. i am 8 minutes in... stop the scratching already !!
Yet another tech conference video with horrible audio.
I like the presentation but this example with the traffic light is very unresponsible. There are humans like children, old people or autism which would have massive problems with throwing out traffic lights for them 🙁
there is nothing in this presentation that is worth talking for 45 minutes about
people writing ridiculous spaghetti code is a timeless problem that will continue forever unless they are lectured about alternatives. even after seeing this talk, you need to take it to practice, and keep hearing talks like this
annoying mouth smacking noise
Yes, more and more techies have adopted this San Francisco mouth smack. It’s very unprofessional and gross sounding. Once in awhile is normal, constantly smacking is a twitch.
@@marktellez3701 and wats with the constant forearm scratching..
@@sohamjoshi9527 mind viruses are weird. I noticed that one recently too. fucking zombies!