让我们讨论一下编辑部的联合项目--为什么以及它们的发展方向 - 页 6

新评论
 
Alexey Volchanskiy:

我今天对某人进行了MQL5的培训，他在没有我的帮助下从头开始创建了一个项目。 这真的非常简单，人们担心的是什么呢...他们以前一定没有处理过项目。

在仓库开始正常工作之前，我曾遇到一些错误，我一直不明白我的错误在哪里。

现在，比方说，我想弄清楚是把我的整个图书馆分成独立的项目，还是把所有东西都变成一个。如果我把它分成独立的--那么，从理论上讲，对库的各个部分的访问是简化的，但同时，一些文件同时落入几个项目--我可以这样做吗？

 
Ilnur Khasanov:
真的不能和编辑联系，现在有了团队项目，会不会有任务跟踪器？在团队组织、任务设置、代码审查方面会有什么？
不，我们不打算这样做。
 
George Merts:

不，我只是在 "吹水"--我总是在仓库里遇到一些问题，直到它开始正常工作，我一直不明白我的错误是什么。

现在，比方说，我想弄清楚是把我的整个图书馆分成独立的项目，还是把所有东西都变成一个。如果你把它分成独立的--那么，从理论上讲，对库中各个部分的访问是有序的，但它最终会使一些文件同时出现在几个项目中--我可以这样做吗？

如果你只为自己做，库应该被移到MQL5目录内的一个单独的项目 中，并进行工作。

如果你想要联合项目，就做一个单独的库项目和单独的工作项目。从工作项目中，通过相对路径引用邻近的库项目。

 
Renat Fatkhullin:

你能在测试器上创建一个类似的主题吗？

 
与经典作品相比，正在讨论的个别开发商的服务有什么优势？
 
Alexey Volchanskiy:

)))))))))))))) 那是一个幽默的笑话吗？让我们在元编辑器中制作一个bugzilla)。

嗯，不是bugzilla - 有很多解决方案。同样是visual studio的工具，tfs被专门集成到编辑器中。
好吧，想象一下你是项目 的指挥官，你有几个参与者给你发送项目的代码。你会如何看待他们的代码，做出评论，等等？你将如何为每个团队成员设定具体任务？你将如何跟踪谁添加了什么，什么时候添加的？
这其实不是一个问题--有很多外部服务。
 
fxsaber:
与经典作品相比，正在讨论的个别开发商的服务有什么优势？

double advantage = 0.00; // for face-to-face progger ))))
 
fxsaber:
与经典之作相比，所讨论的服务对个人开发者来说有哪些优势？

1）将创建复杂的方案并方便地管理它们。再也不用为一个文件而烦恼了。

2）他们将学习如何使用版本控制系统。他们中的大多数人以前从未使用过这些东西。

3）他们将学会在联合项目 中工作。

4）在appstore中准备和发布产品，以及为kodobase编码将更加容易。

5）作为一个自由职业者，当客户不仅可以监督进度，还可以参与开发过程时，工作会更容易。

6) 公共项目是展示他们作为作者和其他项目的贡献者/贡献者技能的另一个地方

7) 提高他们的编程技能：版本控制+1，小组工作+1


这是在表面上的东西。

 
Ilnur Khasanov:
嗯，不是bugzilla - 有很多解决方案。同样是visual studio的工具，tfs被专门集成到编辑器中。
好吧，想象一下你是项目的指挥官，你正在被一个项目的几个贡献者发送代码。你会如何看待他们的代码，做出评论，等等？你将如何为每个团队成员设定具体任务？你将如何跟踪谁添加了什么，什么时候添加的？
这其实不是一个问题--有很多外部服务。

我是在开玩笑。

MQ不会将资源浪费在0.1%的用户需要的废话上。

 
Renat Fatkhullin:

1）将能够创建复杂的程序并方便地管理它们。再也不用为一个文件而烦恼了。

2）他们将学习如何使用版本控制系统。大多数人从来没有使用过它们。

3）他们将学会在联合项目中工作。

4）在appstore准备和发布产品以及代码库的代码会更容易。

5）作为一个自由职业者，当客户不仅可以跟踪进度，而且可以参与开发时，工作会更容易。

6) 公共项目是展示你作为作者和其他项目的贡献者/贡献者的技能的又一个地方。

7) 提高他们的编程技能：版本控制+1，小组工作+1


这是在表面上的东西。


4-6 你能详细说明一下吗？我是否能够在没有目前的繁文缛节的情况下扔进KB？

12345678910111213...16
新评论