среда, 16 сентября 2015 г.

[prog.thoughts] Инструментарий сильно упрощает разработку, но вот внутренний инструментарий...

Если не ошибаюсь, когда-то Бьёрн Страуструп высказался в том духе, что разрабатывать софт на C++ очень сложно, если нет готовых прикладных библиотек. Но зато очень просто, если таковые библиотеки имеются. Как человек, который очень много попрограммировал на C++, могу только подтвердить правильность этого высказывания. Однако, самый интересный вопрос таков: а откуда такие прикладные библиотеки возьмутся?

Ответ простой: либо есть готовая, написанная кем-то библиотека, либо она делается своими силами внутри компании. Хотя есть и третий вариант ответа: никакой библиотеки не делается, все пишется в лоб, без каких-либо вспомогательных, заточенных под задачу инструментов. Как следствие -- большое количество однотипного кода в разных местах, возможно даже полученного в результате копипасты. Но в контексте данного поста этот третий вариант не интересен, поэтому далее он рассматриваться не будет.

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

Хуже, когда готового инструментария либо нет, либо про него ничего не известно, либо же он есть, но не подходит по каким-то критериям (например, тип лицензии или ее стоимости). Что делать тогда?

Возникает вполне естественное желание сделать такой инструмент своими силами.

Очевидно, что есть крупные организации, решающие уникальные задачи, для которых разработка собственного инструментария -- это нормально и естественно. Например, вполне нормально, когда Facebook, Yahoo, Google или Yandex создают собственные внутренние инструменты. Ну просто вряд ли кто-то еще решает такие же задачи и на таком же масштабе, как Facebook или Google.

Однако, если взять компании сильно поменьше. Численностью, скажем, 50-100-150 человек. Насколько оправдана разработка внутреннего инструментария там?

Очень непростой вопрос.

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

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

А тут пять человек над одним внутренним инструментом.

Хотя нельзя судить не зная подробностей. Так что распространяться дальше на эту тему смысла нет.

Зато есть смысл сказать о паре вещей, очень глубоко прочувствованных на собственной шкуре.

Во-первых, для написания прикладного кода и библиотек нужны разные способности. Многие программисты способны писать нормальный прикладной код. Но мало кто способен хорошо разрабатывать библиотеки. Тут нужен какой-то особый склад ума, способность смотреть на вещи иначе, нужно уметь находить какие-то повторяющиеся паттерны (даже если этих повторений как таковых еще и нет), а затем облачать их в удобный API.

Но одних способностей мало. Нужен еще и опыт. Причем не только программерский опыт в разработке библиотек, но и жизненный. В связи с чем я бы очень подозрительно относился к ситуациям, когда разработка внутреннего инструментария ложится на плечи молодых разработчиков. Слишком велики риски: может получиться откровенное Г, может вообще ничего не получится, может возникнуть слишком много терок при попытке внедрения, могут быть сложности с сопровождением и развитием и т.д. Когда разработкой библиотеки занимается умудренный опытом разработчик, которому уже за 30, как-то спокойнее. Рассудительности больше, критика воспринимается спокойнее, к рутине отношение терпимее и т.д.

Во-вторых, серьезные вложения во внутренний инструмент оправданы, если этот инструмент создается с прицелом на длительное использование. А длительное использование подразумевает необходимость передачи знаний от тех, кто создал инструмент к тем, кто им пользуется. Причем чем больше времени проходит с момента создания инструмента, чем больше сменилось людей, тем важнее становится этот фактор. Т.е., если сразу после создания библиотеки автор может на пальцах рассказать трем-четырем пользователям все основные моменты, а потом в личных разговорах объяснять отдельные детали. То спустя год-два-три это уже не будет работать. Нужна нормальная документация, нужны примеры использования, нужны зафиксированные howto и best practices. Это минимум.

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


Что же в сухом остатке? Нужно ли разрабатывать собственный инструментарий?

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

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

Отправить комментарий