中國第一軟件開發_我第一次開發企業軟件中學到的知識

中國第一軟件開發

In this article, I’ll share ten lessons I learned from my first project as a self-taught software developer. I was working for a consulting company at the time, and my official title was Software Engineer. The project I worked on was a web application for the public sector.

在本文中，我將分享作為一個自學成才的軟件開發人員從我的第一個項目中學到的十個教訓。當時我在一家咨詢公司工作，我的正式頭銜是軟件工程師。我從事的項目是公共部門的Web應用程序。

第1課：盡快學習架構 (Lesson 1: learn the architecture as soon as possible)

In the beginning, the most challenging part was getting used to the amount of code that was written. There must have been at least a million lines of code by the time I started! This became so much easier after learning about the architecture that we were using. I remember being confused about this at the time.

剛開始時，最具挑戰性的部分是習慣了所編寫的代碼量。到我開始時，至少必須有一百萬行代碼！在了解了我們所使用的體系結構之后，這變得非常容易。我記得當時對此感到困惑。

It wasn’t until I did a crash course on layered architecture, offered by the company, that I really understood how to navigate through the code base. I got a very brief overview when I started, but I wish I had a better understanding sooner than I did.

直到我完成了公司提供的有關分層體系結構的速成課程后，我才真正了解如何在代碼庫中導航。我剛開始時獲得了非常簡短的概述，但是我希望我能比以前更快地了解。

第2課：不要在架構上走捷徑 (Lesson 2: don’t take shortcuts with the architecture)

Half way through my time on the project, we added a lot of new functionality. We were able to do some of this with newer technology. As I still didn’t really understand the value of the architecture we were using, I decided to take shortcuts. This ended up costing time and resources when we had to go back and fix it.

在我完成項目的過程中，我們添加了許多新功能。我們能夠使用較新的技術來做到這一點。由于我仍然不太真正了解我們所使用的體系結構的價值，因此我決定采用捷徑。當我們不得不回去修復它時，這浪費了時間和資源。

第三課：不要低估業務環境的價值 (Lesson 3: do not underestimate the value of the business context)

An important part of the project is learning the business requirements. I completely underestimated the importance of this for the whole duration of the project. This was an expensive mistake. If you don’t understand the business context of your work, it is very easy to go down the wrong path.

該項目的重要部分是學習業務需求。我完全低估了這個在整個項目過程中的重要性。這是一個代價高昂的錯誤。如果您不了解工作的業務背景，那么走錯路很容易。

教訓4：不要低估自學的價值 (Lesson 4: do not underestimate the value of being self-taught)

This project allowed me to gain a lot of confidence in my abilities as a developer. I strongly believe that, if you have the right tools, you can become an expert in anything.

這個項目使我對自己作為開發人員的能力充滿了信心。我堅信，如果您擁有正確的工具，則可以成為任何事物的專家。

While I’m not claiming to be an expert, my self-taught learning material was more than enough to prepare me for this project. Keep in mind — the list was much shorter back when I started! This revelation inspired me to write Was studying worth it?

雖然我并沒有聲稱自己是專家，但我自學的學習材料足以讓我為這個項目做準備。請記住-當我開始時，列表要短得多！這個啟示啟發了我寫這篇文章值得學習嗎？

第5課：編寫快速的測試，并刪除過時的測試 (Lesson 5: write tests that are fast, and delete those that become obsolete)

Our project consisted of many tests. We had an autonomous test suite that ran unit tests, persistence tests, and integration tests. The unit tests took a few minutes to run, but all of them together took a whole hour! I realized that quick tests are best, and there’s no point in hanging on to old tests that are obsolete.

我們的項目包括許多測試。我們有一個自治的測試套件，可以運行單元測試，持久性測試和集成測試。單元測試需要花費幾分鐘的時間，但是所有這些一起花費了一個小時！我意識到快速測試是最好的，并且沒有必要繼續使用過時的舊測試。

第六課：提防少做的后果 (Lesson 6: be wary of the consequences of committing less often)

We were using Subversion for our version control. Unfortunately, the code we were committing was automatically checked in to the repository. We very rarely worked with branches, as the opportunity cost seemed to be too high. This led to committing code less often. I still tried to commit frequently, but I would sometimes break the build — I didn’t think I needed to invest the hour running the tests locally.

我們使用Subversion進行版本控制。不幸的是，我們提交的代碼已自動簽入存儲庫。我們很少與分支機構合作，因為機會成本似乎太高了。這導致提交代碼的頻率降低。我仍然嘗試頻繁提交，但有時會中斷構建-我認為我不需要花費時間在本地運行測試。

第7課：編寫可靠的測試-不要忘記維護它們 (Lessons 7: write reliable tests — and don’t forget to maintain them)

On top of that, some tests were not always green. They would work sometimes, but they would fail just as often. This would cause the build to be red. As a result, I didn’t really appreciate the value of a red build. Sometimes the build would be red for days because someone didn’t notice that another test had been broken.

最重要的是，某些測試并不總是綠色的。它們有時會起作用，但它們也會經常失敗。這將導致構建為紅色。結果，我并不真正欣賞紅色版本的價值。有時，由于有人沒有注意到另一個測試已被破壞，所以構建會持續幾天的時間是紅色的。

第8課：盡快檢查代碼 (Lesson 8: review the code as soon as possible)

Typically, we would have one developer writing the code and another developer reviewing the code. I had opportunities to do both. Often, I would get a feature to develop. Before finishing it, I would be given something to review. It might take days before I got around to reviewing.

通常，我們會讓一名開發人員編寫代碼，而讓另一名開發人員查看代碼。我有機會做這兩個。通常，我會開發一個功能。在完成之前，我將得到一些回顧。我可能需要幾天才能進行審核。

This often caused headaches, because the code I was reviewing was not the same as the code that had been developed. Pair programming would have avoided this problem, but that was not the way we worked.

這經常引起頭痛，因為我正在查看的代碼與開發的代碼不同。結對編程可以避免這個問題，但是那不是我們的工作方式。

第9課：重構應伴隨測試 (Lesson 9: refactoring should be accompanied by tests)

Tests were only introduced five years into the project’s lifespan. Before that, all the testing was done manually. This meant that a lot of the code base didn’t have any test coverage, which is dangerous.

測試僅在項目壽命的五年內進行。在此之前，所有測試都是手動完成的。這意味著很多代碼庫沒有任何測試范圍，這很危險。

Personally, I really like the idea of applying the boy scout rule to code. I naturally tended to refactor a lot. But as we didn’t have test coverage for everything that I refactored, I would sometimes introduce defects into our software.

就個人而言，我真的很喜歡將童子軍規則應用于代碼的想法。我自然傾向于重構很多。但是由于我們沒有對重構的所有內容進行測試，因此有時會在軟件中引入缺陷。

第10課：開發軟件是業務價值和卓越軟件之間的折衷方案 (Lesson 10: developing software is a compromise between business value and software excellence)

We used a V-model for the software development process. This included deadlines for developing, manually testing, and releasing the software. We didn’t have unlimited time to develop or review the code we were writing. In some cases, I would spend too much time perfecting the code, which wouldn’t always deliver business value.

我們在軟件開發過程中使用了V模型。這包括開發，手動測試和發布軟件的截止日期。我們沒有無限的時間來開發或審查我們正在編寫的代碼。在某些情況下，我會花太多時間來完善代碼，而這并不總是能帶來業務價值。

最后的想法 (Final thoughts)

This project was a very valuable learning experience for me. I hope you were also able to learn something from it. Let me know in the comments below if you had any similar or contrasting experiences!

這個項目對我來說是非常寶貴的學習經驗。希望您也能從中學到一些東西。如果您有任何相似或對比的經歷，請在下面的評論中告訴我！

Before you go… Thanks for reading the article! I write about my professional and educational experiences as a self-taught software developer, so check out my blog or subscribe to my newsletter for more content.

開始之前……感謝您閱讀本文！我寫的是自學成才的軟件開發人員的專業和教育經歷，因此請查看我的博客或訂閱新聞通訊以獲取更多內容。

You might also like:

您可能還喜歡：

Learning material — software development (my learning path starting with Intro to Computer Science)
學習資料-軟件開發 (我的學習路徑從計算機科學概論開始)
Testing Apollo Server with Typescript
使用Typescript測試Apollo服務器
Was studying worth it?
學習值得嗎？