Giter Site home page Giter Site logo

Comments (5)

SBoudrias avatar SBoudrias commented on May 29, 2024

I'm not sure I understand your question correctly. But I'm not designing the product I work on daily, Yelp Seatme have a design/product team in charge of the product design and features.

from ama.

sukrosono avatar sukrosono commented on May 29, 2024

I mean the design of project before code it, like it's spec or cope. I wonder how to stay dry and code re-usability. Sorry become unclear 😕

from ama.

SBoudrias avatar SBoudrias commented on May 29, 2024

Well, I think this is a little bit personal for each person and the way their brain is wired.

I personally usually start by reading the prior code, build a vague idea of how my code will fit in there and then I'll start coding. Then I go over my git diff a lot refactoring and simplifying what I know to be dirty. Sometime, I'll also branch off some refactoring task to be completed on the old code before inserting my new feature - ideally you want to keep the code review diff minimals, so splitting in smaller task helps to keep the context of your changes.

As a rule of thumb, some rules I try to follow:

  • Don't use classes - don't use this
  • Pass contextual data as arguments (dependency injection)
  • Rely on CSS as much as possible (like don't position stuff through JS)
  • Prefer boilerplate to implicit dependencies (I prefer code that is more verbose but explicit)
  • Keep functions small and focused on a single task
  • Don't rely on state

from ama.

sukrosono avatar sukrosono commented on May 29, 2024
  • Keep functions small and focused on a single task

when the task is big, separate them into smaller function? Maybe some of them re-usable, am i correct?

  • Don't rely on state

what kind of state? sorry i just stupid 😕

Thanks Simon, you are really cool 😄

from ama.

SBoudrias avatar SBoudrias commented on May 29, 2024

when the task is big, separate them into smaller function? Maybe some of them re-usable, am i correct?

Yes, that's correct. But the number of lines is not what qualify a function as being big, it's the number of concern.

You don't want to abstract away common patterns your team know about (like the ORM or date handling, etc)

what kind of state?

Anything that is kept between runs. So anything on this or any values kept in a closure.

from ama.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.