Tag Info

New answers tagged

0

The need for iterative and incremental development on most software projects comes from the fact that those projects' requirements are in constant flux, and the fact that quickly delivering a prototype then iterating on it seems to produce better results than trying to produce a comprehensive specification before starting development. The only situation I ...


0

Often you can call the "build" button in an automated way (Visual Studio accepts command line arguments, for example). People write build scripts as soon as they need something that the build button cannot provide. For example, most IDEs will only let you build one platform at a time. Or only one language at a time. Then there's what you do with the built ...


1

Build script advantages: changes look like code (for example, in a git diff command), not like different checked options in a dialog creating more output than a simple build In some of my previous projects, I've used the build scripts to: generate the project documentation (doxygen-based) build run unit tests generate unit test coverage reports pack ...


12

Here's an example that uses Java. It's been a while since I've used log4j, but from what I remember, the whole log4j logging tool would initialize from an XML file. The XML file itself could contain multiple loggers with different configurations(where you write to, what levels are written, etc). So, in this case you would have logger objects rather than ...


1

Logger.new is a factory that will take where the result will be used (name of the class/file). In the configuration files you can then decide what level to log to not logging at all for parts of the program without having to recompile the project. Thus you can disable all but high-level logging (errors) for release builds and only activate the lowest ...


2

The above answers cover a lot of good ground, but one real-world example that I'd like to add (that I can't add as a comment due to no karma), is from Android programming. I'm a professional Android/iOS/Windows Phone developer, and I use Google services APIs (mostly Google Maps) a lot. In Android, these services require that I add a keystore, or a type of ...


1

Most software taxonomies tend to focus on the end user rather than developer interested in implementation aspects. I compiled a list of those I am aware of in descending order based on how developer v. end-user oriented is the taxonomy. Free software taxonomies Software taxonomy on Unilexicon, based on PyPI - collaborative editing welcome Python package ...


14

If all you ever want to do is <compiler> **/*.<extension>, build scripts serve little purpose (though one can argue that if you see a Makefile in the project you know you can build it with make). The thing is - non-trivial projects usually require more than that - at the very least, you'll usually need to add libraries and (as the project ...


104

Automation. When you are developing, only in the most simple projects will the default "build" button do everything you need it to do; you may need to create WS out of APIs, generate docs, link with external resources, deploy the changes to a server, etc. Some IDEs allow you to customize the build process by adding extra steps or builders, but that only ...


29

Like code, a build script is executed by the computer. Computers are exceptionally good at following a set of instructions. In fact, (outside of self-modifying code), computers will execute the same sequence of instructions exactly the same way, given the same input. This delivers a level of consistency that, well, only a computer can match. By contrast, ...


12

Many IDEs simply package up the commands used to build something and then generate a script and call it! For example, in Visual Studio, you can see the command-line parameters for a C++ compile in the 'command line' box. If you look closely at the build output you'll see the temporary file that contains the build script that was used to run the compile. ...


7

make is a lot easier to remember and type than gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h And projects can have very complex compilation commands. A build script also has the ability to only recompile the things that changed. If you want to do a clean build, ...


4

How else would you do it? The only other way is to specify one long command line command. Another reason is that makefiles allow incremental compilation, which speeds up compile time a lot. Makefiles can also make a build process cross-platform. CMake generates different build scripts based on the platform. Edit: With an IDE, you are tied down to a ...


1

There is one drawback: Assigning both tasks in parallel (to two different people) may result in wasted effort, if both end up working in parallel (and reject the change). Consider (measure) how much the two kinds of tasks cost, and how likely they are to result in further changes before acceptance. With those numbers available, you can estimate if it ...


4

The reason you don't see those surgical software teams that much is explained by the way developers are hired and assigned to teams. Two preliminary conditions for such team are: That there should be, within a company, developers who have different levels with an important gap between the most and the lest experienced ones, And that they are ready to work ...


16

For a team of 3-4 devs, you're proposing WAY too many branches. Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost. Keep in mind that the only real benefit to a branch is code isolation. ...


3

Like Mainma says, be careful with the branching. You mention branching every few weeks, is it really necessary to have a lot of branches? Alternatively, you could also have a 'pull' model instead of a push model. If you were using Git or Mercurial, you could have an integration server validate their changes before pushing to the central server. In TFS, you ...


28

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team ...


-1

If you are commonly having difficult merges, there is likely something wrong with the way you are using git. It sounds like you have branches that don't get deleted within a working day of them being created. That is generally, if not universally, considered to be a bad idea. Most of the time, git branches are more an extra (optional) step in the ...


0

If you never make mistakes you don't really need tests. Most developers do make mistakes, but if you never do, and you are confident you will never make mistakes in the future (and you are the only one on the project), there is really no reason to waste time writing tests. But your solution is kind of halfway because you are proposing to write tests when ...


2

I agree with both Daniel Hollinrake and Ewan, that the first key point why your test-only-if-modify works well so far is: I am the sole developer on my projects and I am responsible for everything and that a likely second key point is: you're producing nice clean code I do not think TDD brings a huge productivity boost for sole programmers, and it ...


0

So your problem is ultimately nothing to do with testing but the issue of difficult merges of your feature branch back to develop? I'd say why do you not want to run your tests off the develop branch? Are you testing the individual feature you're developing, or the integration whole of yours and others features? I'd say the feature branch testing is a ...


2

To make the process work in the long term I would write the tests when the code is being written. Which may seem to contradict your approach. However you've posed the question so I'll give you my take: You don't have to write the tests before the code. forget that purity. However you want to write the tests around that time. Once you have got the code ...


2

For me the key thing appears to be this: I am the sole developer on my projects and I am responsible for everything: Requirements gathering, design, architecture, testing, deployment, etc. I suspect this is why my process is working. This works for you and you're producing nice clean code (I assume!). The only thing I would say you need to do is ...


3

This is a good question, and FWIW I'll throw in my two cents. About a year ago I was coding in Salesforce, a platform which had an ingrained mechanism which forced you to not necessarily write tests before you coded, but rather forced you to write tests in general. The way it worked was that the system would force you to write tests, and it would make a ...



Top 50 recent answers are included