07 Jul 2016

База знаний: а стоит ли?

Небольшое вступление

Мир IT - это постоянно движущаяся и развивающаяся структура, все финты и пируэты которой угадать довольно сложно. Технологии и спрос на них меняются не просто во времени, а от команды к команде внутри компании. Из-за этого новичку, да и даже матерому проггеру, порой бывает сложно ориентироваться в происходящем.

Однако основная проблема, на мой взгляд, в том, что в процессе разработки могут возникать проблемы, специфичные для данной конкретной области. О них вряд ли напишут на общедоступных форумах, а если и напишут, то кратко и в такой формулировке, что загуглить это будет непросто выведено опытным путем. Конечно, человеку, который знает область и все технологии проекта будет попроще при возникновении проблемы, а вот новичкам (не только джуниорам, но и просто людям, которые только-только пришли на проект) придется туго. На самостоятельный разбор уйдет довольно много времени, что не желательно, особенно при работе с проектами, требующими от веток отдельных задач быстрого слияния с “боевой” веткой.

Логичный выход - спросить у коллег. Но и это не всегда помогает, и вот три основные причины тому:
1. Высокая загруженность. У команды просто нет времени втаскивать новенького в команду, а потому он обречен болтаться где-то в хвосте, часто исполняя функции “сделай вот эту кнопочку зеленой, а не синей”.
2. “Новая” проблема. Есть такие вещи, которые могут не вылезти и за год разработки. Хотя бы потому, что этот конкретный кусочек не разрабатывался, потребность в нем появилась только сейчас. В таком случае коллеги и не буду способны помочь, так как сами видят такое чудо в первый раз.
3. Человеческий фактор. Новичок в силу особенностей характера может постесняться спросить о чем-либо, может быть, боясь показаться глупым, или навязчивым, или что-то в этом духе.

Соответственно, хотелось бы иметь некий механизм помощи, с которым было бы удобно работать и новичкам, и опытным IT-шникам.

Внутренняя база знаний: кратко о

По сути, база знаний (далее БЗ) - это что-то вроде Википедии, смешанной со StackOwerflow и Habr’ом. В ней аккумулируются внезапно знания о технологиях, используемых на проекте. При этом, это не только полезные статьи о том, как использовать фреймворк или API, это и заметочки о том, как установить нужное ПО, как устранить неочевидные ошибки и т. д., и т. п. Все это оформляется, как правило, в виде web-приложения (можно и настольное сделать, в целом), подключенному к той или иной БД. Туда же можно (и нужно) прикрутить форум, как для простого общения, так и для того, чтобы дать возможность задать вопрос, если нужной статьи в базе пока нет.

Штука хорошая, полезная, но стоит ли игра свеч?

Мысли за

В любой команде разработчиков такие мысли высказывались, я думаю. Приведу пункты, которые мне кажутся наиболее существенными.

Уже третья страница Google…

Существуют довольно специфичные области, разработка в которых ограничена узким кругом лиц (возможно, ваша команда - единственная). Следовательно, найти что-то по теме крайне затруднительно и требует умелой работы с поисковыми системами, что не каждому дано. БЗ же содержит только ту информацию, которая нужна, представлена в понятном Вам виде, а значит, времени на поиск, обработку и усвоение уйдет гораздо меньше.

Вливайся!

Как уже говорилось ранее, новому человеку в коллективе зачастую трудно адаптироваться. Новая область знаний, новые технологии, своя специфика каждой строки кода - поток информации бывает трудно просеять. Конечно же, можно почитать документацию, но где гарантии, что она есть, а если и есть, то хорошо ли написана? Поспрашивать у коллег - это уже освещалось ранее.

Если же существует БЗ, то процесс адаптации в проекте проходит гораздо быстрее. Здесь можно почитать статьи, комментарии к ним, форум, и почерпнуть много всего полезного.

О, у тебя тоже!

Нужно отметить, что порой в проект нужно подключить новую библиотеку или новый модуль. И как всем известно, такое подключение не всегда можно пройти гладко: конфликт версий или с уже существующими модулями, ошибки в самом модуле, некорректная работа с ним и проч. Пытаться решить проблему самому - опять же затратно по времени, значит, думать нужно командой. Предположим, решение найдено. И что с этим делать? Алгоритм может быть путанным, сложным и совершенно не очевидным, понятно, что держать его все время в голове не очень хочется, да вряд ли и не получится. Хочется, все же, где-то это надо записать, чтобы не забыть, а в случае надобности - быстро найти.

БЗ предоставляет такую возможность. Достаточно просто открыть формочку для создания статьи или темы на форуме и поместить туда всю информацию о решении возникшей проблемы. Ура, теперь это никуда не потеряется и всегда будет на расстоянии пары кликов!

Мысли против

Все это, конечно, хорошо, но что-то уж больно ориентировано на сознательного пользователя, да и вообще на человека. А как же все остальное?

А кто работать будет?

Какой бы хорошей идеей не была БЗ, а ее нужно спроектировать. Мало того, что нужно сделать интерфейс и модуль поиска, так еще и структуру БД надо создать. Этим всем должен кто-то заниматься. Можно выделить пару-тройку добровольцев, которые за это засядут, но есть же еще и основной проект. Лезть в overtime? Не хочется как-то ночевать в офисе. Создавать отдельную команду, ответственную за реализацию? Нужно оборудовать рабочие места и выделить деньги за зарплату.

В целом, БЗ несомненно является затратным проектом, требующим упорной работы, времени и денег. С этой точки зрения все упирается в ресурсы, которых у компании может просто не быть.

Нужно больше жести

Исходники, данные, интерпретатор, дополнительное ПО для БД - все это требует места. Всеми правдами и неправдами упихивать это на уже имеющиеся носители - не вариант, там лежат данные основного проекта. Выход есть - закупить еще жестких. Хорошо, а куда же девать бекап? Еще жестких!

Поскольку БЗ подразумевает наполнение, ее исходный, пусть даже небольшой, объем будет неуклонно расти. Будут появляться новые модули, фичи, статьи, темы и сообщения форума, данные о пользователях и проч., и хранить это где-то надо.

Сервер? Какой сервер?

Приложение должно где-то крутиться. Даже если оно настольное, таскать БД на каждую машину не хочется. Значит, надо выделять сервер. Можно подпихнуть его на основные сервера компании, но где гарантия, что все не рухнет от перегрузки? Можно купить дополнительный сервер и развернуть приложение на нем, но сервера-то нынче не дешевые.

БЗ является довольно мощной системой, которой нужны вычислительные ресурсы и оперативная память. Ресурсы, ресурсы и опять ресурсы.

Советы тем, кто решился

Если вы коллективно взвесили за и против и решили сделать у себя БЗ, вот несколько рекомендаций.

  1. Подумайте о БД. Если вы предполагаете, что проблем на проекте будет мало и возникать они будут редко, не нужно создавать монстра, безжалостно поедающего ресурсы ЦПУ и ОЗУ. Подойдите к вопросу рационально, возможно, хватит обычных текстовых файлов, которые будут подгружаться на страницу.

  2. Распределите обязанности оптимально. Не всем в команде нужно бросаться за претворение желаний в жизнь. Подумайте, кому лучше остаться на основных проектах, а кому пойти на БЗ. При этом не стоит сваливать все на одного человека, хорошенько обдумайте и спланируйте распределение обязанностей.

  3. Заранее обдумайте поддержку. БЗ, как и любая система, требует хотя бы минимальной поддержки. Вам придется следить за ее работой, наполнением, возможно, придется что-то дописывать. Лучше всего будет по окончании разработки выделить одного-двух человек, которые будут ухаживать за вашим детищем.

  4. Не запихивайте в БЗ все, что попало. Тщательно фильтруйте информацию, которая будет попадать в БЗ. Решение проблемы “NullPointer на неинициализированной переменной” - это не то, что там должно находиться. Помещайте туда только то, что действительно представляет интерес.

Итоги

Подводя черту под всем выше сказанным, нужно отметить, что БЗ - это полезно и нужно, особенно на больших проектах, когда времени на внезапно появившуюся проблему нет. С другой стороны, ее разработка является весьма трудоемкой, как и дальнейшая поддержка.

Если вы решили создать БЗ - желаю успехов в этом начинании, если нет - тоже успехов, но в чем-нибудь еще!

P.S. Данная статья основана на личном опыте и мнении, конструктивная критика и предложения приветствуются