神刀安全网

The Professional Web Codebase

One of the major advantages of the high career mobility in SF … Cross pollination. Yet each new codebase I comes to seems to lack a few of the following. So I figured I’d list out the essentials that every web codebase should have.

  1. The Obvious: Git, IDE, MV*, relational  DB, 3 environments that match production.
  2. Language regularization:

    Each language has its own idiosyncrasies. Learn your languages weakness and make helper functions to accommodate. In PHP, these weaknesses include single-threaded, bad undefined index default behavior.

    My preferred solution to PHP’s single-threaded limitations is to make use of a job queue . This will emulate additional threads for heavy tasks (e.g. sending emails to all of your user base) or high-latency tasks that ideally should be asynchronous (e.g. certain API calls). I’ve seen this done well, and I’ve seen it done poorly. From experience, I’d point out the following lessons:  don’t use a message queue as a job queue and  the DB is a great place to store a home-grown message queue.

    In PHP, out-of-bound reads on arrays return null and log a notification to the event log. Because this is never the desired effect, I always write two helper functions. One that looks up an key and returns a specific value if the key isn’t found (for cases where you’re using the array as a set). The other function looks up the key and returns an exception if the key is not found (for normal cases where the key should always be present ).

    I strongly believe once you handle these edge cases most popular languages are pretty interchangeable (javascript, java, php, python, ruby).

  3. A powerful, generic staging environment

    One of the most impressive and useful technologies I saw was something we called humblebrag . It was a script that caught all requests to  *.company.com/… . It then took the *, checked-out the corresponding git branch, and mapped the request to that particular branch. Thus in effect, we had a zero-effort way to have all branches usable simultaneously on a single server, even by non-engineers.

    Doing this can be a little harder in more complex environments with versioned services listening on ports, if you don’t plan for it early.

  4. A circuit breaker. Download one from github.
  5. An ability to do cross-server mutexes .
  6. A simple, generic read-through-caching function.
  7. A powerful logging system connected to an alerting system
  8. An A/B test system. Even if you’re not doing A/B tests on user-experience, it can be a great way to rollout to a small portion of users or internal-testers to ensure stability on a new environment.

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » The Professional Web Codebase

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮