+ 2
How did you plan your program
To those programmers out there i want to know how did you plan your code when you making one program.Is there a technique like making a flowchart or something?
7 Réponses
+ 8
for me, I think up vague phases within the program, of which I have a very rough idea of how I might do them. then I approach those phases in order, and figure out the specifics of how I'll code that phase.
+ 4
I think of something first and then I write on paper what will my code look like, and then I start coding next is I remove all of the things that are useless and bam, a masterpiece
+ 2
Mostly all less or more in mind :P
( that's as it's, but not a good way and/or a recommendation ^^ )
+ 2
there are a bunch of different ways of planning programs, and different standard diagrams for designing different aspects of a program (how it looks on screen, how the data is stored or modelled, what different "classes" should be and what they should do etc), as well as different "methodologies" that say how much you plan before coding and what stages you take. Generally now most of the time, methodologies that can be described as "agile" are favoured over the old school "waterfall method", because you see the results of early work in action sooner and often looking at something that runs and mostly works is easier to spot problems, than on diagrams and brainstorms. On my own projects, I get whatever forms naturally in my mind into something on my pc that I can verify if the idea is good, and then I keep building on the ideas as new ideas come into my mind. When ideas stop flowing for a bit, or if I have too much messy code/diagrams, I stop adding or altering ideas (or how they are shown in code/diagrams) and neaten things up (in code this is called "refactoring") So if I think of the user interface first, I'll make that first, see if I like it and alter it a bit and then add code that makes the UI do stuff after. If I think of a snippet of code first, I'll write that code first. I guess if I where to name my process/methodology I would call it "inspiration driven development".
+ 2
(my response was too long for one comment)
If you (or someone you are working for) know immediately just what your program should and shouldn't output for given inputs, I recommend Test Driven Design (often shortened to TDD).
Test Driven Development is where you write "unit tests" that will tell you if functions return the correct outputs for given inputs (including throwing correct error message if that is what you want to happen) before writing your main code, and keep coding until the unit tests pass - a Unit Test is a bit of code that checks if other code does some specific thing you want it to do in a set scenario. The set of unit tests becomes both a stage of planning (as you think about and define what is good and what isn't, what error messages you should expect and when) and something you can use as you code to verify what you've just added does what is intended,and that you haven't broken anything that was previously working.
heres some types of diagram (diagrams tend to have self-explanatory names, but google ones you are interested in for examples and explanations): Data Flow Diagram, Class Diagram, Entity-Relationship (for databases), User Flow Diagram, Storyboard (how the screen looks at each stage of a user doing something - good choice for plans that need to be agreed by a non-technical person), sitemap (websites)
0
use Algorithm chart
0
요구사항 분석
프로그램 설계
프로그램 개발
프로그램 테스트
위단계가 가장 기본적이며 각 단계에 여러가지 방법론이 존재한다.
스터디 라면, 한개의 주재로 여러벌의 코드를 만들어 낼수 있은데, 좀더 빨리 좀더 효율적으로 하고자 하는 마음이 기본으로 깔려 있어야 가능해