1 / 47

Design Part II Getting Ready to Build!

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

chava
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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?

More Related