Μάθετε τις βασικές αρχές μιας καλής νοοτροπίας προγραμματιστή σε 15 λεπτά

«Δύσκολο να κάνεις ακόμη και μικρές αλλαγές»

«Σπάζοντας τη λειτουργικότητα του λογισμικού κάνοντας αλλαγές»

"Παρουσιάζοντας ένα νέο σφάλμα διορθώνοντας ένα άλλο"

"Εφαρμογή κώδικα που δεν είναι απαραίτητο"

"Σχεδόν αδύνατο να προσθέσετε μια νέα δυνατότητα λόγω περίπλοκου κώδικα"

«Το προϊόν που δεν στέλνει ποτέ»

"Απορρίπτει τον κώδικα και ξαναγράφει από το μηδέν"

Είναι γνωστές όλες οι παραπάνω δηλώσεις;

Κάθε λεπτό ένας προγραμματιστής από οποιοδήποτε μέρος του Κόσμου λέει (ή σκέφτεται) οποιαδήποτε από τις παραπάνω δηλώσεις και επιθυμεί να κλαίει. Γιατί;

Αυτά είναι συνηθισμένα ζητήματα που συζητούνται πολύ συχνά από προγραμματιστές. Αυτές οι ιστορίες είναι έμπειρες σε κάθε ομάδα ανάπτυξης.

Υπάρχουν πολλοί μικροί παράγοντες που βλάπτουν αργά και σταδιακά τα έργα ενός προγραμματιστή. Δεν είναι άμεσα καταστροφικές. Τα περισσότερα από αυτά προκαλούν μόνο μακροπρόθεσμες ζημιές. Κάτι που δεν θα δείτε τη ζημιά για ένα χρόνο ή περισσότερο. Έτσι όταν κάποιος τους προτείνει, συχνά ακούγονται ακίνδυνα.

Ακόμα και όταν αρχίσετε να τα εφαρμόζετε, μπορεί να φαίνονται καλά. Όμως όσο περνά ο καιρός - και ιδιαίτερα όσο όλο και περισσότεροι από αυτούς συσσωρεύονται - η πολυπλοκότητα γίνεται πιο εμφανής και μεγαλώνει έως ότου είστε ένα άλλο θύμα αυτής της τόσο συνηθισμένης ιστορίας τρόμου.

Για να αποφύγετε ένα από τα θύματα, θα πρέπει να αγκαλιάσετε τους θεμελιώδεις νόμους του λογισμικού. Πρέπει να αναπτύξετε μια νοοτροπία που πρέπει να έχει κάθε προγραμματιστής. Αυτή η νοοτροπία θα σας βοηθήσει να λάβετε καλύτερες αποφάσεις στο καθημερινό σας ταξίδι προγραμματισμού. Μπορείτε να διατηρήσετε το λογισμικό σας όσο το δυνατόν πιο απλό. Μπορείτε να το προστατέψετε από το να είναι ένα μη διαχειρίσιμο και περίπλοκο σύστημα.

Εδώ είναι τα βασικά σημεία που πρέπει να κυριαρχήσει κάθε προγραμματιστής.

1. Κατανοώντας τον σκοπό του λογισμικού

Πρώτα απ 'όλα, πρέπει να κατανοήσετε τον σκοπό του λογισμικού. Στην πραγματικότητα, υπάρχει ένας και μοναδικός σκοπός όλων των λογισμικών: να βοηθήσουμε τους ανθρώπους .

Θυμηθείτε: ο σκοπός του λογισμικού δεν είναι να δείξετε πόσο έξυπνοι είστε. - Max Kanat-Alexander, Code Simplicity

Οι προγραμματιστές που δεν μπορούν να συλλάβουν το σκοπό του λογισμικού θα γράψουν κακό λογισμικό. Τι είναι κακό λογισμικό; Ένα πολύπλοκο σύστημα που δεν βοηθά τόσο πολύ τους ανθρώπους.

Όταν λαμβάνετε αποφάσεις σχετικά με το λογισμικό, πρέπει να καθοδηγείτε τον εαυτό σας έχοντας πάντα αυτό υπόψη: Πώς μπορούμε να βοηθήσουμε; Μπορείτε ακόμη να δώσετε προτεραιότητα στα αιτήματα λειτουργιών με αυτόν τον τρόπο.

2. Οι στόχοι του σχεδιασμού λογισμικού

Κάθε προγραμματιστής είναι σχεδιαστής.

Όταν το λογισμικό είναι δύσκολο να δημιουργηθεί ή να τροποποιηθεί, οι προγραμματιστές αφιερώνουν το μεγαλύτερο μέρος του χρόνου τους εστιάζοντας στο να κάνουν τα πράγματα "απλώς να λειτουργούν" και λιγότερο χρόνο να επικεντρώνονται στη βοήθεια των χρηστών. Ο σχεδιασμός του λογισμικού στοχεύει να κάνει τους προγραμματιστές δουλειές όσο το δυνατόν πιο εύκολη, ώστε να μπορούν να επικεντρωθούν σε αυτό που έχει σημασία. Θα δημιουργήσετε λογισμικό που θα βοηθήσει τους χρήστες και το λογισμικό σας θα συνεχίσει να τους βοηθάει για μεγάλο χρονικό διάστημα.

Ωστόσο, εάν σχεδιάσετε ένα κακό σύστημα, η διάρκεια ζωής του λογισμικού σας θα είναι σύντομη.

Αυτό μας φέρνει στον πιο σημαντικό στόχο της σχεδίασης λογισμικού:

Να σχεδιάσουν συστήματα που μπορούν να δημιουργηθούν και να συντηρηθούν όσο το δυνατόν πιο εύκολα από τους προγραμματιστές τους, ώστε να μπορούν - και να συνεχίσουν να είναι - όσο το δυνατόν πιο χρήσιμα. - Max Kanat-Alexander, Code Simplicity

Υπάρχουν δύο βασικά σημεία εδώ: Ο σχεδιασμός σας πρέπει να είναι εύκολος για εσάς και χρήσιμος για τους άλλους.

3. (Mis) κατανόηση

Οι προγραμματιστές που δεν κατανοούν πλήρως την εργασία τους τείνουν να αναπτύσσουν πολύπλοκα συστήματα. Μπορεί να γίνει ένας φαύλος κύκλος: η παρεξήγηση οδηγεί σε πολυπλοκότητα, η οποία οδηγεί σε περαιτέρω παρανόηση και ούτω καθεξής.

Στην πραγματικότητα, ένας από τους καλύτερους τρόπους για να βελτιώσετε τις δεξιότητές σας στο σχεδιασμό είναι να είστε σίγουροι ότι κατανοείτε πλήρως τα συστήματα και τα εργαλεία με τα οποία εργάζεστε.

Η κατανόηση είναι η βασική διαφορά μεταξύ ενός κακού προγραμματιστή και ενός καλού προγραμματιστή. - Max Kanat-Alexander, Code Simplicity

Οι κακοί προγραμματιστές δεν καταλαβαίνουν τι κάνουν και οι καλοί προγραμματιστές. Είναι πραγματικά τόσο απλό.

4. Απλότητα

Η απλοτητα ειναι η ΥΠΕΡΤΑΤΗ σοφιστια. - Λεονάρντο Ντα Βίντσι

Ο προγραμματισμός είναι η πράξη της μείωσης της πολυπλοκότητας στην απλότητα. Ένας «κακός προγραμματιστής» είναι ακριβώς κάποιος που δεν μειώνει την πολυπλοκότητα. Ένας «καλός προγραμματιστής» κάνει ό, τι μπορεί για να κάνει τον κώδικα όσο πιο απλό γίνεται για άλλους προγραμματιστές.

Ένας καλός προγραμματιστής δημιουργεί πράγματα που είναι εύκολα κατανοητά, έτσι ώστε να είναι πολύ εύκολο να αφαιρέσετε όλα τα σφάλματα.

Τώρα, οι προγραμματιστές είναι γενικά έξυπνοι άνθρωποι και κανένας από αυτούς δεν του αρέσει να αντιμετωπίζεται όπως είναι ηλίθιοι. Κατά ειρωνικό τρόπο, αυτό τους οδηγεί μερικές φορές να δημιουργήσουν πράγματα που είναι λίγο περίπλοκα. Βασικά σκέφτονται έτσι:

« Ω, άλλοι προγραμματιστές θα καταλάβουν όλα όσα έχω κάνει εδώ. Πρέπει να γράψω έναν έξυπνο κώδικα που είναι δύσκολο να κατανοηθεί, ώστε να μπορούν να πιστεύουν ότι είμαι πολύ έξυπνος. "

Ένα λάθος που προκαλείται από λανθασμένη νοοτροπία - όχι απαραίτητα από την έλλειψη δεξιοτήτων προγραμματισμού. Οι περισσότερες αποτυχίες προγραμματισμού συμβαίνουν λόγω αυτής της νοοτροπίας.

Το να δείχνετε ότι είστε έξυπνοι δεν τους βοηθά.

Οι προγραμματιστές που είναι νέοι στον κώδικά σας δεν γνωρίζουν τίποτα γι 'αυτόν. πρέπει να μάθουν.

Λοιπόν, πρέπει να θέσετε αυτήν την ερώτηση: « Θέλω οι άνθρωποι να το καταλάβουν και να είναι χαρούμενοι ή θέλω να είναι μπερδεμένοι και απογοητευμένοι; "

Η αλήθεια είναι ότι εάν άλλοι προγραμματιστές που διαβάζουν τον κωδικό σας μπορούν να τον καταλάβουν εύκολα, αυτό σημαίνει ότι κάνετε καλό.

Η πολυπλοκότητα δεν έχει καμία σχέση με τη νοημοσύνη, η απλότητα. - Λάρι Μπόσιντι

Η ερώτηση είναι: "Πόσο απλό πρέπει να είσαι;"

Αυτή είναι η απάντησή σας: Ηλίθια, χαζή απλή.

5. Πολυπλοκότητα

Ο έλεγχος της πολυπλοκότητας είναι η ουσία του προγραμματισμού υπολογιστών. - Brian Kernighan

Η πηγή πολλών αποτυχιών λογισμικού είναι η πολυπλοκότητα. Ξεκινάτε με ένα απλό έργο που μπορεί να ολοκληρωθεί σε ένα μήνα. Στη συνέχεια προσθέτετε πολυπλοκότητα και η εργασία θα διαρκέσει έως και τρεις μήνες. Στη συνέχεια, αρχίζετε να προσθέτετε λειτουργίες που πληρούν κάποιον άλλο σκοπό. Τα πράγματα γίνονται πολύ περίπλοκα επειδή επεκτείνετε το σκοπό του λογισμικού σας χωρίς λόγο. Οι εργασίες θα διαρκέσουν έξι μήνες.

Αλλά αυτό δεν είναι το τέλος.

Στη συνέχεια, παίρνετε κάθε κομμάτι της δυνατότητας και το κάνετε ακόμη πιο περίπλοκο και η εργασία θα διαρκέσει εννέα μήνες. Στη συνέχεια, αρχίζετε να εισάγετε πολλά νέα σφάλματα λόγω της πολυπλοκότητας του κώδικα. Φυσικά, αρχίζετε να τα διορθώνετε όλα χωρίς να σκεφτείτε πώς αυτές οι επιδιορθώσεις θα επηρεάσουν άλλα μέρη. Στο τέλος, όταν ακόμη και οι μικρές αλλαγές γίνονται δύσκολες. Όταν οι διορθώσεις σφαλμάτων αρχίζουν να εισάγουν νέα σφάλματα, θα φτάσετε σε μια από τις πιο δημοφιλείς ιστορίες τρόμου προγραμματισμού: Ξαναγράφοντας τον κώδικα από το μηδέν .

Λοιπόν, πώς έγινε θύμα αυτής της ιστορίας τρόμου; Όχι, ποιος νοιάζεται. Είναι καλύτερα να ρωτήσετε: Πώς θα μπορούσατε να αποφύγετε να είστε θύμα;

Well, it is simple. First, you will exactly know your software purpose and its definition. Second, you will be as simple as possible in every piece of code you write. Third, when a new feature or change request comes to the discussion table, you will evaluate them based on your software purpose and question them.

As a developer, your first behavior should be resistance to (unnecessary) change. This will prevent you from adding unnecessary codes into your software. When you are convinced that this change is a need, then you can implement it.

There are many factors that will increase complexity but those are the most popular ones. Aside from everything, there is only one rule that you should follow:

Your main purpose is to control complexity, not to create it.

6. Maintenance

Maintenance is one of the most important things in software development. Unfortunately, developers usually ignore how important it is. Quick coding and fast shipping look more important than code maintenance. This is the point where they make a mistake — ignorance of future code maintenance.

There will always be some implementation of changes. Not only you have to implement them, but you also have to maintain them over time. As a developer, thinking about future maintenance of changes is one of your main responsibilities.

Όλες οι αλλαγές απαιτούν συντήρηση. Η απλότητα και η πολυπλοκότητα είναι οι δύο κύριοι παράγοντες που επηρεάζουν τη συντήρηση κώδικα. Η ευκολία συντήρησης οποιουδήποτε λογισμικού είναι ανάλογη με την απλότητα των μεμονωμένων κομματιών του. Η προσπάθεια συντήρησης είναι ανάλογη με την πολυπλοκότητα του λογισμικού. Ένας κανόνας που πρέπει να ακολουθήσετε σχετικά με τη συντήρηση είναι: Είναι πιο σημαντικό να μειώσετε την προσπάθεια συντήρησης παρά να μειώσετε την προσπάθεια εφαρμογής. - Max Kanat-Alexander, Code Simplicity

7. Συνοχή

Η συνέπεια είναι ένα μεγάλο μέρος της απλότητας. Εάν κάνετε κάτι μονόδρομο σε ένα μέρος, κάντε το έτσι σε κάθε μέρος. Για παράδειγμα, εάν ονομάσετε μια μεταβλητή thisIsVariable, τότε όλες οι μεταβλητές σας θα πρέπει να ονομάζονται με αυτόν τον τρόπο (otherVariable, anAnotherVariable κ.λπ. όχι other_variable). - Max Kanat-Alexander, Code Simplicity

Ο κώδικας που δεν είναι συνεπής γίνεται πιο δύσκολο να κατανοηθεί. Μην συνεχίζετε να αναγκάζετε τους προγραμματιστές να μάθουν ξανά τον τρόπο λειτουργίας του συστήματός σας κάθε φορά που βλέπουν ένα νέο κομμάτι του.

Σε οποιοδήποτε ομαδικό άθλημα, οι καλύτερες ομάδες έχουν συνέπεια και χημεία. - Ρότζερ Στάουμπαχ

8. Προτεραιότητα

Πώς λαμβάνετε αποφάσεις σχετικά με το λογισμικό σας;

Όταν αντιμετωπίζετε πολλές πιθανές οδηγίες, πώς αποφασίζετε ποια είναι η καλύτερη επιλογή; Τι πρέπει να εστιάσετε και σε ποιες δυνατότητες πρέπει να εφαρμόσετε;

Για να απαντήσετε σε αυτές τις ερωτήσεις, υπάρχουν τρεις σημαντικοί παράγοντες που θα σας βοηθήσουν να λάβετε μια καλύτερη απόφαση. Αυτή η εξίσωση εξηγείται πολύ καλά στο βιβλίο Code Simplicity:

  • Η επιθυμία μιας αλλαγής (Δ): Πόσο θέλετε να συμβεί αυτή η αλλαγή;
  • Η τιμή μιας αλλαγής (V): Πόση αξία προσφέρει η αλλαγή; Πόσο βοηθά τους χρήστες σας;
  • Η προσπάθεια που απαιτείται για την εκτέλεση της αλλαγής (Ε): Πόση δουλειά θα πρέπει να κάνετε για να επιτύχετε αυτήν την αλλαγή;

Η εξίσωση είναι απλή: D = V / E

Η επιθυμία οποιασδήποτε αλλαγής είναι άμεσα ανάλογη με την αξία της αλλαγής και αντιστρόφως ανάλογη με την προσπάθεια που απαιτείται για την πραγματοποίηση της αλλαγής. - Απλότητα κώδικα

Όταν δίνετε προτεραιότητα στην εργασία σας, πρέπει να ακολουθείτε αυτόν τον κανόνα:

The changes that will bring you a lot of value and require little effort are better than those that will bring little value and require a lot of effort.

9. Solving Problems

The first step is understanding. Know exactly what is being asked. Most hard problems are hard because you don’t understand them. Write down your problem and try to explain it to someone else.

If you can’t explain something in simple terms, you don’t understand it. — Richard Feynman

The second step is planning. Don’t take action. Sleep on it. Give your brain some time to analyze the problem and process the information but don’t spend too much time on planning.

Think before acting.

The third step is dividing. Don’t try to solve one big problem. When you look at the problem as a whole, it can scare you. Divide it into smaller tasks and solve each sub-problem one by one. Once you solve each sub-problem, you connect the dots.

10. Good enough is fine

“Perfect is the enemy of good.” — Voltaire

Whether creating a new project or adding a feature to existing system developers tend to plan everything out in detail from the beginning.

They want the first version to be perfect. They don’t focus on the problem they will solve and how their software will help people.

They start by thinking of every small detail they could think about. Then assumptions and predictions come along followed by “What if” sentences. They have to predict the future because they were now so captivated by the imagination of the project in their mind and their project has to be as perfect as they imagined it.

Actually, they are not aware of what’s waiting for them and how much it will cost them by chasing perfection.

Let me tell you what will happen:

  • You will be writing code that isn’t needed
  • You will increase complexity by adding unnecessary codes
  • You will be too generic
  • You will be missing deadlines
  • You will be dealing with many bugs caused by the complexity

Do you want this to happen? I guess no.

What you should instead?

Start small, improve it, then extend.

Ο σταδιακός σχεδιασμός πρέπει να είναι ο οδηγός σας. Να πώς θα το χρησιμοποιούσατε για να σχεδιάσετε μια αριθμομηχανή:

  1. Σχεδιάστε ένα σύστημα που κάνει μόνο προσθήκη και τίποτα άλλο.
  2. Εφαρμόστε το.
  3. Βελτιώστε τον υπάρχοντα σχεδιασμό του συστήματος, ώστε να μπορείτε να προσθέσετε και άλλες λειτουργίες.
  4. Σχεδιάστε αφαίρεση και επαναλάβετε τα βήματα 2 και 3.
  5. Σχεδιάστε τον πολλαπλασιασμό και επαναλάβετε τα βήματα 2 και 3.
  6. Σχεδιάστε τη διαίρεση και επαναλάβετε τα βήματα 2 και 3.

11. Προβλέψεις

«Μια πρόβλεψη είναι απλώς μια πρόβλεψη ότι κάτι θα συμβεί στο μέλλον. Θα μπορούσε να είναι πραγματικά και να βασίζεται σε κάποιο είδος αντικειμενικών δεδομένων ή να βασίζεται σε μια υπόθεση. " Όταν αντιμετωπίζουν το γεγονός ότι ο κώδικάς τους θα αλλάξει στο μέλλον, ορισμένοι προγραμματιστές προσπαθούν να λύσουν το πρόβλημα σχεδιάζοντας μια τόσο γενική λύση που (πιστεύουν) ότι θα εξυπηρετήσει κάθε πιθανή μελλοντική κατάσταση. - Απλότητα κώδικα

Being too generic involves a lot of code that isn’t needed.

You can’t predict the future, so no matter how generic your solution is, it will not be generic enough to satisfy the actual future requirements you will have. Most probably, this time will never come and the code you wrote to solve future problems will increase complexity, make it hard to change the pieces of code and eventually it will become a burden that may destroy your software.

Don’t predict to future. Be only as generic as you know you need to be right now.

12. Assumptions

What is the assumption?

“An assumption is something that you accept as true or suppose to be true, although you have no conclusive proof.”

One of the great killers of a software project is assumptions. Let’s see how an assumption can kill a software project.

Ένας προγραμματιστής γνωρίζει ότι πρέπει να αναπτύξουν ένα σύστημα για να κάνουν το Χ. Στη συνέχεια πιστεύουν ότι το σύστημα θα τους ζητήσει να κάνουν Υ στο μέλλον και θα εφαρμόσουν επίσης το Υ. Γράφουν χιλιάδες γραμμές κώδικα για να σχεδιάσουν το Y.

Στο μέλλον, ο προγραμματιστής συνειδητοποιεί ότι οι τρέχουσες απαιτήσεις είναι εντελώς διαφορετικές από αυτές που νόμιζαν. Αλλά τώρα, το λογισμικό έχει περιττούς κωδικούς που δυσκολεύουν την απόρριψή τους επειδή όλα είναι αλληλένδετα. Χρειάζονται μήνες για να αναδιαμορφωθεί ο κώδικας και τώρα σκέφτονται να ξαναγράψουν ολόκληρο το λογισμικό από το μηδέν που θα τους κάνει να χάσουν μήνες.

Για να αποφύγετε το θύμα σαν αυτόν τον προγραμματιστή, ακολουθήστε αυτόν τον απλό κανόνα:

Ο κώδικας πρέπει να σχεδιαστεί με βάση αυτά που γνωρίζετε τώρα και όχι με βάση αυτό που πιστεύετε ότι θα συμβεί στο μέλλον. - Απλότητα κώδικα

13. Σταματήστε να ξαναβρείτε

If, for example, you invent your own garbage collector when a perfectly good one exists, you’re going to be spending a lot of time working on the garbage collector, when you could just be working on your software.

The only times it’s okay to reinvent the wheel is when any of the following are true:

  • You need something that doesn’t exist yet
  • All of the existing “wheels” are bad technologies or incapable of handling your needs
  • The existing “wheels” aren’t being properly maintained

Simple rule:

Don’t reinvent the wheel.

14. Resistance

As a developer, your first reaction to changing requests should be “NO’’.

Always resist adding more code, more features until you are convinced that they are required and there is a need to implement them. Because unnecessary changes will increase defects in your software.

How can you know that there is a need for them?

Go back and remember your software purpose. Then remember the simple equation in prioritizing section.

From: [email protected] (Russ Cox)Subject: Re: [9fans] design clairvoyance & the 9 way Date: Thu, 8 May 2003 04:05:31 GMT > What does tomorrow's unix look like? I'm confident that tomorrow's Unix will look like today's Unix, only cruftier. Russ

15. Automation

Don’t spend your time on repetitive tasks. Set them up and forget about them. They can work while you are sleeping. When you realize that you are doing something again and again, just remember this rule:

If you can automate it, automate it.

16. Code measurement

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

— Bill Gates

I see developers who measure their software quality based on code lines. They think that more code lines mean that they are doing a great job. The software contains hundreds of thousands of lines of code, which means the software they work on is so big.

The question that pops up here is: Is it really that big, or there is something wrong there?

The answer is that most probably there is something wrong with their design. Most of the simple solutions don’t require a lot of code. You can achieve simplicity with a little bunch of code and solve the problem.

I’m not saying that fewer lines of code is always better. While you want to avoid having less code, you can easily fall in a trap that will cause you to write clever code that is hard to understand for others. You should find a balance.

The optimum code is a small bunch of code that is easy to understand, easy to read.

17. Productivity

How do you measure your productivity?

By writing more lines of code or by throwing hundreds of lines of code away?!

Your main goal should be keeping your code base as small as possible. The question is not “How can I write more code?” rather it should be “How can I remove more code?”

“One of my most productive days was throwing away 1000 lines of code.” — Ken Thompson

18. Testing

When should you add logging and error handling to your project?

You should add logging in a very early stage. This will help you to find the problem easily and save your time.

I see many mistakes when it comes to testing code. Let me give you an example. There were two conditions, a simple if-else block. The developer gave input to the software which will enter inside the if block. They tested it and committed code to source control. Done!

But what about the else block? When the software was shipped to production, that caused a lot of errors. When you test your code, you must execute all new lines at least once and you should start to test parts before the whole.

When you have a bug, first you should reproduce it. You shouldn’t guess the source of the bug and apply fixes based on your assumption. Most probably, you will be wrong. You should see it with your own eyes before applying the fix.

You should be reliable. When other developers in your team see that you committed new code to source control, everyone should know that your code is tested, and works.

Untested code is the code that doesn’t work.

19. (Under)Estimation

Developers’ estimation sucks.

Usually, they underestimate things rather than overestimate them. They underestimate the time and effort required to develop a small amount of code or a feature. In the end, this underestimation leads to missing deadlines.

The solution: Break the big thing into smaller things. The smaller it is, the easier it is to estimate. You’re probably still going to get it wrong, but you’ll be a lot less wrong than if you estimated a big project.

Remember:

Everything takes longer than you think.

20. Running Away From Rewriting

I believe that when you embrace the fundamental principles of software development mentioned in that article, you won’t come to this point. However, if, somehow you make these mistakes and find yourself thinking about rewriting your code, here is the main thing that you should know:

Rewriting code is often a developer delusion, not the solution in most cases.

Why is it a delusion?

Well, because it’s harder to read code than to write it. This is why it is so hard to reuse code. This is why our subconscious mind whispers to us “Throw it away and start over” when we read another developer’s code.

There are many cases that you should consider to rewrite your code from scratch and you can read them here. But, here is simple advice for you:

Refactoring should be the first option.

21. Documentation and Commenting

One of the common misconceptions about commenting is that developers add comments that say what code is doing. This is wrong. That should be obvious from reading the code. If it’s not obvious, it means that it is not readable and it should be made simpler.

Όταν δεν μπορείτε να κάνετε τον κώδικα απλούστερο, τότε πρέπει να προσθέσετε το σχόλιο για να εξηγήσετε αυτήν την πολυπλοκότητα.

Ο πραγματικός σκοπός των παρατηρήσεων είναι να εξηγήσει «γιατί» θα έκανε κάτι, δεν «τι» η ο κώδικας κάνει. Εάν δεν το εξηγείτε αυτό, άλλοι προγραμματιστές μπορεί να μπερδευτούν και όταν πάνε να αλλάξουν τον κωδικό σας, ενδέχεται να αφαιρέσουν σημαντικά μέρη του. - Απλότητα κώδικα

Γράψτε ένα σχόλιο για να εξηγήσετε "ΓΙΑΤΙ", όχι για να εξηγήσετε "ΤΙ".

Ένα άλλο πράγμα είναι η τεκμηρίωση. Είναι σημαντικό να έχετε τεκμηρίωση για να εξηγήσετε την αρχιτεκτονική του λογισμικού σας και κάθε ενότητα και στοιχεία. Αυτό απαιτείται για να δείτε την εικόνα υψηλού επιπέδου του λογισμικού σας.

When a new developer joins your team, it will be easier for them to understand the software as a whole. When developers don’t have any clue about other parts of the software, they could easily make a mistake in their own part which can affect other parts also.

22. Picking Technologies (Tools, Libraries, etc.)

First things first, always remember this rule:

Don’t depend on external technologies.But when you have to do so, try to reduce your dependency on them as much as you can.

Why is that? Because they are another common source of complexity. They can kill your active development and make everything even harder.

When you are dependent so much on external technologies, you are not free. What if there is a major bug in that technology? You have to wait for the developers to fix that bug and if this technology is in the center of your project basically you are stuck, you can’t move forward. So that’s why it is so important to pick the right technologies for your project.

There are a few factors you should consider before you start using some technology:

  • Is there active development behind it?
  • Will it continue to be maintained?
  • How easy is it to switch away from?
  • What does the community say about it?

If you can find the right answer these questions, you can reduce the risk of picking the wrong technology.

23. Self-Development

Keep learning. Try out different programming languages and tools, read books on software development. They will give you another perspective. Every day small improvements will make a real difference in your knowledge and skills.

Be open-minded. Don’t be obsessive about one technology. Use the required technology to solve a specific problem. Don’t be in the unnecessary discussion like Microsoft vs Linux :)

Know that every specific problem has its own specific solution.

24. Don’t be a hero

A lot of times it’s better to be a quitter than a hero. As Jason Fried explains,

Για παράδειγμα, ας υποθέσουμε ότι πιστεύετε ότι μια εργασία μπορεί να γίνει σε δύο ώρες. Αλλά τέσσερις ώρες σε αυτό, εξακολουθείτε να είστε μόνο το ένα τέταρτο του τρόπου ολοκλήρωσης. Το φυσικό ένστικτο είναι να σκεφτώ, "Αλλά δεν μπορώ να τα παρατήσω τώρα, έχω ήδη περάσει τέσσερις ώρες σε αυτό!" Λοιπόν, πηγαίνετε σε λειτουργία ήρωας. Είστε αποφασισμένοι να το κάνετε να λειτουργεί (και λίγο ντροπιασμένο που δεν λειτουργεί ήδη). Πιάσε το ακρωτήρι σου και κλείνεις τον εαυτό σου από τον κόσμο. - Τζέισον Φρίντ

Μην είσαι εμμονή. Μάθετε πότε να σταματήσετε. Μην διστάσετε να ζητήσετε βοήθεια.

25. Μην κάνετε ερωτήσεις… Ζητήστε βοήθεια

Όταν έχετε κάτι να εφαρμόσετε και δεν είστε σίγουροι για τις λύσεις, μην ρωτάτε άλλους πώς να το κάνουν… τουλάχιστον όχι αμέσως. Αντ 'αυτού, δοκιμάστε οτιδήποτε και ό, τι μπορείτε να σκεφτείτε. Αυτό είναι πιο σημαντικό όσο λιγότερο άνετα είστε με μια ιδέα ή μια γλώσσα.

When you can’t think of anything on your own, search! Find answers and try them out. Modify those answers, see if you can understand why they work, adapt them to your code.

…But always seek advice.

When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice. Look to peers and senior developers to review your code.

I tried to explain the fundamentals of a good developer mindset in this article. I used some part from Code Simplicity book which has a big impact on my thinking process as a developer. When I read this book, there was a lot of moment that I reacted “ohh I did this mistake, I did that too.” I mentioned some important parts of the book and combine them with my experience.

I strongly recommend you to read Code Simplicity from Max Kanat-Alexander.

Ευχαριστώ για την ανάγνωση! Ελπίζω ότι αυτός ο οδηγός σας βοήθησε!

Μπορείτε να διαβάσετε περισσότερα από τα άρθρα μου στη διεύθυνση // huseyinpolatyuruk.com .