The Test Driven Development is something i have never done and I’m not used to, to be honest i had to take some time to fully grasp the idea because i found confusing the thought of generating test for a code that hasn’t even been written.
I feel like it make take some time to get used to this workflow because code has to be deleted often if you make mistakes (which i do very often) so it means changing everything. On the other hand it sounds like a great advantage to have in your master branch only code that has been tested and worked, it makes things more stable.
The technique sounds amazing, basically you just need to have all tests in green, and if you have all of them green then the program as a whole is green because mistakes don’t propagate precisely because all your tests worked before…wow.
I think TDD is perfect for pacient people because you are developing small parts of the code at a time, taking care of it until it’s as good as it can be and then move on. For people that are not as pacient it must feel like a burden to do all this test in small parts instead of having and entire thing and then from there solve the problems.
In conclusion, only reading about it TDD sounds too tiresome for me but i will give it a chance to change my mind, i might get pleasently surprised. And i’ll keep in mind the most important: test && commit || revert
The article, Lisp: good news, bad news, how to win big was written by Richard Gabriel and originally published in 1991.
Troughout the lecture I could grasp that at the time this was written, Lisp was very popular and used but then it got really bad reputation for many reasons like problems withing the language and also how people talked about it damaged its image a lot.
There were a lot of things done right with Lisp that may have inspired a lot of other languages to do the same like standarization, it had good performance, good integration to coexits with the different programing languages that existed, and of course you could do object oriented programming.
Then there were all those things that Lisp failed at, the most remarkable are:
Simplicity — the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
Correctness — the design must be correct in all observable aspects. Incorrectness is simply not allowed.
Consistency — the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
Completeness — the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
It had a different philosophy for this things that at the end of the day didn’t sit well with most. Other things it failed at were that, even thought it might have seem easy to build things with it, it was not that simple to make good programs, there were a lot ofmistakes people could make about the declarations, implementations and bad data structures.
We need to create those classes that we stated that we had, in this case we have 4 of them: Passenger, Train, TrainRide and Login. Each have their attibutes that we need to add to the class, plus the methods that we thought each of them should have. THen we alsoneed to consider the type of relationship each class have with one another, it could be a relation of composition or aggregation or some other type of relationship, all that we should correctly translate into the code, making a class an interface, the parent/son of another or just make it a normal class.
This is why we should thrive for better diagrams, if we make the perfect diagram then when we translate it, it will inevitably be good code because it has been well thought through, all the attributes are the right data type, they are all the necesary ones, the methods belong to the class that will hold them and also all the relationships in between the clases are the necesary ones to have comunication inside our program in the most logical and eficient way without compromising the independency of each component (that each class modifies its own attibutes and calls it’s own methods and not the other ones).
This is what we’ve been waiting for, the moment we put all those pices together to make it all part of a single thing. For this we have had followed this developing process:
Make sure that your software does what the client wants: here we do the feature list, use cases diagrams, break up the project and list the requirements.
Apply OOP principles to add flexibility: includes domain analysis, preliminary design, and everything to delimit the problem
Strive for mantainable and reusable design: this is when we implement the solution and we have to make sure we have an order and clear documentation for when we want to add features, update or whatever we need.
When we were thinking about the project i have to admit that sometimes we were to caught up in what we wanted the program to be that we didn’t stop and think what a customer might want/expect from something like that, so we needed to step back and consider the design process, do it in order to have in mind the customer before the program (i think that’s why we had trouble with the use cases in the delivery of the first partial).
The thing that i learned is that we need to follow like a timeline process and, if it is needed, iterate though it to refine everything and define new things that we might have not considered before. So in conclusion it’s everything about ORDER.
Just the title of the chapter speaks so much: how many thimes they ask us for something and in the process we think about some modifications that we think will make it better and forgot what we were asked to do in the first place. I have had this kingo of thought when i had to help build a web page for some people, they gave us the designs and we were just supposed to make it look like that but honestly their designs were find of ugly to me so i had to keep reminding to myself that that’s what they asked me to do and that I should just stick to it.
They talk about how we must think about the user while we build our program, to think all the use cases we can with no limits, to be creative and expect everything to avoid a situation in which out program doesn’t work because we didn’t thought about something that the customer might do. For every scenario that we think of we must make our program work for it, guiding the user to what the right path is in case they make an unexpected action, and that the expected uses work perfectly.
Also, what called my attention is how they say that yeah, all that OO principles and practices that you use to build your program are very helpfull to you and makes things clearer and all but at the end of the day the customer doesn’t care at all about that, they just want you to deliver something that works and solves their problem. That’s why we must think about the client ALL through the process.
Anyways, that is all, enjoy a good song for the morning: