mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-30 02:40:11 +08:00
20141127-6 选题 带一朵云去远行a598799539 推荐
This commit is contained in:
DeadFire
parent
85f5316139
commit
3b056857e3
62
sources/talk/20141127 What Makes a Good Programmer.md
Normal file
62
sources/talk/20141127 What Makes a Good Programmer.md
Normal file
@ -0,0 +1,62 @@
|
||||
What Makes a Good Programmer?
|
||||
================================================================================
|
||||
What makes a good programmer? It’s an interesting question to ask yourself. It makes you reflect on the craft of software development. It is also a good question to ask your colleagues. It can trigger some interesting discussions on how you work together. Here are five skills I think are crucial to have in order to be a good programmer.
|
||||
|
||||
### 1. Problem Decomposition ###
|
||||
|
||||
Programming is about solving problems. But before you write any code, you need to be clear on how to solve the problem. One skill good programmers have is the ability to break the problem down in smaller and smaller parts, until each part can be easily solved. But it is not enough simply to find a way to solve the problem. A good programmer finds a way to model the problem in such a way that the resulting program is easy to reason about, easy to implement and easy to test.
|
||||
|
||||
Some of the most complicated programs I have worked on were complicated in part because the implementation did not fit the problem very well. This led to code that was hard to understand. When the problem is well modeled, I agree with Bernie Cosell (interviewed in the excellent [Coders at Work][1]):
|
||||
|
||||
> “…there are very few inherently hard programs. If you are looking at a piece of code and it looks very hard – if you can’t understand what this thing is supposed to be doing – that’s almost always an indication that it was poorly thought through. At that point you don’t roll up your sleeves and try to fix the code; you take a step back and think it through again. When you’ve thought it through enough, you’ll find out that it’s easy“.
|
||||
|
||||
### 2. Scenario Analysis ###
|
||||
|
||||
Good developers have the ability to consider many different scenarios for the program. This applies both to the logic in the program, and to the internal and external events that can occur. To consider the different paths in the logic, they ask questions like: What happens if this argument is null? What if none of these conditions are true? Is this method thread-safe? To discover what types of events the software needs to handle, they will ask questions like: What if this queue becomes full? What if there is no response to this request? What if the other server restarts while this server is restarting?
|
||||
|
||||
The good programmers ask themselves: How can this break? In other words, they have the ability to think like testers. In contrast, inexperienced programmers mostly only consider the “happy path” – the normal flow of control when everything goes as expected (which it does most of the time). But of course, the unexpected inevitably happens, and the program needs to be able to cope with that.
|
||||
|
||||
### 3. Naming ###
|
||||
|
||||
Programming consists to a large degree of naming things: classes, methods and variables. When done well, the program becomes largely self-documenting, meaning that the function of the program is quite clear just from reading the source code. One effect of self-documenting code is that it naturally leads to many smaller methods, rather than a few large ones, simply because then you have more places to put meaningful names (there are [other reasons][2] why many small methods are good too).
|
||||
|
||||
Coming up with good names is much harder than it sounds. I like this quote (from Phil Karlton): “There are only two hard things in Computer Science: cache invalidation and naming things.” Partly naming is hard because it needs to be clear in your mind what each name represents. Sometimes that is not immediately clear, but only becomes apparent as the development proceeds. Therefore, renaming is just as important as naming.
|
||||
|
||||
Naming things well also includes coming up with concepts to be used, and what these concepts should be called. By having well-thought out, distinctly named concepts that are used consistently (in the program, and when discussing the domain with programmers and non-programmers), writing the program becomes much easier.
|
||||
|
||||
### 4. Consistency ###
|
||||
|
||||
Perhaps the biggest challenge in programming is managing complexity. Consistency is one way to combat complexity. It reduces some of the complexity by allowing us to see patterns and infer how things are named, used and handled. With consistency, we don’t need to use brain power to remember exceptions and random variations. Instead we can concentrate on [essential complexity, not accidental complexity][3].
|
||||
|
||||
Consistency is important across the board. It applies to variable names and grouping, method naming, the division into modules, the directory structure, the GUI, error handling, logging, documentation etc. For example, if some variables are related and appear together (in declarations, method calls or as columns in the database) then always use them in the same order. Then it becomes easier to see if one is missing, or if they have been mixed up. For an operation, if it is called delete in one place, don’t call it remove in another place – stick with the same name. Steve McConnell also has some good advice on using opposites precisely in [Code Complete][4]. For example, begin/end are opposites, as are start/stop. Don’t mix names from different pairs (for example using begin/stop) when dealing with opposites.
|
||||
|
||||
Inconsistencies can get introduced when modifying a program. Sloppy programmers don’t pay attention to if what they add is consistent with the existing code or not. Good programmers are relentless in ensuring that seemingly small details are just right. They know how important consistency is in the overall fight against complexity.
|
||||
|
||||
### 5. Learning ###
|
||||
|
||||
As a software developer, you are constantly learning. Before adding a new feature, you have to understand what it is supposed to do. Before adding code to an existing program, you usually have to learn what the existing code does, in order fit the new functionality in properly. You also have to learn about the surrounding systems, in order to interface with them correctly. The ability to learn fast therefore makes you a much more effective developer.
|
||||
|
||||
Furthermore, because the pace of development in the software engineering field is so high, there is a steady stream of new languages, tools, techniques and frameworks to learn about. You can view this as good or bad. Fred Brooks lists learning as [one of the joys of the craft][5], and I agree. Learning new things is satisfying in itself. It also means that life as a developer never is boring.
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
All of the above skills are generic – none of them are specific to any one language, framework or technology. If you have them, you can quickly learn a new language or tool, and write good software in that environment. Furthermore, because they are general in nature, they will not become obsolete in a couple of years.
|
||||
|
||||
These are my answers for what makes a good programmer. What do you think makes a good programmer? Let me know in the comments.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://henrikwarne.com/2014/06/30/what-makes-a-good-programmer/
|
||||
|
||||
作者：[Henrik Warne][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://henrikwarne.com/about/
|
||||
[1]:http://www.amazon.com/review/R2OV0TG7MJGXGL
|
||||
[2]:http://henrikwarne.com/2013/08/31/7-ways-more-methods-can-improve-your-program/
|
||||
[3]:http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf
|
||||
[4]:http://www.amazon.com/review/R269BBARXH1V6R/
|
||||
[5]:http://henrikwarne.com/2012/06/02/why-i-love-coding/
|
||||
163
sources/tech/20141127 Some Sentences about Java.md
Normal file
163
sources/tech/20141127 Some Sentences about Java.md
Normal file
@ -0,0 +1,163 @@
|
||||
Some Sentences about Java
|
||||
================================================================================
|
||||
There is nothing new in this article. I just collected some trivial statements which may not be trivial for some of the junior programmers programmers. Boring old stuff.
|
||||
|
||||
If you happen all of these things you know more about Java than the average house wife. I do not know if there is point to know all of these. You can be a fairly good Java programmer if you do not know some of these features. However a lot of new information in this article probably indicates you have room to develop.
|
||||
|
||||
### There are 4 different protection types ###
|
||||
|
||||
in Java (not three). These are `private`, package private, `protected` and `public`. If you do not specify any protection modifier when you define an element in a class it will be package private (and not public and not protected).
|
||||
|
||||
|
||||
|
||||
There are four levels of protection in Java.
|
||||
|
||||
On the other hand if you do not specify protection modifier in front of a method declaration in an interface: it will be public. You may specify it to be explicitly public but it does not have effect on Java and SONAR will not like you doing so.
|
||||
|
||||
|
||||
|
||||
Protection is Transitive
|
||||
|
||||
> My opinion about Java allowing you to optionally write `public` in front of a method in an interface is that this is a technology mistake.
|
||||
|
||||
Similarly you can write `final` in front of a field in an interface, or even `static`. It may imply that they could be non-static or non-final: not true. Fields of an interface are final and static. Always.
|
||||
|
||||
### Protected and package private are not the same ###
|
||||
|
||||
Package private (or default) protection will let other classes of the same package access to the method or field. Protected methods and fields can be used from classes in the same package (so far the same as package private) and in addition to that it can be used from other classes that extend the class containing the protected field or method.
|
||||
|
||||
### Protected is transitive ###
|
||||
|
||||
If there are three packages `a`, `b` and `c`, each containing a class named `A`, `B` and `C` so that `B` extends `A` and `C` extends `B` then the class `C` can access the protected fields and methods of `A`.
|
||||
|
||||
package a;
|
||||
|
||||
public class A {
|
||||
protected void a() {
|
||||
|
||||
}
|
||||
}
|
||||
package b;
|
||||
|
||||
import a.A;
|
||||
|
||||
public class B extends A {
|
||||
protected void b() {
|
||||
a();
|
||||
}
|
||||
}
|
||||
package c;
|
||||
|
||||
import b.B;
|
||||
|
||||
public class C extends B {
|
||||
protected void c() {
|
||||
a();
|
||||
}
|
||||
}
|
||||
|
||||
### Interface can not define protected methods ###
|
||||
|
||||
Many thinks that you can also define `protected` methods in an interface. When programming the compiler makes it obvious fast and brutally: you can not. Btw: this is why I think that allowing the `public` keyword in an interface is a technology mistake: it makes people think that it could also be something else as well.
|
||||
|
||||
|
||||
|
||||
Private is the new public
|
||||
|
||||
If you want to declare a `protected` method in an interface, you probably did not understand encapsulation.
|
||||
|
||||
### Private is not that private ###
|
||||
|
||||
Private variables and methods are visible inside the compilation unit. If that sounds too cryptic: in the same Java file (almost). This is a bit more than “in the class where they are defined”. They can also be seen from classes and interfaces that are in the same compilation unit. Inner and nested classes can see private fields and methods of the class enclosing them. However enclosing classes can also see the private methods and fields of the classes they enclose down to any depth.
|
||||
|
||||
package a;
|
||||
|
||||
class Private {
|
||||
private class PrivateInPrivate {
|
||||
private Object object;
|
||||
}
|
||||
|
||||
Object m() {
|
||||
return new PrivateInPrivate().object;
|
||||
}
|
||||
}
|
||||
|
||||
This latter is not widely known. As a matter of fact it is rarely useful.
|
||||
|
||||
### Private is class level not object ###
|
||||
|
||||
If you can access a variable or method you can access it no matter which object it belongs to. If `this.a` is accessible then `another.a` is also accessible assumed that `another` is an instance of the same class. Objects that are instances of the same class can fool around with each others variables or methods. Rarely makes sense to have such a code though. A real life exception is `equals()` (as generated by Eclipse, lines 15 and 18):
|
||||
|
||||
package a;
|
||||
|
||||
public class PrivateIsClass {
|
||||
private Object object;
|
||||
|
||||
@Override
|
||||
public boolean equals(Object obj) {
|
||||
if (this == obj)
|
||||
return true;
|
||||
if (obj == null)
|
||||
return false;
|
||||
if (getClass() != obj.getClass())
|
||||
return false;
|
||||
PrivateIsClass other = (PrivateIsClass) obj;
|
||||
if (object == null) {
|
||||
if (other.object != null)
|
||||
return false;
|
||||
} else if (!object.equals(other.object))
|
||||
return false;
|
||||
return true;
|
||||
}
|
||||
}
|
||||
|
||||
### Static classes may have many instances ###
|
||||
|
||||
|
||||
|
||||
Protection is not object level. It is class level.
|
||||
|
||||
Classes that are not supposed to have any instances are usually called utility classes. They contain only static fields and static methods and the only constructor is private, not invoked from any of the static methods of the class. In Java 8 you can have such a beasts implemented in interfaces, since Java 8 interfaces can have static methods in it. I am not convinced that we should use that feature instead of utility classes. I am not absolutely convinced that we should use utility classes at all.
|
||||
|
||||
Static classes are always inside in another class (or interface). They are nested classes. They are static and just as static methods can not access instance methods and fields of the class similarly a static nested class can not access the instance methods and fields of the embedding class. That is because nested classes do not have a reference (pointer if you like) to an instance of the embedding class. Inner classes, as opposed to nested classes are non static and can not be created without an instance of the embedding class. Each instance of an inner class has a reference to exactly one instance of the embedding class and thus an inner class can access instance methods and fields of the embedding class.
|
||||
|
||||
Because of this you can not create an inner class without an instance of the surrounding class. You need not specify it though if this is the current object, a.k.a `this`. In that case you can write `new`, which is, in this case, just a short form for `this.new`. In a static environment, for example from a static method you have to specify which instance of the enclosing class should the inner class created with. See the line 10:
|
||||
|
||||
package a;
|
||||
|
||||
class Nesting {
|
||||
static class Nested {}
|
||||
class Inner {}
|
||||
void method(){
|
||||
Inner inner = new Inner();
|
||||
}
|
||||
static void staticMethod(){
|
||||
Inner inner = new Nesting().new Inner();
|
||||
}
|
||||
}
|
||||
|
||||
### Anonymous classes can access only final variables ###
|
||||
|
||||
|
||||
|
||||
Variable has to be effective final
|
||||
|
||||
When an anonymous class is defined inside a method, it can access local variables if they are final. But saying that is vague. They have to be declared final and they also have to be effective final. This is what is released a bit in Java 8. You need not declare such variables as final but they still have to be effective final.
|
||||
|
||||
|
||||
|
||||
Java 8 does not require final, only effective final
|
||||
|
||||
Why do you need to declare something final, when it has to checked to be like that anyway. Like method arguments. They also have to be final. You say that this is not a requirement of Java? Well, you are right. It is a requirement of programming in good style.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.javacodegeeks.com/2014/11/some-sentences-about-java.html
|
||||
|
||||
作者：[Peter Verhas][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.javacodegeeks.com/author/peter-verhas/
|
||||
Loading…
Reference in New Issue
Block a user