Last Updated: 28 Jan 2024
|
Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
server-tech:development-platform-and-standards [Jun 22, 2016 08:22 PM] dordal [Next Up: Figure Out What Version to Use] |
server-tech:development-platform-and-standards [Jan 19, 2024 04:24 PM] 111.225.149.152 removed |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | = Choosing a Development Platform & Standards = | ||
+ | Getting a bunch of engineers on the same page about anything has been likened to ' | ||
+ | |||
+ | < | ||
+ | Oh, GAWD! | ||
+ | |||
+ | Once upon a time, Global Amalgamated Worldwide Designs (GAWD) decided to build a | ||
+ | widget. After finishing the requirements for the widget, GAWD put all its programmers | ||
+ | in a room, and said ‘go forth and build thy widget’. | ||
+ | |||
+ | So the programmers reviewed the requirements, | ||
+ | themselves. And then each programmer sat down at his terminal, and began to write | ||
+ | code. And the code flowed forth from the keyboards like wine. Good, clean code. | ||
+ | Beautiful code. | ||
+ | |||
+ | After a fornight, each programmer finished his task. And he submitted his code to the | ||
+ | group, and the group put all the pieces together, and went to test their widget. And | ||
+ | the widget didn’t even compile! | ||
+ | |||
+ | “There must be a simple solution” cried one! “Let us examine our code” cried another. | ||
+ | |||
+ | And there, plain as day, was the problem. But there was no simple solution. Each | ||
+ | programmer had written his code differently. Some had used obsolete functions from | ||
+ | outdated versions of the language. “But that’s the way I’ve always done it”, one | ||
+ | bellowed. Several had used conflicting libraries. Each shouted “but my library is | ||
+ | the best one!” | ||
+ | |||
+ | After much debate, the decided on one version of the language and one set of libraries. | ||
+ | And so they went to fix each other’s code. But as each programmer sat with his assigned | ||
+ | companion, they realized another problem. For two weeks, they hadn’t talked about how | ||
+ | they should write code, so none used the same variable name or function name | ||
+ | conventions. Filenames and comment styles were all different, and only the programmer | ||
+ | who wrote the original code could possibly know what it did. | ||
+ | |||
+ | And as they realized the magnitude of the problem, they humbly went to GAWD and told it | ||
+ | that they would need another fortnight to finish the widget. | ||
+ | </ | ||
+ | |||
+ | If you’re just starting a company that will build software of some sort (web based, desktop or otherwise) you don’t want this to happen to you. Choosing a language, a development platform and a set of coding standards up front can be a daunting task. If you have technical staff already, this is likely to ignite all sorts of religious wars. If you don’t, and aren’t technical yourself, you probably don’t have a clue what to do, but you likely know enough to know that you shouldn’t make the wrong choice. | ||
+ | == First Things First: Pick a Language == | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Fortunately, | ||
+ | |||
+ | |||
+ | * Pick a popular, modern language. It shouldn’t be too old-school (e.g. COBOL) but shouldn’t be too new either. You want something that a lot of programmers know how to use, and that has broad industry support so that your developers can go to conferences, | ||
+ | * Figure out what other companies in your industry use, and consider that. As a second step, figure out what possible partners use (this can be harder to do, from a practical standpoint) and consider that. Although it certainly isn’t necessary anymore to use the same language as partners in order to exchange data with them, it certainly doesn’t hurt. | ||
+ | == Next Up: Figure Out What Version to Use == | ||
+ | |||
+ | Second, establish what frameworks and libraries your application will depend on, and which versions you will use. For example, if you’re developing in PHP, you’re probably going to want to use a template system of some sort to separate your application logic from your display code. But there are plenty of choices… you can use [[http:// | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Once you get your language platform choices made, you’ll want to setup your build environment, | ||
+ | == Finally: Get Some Coding Standards In Place == | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Here are some questions you need to answer: | ||
+ | |||
+ | * What shall we do about comments? What’s the minimum standard? I don’t think I’ve ever seen code that has enough comments, short of code in technical demos written by vendors. At a minimum, I’d recommend that you have filename, author name, last date modified, and a description of what the code in the file does at the top (some of this will be contributed by a source control system such as cvs or subversion, if you’re using such a thing). Realistically, | ||
+ | * '' | ||
+ | * Whitespace and Linebreaks. Generally I just say to use lots, and leave it at that. If you want to be anal, you can try to decide where programmers should put curly braces and whatnot, but that is probably overkill. | ||
+ | |||
+ | If you can get your programmers to decide to take care of these things upfront, you’ll avoid the awful experience that Global Amalgatmed Worldwide Designs had. Then the only thing you’ll have to worry about is what to do with all that extra time. I’ve got [[/ |