3 ms·

A good solution to this is the traditional[1][2] UNIX approach of separating mechanism and UI. First develop the core functionality without a UI as a library (o

by pdkl95 5y ago

A good solution to this is the traditional[1][2] UNIX approach of separating mechanism and UI. First develop the core functionality without a UI as a library (or daemon or whatever). The actual UI is then developed as a front-end to the library. This allows multiple front-ends to coexist so a new UI can be developed without disturbing the people that like the old version. Too many projects tightly couple their UI and mechanism, which always leads to problems. [1] http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877777 http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id... [2] http://www.catb.org/~esr/writings/taoup/html/ch04s04.html http://www.catb.org/~esr/writings/taoup/html/ch04s04.html

bruce343434 5y ago
Interesting way to develop a program while keeping ui seperated, would have never thought of that approach. But in my experience, developing the UI alongside also leads to insights into your product you hadn't foreseen.
- pdkl95 5y ago
  Sure! Developing both the backend and an initial UI front end in parallel is a good idea. The point is to separate different aspects of the program into manageable, modular sections. Separating the mechanism and UI is just an another way to practice information hiding and modular programming.