Tag Info

New answers tagged

1

I would just ask Why Not? When we are talking about a project we also talk about the team working on it and it is expected and should be welcomed to hear opinion about the features and and structure used. As a developer I personally believe and value the contributions of teammates. You know there is a saying "if you want to go fast go alone. if you want to ...


3

TDD "by the book" has a specific cycle, and specficially for changing specs, this cycle should ideally look like this: write one test according to the new spec (-> "red") change the SUT ("subject under test") to match the new test; depending on the change, this might break some old tests (-> the new test goes "green", but the old tests become "red") Change ...


-1

by it's very nature, actually must break the unit test? Yes. That is the exact purpose of the Unit Test, So you have to change your tests and then verify if the new changes are meeting your test.


10

The advertised cycle of TDD is write tests until they fail then hack at the code until they pass again and then refactor while keeping all test succeeding. When the spec changes you will need to remove the old tests that would verify a violation of the new spec and write new tests that will verify the new spec.


3

Welcome to the wonderful world of middleware development. It can be a lot of hard work and debate to develop a protocol, and no one should ever see the results. If you are on a small team, then avoid a dictator: have quick meetings with everyone to hammer out the protocol. Medium sized teams may wish to have representatives that work out the protocol. ...


10

You most definetly should contribute to how the format and structure of the JSON should look like. I see it more than often that the front-end engineers, the API consumers, is the ones knowing how the data-structure should be. You are the one going to use the data, format it, loop through it and work with it. You should have an opinion on how you want it ...


38

This is a conversation you should be having together, discussing the requirements and pros and cons of different formats. If one side or the other is dictating what happens, you're going to end up with bad software and an unhappy team.


1

You are asking two very different questions. The former one is not a generalization of the latter, because answering the first won't answer the second. There are many other things that might influence the second question, like how you would tackle transactions with multiple users and such. As for the first question, everybody agrees that a shorter ...


2

Are there any clear (measurable?) guidelines (besides "it depends") for setting the degree of explicitness/inderection. Not many. The first is the Law of Demeter, which focuses on how many "steps" it takes to get to what you want, which directly relates to your question about indirection. Another is Tell, don't Ask. If you have some implicit state ...


0

Another option is to write completely separate native apps with no shared code. Obviously this is a huge breach of the Don't Repeat Yourself principle, but it's actually quite common and successful, especially in larger companies. It means each team can focus purely on their platform without constantly having to coordinate their work with the shared code. ...


0

In a high-level language, typically it is mostly cross-platform anyway. Examples such as Java or Python will work on any supported platform. Your task then is just to test and fix up bugs on each platform you want to support to catch the edge cases (such as different filename or folder support). For lower level languages, the platform specific parts are ...


0

Best way of achieving this is by using a higher-level modern language that compiles to an independent bytecode. A good example would be using Xamarin toolchain (paid): 1) write code in C# and/or F# - many similarities with Swift: http://developer.xamarin.com/guides/cross-platform/fsharp http://msdn.microsoft.com/en-us/library/67ef8sbd.aspx 2) compile ...


1

Contrary to the other answers, it is important to note that some ways of testing can become fragile when the system under test (SUT) is refactored, if the test is whitebox. If I'm using a mocking framework that verifies the order of the methods called on the mocks (when the order is irrelevant because the calls are side-effect free); then if my code is ...


0

You really have 2 questions: First: Why do non development groups not use LaTeX or other Markdown in the software development process? The problem with migrating to LaTeX is the perceived learning curve particularly when you are dealing with non technical users. Users already know other formats and don't want to have to learn another method of doing the ...



Top 50 recent answers are included