Java:学习一个你有很少经验或没有经验的项目有哪些步骤

发布于 2024-07-30 00:40:09 字数 309 浏览 4 评论 0原文

作为一个缺乏行业经验的新手程序员,我发现学习一个基于许多我不熟悉的技术的新项目是令人沮丧的。 我正在从事的项目有大约 150 个类和 15000 行代码,并且广泛关注套接字和安全编程,而我在这方面的经验为零,我不知道应该从哪里开始。

由于手头上的文档和帮助有限,自学是我尝试从整体上理解这个项目的最佳资源。 我经常发现自己花了太多时间学习产品的无关紧要的功能,而错过了我真正应该关注的关键类...花费这么多时间的主要原因是我经常不得不研究 Java API每隔几分钟参考一次以理解一个小代码块...我确信我最终会通过反复试验来学习它,但我确信我可以使用一些有用的建议和指南:)

As a starting programmer with little industry-experience, I find it frustrating to learn a new project which is based on many technologies that I am not familiar with. The project I am working on has about 150 classes with 15000 lines of code, and with its extensive focus on socket and security programming which I have zero experience in, I am not sure where I should start.

With limited documentation and help at hands, self-study is my best resource in trying to understand this project as a whole. I often find myself spending way too much time learning insignificant features of the product while missing out the crucial classes that I should really be focusing on... The main reason why it takes so much time is that I often have to look into Java API reference every few minutes to understand a small code block... I am sure I will eventually learn it through trial-and-error, but I am sure that there are some useful advices and guidelines I can use :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

春庭雪 2024-08-06 00:40:09

最初,您不需要理解每一行代码。

借用一位高级开发人员半个小时的时间,让他给你一个架构的鸟瞰图——主要的代码块是什么,它们如何交互,以及用户/使用情况如何通过系统驱动数据。

然后花一些时间调查您认为的模块的来源(在解释之后)将使您最好地了解“这一切是如何工作的”。

我有一个(可能很奇怪)的习惯,打印大块源代码,并用打印输出覆盖地板。 然后我可以跪下来,用笔在地板上爬来爬去,逐点绘制箭头,并绘制各个部分 - 我发现以 2D 显示代码可以更轻松地弄清楚事情。 它还可以做大量的笔记,帮助我更详细地理解流程。

不久之后,您将开始识别表征代码的惯用语(做事的风格化方式),并最终您将找到进入作者思维方式的方法。
那么一切就会简单很多。

当你在地板上爬来爬去时,手边有一台笔记本电脑+谷歌,这样你就可以破译你遇到的任何奇怪的事情。 另外:彩色荧光笔 FTW。

(至少)两次了解来源。
第一次不要试图理解任何细节......尝试去感受“运动”——数据去往何处,以及执行去往何处。 这将为您提供代码思维模型的框架。 当你下次浏览时,你可以开始分解细节,但自上而下的方法总是让事情对我来说更容易。

如果你对技术、语言或环境不熟悉,那么一定要看看周围有没有可以借用的书籍。 现实世界中的可见空间比计算机屏幕上所能容纳的要多得多,笔记本电脑上的谷歌、书中的语法/库参考以及你周围的代码(至少对我来说)构成了整个过程简单得多。

Initially, you don't need to understand every line of code.

Borrow a senior developer for a half-hour and ask him to give you the birds-eye view of the architecture - what the major blocks of code are, how they interact, and how the user / usage drives data through the system.

Then spend some time investigating the source for the modules you feel (after the explanation) will give you the best insight into "how it all works".

I have a (probably quite odd) habit of printing out large blocks of sourcecode, and covering a floor with the printouts. Then I can kneel down and crawl around on the floor with a pen and literally draw arrows from point to point, and draw around sections - I find that displaying code in 2D makes it easier to figure things out. It also enables making copious notes that help me understand the flow in more detail.

Before long, you'll start to recognise idioms (stylised ways of doing things) that characterise the code, and eventually you'll find your way into the mindset of the authors.
Then everything will be a lot simpler.

While you're on the floor, crawling around, have a laptop+google handy, so you can decipher anything odd you encounter. Also: Coloured highlighter pens FTW.

Make (at least) two passes at understanding the source.
The first time don't try to understand any of the minutiae... try to get a feel for "movement" - where data goes, and where execution goes. That will give you a framework for your mental model of the code. When you go through next time, you can start to break down details, but a top-down approach always makes things easier for me.

If you're not familiar with the technologies, language or environment, then do see if there are any books around you can grab. There's a lot more visible space in the real world than you can fit on a computer screen, and having google on a laptop, syntax/library references in a book, and the code all around you makes (for me at least) the whole process VASTLY simpler.

甜心 2024-08-06 00:40:09

我想到了一些事情:

  1. 花一点时间熟悉 JDK 及其标准类。 掌握这些知识需要花费时间,并且需要更多地检查 API 规范,但您也可以花一些时间只是浏览,而不需要查找您要查找的特定内容。
  2. 如果您的项目正在使用某些框架或库,您通常可以通过阅读项目站点上的“介绍”页面来获得这些框架或库给项目带来的高级视图。 我认为这可能对您特别有帮助,因为您表示对项目中使用的某些技术的不熟悉是沮丧的根源。
  3. 如果有任何功能集成或回归测试,这些通常是了解项目主要入口点的好方法。 当试图理解小细节时,很好地掌握项目的高级功能通常很有帮助。
  4. 如果您能在团队中找到一位导师来指导您,这可能会有很大帮助。

我认为,根据您提到的项目的规模,这可以是对您生产代码的温和介绍。 现在看起来可能很大,但 15000 行代码对于您在职业生涯中最终可能从事的项目来说只是较小的一部分。

还要记住,这对您来说必然是一次学习经历。 这是您在该行业的第一个项目之一,因此可能需要一段时间才能适应。 请记住,您并不是第一个在不熟悉的代码库中在库/框架汤中游泳的人。

祝你好运!

A few things come to mind:

  1. Spend a little time getting familiar with the JDK and its standard classes. Having knowledge off the top of your head will take time and a lot more checking the API spec, but you can also spend some time just browsing without a particular thing you're looking up.
  2. If your project is using some frameworks or libraries, you can often get a high-level view of what these bring to the project by reading the "intro" page on the project site. I think this might be of particular help to you, since you cited unfamiliarity with some of the technologies used in the project as a source of frustration.
  3. If there are any functional integration or regression tests, these can often be a good way to get a handle on what the main entry points into the project are. Having a good grasp of the high-level functionality of a project is often helpful when trying to understand the little details.
  4. If you can find a mentor on your team to show you the ropes, that will probably help a lot.

I think, based on the size of the project you mentioned, that this can be a gentle introduction to production code for you. It might seem big now, but 15000 lines of code is on the smaller side of the projects you might eventually work on during the course of your career.

Remember also that this is necessarily going to be a learning experience for you. It's one of your first projects in the industry, so it might take a little while to get used to things. Keep in mind that you're not the first person to have to swim in library / framework soup in an unfamiliar code base.

Good luck!

站稳脚跟 2024-08-06 00:40:09

学习代码库需要时间。 我认为新开发人员熟悉代码库的一般规则是 3 个月左右。

唯一真正对我有帮助的是进行实验,看看会发生什么,并熟悉 API。

Learning a code base takes time. I think the general rule is about 3 months for a new developer to be familiar with a code base.

The only things that really help me are to experiment and see what happens, and get familiar with the API.

人间不值得 2024-08-06 00:40:09

结对编程。 与有相关经验的人一起编写代码。 帮助他或她; 让他或她帮助你。 当您处理经验丰富的开发人员的代码时,您将了解代码的一些重要方面 - 因为经验丰富的开发人员知道它们。 您将开发出一种与经验丰富的开发人员相当接近的软件思维模型,而不是追逐自己的死胡同和老鼠洞。 一对。

Pair Programming. Work on the code with someone who has experience with it. Help him or her; have him or her help you. As you work on the more experienced developer's code, you will learn some of what the important aspects of the code are - because the experienced developer knows them. You'll develop a mental model of the software that is reasonably close to the experienced developer instead of chasing down dead-ends and ratholes of your own. Pair.

浅紫色的梦幻 2024-08-06 00:40:09

如果您有测试,请研究它们。 如果没有,那就写一些。

if you have tests, study them. if not, then write some.

爱殇璃 2024-08-06 00:40:09

我建议打印出我的老师过去所说的“类图”,其中只有类名、方法名称和成员名称。 然后将表格放在桌子/墙上,找出哪个类与哪个类通信,哪个方法与哪个方法通信等等。在类/方法之间建立箭头和连接。 尝试感受一下代码。
一开始,理解一行代码的作用并不重要,重要的是方法/类应该做什么,以便您了解基本的数据流。

I suggest printing out what my teachers used to refer to as "class diagrams" that just have the Classname, method names and member names. Then arrange the sheets on a table/wall and find out which Class talks to which Class, which Method talks to which Method etc. Make arrows and connections between the classes/methods. Try getting a feeling for the code.
In the beginning it's not important to understand what a line of code does, but what a method/class is supposed to do so that you understand the basic data flow.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文