Неверный взгляд: приоритет коллег над пользователями

Сколько раз вы смотрели на чей-то код и говорили:

Я не использую это, потому что это не выглядит хорошо написанным.

И в этом случае «выглядеть хорошо написанным» может заменить:

• «похоже, как я это напишу»,
• «кажется, имеет смысл для меня».

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

Это означает, что нам остается смотреть на то, что мы можем использовать, но предпочитаем не использовать, потому что это кажется написанным не так, как мы думаем, что это должно быть написано.

Приоритет коллег над пользователями

Разработка сложна, потому что есть несколько компромиссов, на которые нам — или другому разработчику — приходится идти всякий раз, когда они что-то создают.

Глядя наизнанку

Мы должны учитывать:

• ограничения времени и бюджета,
• какая парадигма поможет нам создать прочную основу в рамках указанных ограничений,
• действительно ли окончательное решение решает основную проблему,
• будут ли расходы на техническое обслуживание, связанные с тем, как мы что-то собрали?

И список можно продолжить.

Рассмотрение различных аспектов разработки и обсуждение философии того, как что-то должно быть построено, вовсе не редкость в нашей отрасли.

Но это также отнимает много времени и может оказаться упражнением, которое дает чистый нулевой результат, потому что из него ничего не выходит. (Да, часто это может быть учебным опытом, но не всегда.)

Фото Хосе Алехандро Куффиа на Unsplash

Глядя снаружи внутрь

Хотя на практике:

• Влияет ли парадигма, используемая для создания решения, на использование вами программного обеспечения?
• Решает ли рассматриваемое программное обеспечение проблему?
• Если бы вы не смогли увидеть, как был собран проект, какой вывод вы бы сделали о программном обеспечении?

И последний пункт может быть самым важным, поскольку он касается программного обеспечения с открытым исходным кодом.

Я проработал в отрасли достаточно долго, чтобы знать, что часто люди хотят функциональное решение, которое решает их проблему, и предполагают, что оно надежно построено.

Разработчики, с другой стороны, будут изучать код больше, чем решение, которое он предоставляет, и проблему, которую он решает.

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

И когда вы решаете проблему для других людей, они должны быть теми, кто важнее, чем ваши коллеги.