Как Ваша организация обрабатывает общие компоненты?
Вы можете просто проверить size из Set перед циклом.
public void getNumber(String person) {
if (this.phonebook.get(person)
.size() > 1) {
System.out.println("numbers :");
}
for (final String n : this.phonebook.get(person)) {
System.out.println(n);
}
}
6 ответов
What you have here may be a human factors problem rather than a technical one. In fact it may be primarly a learning issue (coupled with the typical not invented here syndrom).
Having worked in large companies, I realise that it is tough for a new person to understand all the resources (i.e. shared code libraries) available to him, much less how and when to properly use them.
When you have a new hire, is he/she given formal training in your common component library?
Then there is the problem of what people are rewarded for. At review time do managers reward people for using the common components, improving them and submitting improvments back to the library? Or do managers simply care about their own projects.
As for your group that maintains the common library, what form or reconginition do they give to people who take the time to suggest or submit improvements? Do they get written up in the company newsletter? Get a cash bonus? Get their photo on the bulliten board?
Remember, people are highly unlikely to do something for a company for which they receive no recognition or reward.
Мы пытаемся перейти к большему количеству систем на основе сервисов, чтобы, если мы создадим определенную функциональность для одного проекта, ее можно было использовать из другого проекта через веб-сервис. Таким образом, есть только один экземпляр кода.
Естественно, это работает лучше для некоторых типов компонентов (пример: мы недавно создали службу создания PDF), чем для других (вероятно, излишне для утилиты манипуляции со строками).
Единственный успешный компонент, который я видел здесь, - это перераспределение в скомпилированной версии (* .dll). Пользователи сообщают об ошибках и запрашивают функции непосредственно у команды-владельца и сами их внедряют. Существует API для написания собственных плагинов для вещей, которые наиболее вероятно изменятся, поэтому люди могут расширять функциональность во многих случаях.
Всегда есть компромисс с
- , чтобы убедить людей использовать ваш компонент
- поддерживать приемлемый уровень качества в то же время
Не уверен, что лучше всего делать в вашем случае, но в целом постарайтесь реализовать основную логику самостоятельно, сохраняйте компонент настраиваемым / расширяемым, чтобы люди не Нужно все время менять ядро и предлагать хорошую поддержку. По некоторым причинам некоторые разработчики всегда имеют тенденцию изобретать велосипед, каким бы глупым он ни был, поэтому я бы не стал
Treat them the same way you would third-party libraries. I wouldn't even let the other teams see the source - doing so can lead to a lot of time-wasting criticism and back-biting.
Хорошим способом является периодические проверки кода. Во время этих действий, если вы обнаружите, что колесо изобретено заново, вы можете использовать эту возможность, чтобы либо научить разработчиков использовать общий компонент, либо почему они почувствовали необходимость переизобрать его и объединить свои доводы с исходным кодом. Таким образом, создаются все требования, а компоненты улучшаются для всех.
How big is the organisation? I've seen this stuff handled very well in a small organisation (a few dozen programmers total) where one or two individuals are known to have ownership of each component, and are responsive to feature requests.
It's easier to march off to someone's office (or mail them), explain what you need, and get one of:
- the expected way to do what you want,
- agreement to add the required feature (or direct a minion to do so),
- permission to implement the required feature in the common component,
Than it is just to launch into writing workarounds, starting a fork, or writing an equivalent new component. If your programmers are smart, they'll do what they think is easiest. The trick is to ensure that this is the right thing.
Aside from really simple stuff like linked lists, there wasn't a whole lot of wheel-reinvention going on. There were, very rarely, private forks for particular products, most commonly to reduce code size by chopping things out. But the usual way to do that was to modify the original component to have more build options.