開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《只狼 Sekiro》
今日推薦英文原文:《What It』s Like to Write Software on a Team》
開源日報第641期:《只狼 Sekiro》
今日推薦開源項目:《只狼 Sekiro》傳送門:GitHub鏈接
推薦理由:年度遊戲不出所料的落到了只狼手上,那麼這個時候自然也要趁著熱鬧入坑……然後看著屏幕中間那個大大的死字。這個項目列出了玩只狼的備忘清單,大概把流程里需要注意的道具等都列了出來用於備忘,對於收集要素不少而且能夠提升實力的遊戲來說掃一眼備忘自然是好事,但是有一說一,不死個幾十次該打不過的還是打不過……
開源日報第641期:《只狼 Sekiro》
今日推薦英文原文:《What It』s Like to Write Software on a Team》作者:Obaid Farooqui
原文鏈接:https://medium.com/@obaidfarooqui/what-its-like-to-write-software-on-a-team-ccb6a70a1eaa
推薦理由:寫軟體和寫小說

What It』s Like to Write Software on a Team

Imagine you are on a team tasked with writing a novel.

At first you all huddle together and figure out what it』s about. Who is the intended audience? What will readers take away from the book? You hash out the arc of the story, the characters, how they』ll interact with each other to drive the plot forward.

Your team starts to storyboard, passionately debating each other as you bring this story to life on the whiteboard. You squiggle, you erase, you draw diagrams and write a few paragraphs here and there to show that this story can work. You align on a vision of what this novel will be.

And then, the real work starts. You open up a shared Google Doc, and each person takes a chapter, or a portion of a chapter, and starts writing, at the same time. Some people take on characters instead of chapters; others focus on a specific event in the story, perhaps the climax or a scene of rising action. This is fine- it takes some planning, but you can write your part as your teammates write theirs, as long as you all know what everyone is working on and how your part interfaces with everyone else』s.

Sometimes someone has a brilliant idea to change how their part reads: maybe they want to end their chapter on a cliffhanger, or engage in a little foreshadowing. What they do in their section affects the sections before and after as well, and so they must communicate to ensure the novel flows logically.

Then there』s the question of voice. You want the novel to read smoothly and consistently, and not vary wildly from chapter to chapter. Not only does this make it pleasant for the reader, it also makes it easier for someone to come in and make edits in the future. So teams must agree on what that voice is, and must edit each other』s work to iron out the differences in style. This means agreeing on mundane things like whether to use oxford commas, as well as on more subjective things like how funny or formal you want the characters to sound.

Now let』s throw in some illustrators and designers into the mix too. They』ll play with fonts and sizes and colors, as the Google Doc continually unfolds. They』ll design a book jacket, and maybe add some drawings or graphs or photos. Ideally, they make their designs bespoke for what you』ve written and it』s exactly what your team wants. But sometimes they may draw something that doesn』t fit the tone you』re setting, or illustrate a scene that has changed given the latest edits. You need to work with them to modify those artifacts, as your team continues to write this book.

Sometimes people from outside of your team will want to have a say in what you write. Marketing might come to you and tell you that your novel needs a vampire to be commercially viable with teenagers. Sometimes legal wants you to take something out- maybe you can』t call your villain Vuelo de Muerte because it』s too close to someone Who Must Not Be Named. You have to negotiate how you write those things in, and sometimes you』ll win your battles but other times you just have to throw in a werewolf because the folks upstairs want one. All this while the Google Doc is continually evolving.

Writing a sizable novel in this manner will take some time, and as a result, maybe the team grows or churns as well. The original storyboarding must be clear and instructive enough, and the writing in the Google Doc must be consistent and cohesive enough, that a new person can walk onto the team, spend some time familiarizing themselves with the story, and begin editing and writing where someone else left off, without any noticeable difference to anyone reading.

Finally, at the end of all of this, your team produces this book. It is a work of art. You know how much effort went into it, and you are more astounded than anyone that it is a cohesive, comprehensible, dare you say enjoyable piece of literature.

And that, in a nutshell, is what it』s like to write software on a team.
下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/