Table of contents
- Clean Code - Uncle Bob (Lesson 1)
- Clean Code - Uncle Bob (Lesson 2)
- Clean Code - Uncle Bob (Lesson 3)
- Clean Code - Uncle Bob (Lesson 4)
- Clean Code Uncle Bob (Lesson 5)
- Clean Code Uncle Bob (Lesson 6)
These are the summary of what I learned from all these "Coding a Better World Together" lessons from Uncle Bob in my own words. I only extract the information that is useful to me.
I added my comment in bold for those that I do not fully agree with him or anything that is significant to me.
Clean Code - Uncle Bob (Lesson 1)
- By nature, we don't write clean code. Solving the problem is the main priority. Thus, we need to refactor.
- Keep function small, do one thing.
- One thing means you extract until you can can't do it anymore.
- Function should be properly named (tells what the function does)
- Function must be verb.
- Function should have less than 3 arguments.
- Don't pass
Booleaninto a function for branching purpose.
ifstatement. Use polymorphism (open-closed principle).
- Side effect function changes the state of the system.
lambdafor side effect function that comes with pair (e.g.
opena file, and
closea file). Pass in processing callback implementation as
lambdainto a function.
- Convention to follow - command is a function that returns nothing, should have a side effects. Query is a function that returns value, should NOT have a side effect.
- Prefer exceptions to returning error codes. Try block should only content one function call which throws the exception. [I made this mistake. Most of my try block contains unnecessary stuff that can be pulled out.]
- Don't Repeat Yourself, avoid duplicated code.
- Software is like science, which cannot be proven correct.
Clean Code - Uncle Bob (Lesson 2)
- Comment is to explain the code that you can't use the code to explain.
- Comment is a lie, it degrades over time and no one maintains it.
- Put effort into the code, not the comment.
- Don't check it
TODO, once checked in, it becomes don't do [I disagree. Having
TODOin code is quite useful. It is developer's responsibility to implement the
- Avoid mandated, journal, noise, position marker, closing brace, attribute (by author) comments.
- Avoid commented out code
- Don't comment code that happens in somewhere else. [I do not fully agree because sometimes we need to do that in oder to clearly explain the intention of the code. I would say avoid this if possible.]
- Legal comment (copyright)
- Informative comment (design pattern convention naming that can't reflect the actual intention, complex regular expression)
- Amplification (emphasize the importance of why certain code is there)
Variable & Function Naming
- Should reveal it's intent
- The length of the variable name should be proportional to the size of the scope that contains it.
- Function is opposite, the larger the scope, the smaller the function is.
- Time to spend in code reviews should same as amount of time to write the code
- Pairing in a good alternative than code reviews
Clean Code - Uncle Bob (Lesson 3)
- When you release code, you know it works.
- Ready to deploy (shippable) in each iteration (e.g. 2 weeks iteration)
- The code should be better over time
- Fearless competence - don't afraid to refactor or touch the code. When you touch the code, you break it, then the code is yours. So you avoid touching code. [This sounds so familiar! However, practically this is subjective. Sometimes you do want to minimize the risk with minimum code changes]
- Expect QA to find nothing.
- You do not get slower (feature production rate does not slow down) when the system gets bigger.
- Software must be changeable by design. That's why is it "Soft" ware.
- The cost of the change should be proportional to the scope of the change
- Always give estimate in a range from the best case to worst case scenario.
Clean Code - Uncle Bob (Lesson 4)
- No innovations have been made in the software programming for decades. All codes written are still sequence, selection and interaction.
- But hardware has gone crazy as compared to software.
- Senior software engineer need to say "NO" when the answer clearly is no. [This is subjective. In software, you do not have definite answer, so you shouldn't say no in my opinion. "NO" is also a negative word where people often think you're defensive. I will rephrase it with more convincing bullets]
Test-driven Development (TDD)
- TDD is discipline and is arbitrary.
- 3 TDD Rules
- You're not allowed to write any production code until you have first written a test that fails because the production code doesn't exist
- You're not allowed to write any more tests until all the tests are passed
- You can only write the minimum production code that makes the test compile or pass.
- TDD is like double entry bookkeeping in accounting (e.g. balance sheet)
- TDD is a significant skill. Learn it well first before you bring into the work.
Clean Code Uncle Bob (Lesson 5)
- Software architecture evolves, it is not fixed.
- The goal of software architecture is to minimize the human resource that required to build and maintain the system
- Writing clean code doesn't make you slow. You feel slow because of all these disciplines.
- Software has 2 values:
- Value of what it does
- Value of its structure (often get ignored)
- The second value is more important than the first one, because it makes the software flexible. Thus, the cost to change is minimized.
- Software engineer is responsible to communicate the second value to the stakeholders (who only cares about the requirement), and it is not an easy job.
- A good architecture allows major decisions to be deferred
Clean Code Uncle Bob (Lesson 6)
- Fundamental law of any projects you do. Pick any three...
- Good (Quality)
- Fast (Time to Market, Schedule)
- Cheap (Cost Effectiveness, Staff)
- Done (Scope)
- Manage the projects to the best possible outcome (maximize all four qualities above) based on data
- Agile is iterative development(for small team to do small things) and meant to provide the data (e.g. velocity and burn down charts)
- The deadline is fixed due to business reason but not the requirement which keep changing
- Requirements keep changing because the customer does not know what they want until they see it. Thus, the "Waterfall Model" is no longer applicable.
- Quality is the only way to go fast, do well, go fast. Assuming staff and schedule is fixed, we can only play around with the scope.
- Never put refactoring into schedule because we're constantly refactoring. Stakeholder doesn't care about it.
- [In my opinion, Agile is a good tool ONLY IF it is "properly" used by the project management. It is often being misused, for example, Garbage in, garbage out.]
These series of videos are motivating to watch, but a bit too long. I learned something from it but not significant. A lot of stuff is quite common sense, and it could be subjective to the company's culture.
Personally, I have never done test-driven Development (TDD) before and some minimum of pairing experience. If I have a chance, I would like to give TDD a try.