Jun 21, 2019 08:00:00

A summary of what I learned from my 30 years of experience with programmers

For programmers, 'how can we build programs more efficiently' has always been one of the most annoying issues, but from the experience of 30 years of software development, engineer Julio Bearson who is an expert on the road I have put together a blog about what I learned.

Julio Biason .Net 4.0-Things I Learnt The Hard Way (in 30 Years of Software Development)

https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/

Mr. Bearson divides the many learned things into the following three parts.

◆ About software development
◆ About team, work
◆ About personal thing

Here is a list of Mr. Bearson's summary for those who are going to become programmers or are already active as programmers.

◆ 1: About software development
・ Determine requirements before writing code
・ Leave each action in the comment
· Gherkin is a good help in understanding the expected behavior
Gherkin is one of the notations for testing, and it is described in the form 'If this kind of operation, it is expected that this will happen'. 'Even if you don't actually use it in testing, writing Gherkin makes it easier for you to understand what the app is expected to do,' Bearson says.

・ Unit test, integration test should be done
・ Test makes API better
・ Testing should be done on the command line
Because testing can be done automatically or can be used in CI tools.

・ Be prepared to discard the code
Test-driven development in particular is 'designed to throw away code,' says Bearson. Even if you lose the time to write the code, it is not that all is wasted because the understanding of the task is deepened by that much.

・ Good language has built in test
・ It is a waste of time to consider future issues
・ Document is a future love letter to oneself
Writing a document is a lot of trouble, but it helps me understand what I was thinking when I wrote a function and help me in the future.

・ Document of function is contract
・ 'And' will not appear in the function description
If you need to connect with 'and', the function should be divided into two.

・ Don't use boolean value as function parameter
When designing a function, you may want to set boolean values as flags to arguments. However, if you use the boolean value, the code of the part where the function is used becomes like 'getData (dataId, true)', and if you read it, you can understand what 'true' means not. Biason advises you to create another function instead of using a boolean value.

-Be careful with function renaming
Changing the function name will affect many people if it is open to others as a library. First of all, it is recommended to display the warning of deprecation to the original function, and to put out after a while.

・ Good language has built-in documentation
・ Language selection should be considered including the surrounding environment
・ In some cases it is better to crash than crush the error
Of course if you can handle errors properly you should
・ Types indicate how to read memory values
・ If the data has a structure, keep the structure as much as possible
・ Has the spirit of cargo cult

Cargo cult is the idea that 'someone can do it, too', so when deciding how to store data, in most cases it is the fastest way to do the same thing as others. Says.

・ 'Best language' controversy is barren
The argument that 'there is a language framework that is suitable for the task, and we should move to that' is usually just to announce my favorite language framework.

・ 'Best language' is surprisingly obvious
It is natural to choose Perl, which is a language that is good at language processing when you want to process language, but if project members are only people who are good at C and if the project is important and can not fail For example, it is wiser to choose C.

・ Don't reach out to things outside the project
Occasionally, instead of using the appropriate extensions, you may want to work directly with external library frameworks such as WordPress or Django. However, the need to capture changes every time the external library is updated can dramatically increase project maintenance costs.

・ You can write better code if you understand how data flows in the code
・ Don't stick to design patterns
The basis of functional programming is useful elsewhere
・ Cognitive dissonance makes code difficult to read
Cognitive dissonance is a word that expresses the phenomenon of discomfort when holding contradictory contradiction at the same time, for example, the action of the function named 'sum ()' is not 'add all the numbers in the list' but 'list The use of an uncommon function name, such as 'counting the true number of', would confuse the reader.

・ Simplify function nesting
If the function is called in the function and another function is called in the called function ... and the function is nested, it will be difficult to understand the operation, so we will receive the return value each time and make it another function Implementation seems to be preferable to pass.

・ If you use easy-to-write notation, you should also learn formal notation
・ We resist temptation of 'easy'
It's easy to build a project using the integrated development environment (IDE), but it's easy to get stuck without knowing how the build system is built and how to run it without the IDE.

・ When dealing with dates and times, be sure to enter the time zone
・ Always use UTF-8
・ Does not log messages to users
The debugger is overestimated
The debugger isn't bad, but actually logging is more useful.

・ Be sure to use a version control system
・ Commit every change
・ You can select the file to commit using 'git add -p'
· Organize projects by data type
Many projects are divided into functional folders as shown on the left, but organizing data by data as shown on the right makes it much easier to divide into smaller projects.

・ Create a library as needed
・ Learn how to monitor the system
-Convenient to use configuration file instead of command line option
・ Even if you handle multiple apps, it is good at first
It may be difficult to learn how to communicate between applications, but initially there is no problem in a primitive way, such as using files. Bison says that communicating directly isn't late after learning about the network.

· Leave the optimization to the compiler

◆ 2: About team work

・ In code review, you should check the design, not the style
・ Use formatter
・ Follow the code style of the project
・ C / C ++ uses K & R, Python uses PEP8
・ Explicit is better than implicit
For example, 'sleep ()' does not know whether the unit of the argument is seconds or milliseconds, but it is easy to understand by setting 'sleepForSecs' or 'sleepForMs'.

・ Touching many languages will be useful in the long run
・ Protect user's privacy
・ The best way to protect user data is not to collect user data
・ If you waste more than an hour due to a mistake, keep a record
・ If you can not run on your own computer, you will lose productivity
If you use code that only works in special environments, such as using the cloud functionality, you will lose productivity. You should find a way to do it locally, says Bison.

◆ 3: About personal things

・ Sometimes you should not write code
Mr. Bearson used to write a code when he was having a cold, but the code written at that time seemed to have to be almost rewritten if he looked at it after the cold had healed.

・ The code of conduct of the project protects the users
When using a new language, library or framework, you should first read the code of conduct for the project. By reading the code of conduct, you can avoid feeling uncomfortable without understanding what is happening.

・ There is also a time to say NO
・ Responsible for using the code you wrote
・ Don't say 'completed' even though it's not completed
If you feel any signs of bugs, but you're tired and you think the code is complete, the first user will just get a bug report right away.

People who complain about code and architecture are paying attention
・ Learn from troubles instead of ignoring troubles
・ Be aware of people's reactions
・ Should be away from people with poor speech
・ It is better to keep distance from people who make discriminatory statements even if they are unconscious
Mr. Bearson prefaced that 'this is a personal opinion', and said, 'If I feel that I am a discriminatory behavior, it is natural for the speaker and it is useless to say it.' .

・ There will be a day when we have to do a hero project
A hero project is a project for a major change that I personally think of as 'solving various problems of the project existing at that time', for example, a new architecture or a new framework is introduced. And sometimes change the language. Of course, it may be concluded that the current situation is better as a result of the survey.

・ Learn when to make a decision to quit
・ The world of IT is narrow
The IT industry is said to be a narrow world at the level where you may be working in the same place as your original colleague after making several changes. You should be careful enough about your behavior.

・ Paper notes are useful
・ Trello is cool, but post-it can be used
・ It is better to leave a silly way to blog than to do nothing
・ ・ ・ But it is better to turn off comments
・ Create a list of 'don't know'
Physicist Richard Feynman added a note titled 'Things I Don't Know'. If you find something cool and you want to know more, you can become more detailed by creating a file or note with that title, Bierson says.