design part ii getting ready to build n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Design Part II Getting Ready to Build! PowerPoint Presentation
Download Presentation
Design Part II Getting Ready to Build!

Loading in 2 Seconds...

play fullscreen
1 / 47

Design Part II Getting Ready to Build! - PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on

The George Washington University. Design Part II Getting Ready to Build!. Kunal Johar CSCI 4243 (Senior Design). Where are We in Design?. Specifications Document Development Idea / Problem Statement High Level Requirements Use Cases Functional / Non-Functional Requirements

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Design Part II Getting Ready to Build!


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. The George Washington University Design Part II Getting Ready to Build! Kunal JoharCSCI 4243 (Senior Design)

    2. Where are We in Design? • Specifications Document Development • Idea / Problem Statement • High Level Requirements • Use Cases • Functional / Non-Functional Requirements • Components Needed • Workflow

    3. Where are We in Design? • UI / Mockups • Final Workflow • Data Structures / Algorithms • Third Party APIs

    4. Where Are We in Development? • Bootcamp I Complete • Bootcamp II in Progress

    5. What is Next? • Design Part III • Coding Structure • Repository Setup • Test Plan • Development Task List / Estimation • Bootcamp II • 30% Demo!

    6. Good Code Structure • Why Bother? What are some traits?

    7. Good Code Structure • Remember Shop Vote?

    8. Shop Vote Code Structure • How would you lay out your code?

    9. Which Is Better? /Data - Vote.java - Images.java /Logic - Vote.java - Images.java /Configuration - General.java - Votes.java /Vote - Data.java - Logic.java - Configuration.java /Images - Data.java - Logic.java GeneralConfiguration.java

    10. Attributes of Good Structure • Well defined, yet simple • Intuitive to you and other developers • Extensible • Supports additions without needing to create a new “structure” • Good News: There are techniques for this!

    11. Naming Conventions • CONSTANTS _constants • VariableNaming variableNaming • Methods / Procedures() • Classes • Sounds a bit OO • How about C? Or LISP?

    12. Naming Conventions • Why Have Them? • Make code readable • Common construct for developers of a language • Fundamental to the success of an open source project • Makes code safer! Really.http://www.joelonsoftware.com/articles/Wrong.html

    13. Where To Start • Find a code writing style guide • Java (http://www.oracle.com/technetwork/java/codeconv-138413.html) • Javascript (http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml) • C# (http://www.akadia.com/services/naming_conventions.html) • Haskell (http://urchin.earth.li/~ian/style/haskell.html) • C / Systems Code (http://www.seas.gwu.edu/~gparmer/csg.pdf)

    14. Read Their Rules • Capitalization Style • PascalCase, camelCase, UPPERCASE • Notation • Brief: SetScrollX • Verbose: SetHorizontalScrollPosition • Hungarian: fBankBalance, studentCurrentStudent

    15. Add Your Rules • Special Classes • Folder Naming Structure • Packages / Name Spaces • What is a Name Space? • edu.gwu.cs.BiFi

    16. Shop Vote • C# Language • Server Side and iPhone Application • “Simple” application • How would you lay out the server side? • How about the client side?

    17. Shop Vote • Even Simple Applications Need Structure

    18. Intro to Design Patterns • Idea that code creation follows patterns depending on what code is for • Widely accepted concepts on how to structure code • Implemented across standard libraries for countless langages

    19. Naming Conventions on Steriods • Creational patterns • Builders, Factories, Singleton • Structural patterns • Wrappers, Bridges, Proxies • Behavioral Patterns • Iterators, Observers, States • Concurrency Patterns • Lock, Monitor, Thread, Pool

    20. Comments • Intuitive code means fewer comments • Good naming conventions • Avoid complex code • Loosely couple components • What does this mean?

    21. Documentation • Comment public properties / public methods • Use a documentation tool • http://www.stack.nl/~dimitri/doxygen/

    22. Setup a Repository • Git, SVN, Mercurual • Herve spoke to you about this a few weeks ago • No excuse for not having one setup • Decide when you will check in code • Only working code? • Only after full modules are built? • Make sure you comment your check ins

    23. In Class Exercise • Write out the authentication class of the web service • Then write a set of unit tests to confirm the functionality works • Use realistic pseudocode

    24. Let’s Take a Look at ShopVote • Model View Controller • Makes Unit Testing a Lot Easier • Two repositories • Server side • Client side (phone) • [Link to code spaces]

    25. Project Management Planning • Better idea of difficulty of your project after Bootcamp I and II • But to get to 30% we need a Bootcamp III • 30% - 100% can then be defined

    26. Plan a Daily Activity • What to develop first? • The hard stuff • What to develop last? • Get everything working • Make everything look good • Get a few things to look great http://www.joelonsoftware.com/articles/fog0000000018.html

    27. Filling in the Empty Shell • Build a Shell of Major Functionality • Fill in the shell with code • Use Unit Tests and Mock Objects to test subcomponents • These won’t catch all errors but will help narrow them down

    28. Unit Testing • Ensure baseline functionality works • Speeds up Debugging • Does not require custom tools • Method stubs with expected return values • Tools Do Help Though  • JUnit / JMock • NUnit

    29. Project Management Tools • “Task List” manager • Time Estimation • MS Project • Large learning curve, very powerful • Useful for large projects with large teams (building an airplane) • Assembla, Google Code, Microsoft CodePlex • Simpler task tracking “ticketing” tools • Bug Tracking / Feature Tracking • Integrate with repository

    30. Bootcamp III • What are the remaining challenging parts of this project? • What are the frameworks / APIs that need setup • What do you have the least control over?

    31. ShopVote Bootcamp III

    32. 30% - 100%, 110% • Look at HW5.pdf for remaining tasks • Get the framework done • E.g. Site map, login screens • These are easier to do now than later • Look at your workflow steps with no dependencies • Integrate components that depend on them • Repeat

    33. Time Estmiation • For each task • Write a description • Write a test plan to ensure results work • Estimate Time • Time = (Coding + Testing + Integration)*P • P = Polish, which means 3x your expected effort

    34. Task Strategy • For each major work flow create a single large task • Break each task into sub tasks of 4-6 hour blocks • Bootcamp tasks are all resolved so these remaining tasks are manageable chunks • (Bootcamp tasks can be dozens of hours each)

    35. What can you do in 4 hours? • Code the front end of a single UI form • Code the backend of a single UI form • Develop a handful of API calls • Input a medium (15 table) database scheme and map it to code

    36. What can you do in 4 hours? • Nothing if there are even minor distractions • Nothing if you run into a nasty runtime error • Nothing if you focus too hard on a minor problem (repositioning controls on a resize)

    37. Work Plan • You know how you work besthttp://www.paulgraham.com/makersschedule.html • I recommend • 2-4 hours of coding per day • 1 day off per week • 1 marathon coding session per week • 4 hours, 1 hours testing, 3 hours fixing, 1 hour refactoring (why?)

    38. Formulate Task List • [Code Spaces Link] • How long do you think each task should take us? • Let’s talk about how long they really took us

    39. In Class Exercise • Start work on your coding plan • Find a naming convention • Determine initial directory structure • Determine Bootcamp III tasks

    40. Discipline + Good Code Structure • Structure alone is insufficient • We can’t forget good general coding rules http://developerart.com/publications/4/wise-programming-techniques-for-writing-quality-code

    41. Avoid Quick Hacks • Y = Z/N • Transform it to If (N == 0) {Z=0;N=1; Y= Z/N}

    42. Write Self-Explanatory Code • SendThumbnailToAmazonS3(image); • SendPushNotifications(contacts[], message){ foreach (contact c in contacts) SendPushNotification(message, c.DeviceID)}

    43. Avoid Showing Off • A = A ^ BB = A ^ B • A = A ^ B

    44. Avoid Dense Code Blocks • Acc[categoryC] += GetUniqueHours(start, end) * 24;categoryC = NextCategory(categoryC, lookupCodes);TotalTime += Acc[categoryC];MaxTotalTime = Acc[PrevCategory(categoryC, lookupCodes] + TotalTime;This is the cleanest part of a 2,000 line time sheet generator that I wrote.  Updated to:foreach (TimeSheetCategory tc in TimeSheetCategories){  decimals timeInDays = GetTimeForCategory(start, end, tc);  TotalTime += timeInDays;  TotalTimePlusOverhead += timeInDays * 2;}

    45. Avoid Duplicative Functionality • Windows APIs • ShellExecute • ShellExecute32 • ShellExecuteEx • ShellExecuteEx32 • ShellExecute64

    46. Other Tips • Avoid “magic constants” • Place all constants in a properties or config file / class • Keep related code together • Strive for loose coupling • What does this mean? • Optimize last!

    47. What Are You Here For?