小站会根据您的关注,为您发现更多,

看到喜欢的小站就马上关注吧!

下一站,你会遇见谁的梦想?

小站头像

Lets Tech

Let's Tech 打造最好的,以技术指导为基础,以技术新闻为核心,以产业发展为扶助的 Tech 小站。 
 
爱生活,爱音乐,爱写作,爱摄影,更爱技术。 
 
如果喜欢,请推荐啊 (单击右上角的那个小星星),谢谢啦。也欢迎投稿哦~~ 
 
(在墙外的我们有的时候也好想念墙内的日子 T.T ) 
 
站长微博,欢迎围观: http://weibo.com/chuxiwen1987

RSS 归档

站长

49227人关注

站长在关注

2013 / . 04 / . 17

How to Work with Software Engineers

By Ken Norton

 

https://www.kennethnorton.com/essays/how-to-work-with-software-engineers.html

 

I’ve worked in technology for twenty years, the past thirteen as a product manager. I’ve gained somewhat of a reputation for being effective at working with software engineers. This skill has earned me a place in history as one of the three greatest product managers of all time.[1] (On this exclusive list I am joined only by Steve Jobs and Niccolò Machiavelli.)


For years I’ve kept my secrets close to the vest. But no longer: today I will share with you myTen-Step Plan for Working With Engineers. Or more to the point: how to make engineers do what you tell them to do.

Why should you listen to me, one of the three greatest product managers of all time? [2] Just consider the numbers. I estimate that I’ve worked with 3,875,000 engineers during my career. Of those men and women, more than 95% have done what I told them to do. That means that precisely 1,000,000 engineers have done what I told them to do [an estimate: PMs don’t have time for math]. That’s a lot of engineers, and a lot of experience you should heed.

1. Absorb praise

As a PM, expect your successes to be recognized. Understand that executives will often attempt to spray accolades across the entire team. You must be vigilant: you are the one who is being celebrated, and you are the one who must take all of the glory. Credit is career currency, and you’re polishing your own LinkedIn profile, not theirs. Step up you ninja star, take the spotlight and bathe in the attention.

2. Deflect blame

Occasionally something will go wrong. In software development, the thing that goes wrong is usually software. When software fails, a software developer is to blame. That's just logical. Make sure to redirect the accusations when they’re aimed at you, and to preemptively sow blame whenever possible. Always remember: there is no “we” in me.

3. Don’t bother with the details

Frivolous little technical details are for the engineers, and you have much better things to be doing. Like ideating. Comprehension only leads to disappointment and fosters a so-called “rational” view of what’s possible. You can’t change the world if you know what’s hard and what’s easy. Avoid minutiae at all costs. Anything you imagine can be done in ten lines of code. It hardly matters which ten.

4. Involve them late

Software engineers write code, that’s what they do. They’re always fretting about how stuff is distracting them from their hacking. So why would you waste their time involving them in a project before it’s ready for coding? You don’t see a bunch of construction workers kicking back in an architect’s office. Bring them in once all of the strategizing and synergizing is done and all that’s left is the programming.

5. Add process

The best way to demonstrate your value to the team is by introducing process. Rules grease the wheels of progress. Look for opportunities to schedule update meetings, daily briefings, and all-day reviews. Keep your engineers productive by requiring them to fill out tracking spreadsheets, status reports, and cross-functional executive update emails. If you don’t do it, nobody will. Get going: those voicemails aren’t going to “touch base” by themselves!

6. Never tell the reasons

Engineers are highly analytical, which means they take a less-sophisticated approach to decision-making that often relies on “supporting data” or “rationales” rather than vision and blue sky thinking. Maintaining an air of mystery when decisions are made will keep them on their toes. They’ll complain regardless, there’s no reason to give them specific things to gripe about.

7. Commit for them

Your job as the product manager is to make assurances on behalf of your team. Leadership means setting the bar high and challenging everyone to teleport over it. Show your ambition by committing to project schedules without consulting your team. Being held accountable to somebody else’s promises builds character and brings out the best in people. Think of JFK. He picked a totally random date to land on the moon and NASA beat it, claiming the planet's vast mineral reserves for Standard Oil.

8. Interrupt at any time

 

You’re a busy knowledge worker, and the last thing you need is to wait for an engineer to finish their current task. You need it ASAP (pronounced “AY-sap”). Whatever an engineer is working on is less important than what you need right now. Feel free to interrupt them at any time. Chat windows and phone calls can be effective, but nothing beats the good old shoulder tap for impact. What if they're working on something you asked them to do an hour ago? No problem! This will serve as a good lesson in prioritization.

9. Be ambiguous

There are few things more dangerous to your career than being proven wrong. Ensure this never happens by aiming to be as vague and imprecise as possible. Feel free to change your mind at will. If you take every position imaginable, by definition you were right. Don’t record anything in writing, or better yet make documents so wordy and tedious nobody will bother reading them.

10. They’re always lying

Engineers will sometimes say something is “impossible.” They’re lying. Nothing in engineering is impossible if you set your mind to it. The Wright Brothers never thought that flying across the Atlantic was impossible! Assume a software engineer is always deceiving you and act accordingly. So when you hear terms like “technical debt” or “working from home,” you’ll be ready to call their bluff.

There you have it. My Ten-Step Plan for Working With Engineers. Print this out and hang it in your workspace (consider keeping it hidden from view). If you follow my plan, you too can become a great product manager (if not one of the three greatest[3]). It’s that simple.

 

Afterword

If it's not blindingly obvious by now, you should do exactly none of these things. Even the most conscientious PMs are occasionally guilty of less extreme infractions in each of these categories. I certainly am. Strive for the opposite and chances are you'll succeed as a PM. Or at the very least, you'll have engineering co-workers who'll want you to.

  1. Deflect praise
  2. Absorb blame
  3. Sweat the details
  4. Involve them early
  5. Streamline process
  6. Always tell the reasons
  7. Never commit without them
  8. Respect their time
  9. Be specific
  10. Trust them

And finally...

  1. Always bring the donuts

 

 

2013 / . 04 / . 16

How Social Media Networks Facilitate Identity Theft and Fraud

Recent research reveals that identity theft affects millions of people a year, costing victims countless hours and money in identity recovery and repair. What causes this pattern of online theft and fraud? It’s a combination of factors: a lack of consumer knowledge regarding protecting your identity online; growing comfort with, and trust in, social platform providers; the need for social platforms to generate revenue; and a lack of standards or policing of these standards. Although this issue is not yet in the mainstream consciousness, it likely will be sooner rather than later.

Fueling the Fire
Social media sites generate revenue with targeted advertising, based on personal information. As such, they encourage registered users to provide as much information as possible. With limited government oversight, industry standards or incentives to educate users on security, privacy and identity protection, users are exposed to identity theft and fraud. Additionally, these platforms have a ton of confidential user information, and are likely vulnerable to outside (or inside) attack. On the marketing front, Google recently patented an algorithm to rate individual’s influence within social media. Once publicized, it will likely encourage greater participation by active users in order to boost their influence score.

Crimes of Opportunity
With the increased global use of social media, there are more opportunities than ever before to steal identities or perpetrate fraud online. For example, status updates posted on Twitter, Facebook and many other social media sites can be used by criminals. If you post that you’re out of town on vacation, you’ve opened yourself up for burglary. If you mention that you’re away on business for a weekend, you may leave your family open to assault or robbery. When it comes to stalking or stealing an identity, use of photo- and video-sharing sites like Flickr and YouTube provide deeper insights into you, your family and friends, your house, favorite hobbies and interests.

That being said, social networking sites have the greatest potential for abuse. While everyone knows they should never share their social security number and driver’s license, many social networking sites ask for, if not require, similar sensitive information that can be used against you in a variety of malicious ways. The following profile elements can be used to steal or misappropriate your identity:

  • Full name (particularly your middle name)
  • Date of birth (often required)
  • Home town
  • Relationship status
  • School locations and graduation dates
  • Pet names
  • Other affiliations, interests and hobbies

Horror Stories
You’re probably asking why sharing your pet’s name, high school graduation date and membership to an organization with the public is a potentially dangerous move. There are a variety of reasons why you should keep personal information confidential, or at least closely managed. Below are just a few examples of how this information can be used to compromise your identity:

  • Phishing attempts using this information can be used to gain trust in order to obtain non-public information through online conversations. A Portland, Oregon, USA, company was recently attacked with false Better Business Bureau complaints in order to obtain additional information about the company and its employees.
  • GPS-enabled phones sharing your location can reveal sensitive information like your home address, work address and the places you visit.
  • Ninety-five percent of Facebook profiles have at least one application, many of which are not reviewed and can be used for malicious and criminal purposes.
  • False profiles can be used to fuel resume fraud or defamation of character. A Canadian reporter recently was defamed via a false profile that included misleading posts, poorly considered group memberships and intellectually inconsistent political positions.
  • An American soldier abroad in Iraq discovered his bank account was repeatedly being accessed online and drained. A security expert was able to replicate access with nothing more than his name, e-mail and Facebook profile.

Best Practices
Before you jump online and cancel all of your social media accounts, consider that there are ways to be smart about what you share and who you share it with. By following the best practices outlined below, you can enjoy the benefits of social media without making yourself a target for criminals.

  • Never, ever give out your social security number or driver’s license numbers.
  • Consider unique user names and passwords for each profile.
  • Vary your passwords and change them regularly.
  • Don’t give out your username and password to third parties (even if it helps you connect to others and build your network).
  • Assuming you plan to be active in social media, minimize the use of personal information on your profiles that may be used for password verification or phishing attacks.
  • Avoid listing the following information publicly: date of birth, hometown, home address, year of high school or college graduation, primary e-mail address.
  • Only invite people to your network that you know or have met, as opposed to friends of friends and strangers.
  • For password security verification questions, us a password for all answers (rather than the answer to the specific question, like “What is your mother’s maiden name?”).
  • When age-shifting to protect your real birthday, keep the date close; otherwise, you may expose yourself to age discrimination.
  • Watch where you post and what you say, as it can be used against you later.
  • Google yourself regularly and monitor your credit using the free annual report or monthly monitoring services.

Consumers need to be educated on the proper use of social media as it relates to protecting privacy and security. Social networks need to also understand the impact of not addressing security and privacy issues. If the information becomes corrupted, it not only casts doubt on the social network, but on your real-life personality, as well.

2013 / . 04 / . 10

LinkedIn Moved From Rails To Node: 27 Servers Cut And Up To 20x Faster

Update: More background by Ikai Lan, who worked on the mobile server team at LinkedIn, says some facts were left out: the app made "a cross data center request, guys. Running on single-threaded Rails servers (every request blocked the entire process), running Mongrel, leaking memory like a sieve." Which explains why any non-blocking approach would be a win. And Ikai, I hope as you do that nobody reads HS and just does what somebody else does without thinking. The goal here is information that you can use to make your own decisions.

 

Ryan Paul has written an excellent behind-the-scenes look at LinkedIn’s mobile engineering. While the mobile part of the story--23% mobile usage; focus on simplicity, ease of use, and reliability; using a room metaphor; 30% native, 80% HTML; embedded lightweight HTTP server; single client-app connection--could help guide your mobile strategy, the backend effects of moving from Rails to Node.js may also prove interesting. 

After evaluation, some of the advantages of Node.js were:

  • Much better performance and lower memory overhead than other tested options, running up to 20x faster in some scenarios
  • Programmers could leverage their JavaScript skills. 
  • Frontend and backend mobile teams could be combined into a single unit. 
  • Servers were cut to 3 from 30. Enough headroom remains to handle 10x current levels of resource utilization.
  • Development could focus more on application development than firefighting

Clearly a lot of issues are being mixed together here. We have a rewrite, a change of stack, and a change of logic distribution between the server and the client, so there's plenty of room to argue where the gains really came from, but it's clear LinkedIn believes the use of Node.js was a big win for them. YMMV.

The comment section is, well, vigorous, but has some interesting observations. I especially liked one comment by oluseyi:

 

For our inevitable rearchitecting and rewrite, we want to cache content aggressively, store templates client-side (with the ability to invalidate and update them from the server) and keep all state purely client side. This means the application may request from the server all content matching a set of filters updated since a provided timestamp in order to refresh its cache; rather than opening and closing several connections, we want to open a single long-lived connection and stream all of the relevant metadata, assets and content. (Again, remember that the original implementation just rendered the returned HTML, which means that URIs for images, etc pointed to the server, and because the web views were being created and destroyed with navigation, the images were not being effectively cached.)


In the long-lived connection implementation, there are no longer "views" in the traditional MVC web application sense. The final result of server-side processing in the controller to aggregate any necessary data is not markup written to the output stream but rather a large binary blob which the client unpacks to extract all relevant data.

So while I see your concern that the term MVC is being misused here, its usage is correct in a web application context-specific sense. The "view" (markup written to output, including references to external URIs that must be resolved by the rendering web view) is now an aggregated data stream, which gets unpacked, cached and then rendered client-side into the view.

2013 / . 04 / . 02

Linus Torvalds To Join Microsoft To Head Windows 9 Project

(Published on APRIL 1, 2013, could it be a joke?)

 

This is breaking bad. This is big. Linus Torvalds, the creator of Linux, and a champion of free and open source software has finally call it a day and has agreed to join Microsoft as the project head of the upcoming Windows 9 project.According to Bloomberg, Linus will be working on a new Kernel design for Microsoft that will make, usually vulnerable, Windows OS virtually impossible to be infected by viruses and malware.


Windows 9 is the most ambitious program of Microsoft till date as it aims to revolutionize the computing experience like never before. Apart from no viruses, it will also not have the blue screen of death anymore. The OS will run smoothly on any PC, Tablet or Smartphone providing a unified experience on all devices. Windows 9 will boot very quickly (in 9 seconds) and will not slow down after one month of use. It will also not have tons of temporary files and user will face no registry problem at all.

(Linus + Microsoft) vs Apple?

Many in the industry seeing this step as an end to 20 years long battle between Linux and Microsoft. On the other hand, some speculate that this is the second level of Linus vs Apple battle and Linus has joined hands with Microsoft to take on Apple. Linus had been unhappy with the iOS file system and called it worse than that of Windows. Honestly, Linus has been unhappy over a lot of stuff lately, remember Fuck You, NVIDIA? Any ways, it would be interesting to see how Apple reacts to this move by Microsoft while it plans to take on Google with its recently launched ‘iSearch‘ search engine.

Angry reactions from Linux fans:

The news of Linus joining Microsoft has outraged the hardcore Linux users. Forums and Google Plus are flooded with reactions from angry users who felt like cheated on this news. Billy Soft, who started using Ubuntu 2 weeks back, when his Windows Vista crashed, was almost in tears. “Man! I hate Windows”, said Billy, “I was making fun of my friends the other day for they are still using Windows. Windows is for grandpa, Linux is hip and cool. It makes you feel like a Geek. But now my friend just poked me asking if I’ll revert to Windows after 20 years.”

When I contacted Linus for his input on this news, on 1st April, he just smiled at me.

2013 / . 04 / . 01

Apple 与 Adobe 那纠结的历史

Chronicles of Conflict: the History of Adobe vs. Apple

Daniel Eran Dilger

If you didn’t know any better, you might think this whole Apple vs Adobe thing blew up out of nowhere because Steve Jobs woke up one morning with a stiff neck and decided to take it out on Adobe. Those of you who imagine there might be more to it than that that might like to reminisce with a little walk down tech history lane.

.
The Genesis of Adobe

In the beginning, Xerox PARC created the graphical desktop. The personal computer was yet formless and empty, and darkness was upon the face of its software development. And then the money of Xerox moved to and fro upon the waters of innovation and PARC said, let there be icons and windows and Ethernet and SmallTalk object oriented development. And lo, there was a $15,000 workstation, and Xerox saw the Alto, and that it was good.

And then Steve Jobs saw the Alto, and he convinced Xerox to invest a million dollars in Apple. And Jobs said that Apple would commercialize Xerox’ technology and make the company rich on its investment. And thus Apple created Macintosh, which then attracted engineers from Xerox who joined Apple in order to work on products that might actually turn into something a person might actually see in the real world and not just in a PARC lab.

And then Apple released Macintosh to the people, and it wasn’t entirely clear what the new graphical computer for regular people could do. And then Steve Jobs saw PostScript, a language created by Xerox engineers who had left PARC to form Adobe Systems. And Jobs said, look! you must take PostScript and make it the language of laser printers, so that common people can create wonderful type and high resolution graphics, and it will be driven by the Macintosh.

And so Adobe licensed PostScript to Apple, and Apple shipped the LaserWriter as the first printer with a sophisticated language for describing typography and graphics, and thus verily the Macintosh and the LaserWriter brought forth desktop publishing, and the world observed and saw that it was good, and Macintosh enjoyed its first killer app. And the people rejoiced.

And then Steve Jobs left Apple to form NeXT, and he licensed Adobe’s PostScript as the language of the entire graphical desktop, so what the user saw on the screen was identical to what was printed out on paper, and it was Display PostScript, and it was good.

An Exodus from the Enslavement to Adobe

And money flowed into desktop publishing. And Adobe began to sell PostScript Type 1 fonts to publishers with Macintoshes, and it charged prohibitively high rates for Type 1 fonts and for its PostScript language.

And Apple’s countenance began to fall at Adobe’s greed, and so Apple visited Microsoft in the late 80s and proposed TrueType as an alternative format to Adobe’s expensive fonts, and Microsoft bought TrueImage and proposed to Apple that it license its PostScript-clone language as an alternative to PostScript.

And Adobe saw the writing on the wall and begged Apple not to leave and Apple agreed to keep licensing PostScript for its laser printers, but the Mac OS and Windows both began using Apple’s TrueType and fonts thus became affordable to mere mortals. And TrueType begat OpenType and never again did anyone pay huge sums for Adobe Type 1 fonts again.

Numbers of Adobe Applications

And Adobe had created Illustrator to draw on the Macintosh in 1987, and then purchased Photoshop to paint on photos on the Macintosh in 1990, and then created Premiere to edit movies on the Macintosh in 1991. And in 1994 Adobe merged with Aldus to acquire its 1986 PageMaker for desktop publishing on the Macintosh and its 1993 After Effects for motion graphics on the Macintosh. And in 1995 Adobe bought Frame to acquire its 1990 FrameMaker for building long documents on the Macintosh.

And Adobe began to notice that Windows was selling to large numbers of commodity PC makers, and it was tempted by the volume of its user base, and it sinned against Apple which had caused its birth and wealth, and it began having relations with Windows and lost interest in the Macintosh and told its user base to move to Windows because it was comely and good for use.

And Apple pleaded with Adobe to use its new technologies, saying, lo, we have created QuickDraw GX to perform complex typography and printing, and QuickDraw 3D for modeling, and PowerTalk for messaging. And Adobe ignored Apple and laughed at its plight, and Apple wept bitterly as its operating system roadmap collapsed. And Apple went looking for a new strategy to stave off death, and happened upon Steve Jobs and his NeXT Software, and Apple said, you must be our savior and Jobs reluctantly agreed to sell NeXT to Apple and see what the company would do with it.

And then Jobs grew excited with what might happen, and he usurped the leadership of Apple, and visited Adobe again with his combined portfolio of NeXT and Apple. And Adobe said verily to Apple, pay us 30 pieces of silver that we may port our applications to your operating system. And Adobe demanded huge royalties for Display PostScript.

And Jobs brought his operating system to Macromedia and then Microsoft, and they all scoffed at the idea of porting their apps to a new and unproven operating system, and thus Apple was forced to start over and develop a legacy API called Carbon to enable their old code to work on the new operating system. And Apple removed Display PostScript and created a new imaging model based on PDF, which Adobe had released as an open specification. And so Apple no longer needed to pay Adobe royalties for Display PostScript.

And Jobs returned to the developers after working on Mac OS X for five years and said, lo, we have created all you have asked for, and your old code will work natively if you only do some simple Carbonization work, and look! we have done this ourselves with the Finder. And in 2001, Macromedia brought forth a Carbonized Freehand and Microsoft brought forth a Carbonized Office v.X. But Adobe sat on its hands and refused to Carbonize most of its apps for several years.

And in 2002, Adobe released InDesign for Mac OS X before QuarkXPress, making Adobe the second to the last major Mac developer to support Apple’s new operating system. Adobe then ported AfterEffects and GoLive in 2002, but didn’t port Acrobat, Photoshop, or Illustrator for Mac OS X until the end of 2003 as part of Creative Suite. In 2003 Adobe also canceled Premiere and FrameMaker for the Mac, and focused all new development on Windows. And Adobe made great money from Mac users on Creative Suite, and CS2 in 2005.

And in 2005, Adobe bought Macromedia. And that same year Apple said, lo, we have ported Mac OS X to Intel, and we shall verily migrate the Macintosh to Intel in 2006. And Adobe joined Apple on stage and said this was good. And then for a year Adobe said it would not update Creative Suite 2 or its Macromedia Studio 8 suite to run on Intel Macs natively. And then Adobe did finally release Creative Suite 3 as a Universal Binary in the spring of 2007. And Apple was greatly annoyed.

Adobe Judges Mac Ruthlessly

And Adobe reviewed its resources for Macromedia’s Flash, and it assigned a development team of four full time employees to maintain development of the Windows version of Flash Player. For the Mac version, it had a half time assignment for one employee who was not a Mac expert. And so Flash Player for Mac continued to be unstable and serve as the number one cause of crashes system wide for Mac OS X, and would regularly consume 100% of the Mac’s CPU in a spin lock while idle. And the people blamed Apple, and Apple was greatly annoyed.

And sources within Apple reported, “anyone who’s ever written threaded code can tell you that this is a brain-dead beginner mistake. They finally fixed this a couple of months ago, after years of Apple engineers telling them to get their act together.”

And Flash for Mac was so terrible that Apple was forced to develop a mechanism to isolate the Safari plugin in Snow Leopard so that when it crashed it would not always kill Safari, as Flash was verily an awful piece of software. And Adobe did not care, because Flash Player was free, and it planned to make its money from Windows and to simply use Mac users to sell them slightly rewarmed, high priced versions of Creative Suite apps on a regular basis, just like Microsoft and its Office suite.

Lamentations over iPhone

And then in 2007 Adobe noticed that Apple had created the iPhone, and that it was comely in appearance. And Adobe longed to have Flash on the iPhone, for it wanted its HTML alternative to cover the entire Earth. And Apple said no, your desktop version of Flash is too unstable and too big, and your Flash Lite version is not good enough and will not run the Flash content users expect. And Adobe told the people that Flash for iPhone was right around the corner and that it was working with Apple, but this was not true at all. And the people waited.

And then iPhone users began to forget about Flash, and began to consume more than half of the Earth’s mobile web traffic, and Adobe began to panic because it lusted after mobile licensing fees for Flash. And Adobe grew embarrassed and fashioned fig leaves for itself after recognizing its nakedness, and Steve Jobs banished Adobe from the Garden of iPhone.

And Adobe wept bitterly and its days were frustrated and its nights were filled with terrors, and the work of its hands bore little fruit as Flash Player for mobile only worked on Android and webOS and some vaporware mobile product Microsoft planned to release sometime in the future. And Apple said no, the iPhone will not ever run Flash for we do not want to be enslaved to your platform, for we have worked with W3C partners to develop HTML5 as a way to deliver rich interactive content, and do not need Flash anymore.

And Adobe cursed Apple and Steve Jobs and made great noises and gnashed its teeth and ripped its garments apart and scraped its festering boils with shards of pottery. And Steve Jobs did not listen. And so Adobe said we shall build a tower to heaven, and our Flash Professional shall create an army of App Store titles based on Flash games, and Creative Suite 5 shall trump Steve Jobs and his refusal to license Flash Player. And Steve Jobs looked down upon the tower and he confused their languages with SDK section 3.3.1 and interest in Flash Professional CS5 was scattered.

A Revelation of Adobe

And Adobe saw four horsemen of the apocalypse ascending from the sea, the the rider of the white horse was Steve Jobs and he was bent on conquest. And a second horse, red, was given to iPhone to take away market share from smartphones, and to cause phone makers to wage war and to fall upon their own swords. And a third horse, black, was carrying the scales of the iPod touch, and it measured out music playback from iTunes and sold many apps and starved other mobile platforms of mobile application demand. And fourth horse, pale, had a rider named iPad, which pundits called Death. And it caused famine for tablets and plague for slates and killed with a sword. And none of the horsemen used Flash.

And Adobe frightfully woke from its vision of terrors, and realized that its days of monopolizing the web with Flash content were over. And Adobe began creating new apps for iPhone and for iPod touch and for iPad, and began porting its Creative Suite to Cocoa as Steve Jobs had asked it to do ten years ago. And Adobe continued to develop Lightroom and Adobe earned profits for its efforts.

And then Adobe began building HTML5 development tools, and it charged reasonable prices and built cross platform products and the people rejoiced and Adobe’s death was spared and it lived comfortably for many days next to Apple. And Steve Jobs said thank you and Adobe said no, thank you. And they all lived happily ever after.

2013 / . 03 / . 28

The Principles of Good Programming

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.”

http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal. Simple code takes less time to write, has fewer bugs, and is easier to modify.

http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it. 

http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design. 

http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplifiedhttp://www.sensible.com/dmmt.html

Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend. 

http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else. A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” 

http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible. 

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task. 

http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability” 

http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion - Code that has similar functionality should be found within the same component. 

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component. 

http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.)

http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth.

http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time.

http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code.

http://en.wikipedia.org/wiki/Separation_of_concerns

Embrace Change - This is the subtitle of a book by Kent Beck, and is also considered a tenet of extreme programming and the agile methodology in general. Many other principles are based on the concept that you should expect and welcome change. In fact very old software engineering principles like minimizing coupling are related directly to the requirement of making code easier to change. Whether or not you are an extreme programming practitioner, this approach to writing code just makes sense.

http://www.amazon.com/gp/product/0321278658

2013 / . 03 / . 28

程序设计里的“小聪明”

http://blog.sina.com.cn/s/blog_5d90e82f0101j529.html

 

很早就想写这样一篇博文了,可是一直没来得及动笔。在学校的时候,时间似乎总是不够用,因为一旦有点时间,你就想是不是该用来多看点论文。所以我很高兴,工作的生活给了我真正自由的时间,让我可以多分享一些自己的经验。

 

我今天想开始写这系列文章的原因是,很多程序员的头脑中都有一些通过“非理性”方式得到的错误观点。这些观点如此之深,以至于你没法跟他们讲清楚。即使讲清楚了,一般来说也很难改变他们的习惯。

 

程序员的世界,是一个“以傲服人”的世界,而不是一个理性的,“以德服人”的世界。很多人喜欢在程序里耍一些“小聪明”,以显示自己的与众不同。由于这些人的名气和威望,人们对这些小聪明往往不加思索的吸收,以至于不知不觉学会了很多表面上聪明,其实导致不必要麻烦的思想,根深蒂固,难以去除。接着,他们又通过自己的“傲气”,把这些错误的思想传播给下一代的程序员,从而导致恶性循环。人们总是说“聪明反被聪明误”,程序员的世界里,为这样的“小聪明”所栽的根头,可真是数不胜数。以至于直到今天,我们仍然在疲于弥补前人所犯下的错误。

 

所以从今天开始,我打算陆续把自己对这些“小聪明”的看法记录在这里,希望看了的人能够发现自己头脑里潜移默化的错误,真正提高代码的“境界”。可能一下子难以记录所有这类误区,不过就这样先开个头吧。

 

 

小聪明1:片面追求“短小”

 

我经常以自己写“非常短小”的代码为豪。有一些人听了之后很赞赏,然后说他也很喜欢写短小的代码,接着就开始说 C 语言其实有很多巧妙的设计,可以让代码变得非常短小。然后我才发现,这些人所谓的“短小”跟我所说的“短小”,完全不是一回事。

 

我的程序的“短小”,是建立在语义明确,概念清晰的基础上的。在此基础上,我力求去掉冗余的,绕弯子的,混淆的代码,让程序更加直接,更加高效的表达我心中设想的“模型”。这是一种在概念级别的优化,而程序的短小精悍只是它的一种“表象”。这种短小,往往是在“语义” (semantics) 层面的,而不是在“语法”层面死抠几行代码。我绝不会为了程序“显得短小”而让它变得难以理解,或者容易出错。

 

相反,很多其它人所追求的“短小”,却是盲目的,没有原则的。在很多时候,这些小伎俩都只是在“语法” (syntax) 层面,比如,想办法把两行代码写成一行。可以说,这种“片面追求短小”的错误倾向,造就了一批语言设计上的错误,以及一批“擅长于”使用这些错误的程序员。

 

举一个简单的例子,就是很多语言里都有的 i++ 和 ++i 这两个“自增”操作(下文合称“++操作”。很多人喜欢在代码里使用这两个东西,因为这样可以“节省一行代码”。殊不知,节省掉的那区区几行代码,比起由此带来的混淆和错误,其实是九牛之一毛。

 

从理论上讲,++操作本身就是错误的设计。因为它们把对变量的“读”和“写”两种根本不同的操作,毫无原则的合并在一起。这种对读写操作的混淆不清,带来了非常难以发现的错误,甚至在某些时候带来效率的低下。

 

相反,一种等价的,“笨”一点的写法,i = i + 1,不但更易理解,而且更符合程序内在的一种精妙的“哲学”原理。这个原理,其实来自一句古老的谚语:你不能踏进同一条河流两次。也就是说,当你第二次踏进“这条河”的时候,它已经不再是之前的那条河!这听起来有点玄,但是我希望能够用一段话解释清楚它跟 i = i + 1 的关系:

 

现在来想象一下你拥有明察秋毫的“写轮眼”,能看到处理器的每一步微小的操作,每一个电子的流动。现在对你来说,i = i + 1 的含义是,让 i 和 1 进入“加法器”。i 和 1 所含有的信息,以 bit 为大小,被加法器的线路分解,组合。经过一番复杂的转换之后,在加法器的“输出端”,形成一个“新”的整数,它的值比 i 要大 1。接着,这个新的整数通过电子线路,被传送到“另一个”变量,这个变量的名字,“碰巧”也叫做 i。特别注意我加了引号的词,你是否能用头脑想象出线路里面信息的流动?

 

我是在告诉你,i = i + 1 里面的第一个 i 跟第二个 i,其实是两个完全不同的变量——它们只不过名字相同而已!如果你把它们换个名字,就可以写成 i2 = i1 + 1。当然,你需要把这条语句之后的所有的 i 全都换成 i2(直到 i 再次被“赋值”)。这样变换之后,程序的语义不会发生改变。

 

我是在说废话吗?这样把名字换来换去有什么意义呢?如果你了解编译器的设计,就会发现,其实我刚刚告诉你的哲学思想,足以让你“重新发明”出一种先进的编译器技术,叫做 SSA(static single assignment)。我只是通过这个简单的例子让你意识到,++操作不但带来了程序的混淆,而且延缓甚至阻碍了人们发明像 SSA 这样的技术。如果人们早一点从本质上意识到 i = i + 1 的含义(其实里面的两个 i 是完全不同的变量),那么 SSA 可能会提前很多年被发明出来。

 

(好了,到这里我承认,想用一段话讲清楚这个问题的企图,失败了。)

 

所以,有些人很在乎 i++ 与 ++i 的区别,去追究 (i++) + (++i) 这类表达式的含义,追究 i++ 与 ++i 谁的效率更高,…… 其实都是徒劳的。“精通”这些细微的问题,并不能让你成为一个好的程序员。真正正确的做法其实是:完全不使用 i++ 或者 ++i。

 

当然由于人们约定俗成的习惯,在某种非常固定,非常简单,众人皆知的“模式”下,你还是可以使用 i++ 和 ++i。比如: for (int i=0; i < n; i++)。但是除此之外,最好不要在任何其它地方使用。特别不要把 ++ 放在表达式中间,或者函数的参数位置,比如 a[i++], f(++i) 等等,因为那样程序就会变得难以理解,容易出错。如果你把两个以上的 ++ 放在同一个表达式里,就会造成“非确定性”的错误。这种错误会造成程序可能在不同的编译器下出现不同的结果。

 

虽然我对这些都了解的非常清楚,但我不想继续探讨这些问题。因为与其记住这些,不如完全忘记 i++ 和 ++i 的存在。

 

好了,一个小小的例子,也许已经让你意识到了片面追求短小程序所带来的巨大代价。很可惜的是,程序语言的设计者们仍然在继续为此犯下类似的错误。一些“新”的语言,设计了很多类似的,旨在“缩短代码”,“减少打字量”的雕虫小技。也许有一天你会发现,这些雕虫小技所带来的,除了短暂的兴奋,剩下的就是无尽的烦恼。

 

思考题:

 

1. Google 公司的代码规范里面规定,在任何情况下 for 语句和 if 语句之后必须写花括号,即使 C 和 Java 允许你在其只包含一行代码的时候省略它们。比如,你不能这样写

 

for (int i=0; i < n; i++)

   some_function(i);

 

而必须写成

 

for (int i=0; i < n; i++) {

  some_function(i);

}

 

请分析:这样多写两个花括号,是好还是不好?

 

(提示,Google 的代码规范在这一点上是正确的。为什么?)

 

 

2. 当我第二次到 Google 实习的时候,发现我一年前给他们写的代码,很多被调整了结构。几乎所有如下结构的代码:

 

if (condition) {

  return x;

} else {

  return y;

}

 

都被人改成了:

 

if (condition) {

  return x;

}

return y;

 

请问这里省略了一个“else”和两个花括号,会带来什么好处或者坏处?

 

(提示,改过之后的代码不如原来的好。为什么?)

 

 

3. 根据本文对于 ++ 操作的看法,再参考传统的图灵机的设计,你是否发现图灵机的设计存在类似的问题?你如何改造图灵机,使得它不再存在这种问题?

 

(提示,注意图灵机的“读写头”。)

 

 

4. 参考这个《Go 语言入门指南》,看看你是否能从中发现由于“片面追求短小”而产生的,别的语言里都没有的设计错误?

2013 / . 03 / . 08

郭昂:漫谈重构

因为工作内容的原因,我在前后两家公司中的工作中主持和经历了十余次代码和架构的重构,下面随便说说我对重构的一些经验和想法。

关于重构

首先重构面临的背景都是相似的,程序员们为了快速完成需求和上线而写出了最基本的代码,而在功能的不断扩充过程中,以打补丁的方式对代码进行扩充,中间还会面临着开发人员的变更和离职。逐渐的,代码就会越来越臃肿,渐渐的变得难以维护。

糟糕的架构会有什么样的影响?首先是开发效率的降低,在糟糕架构下加进新功能,会受之前代码的影响,可能存在意想不到的改动点和问题点,开发和调试时间都会大大增加;其次是故障率的提升,在质量低下的代码中,总是容易藏着很多不易发现的坑,这些都会成为故障的隐患;同时,架构也会使得需求的完成大打折扣,使得设计好的目标,因为架构限制或者性能等原因,只能完成80%甚至更低。

重构要解决的问题

重构不能凭空重构,一定是要解决一个问题,一般情况下重构要解决的问题大致有以下几种。

  • 结构糟糕。相信很多码农们,都遇到过接手别人的代码后都感到挠头的事情,五千行以上的文件,三千行以上的函数,面对这样子的代码,对其进行修改和继续开发是件很艰难的事情。
  • 安全隐患。很多代码,都只是为了功能上快速完成,而对很多潜在的安全风险置之不管,如内存管理、异常处理、模块接口等。有的雷如果不扫,可能迟早有一天会爆发。
  • 性能问题。对于很多大型服务,性能高一点可以节省很多的服务器费用。性能问题主要需要找到核心问题,有的问题出在架构,而大多出代码上。
  • 功能扩展。有的模块,开始设计时只是实现一些很基本的功能,而随着产品功能不断增强,被赋予了越来越复杂的功能,到了一定程度,需要进行重构以让其能够实现新赋予的任务。
  • 协同开发。很多时候,一个大系统往往需要多个人一起进行开发,如果需要这些人改同一个类甚至同一个函数,往往是冲突不断,而代码的整合往往也会存在更多问题。这时候需要很好的架构能够支持多人的共同开发和修改。
  • 模块调试。在一个大系统中,往往有很多子模块互相关联,而假如某个模块的调试需要启动整个大系统,或者会受到其他模块稳定性的影响,对于效率是非常低的。而重构建立调试层或者开发调试工具是更好的选择。
  • 模块复用。有些时候,多个系统或算法,可能会用到子算法和子模块,而不同项目或模块重复开发相同功能的子模块,在很多公司都很常见。而很多时候,将一些公共的部分抽象出来,能够将这部分做的更好更精,而从整体上,往往能大幅度提高开发效率和效果,往往也能优化算法性能。
  • 算法使用不当。在有些模块中,使用了不恰当的数据结构或者相关算法,使得或者是性能,或者是效果出现了问题。这种情况,甚至要将原有的体系结构推到重来,重新设计算法和数据结构,达到尽可能好的匹配效果。
  • 承载规模不够。对于一些系统,都有其设计的容纳规模,例如瞬间访问量、同时在线人数,很多公司从小到大都经历过这个过城,当超过一定量级时,很多时候并非简单通过加服务器能解决,有时需要重新设计架构。就像12306,因为架构问题使得很难承担过高的瞬时在线人数。

重构经验感受

重构时,第一道难关是如何过领导这道关。很多领导都要背着产品指标和任务,大多人也更关心其能够在多长时间做出什么,重构这种事情,在很多时候,有可能是“费力不讨好”的代名词,因为在大多情况,无法帮助领导完成指标。这种情况下,如何获得领导的支持就极其重要了。

对于重构,一种方法是,让重构与某些技术或产品指标挂钩,例如完成新产品、改进效果、提高性能等,相当于是重构伴随着其他改进搭帮上线,那么这种情况可以比较顺利的完成重构。

而如果单纯的为了架构的合理性而去重构的话,就需要去说服领导,为什么原来的架构会降低开发效率,新做的架构能带来哪方面的提升。一定要让领导明白,这个能带来实实在在的长期收益,不管性能、效率、安全等都可以,而并非只是“看着不爽”而进行的重构。

如果团队规模有一定的人的话,也可以分出一部分进行新型架构的开发,而另一部分人在现有架构上进行改进,使得短期目标和长期目标两不耽误。这时候,值得注意的就是,不管从代码还是设计角度上来看,都要让现有做的事情能够复用,而不是新架构上线之后就会被废掉。

如何进行渐进式重构,也是很多架构师需要去思考的问题。就是不搞一下子半年一年的重构,而是以月为单位,快速的迭代,能够很快的看到效果,并且小规模投入使用。

不管怎样,重构,一定不能是为了重构而重构,或者对前人的代码看着不爽,或者抱有技术完美主义而进行重构,最重要是找准其要解决的实际问题,这时候的重构,能带来的是开发效率上的提升。

而在重构的过程中,也需要做好新架构的设计,并且拥有一定的前瞻性,否则很容易出现新架构、新新架构、新新新架构这样子的事情。另外,也要尽可能的增强代码的复用性,让其中的模块,在任何一个架构中都能够很好的被应用,当然这个要根据具体情况具体分析。

对于重构,也尽量不要拥有技术完美主义。很多时候,使用最成熟的方案及最简单的架构模型实现所需要的功能一般来说更加“简单可依赖”,有的时候架构过于复杂反而喧宾夺主,因为所有架构都是为了功能服务的。同时,也尽量不要使用很多未经广泛使用的前沿技术,因为这些在开发和部署过程中,很多都可能会遇到意想不到的问题,延缓开发速度并影响线上效果。

此外,作为重构时的负责人,一定要紧跟代码开发的过程,并随时进行指导,一般情况下,不要相信写出糟糕代码的人,经过略加指导就能写出漂亮代码了。我曾经有过这样的经历,要将一个超大的类按照功能进行模块化拆分,设计好了架构及每个子模块就让组员进行开发。开发完了我看代码时登时就抓狂了,模块是拆分了,每个功能也都建立好了子类,并通过主类调用子类,但是每个子类又都将主类作为友元,又去调用主类里面的成员变量和函数。这种代码,再次重构也是难免的,这个给我的经验教训就是,重构的工作一定要做细,迭代中的代码检查也是必不可少的。

良好的习惯,从最初做起

当然,重构再怎么样,也是一种推翻重做,耽误时间的做法。从我的经验来看,其实大多数的重构都是可以避免的,这需要从以下几个方面去提高。

良好的编码风格,好的习惯往往很难是天然形成的,更多是在工作中不断的老带新中耳濡目染练出来的。很多领导希望员工全部时间都用来做项目,不断地去压更多的活,实际上是在用跑短跑的方式跑长跑,很容易出现后劲不足的情况。而我在微软的经历,也让自己感受到了从潮手到逐渐成熟的过程,后来在搜狗时即使再忙没法搞team review,我也会去尽量给每个组员检查他们的代码,帮助别人去提高。

初期的架构设计,这个也是非常重要的。架构设计能不能一次到位,这个不太好说。但是相信好的架构,一定比粗糙的设计能够坚持更长得多的时间。并且好架构可以考虑到未来可能扩充的规模和功能,为未来的发展留好接口。同时在其中所有的模块都非常有序,即使大的框架要修改的话,也只是搭一个架子,原有的子功能和子模块都能够被很好的复用,

其实很多时候,代码并非要开发一阵就重构一次,而写出好的架构,也并非是那么难。更重要的是,需要的是不断的提高程序员的自我修养,不仅仅是能力上的,还有态度上的。不要只想最初开发时省事,而不考虑若干时间后的事情。好的架构,对未来的开发以及发展,可以说是真真实实的“事半功倍”。

 

最后,我们看一个关于扁鹊的故事:

魏文王曾求教于名医扁鹊:“你们家兄弟三人,都精于医术,谁是医术最好的呢?”扁鹊:“大哥最好,二哥差些,我是三人中最差的一个。”  魏王不解地说:“请你介绍的详细些。”

扁鹊解释说:“大哥治病,是在病情发作之前,那时候病人自己还不觉得有病,但大哥就下药铲除了病根,使他的医术难以被人认可,所以没有名气,只是在我们家中被推崇备至。我的二哥治病,是在病初起之时,症状尚不十分明显,病人也没有觉得痛苦,二哥就能药到病除,使乡里人都认为二哥只是治小病很灵。我治病,都是在病情十分严重之时,病人痛苦万分,病人家属心急如焚。此时,他们看到我在经脉上穿刺,用针放血,或在患处敷以毒药以毒攻毒,或动大手术直指病灶,使重病人病情得到缓解或很快治愈,所以我名闻天下。”        

扁鹊实际上就是一个很好的重构高手,但是扁鹊的大哥,就是因为能够将问题看在前面,处理在前面,所以能够永葆健康,这更是高手中的高手!

+
X