[[The Art of Readable Code]] has tips on naming, early return (from functions), de-nesting, variable reduction, and many other topics…. Here are my own thoughts.
I said in another blog that “in early phrases (perhaps including go-live) of a ent SDLC, a practical priority is instrumentation.” Now I feel a 2nd practical priority is readability and traceability esp. for the purpose of live support. Here are a few unconventional suggestions that some authorities will undoubtedly frown upon.
Avoid cliche method names as they carry less information in the log. If a util function isn’t virtual but widely used, try to name it uniquely.
Put numbers in names — the less public but important class/function names. You don’t want other people outside your team to notice these unusual names, but names with embedded numbers are more unique and easier to spot.
Avoid function overloads (unavailable in C). They reduce traceability without adding value.
Log with individualized, colorful even outlandish words at strategic locations. More memorable and easier to spot in log.
Asserts – make them easy to use and encourage yourself to use them liberally. Convert comments to asserts.
If a variable (including a field) is edited from everywhere, then allow a single point of write access – choke point. This is more for live support than readability.
How do global variables fit in? If a Global is modified everywhere (no choke point), then it’s hard to understand its life cycle. I always try to go through a single point of write-access, but Globals are too accessible and too open, so the choke point is advisory and easily bypassed.
This is a frank, honest but personal observation/reflection of the reality I witnessed. We should always bear in mind how (in)dispensable we really are to the business.
+ Many wall st trading system development teams have no QA personnel so developers do that. I did that.
+ Many wall st trading system development teams have no BA, so the project lead or key developer do that. I did that.
+ Many wall st system development teams have no RTB (Run-The-Bank, as the opposite side from Build-The-Bank) support team, so developers do
that. I did that. RTB can probably handle major FO (front office) apps but a lot of apps aren’t in that league.
+ Each wall st trading system development team I have seen never has a hands-off architect. If there’s an architect this person is first a coder then an architect.
+ Some wall st trading system development teams have no need for a DBA or unix SA (system admin). Without going into specifics, much of the expertise isn’t needed before release to production if (not a big if) developers _can_ build their apps themselves. In rare cases developers need some tuning advice.See also http://bigblog.tanbin.com/2010/12/hands-off-manager-according-to-lego.html
– However, proj mgr is crucial, every time. Most wall st systems are interdependent and extremely quick turnaround, requiring non-trivial communication, coordination, estimation, monitoring. I feel half the time the key developers don’t play the PM role.
My Citi mgr divided my work into ProdSupport + Greenfield + BAU i.e. (strategic or quick) enhancements on current production codebase.
In ML, effort is divided into BAU 66% + 33% Greenfield
GS is 75-25
One of the hardest part in Greenfield is replicating BAU behavior. The closer we get to prod release, the more we rely on prod system knowledge. Those nitty-gritty BAU behaviors become necessary features and show stoppers.
I think recruiters generally see Greenfield as more attractive. More design involved. More experienced candidates required.
A friend said green field becomes stressful as release date approaches.
hi, Tan Bin
Varies Knowledge Module comes with Agent, base on the role, other than monitor OS itself, you can purchase and configure Knowledge Module to monitor applications/services running on it.
it is similar to Microsoft MOM. every new application come on, MS will develop Management pack to install and moitor it.