DEV Community: Yusuf Ali Koyuncu

Clean Code Book Summary II

Yusuf Ali Koyuncu — Thu, 25 Jan 2024 07:04:03 +0000

Hello, in this article I am here with the last part of this series. You can reach the previous part of the series from the link below. So let’s start;

Clean Code Book Summary I

Yusuf Ali Koyuncu ・ Jan 25

#programming #softwaredevelopment #softwareengineering #cleancode

Chapter-09 Unit Tests

3 rules of Test-Driven Development, these three rules keep you in the loop and iterate until the desired development is done;
- You cannot write production code without writing a failed unit test.
- You may not be able to write more unit tests than are enough to fail, and the compiling will fail.
- You cannot write more production code than is sufficient to pass the already failing test.
Keep tests clean.
Test code is just as important as production code.
Code Base also makes it easier for us to make changes.
Tests must be strictly dignified and readable.
Must have one assert per test.
Each test must test a single job.
Clean tests follow this abbreviation. F.I.R.S.T.
- Fast → Tests should be fast.
- Independent → Tests must be independent.
- Repeatable → Tests must be testable in any environment.
- Self-Validating → Tests must contain a result.(Fail or Pass)
- Timely → Writing tests on time makes test writing more successful.

Chapter-10 Classes

Class organization (according to java convention)
1. Variables list.
2. Public static constants variables.
3. Private static variables.
4. Private instance variables.
5. Public variable.
6. Public functions.
7. Private utilities.
Follows the above steps and helps the program read like a newspaper article.
Encapsulation; Instead of accessing the variables in the class directly, it is to be accessed through functions.
Classes must be small. To be able to measure, responsibility must be taken into account.
If you use the words "if", "and", "or" and "but" when describing a class or function to someone, it means you have more than one responsibility. It is not clean.
The Single Responsibility Principle (SRP); A class or module specifies only one responsibility, and it should have only one reason to change.
The logic of doing something is done is wrong. You have to be focused on turning around and improving.
You should have multiple structures that do the target work and rotate between themselves.
Cohesion; You have to keep the structures that are close to each other together.
Writing clean code greatly reduces the risk at the time of change.
In some developments, that is, writing a class preserves the SRP feature of the system. This is what needs to be done. In this way, it allows us to add new structures to be added without changing the existing structure.
Abstract classes for isolation, depend on interfaces.

Chapter-11 Systems

Complexity should be measured.
The construction phase and the usage phase are different from each other and should be separated.
Builder patterns can be used.
Dependency Injection; It allocates secondary responsibilities from one object (IOC) to other dedicated objects, thus supporting SRP.
Dependency injection provides method and constructor arguments that inject dependencies and link dependencies together.
System Design is an important element.
Separate concerns adequate structure should be properly constructed.
Aspect-oriented programming (AOP) should be used to solve cross-cutting concerns.
Focus on systems that are simple and open to expansion.
The system should be designed as testable.
If you can see the standards add value, you should use them.
System must be clean. Processes should be advanced and a TDD-oriented approach should be exhibited.
No matter what level you are, you should think simply.

Chapter-12 Emergence

We find Kent Beck's four rules to be of great help in creating well-designed software. According to Kent, a design is simple if it follows these rules;
- Runs all tests.
- Does not contain duplicate code.
- If the programmer's purpose is clearly stated.
- Minimizes the number of classes and methods.
Refactoring is important. It should be done regularly and questioned.
Pay attention to the naming pattern when using the design pattern. This improves readability.
It takes a lot of practice.

Chapter-13 Concurrency

Objects are absorptions of processes. Threads belong to the schedule.
Concurrent programming is not easy. Especially when it starts working under load, problems will arise.
Concurrency is a decoupling strategy. (Decoupling)
The schedule determines when it will work.
Dealing with more than one thing at the same time.
Concurrency can always improve performance.
If a concurrency system is to be built, the design must be changed.
You need to know how to deal with concurrency updates and deadlock.
It is difficult to simulate the same error again.
Concurrency has a life cycle. But it should be kept completely different and separate from other code parts.
"Lock" is used for data consistency. Atomic structures perform the same process on the back.
Keep data encapsulation ahead and reduce tampering with shared data.
Threads must be independent. Examples, ReentrantLock, and Semaphore CountDownLatch. (Suggestion: Check out the classes you can use.)
Execution Models; Bound Resources, Mutual Exclusion, Starvation, Deadlock, Livelock. Examples; Producer-Consumer, Readers-Writers, Dining Philosophers. (Suggestion: Learn these basic algorithms and understand their solutions)
Synchronized Methods; Client-Based Locking, Server-Based Locking, Adapted Server. (Suggestion: Avoid using multiple methods on a shared object)
Keep your synchronized partitions as small as possible.
It is Difficult to Write the Correct Shut-Down Code. The graceful shutdown can be difficult to fix. (Suggestion: Think about shutdown early and getting it working early. It will take longer than expected. Review existing algorithms because this is probably harder than you think.)
Experiment with different scenarios to test.
- Handle threading errors.
- Run nonthreaded codes first.
- Make thread code pluggable.
- Make thread code adjustable.
- Invoke more threads than the number of processors.
- Run on different platforms.
- Use code to try errors and force the system.

Chapter-14 Successive Refinement

This chapter is a case study examining the argument parser structure of a CLI application.
It is explained through the code. This chapter should be read directly.
Working code is just useless. It will break in the future and will not work.
The impact of bad code on a project is huge.
Bad code creates a lot of technical debt.
It costs a lot of time to clean the code.
Bad code creates multiple dependencies and makes it more difficult to resolve.

Chapter-15 JUnit Internals

This chapter critiques some of the JUnit framework.
It is explained through the code. This chapter should be read directly.
When it comes to frameworks, JUnit is simple in design, precise in definition, and clever in implementation.
Coverage of tests is important.
Each of us has a responsibility to leave the code a little better than we found it.

Chapter-16 Refactoring SerialDate

In this chapter, the org.jfree.date package of the JCommon library has the SerialDate class and refactors it.
It is explained through the code. This chapter should be read directly.
Criticism is good and it develops people.
First make the code work. Make sure you test everything and make sure it passes the tests.
Leave the code cleaner than you found it. This may take time, but it’s worth it.

Chapter-17 Smells and Heuristics

This chapter talks about the definition of “Code Smells” in Martin Fowler’s Refactoring book.

Comments

Inappropriate Information; keep everything but the code in a different place. Comments should be reserved for technical notes on code and design.
Obsolete Comment; Reviews age fast. You should delete the comment at the point where you can.
Redundant Comment; unnecessary comments.
Poorly Writer Comment; There should be no incomplete or poorly written comments.
Commented-Out Code; if a code is being commented out, it’s an abomination.

Environment

Build Requires More Than One Step; Running a project should be simple.
Tests Require More Than One Step; Running tests should be easy.

Functions

Too Many Arguments; functions must have few arguments. Question yourself if he has more than 3–4 arguments.
Output Arguments; If the function needs to change the state of an object, have it change the state of the object it is called from, rather than passing it as output.
Flag Arguments; Having a boolean parameter means that it is overworking.
Dead Function; delete dead functions.

General

Multiple Languages in One Source File; avoid using multiple languages within a file.
Obvious Behavior Is Unimplemented; The code we read should meet our expectations. It shouldn’t offer anything different while waiting for an output.
Incorrect Behavior at the Boundaries; don’t trust the code you wrote, try to write a test for each boundary condition.
Overridden Safeties; skip security steps.
Duplication; It is one of the most important rules. Dave Thomas and Andy Hunt called it the DRY principle (Don’t Repeat Yourself). Kent Beck has made this one of the core tenets of Extreme Programming, “Once, and only once.” said. Ron Jeffries ranks this rule just below making sure all tests pass. Any time you see duplication in code, it represents a missed opportunity for abstraction. Replace switch/case or if/else structures with polymorphism. Modules that have similar algorithms but don’t share similar lines of code are even more subtle. This is again a repetition and should be handled using “TEMPLATE METHOD” or “STRATEGY PATTERN”.
Code at Wrong Level of Abstraction; There should be no abstraction at the wrong level.
Base Classes Depending on Their Derivatives; The base class should not depend on what comes from the subclass.
Too Much Information; well-defined modules have very small interfaces that let you do a lot with very little. This way interfaces should be defined.
DeadCode; dead ie unused codes should be detected and deleted.
Vertical Separation; variables and function should be defined close to where they are used.
Inconsistency; names should be named consistently according to the work they do on the whole project.
Clutter; You should delete what you don’t use.
Artificial Coupling; Things that are not connected should not be artificially combined.
Feature Envy; The methods of one class should deal with the variables and functions of the class they belong to, not the variables and functions of the other class.
Selector Arguments; It’s better to have many functions than to pass some code to one function to choose the behavior.
Obscured Intent; The code must be meaningful and readable.
Misplaced Responsibility; Make sure you put the code you are using in the right place. You have to keep related structures together.
Inappropriate Static; You should prefer non-static methods to static methods. If you really want a function to be static, make sure you don’t have the chance to want it to behave polymorphically.
Use Explanatory Variables; variable names should be good and descriptive.
Function Names Should Say What They Do; A function name should describe what it does.
Understand the Algorithm; The best way to understand the algorithm is to refactor the function until you have something clean and meaningful enough to clearly show how it works.
Make Logical Dependencies Physical; if one module depends on another, that dependency must not only be logical but also physical.
Prefer Polymorphism to If/Else or Switch/Case; When writing code, replace the switch/case or if/else structure with polymorphism.
Follow Standard Conventions; Team rules and standards need to be determined.
Replace Magic Numbers with Named Constants; having raw numbers in your code is a bad idea. You should hide them behind well-named constants.
Be Precise; The reason for ambiguities and inconsistencies in the code is either the result of disagreements or laziness. In both cases, they must be eliminated. That’s why you have to be determined.
Structure Over Convention; we must keep the structural rules above all else.
Encapsulate Conditionals; If more than one structure is checked in the if condition, it should be extracted in a method and the method should be called in the if condition.
Avoid Negative Conditionals; Positive conditions should be checked in the if condition.
Functions Should Do One Thing; the function should be responsible for and do a single job.
Hidden Temporal Couplings; use arguments that make temporal coupling explicit.
Don’t Be Arbitrary; Your code structure should be correct and consistent.
Encapsulate Boundary Conditions; +1 or -1 may be needed in some controls. Don’t let them leak all over the code. We don’t want the +1’s and -1’s to scatter left and right.
Functions Should Descend Only One Level of Abstraction; The expressions within the function must all be written at the same abstraction level, which must be one level below the operation described by the function name.
Keep Configurable Data at High Levels; high-level constants are easy to change.
Avoid Transition Navigation; A to B; If B and C cooperate, we don’t want modules A to know about C. So A; He must not know C over B.

Java

Avoid Long Import Lists by Using Wildcards; If you are using two or more classes from a package, import the entire package.
Don’t Inherit Constants; constants are hidden at the top of the inheritance hierarchy. Don’t use inheritance as a way to cheat the language’s scope determination rules.
Constants versus Enums; Refer to enum instead of defining public static final int.

Names

Choose Descriptive Names; Choose descriptive and meaningful names.
Choose Names at the Appropriate Level of Abstraction; Choose correct naming according to abstraction level.
Use Standard Nomenclature Where Possible; use nouns denoting the work done in all nomenclature.
Unambiguous Names; Do not be afraid of long names, the important thing is that it is descriptive.
Use Long Names for Long Scopes; The nomenclature should be chosen according to its scope.
Avoid Encodings; Do not use encrypted names.
Names Should Describe Side-Effects; naming should describe everything that a function, variable, or class is or does. Do not store Side-Effects with a naming, specify them in the naming.

Tests

Insufficient; test code should test anything that might break in the code. Tests are inadequate as long as there are unverified tests or conditions undiscovered by calculations.
Use a Coverage Tool; Use tools to see what tests cover in the code.
Don’t Skip Trivial Tests; Don’t be afraid to write tests, even if the cases are trivial.
An Ignored Test is a Question about an Ambiguity; If you’re ignoring your test, query your code.
Test Boundary Conditions; Take particular care to test boundary conditions. Often we get the middle of an algorithm right, but we get the bounds wrong.
Exhaustively Tested Near Bugs; When you find a bug in a function, it’s wise to do a thorough testing of that function.
Patterns of Failure Are Revealing; poorly organized test cases will reveal failure patterns.
Test Coverage Patterns Can Be Revealing; Looking at code that may or may not be executed by passed tests gives clues as to why failed tests.
Tests Should Be Fast; a slow test is a test that will not run. Do what you have to do to keep your tests fast.

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” — Linus Torvalds

Reference

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Clean Code Book Summary I

Yusuf Ali Koyuncu — Thu, 25 Jan 2024 06:39:04 +0000

Hello, I would like to share with you an issue that is accepted as a touchstone in the software world and that has entered the literature, such as if you write “clean” in the industry.

In this article, I will share with you the notes I took while reading this book. The book consists of 17 chapters in total, and I will talk about all chapters. I planned this as a series and I will share 2 parts in total. While taking notes, I wrote down the points that I consider important, so this is a summary. The best source, of course, is to read the book itself. I aim to convey it to you in a simple way by progressing from a long article, rather than a long article. Let’s get started, foremost, let me briefly talk about the book and its author.

Robert C. Martin (Uncle Bob); A software expert since 1970, Robert has spent the last 40 years improving the field, from launching the Agile Alliance to writing landmark books on Agile Programming, Clean Code and more. This book is technical, pragmatic, and important in content. The author is highly experienced and professional, dedicated to writing what works in practice as opposed to what might work in theory.

When writing code, there should be minimal and straight logic. In this way, maintenance is easy and problems in error handling are minimal.
The written code must be able to convey its intention simply and effectively, that is, directly.
Must be highly legible. For example, it should not get stuck when reading from top to bottom, such as a newspaper, and it should be easily understandable.
The person reading the code must be able to meet their expectations.
When a code is clean, it is understood by how few comments are made while reading it. For example, the less we say the question of what he meant here, or what it does, the cleaner it will be.
Must pass all tests. Tests increase the stability of a code and minimize errors.
There should be no repetitive pieces of code in the code. It should be a minimal class, method, or function.

Chapter — 2 Meaningful Names

Variable names should be clear when read.
Constant values should be kept as static variables.
Variable names must be the same as common names. For example, constant names of the language used, or the nomenclature used by the Unix platform should be avoided.
The programmer should avoid leaving false clues that obscure the meaning of the code
We should not add "List" to the end of any list to specify it. We should use the plural, what it belongs to. For example, animal → animals.
We should not make meaningful distinctions, so we should avoid using noisy words("the", "a", "an", etc.)
We must use pronounceable nomenclature.
We should put searchable nomenclature. It's like writing-related things with a specific pattern.
The naming meaning given to a variable scope should increase at the right rate.
We should avoid using encoded variable names.
Class naming should not be a verb.
Methods naming must be verb or verb phrase.
Do not be playful, funny, and sarcastic in naming. So don't play word games.
Choose a different word for each abstract concept and stick to it.
Remember that people who read your code will be programmers. You can use Computer Science terms, algorithm names, pattern names, math terms, etc. use it.

Chapter — 3 Functions

Functions and methods manage behaviors of classes.
A function length must not exceed 100 lines. If it passes, it makes it harder to write tests.
Line length must not exceed 150 characters. If it passes, it reduces readability.
The function must be responsible for a single job. So it should only do one thing. "Functions should do one thing. They should do it well. They should do it only."
To make sure our function does only one thing, we need to make sure that all expressions in the function are at the same abstraction level.
The code should flow from top to bottom. (The Step-down Rule)
When dividing our function, we should do domain-based division.
We can't always avoid switch cases, but we can make sure that each switch case low-level class is embedded and can never be repeated. We do this, of course, with polymorphism.
With the Switch case, we should call classes, not functions.
Function names should not be too long or in encoding format.
A function should not exceed 3–4 arguments. We should avoid more. It complicates testability.
To send more arguments, we must either send an object or a list.
We should avoid the common monodic form.
We should avoid adding flag arguments. Indicates that this function does more than one thing. The flag does one thing if it's true, and another if it's false!
It should not cause side effects. So it shouldn't be secretly affecting other things.
The function should either do something or respond to something, not both. Either your function should change the state of an object or return some information about it.
It is a thing in error handling and must be managed separately.
The DRY principle (Don't Repeat Yourself) is a powerful principle that comes across as not repeating yourself. Repetitive tasks increase complexity.
First write the function as it works and then refactor it to clean.

Chapter-04 Comments

Random comments should not be written. It should not be written at all, instead of having no purpose or being written randomly.
It is a failure to explain the things that you can tell with the code with comments.
Comments don't make up for bad code. Comments are not written for bad code.
Describe what you are trying to tell with code.
The best comment is the one you didn't find a way to write.
Sometimes our corporate coding standards force us to write certain comments for legal purposes. So we can write a legal comment.
We can write informative comments. (date format, regex, etc.)
We should use the interpretation when trying to express our intention.
When writing a test or what the result of an operation should come to, the code can be written in the comments.
Comments can be made on the code that has been canceled or caused problems.
TODO comments can be written.
A part that seems insignificant can be written to emphasize its importance.
Bad comment is an excuse for bad code.
If you're going to do it for the sake of doing it, don't do it at all. It is necessary to write a comment with thought and thought.
Comments summarizing the code should not be written.
The comment should be specific for what it is written for.
Keep diary-style comments at the top of the code.
Do not write empty comments. (Noise Comments)
Do not write the same code you wrote in the comments. (Scary Noise)
Sometimes programmers like to mark a specific location in a source file. Don't do this. (Position Markers)
Adding an author as a comment to the code.
Do not write which one is closed at the end of a closing parenthesis as a comment.

Chapter-05 Formatting

Formatting is an important issue. Changes are never made when different formats are detected. The diff in code is always incomprehensible.
Vertical formatting is important. There is a general answer to the question of how big a source file should be. It is recommended not to be too long. Note that this is a log scale, so a small difference in Vertical position means a huge difference in absolute size.
The Newspaper Metaphor; it should be like a newspaper article or a source file. The name should be simple but descriptive. The name alone should be enough to tell us if we are in the right module. The top part of the source file should provide high-level concepts and algorithms. The detail should increase as you go down until you finally find the lowest-level functions and details in the source file. A newspaper consists of many articles; most are very small. Some are a little bigger. Few contain as much text as one page can hold. This makes the newspaper usable. If the newspaper were a long story with an untidy pile of facts, dates, and names, then we wouldn't be reading it.
Vertical Openness Between Concepts; almost all code is read from left to right and top to bottom. Each line represents a statement or a sentence, and each set of lines represents a complete thought. These thoughts should be separated from each other by blank lines.
Vertical Density; If openness separates the concepts, Vertical Density means a close relationship. Therefore, tightly related lines of code should appear vertically dense.
Vertical Distance; Closely related concepts should be kept vertically close together. Invalid for concepts in separate files. Closely related concepts should not be separated into separate files.
Variable Declarations; variables should be defined as close to where they are used as possible.
Instance variables; must be defined at the top of the classes.
Dependent Functions; If one function calls another, they should be vertically closed and the collar above the caller if possible.
Conceptual Affinity; certain pieces of code want to be close to other pieces. They have a certain conceptual affinity. The stronger this closeness is, there should be the less vertical distance between them. For example; assert functions because they share a common naming scheme and perform variations of the same basic task.
Vertical Ordering; In general, we want function call dependencies to point downward. So a called function must be below a calling function
Horizontal formatting is important. This shows that we should try to keep our lines short. Our line length can be up to 100–120 characters.
Horizontal Openness and Density; We use spaces to separate them according to whether the relationship between them is strong or weak.
Horizontal Alignment; Horizontal alignment is useless when defining a variable.
Indentation; the code has a structured outline from top to bottom. This must be complied with.
Breaking Indentation; Don't reduce short definitions to one line.
Team Rules; every programmer has his own favorite formatting rules, but if he works in a team, then the team makes the rules.

Chapter-06 Objects and Data Structures

We can store our data with data abstraction. (Getter, Setter)
The use of procedural code allows adding existing functions without changing existing data structures.
Object-Oriented code makes it easy to add new classes without changing existing functions.
Adding new data structures is difficult as all functions of the procedural code have to change.
Object-Oriented code is difficult to add new methods because all classes have to change.
Hybrid structures should be avoided. It complicates everything.
In an Object-term structure, the object cannot be accessed through it. Data structures cannot be accessed from a rotating structure, from above it.
Hybrid structures should not be built from data structures and objects.
Data Transfer Objects; The concise form of a data structure is a class with public variables and no functions. This is sometimes called a data transfer object or DTO. DTOs are especially useful when communicating with the database or parsing messages from sockets etc. They are very useful structures.

Chapter-07 Error Handling

Return expectation rather than checking the code with if-else.
We can create different errors and manage them.
When you execute code in the Try portion of a Try-Catch-Finally statement, you indicate that execution can be canceled at any point and then resumed in a catch. Try blocks are like transactions in a way. The catch should leave your program in a consistent state no matter what you try.
It's good practice to start with the Try-Catch-Finally statement when writing code that can throw an Exception.
Use Unchecked Exceptions.
Provide Context Exceptions.
You should set up your error handling structure.
Functions should not return null.
Null values should not be passed to functions.

Chapter-08 Boundaries

Sometimes we buy Third-Party packages or use open source. We have to somehow integrate this foreign code cleanly into our code. In this section, we look at practices and techniques for keeping the boundaries of our software clean.
Using Third-Party Code; direct use. This code creates many dependencies and vulnerabilities. Instead, you can write a single client that uses it and access it in a more restricted way from anywhere in your code. It results in code that is easier to understand and harder to abuse.
When you have a Third-Party dependency, you can test it with mock data.
It may be in our interest to write tests for Third-Party code. Assuming it's not clear how to use our Third-Party library. We might spend a day or two (or more) reading the documentation and deciding how to use it. Then we can write our code to use Third-Party code and see if it does what we think. We wouldn't be surprised if we find ourselves stuck in long debugging sessions trying to figure out whether the bugs we encounter are in our code or theirs.
Difficult to learn and integrate Third-Party code. Doing both at the same time is twice as difficult. Instead of trying and experimenting with new things in our production location, we can write some tests to explore our understanding of Third-Party code. Jim Newkirk calls these types of tests learning tests.
Learning tests cost nothing. We had to learn the API anyway, and writing these tests was an easy and isolated way to get that knowledge. Learning tests are definitive experiences that help increase our understanding.
The learning tests are free and have a positive return on investment. When there are new versions of the Third-Party package, we run learning tests to see if there are any behavioral differences.
Sometimes it is necessary to work in a module that will connect to another module under development, and we have no idea how to send the information as the API has not been designed yet. In these cases, it is recommended to create an interface to encapsulate communication with the waiting module. This way we have control of the module and can test it even though the second module is not yet available.
Interesting things are happening at the borders. Change is one of them. Good software designs adapt to change without major investments and rework. When we use code beyond our control, special care must be taken to protect our investment and ensure that future changes are not too costly.

“Details matter, it’s worth waiting to get it right.” -Steve Jobs

Reference

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Where should I start programming, How can I be a good programmer?

Yusuf Ali Koyuncu — Fri, 10 Feb 2023 06:30:16 +0000

Foreign Language

Foremost, if you have a foreign language problem, you have to deal with it before you start programming. “Can’t it be done without a foreign language?” The answer to the question is not yes. Because almost all documentation and resources are available in English, and you need to constantly read and research to improve yourself. In addition, improving your language will enable you to communicate with employment opportunities and other communities and will allow you to receive information directly.

Communications Skills

Good communication skills directly correlate with good development skills. The ability to communicate is crucial for understanding problems clearly, being able to break them down into hypotheses and propose solutions in a coherent manner. You should be able to learn concepts quickly. And yes, this is a skill that improves through practice.

If English is not your first language, make sure you know it well and can communicate it effectively. In the world of technology, English is the de facto language of most documentation and developer interactions. If you don’t speak it well enough, interpreters or translators may be required, making your knowledge second hand and easily outdated.

Desire to Learn

The desire to constantly learn and improve will make you different from other people throughout your life. Although we are not likely to see this difference immediately, as time passes, the sense of awareness in ourselves and the satisfaction of knowledge will remind you that you are a few steps away from success. If you want to be successful while starting this process, you should want to be a lifelong student, that is, to learn lifelong. Answering the question “Which language should I learn?”; Each language has different uses, pros and cons. What matters is what you want to do. Purpose-oriented learning will save you time. Choose what you want to do and learn the most popular language used in that field.

Foster deep knowledge

Carefully select the technologies you want to work with. Aim to become an expert in a couple — but competent with many. Research skills carefully and you can future-proof your career. I’ve answered a question about this on Quora, which you may want to take a look at. Always follow coding standards and write code that is understandable and commented where necessary and can be passed on to someone else easily. This was always important, but in the remote age, it’s essential.

University

Firstly, I recommend you to get into a good university and study in one of the departments of Computer, Software, Information Engineering. Studying in these departments will give you the opportunity to learn computer science. The most important point here is to study in a good school. Because a good university hosts good teachers, and good teachers improve your horizons. It also has other advantages. A good university means competition, and too much competition will force you to improve. Remember that studying at a good university will not save you. In general, the biggest mistake people make is to immerse themselves in entertainment, travel and games when they go to university. Of course, they should be, but in moderation. Suggestions that will take you forward while reading;

Entering and managing clubs according to your interests at school, if not, establishing and managing them. This will both socialize you and give you the ability to manage.
In general, student projects are opened every semester. This is opened by your department teachers and participate in projects where they have successfully built (high grade point average) and developed over the course of a semester or a year. This both improves you and provides a plus in your business life. You also have the chance to win a scholarship in some projects.
Although not always, some projects are carried out jointly with large companies and organizations. Participate in these projects. In some cases, a monthly payment is provided to the student.
Do an internship in a company every summer while you are studying, do it in different fields so that you can discover your field of interest and make yourself liked by the people there as much as possible and communicate well, this will open many doors in your business life in the future.
Do an Erasmus or Erasmus internship. This will provide you with the chance to see abroad, as well as the opportunity to study with different people and see different working disciplines.
Working while studying. Working part-time in a company will take you further. It will teach you to stand on your own feet, as well as to see what it is like to work. If you can’t find a job, earn money by doing homework. There are sites that work with domestic or international companies, and you are paid for the work you do.
There is a process called co-education in the last period of school. You get some of your courses counted, work in a company for 6 months, prepare a report and present it to the school, and it replaces your courses of that semester.

Even if you apply any of these items, it will move you forward a lot. Do as much as you can. “I’m studying at a bad university, what should I do?” answer the question; Try to apply the above items and raise your grade point average as high as possible. Remember that 4 years at university will shape your 40 years. If you work hard and invest in yourself while you are traveling, you will only enjoy your life in the future.

Can it be done without studying at university?

Yes it does. Up to 15% of the employees of large companies such as IBM and Google are without a diploma. It is unnecessary and absurd to pay for a course or a place to learn a language or a programming language first here. Because you can access everything on the internet for free. Complete item 1st and 2nd. Once you’ve dealt with them, you can access unlimited information from the following sources.

YouTube: freeCodeCamp, MIT OpenCourseWare, CS50, etc.

The second channel is the Massachusetts Institute of Technology (MIT) university, which videotapes and uploads all its lectures and allows you to get the same education as the people there, even if you don’t go there. You can turn on the translation in the subtitles section of both channels and watch.

Websites: Coursera, Udacity, Khan Academy, GeeksforGeeks, etc.
Form Sites: It is possible to learn the information you want from the form sites in the form of question and answer and with virtual dialogue as content.
Books: I recommend it for those who love to read and learn in depth. You can buy any book you want and improve yourself.
Documentation: There is also a section called documentation, and this is the most important part. They don’t teach in this school or anywhere else. You can access the documentation of any language, library or framework you want. The people who created these languages and tools prepare these documents and explain everything.

Have a positive attitude

It doesn’t matter how hard you work, if your attitude is bad, you won’t get very far. It’s important to show that you care about your work and that you are willing to go the distance to get the job done. A good way to keep a positive attitude is to work on projects that are interesting to you. It sounds obvious, but many people will agree to roles they have no interest in. Playing it safe won’t make you a great developer!
Keep Up to date with new technologies

There is no point in being an expert in dates tech. You should be highly competent with Agile development, task management software (Jira, Trello…), version control (Git…), and different environments (local development environment and working knowledge of deploying applications).

Learning Ability

Every programmer will experience a situation where they don’t know an answer. The great programmers will work to find that answer. They will look at different resources, talk to the right people and find the solution no matter what. Great developers have mastered the skill of self-learning.

Time Management

It’s important to be reliable and show up at meetings on time. If you want to be great at what you do, you should be able to manage your time effectively. Another vital skill is the ability to estimate the amount of time needed to complete a task, communicating this and delivering on it.

Be a Team Player

Great developers help other developers improve. They offer teammates help when they are stuck, teach new skills to others and write documentation that would help teammates not only in their organization but the developer community in general.

Expertise is overrated

As much as specific skill expertise is important, it shouldn’t be the single factor you focus on. A great [insert any skill here] developer is not necessarily a great developer. It’s the addition of the soft skills above that make them great. The ability to learn quickly and jump into a project seamlessly, to help others out, to always have a great attitude. These are the skills that make you invaluable to a business. Consider implementing some (or all!) of these characteristics, and you can easily become a good (if not great) programmer much faster.

“We don’t have to be smarter than the rest. We have to be more disciplined than the rest.” -Warren Buffett

DEV Community: Yusuf Ali Koyuncu

Clean Code Book Summary II

Clean Code Book Summary I

Yusuf Ali Koyuncu ・ Jan 25

Chapter-09 Unit Tests

Chapter-10 Classes

Chapter-11 Systems

Chapter-12 Emergence

Chapter-13 Concurrency

Chapter-14 Successive Refinement

Chapter-15 JUnit Internals

Chapter-16 Refactoring SerialDate

Chapter-17 Smells and Heuristics

Comments

Environment

Functions

General

Java

Names

Tests

Reference

Clean Code Book Summary I

Chapter — 2 Meaningful Names

Chapter — 3 Functions

Chapter-04 Comments

Chapter-05 Formatting

Chapter-06 Objects and Data Structures

Chapter-07 Error Handling

Chapter-08 Boundaries

Reference

Where should I start programming, How can I be a good programmer?

Foreign Language

Communications Skills

Desire to Learn

Foster deep knowledge

University​

Can it be done without studying at university?

Have a positive attitude

Learning Ability

Time Management

Be a Team Player

Expertise is overrated

University