How to organize software development?

Question

Programming

Everyone develops programs differently. I would like to know - but there are some methods / techniques in the complex - how to work in a team, how to write tests, which tracker to use, how to work with GIT (in the sense of how often to commit, how much, how to describe), how to optimally configure emacs /vim for coding, for example with Python, which DE is better to take for coding (XFCE or Xmonad).

In general, a lot of questions related to pleasant and efficient coding. Everyone decides for himself, or are there any methods, tricks, tips, how should it all be in a complex? Something like ISO / GOST / RFC for organizing coding.

Answer 1

We are just now implementing Agile methods, specifically Scrum.
So far, of course, it’s not working out well, but in any case, the backlog has already begun to be maintained and the programmers have stopped sitting idle ...

Answer 2

1. How to write autotests - depends on the development tools. Perl scripts, Qt desktop applications, and Java server applications are obviously tested differently.
2. How to write test descriptions (for testers) - an experienced tester is hired for this, who will explain everything himself.
3. When working with git, it is desirable to commit with separate logical changes. It is advisable to check compilability before committing. It’s not worth making major changes in one commit, it’s better to separate it - here we made a subsystem, here we use it in this module, here it is in another. If some functionality develops for a long time in parallel with other activities, git rebase will allow the team that deals with this subsystem to be synchronized with the rest, but not to send their changes until the work is completed. And then send a group of commits at once.
4. How to set up the environment for coding - I don't think it will be possible to set this as a standard. Every programmer has their own habits. There is no perfect emacs/vim setup.
5. About DE - I personally am a fan of xmonad. Many tiling WMs can't stand it and it's not suitable for them. I don't understand why, but it's a fact. When hiring a programmer, it is important to me how he writes the code, and not what window manager he uses.
6. Here's the thing - in Linux it's easy to organize the migration of configs. So even when using pair programming, it is elementary to ensure that everyone works with the environment they are used to.
It is not the window manager that needs to be standardized, but the requirements for the design of the code.
Perhaps even the color schemes and fonts used in the interfaces - so that when pair programming people do not break their eyes. But even here I would be careful, but rather give people the opportunity to spend some of their working time on tuning. Then they will steal interesting ideas for setting up a workplace from each other. The result will be better than any standard.

Answer 3

In general, there is no one standard or super-techniques that are de facto effective. The development process can be influenced by many factors, such as the organizational structure of the company, the features of the sales model, the charisma or experience of the leaders, the experience and coherence of the development team, the development methodology, programming languages, and the features of the products being developed. The list can be long.
Personally, I would single out two main rules in all this:
1. Don't take anything in your models for granted. This means that if something works effectively today, it does not mean that in a year it will work just as effectively. Constantly improve positive solutions and avoid negative ones. For example, if now you commit at a rate of five times a day, this does not mean that in a year this rate will be in demand.
2. Economic efficiency of development - that's what you should think about every day. All decisions made must be cost-effective. For example, you can abandon one technology or program in favor of another, if only the speed of development would increase, the number of errors in the code would decrease, the quality of the code would increase, the amount of time to fix errors would be minimal, and so on. In fact, it doesn’t matter which program you are working in, it doesn’t really matter in what language, how often you make commits and what you write in comments, it is important that you don’t get loaded with all this, being distracted by beautiful passages and curtsy, although you need to just write code. Problems need to be addressed as they arise. For example, we have made many changes to the bug tracking and tasking software, now we use them so rarely that we can say that it has completely died out. And this does not prevent us from controlling the process and leading successful development. Tools need to be effective, and that only happens when you have experience using them. The tool itself will not help, sometimes even hurt.

Answer 4

IMHO, the main thing is not Scrum or Agile, but the right approach to design. That is, first, a thorough study of the architecture, drawing all kinds of schemes, writing documentation. And only then start coding.
If the project is small, then you can do without a bug tracker. In Git, it's better to commit often on the local machine, and squash into several commits before pushing.