Невирівняний погляд: пріоритет однолітків над користувачами
Скільки разів ви дивилися на чийсь код і казали:
Я не використовую це, тому що воно не виглядає добре написаним.
У цьому випадку слово «виглядає добре написаним» може замінити:
- «Подивіться, як я б це написав»,
- «здається, це має сенс для мене».
Звичайно – бувають випадки, коли використання відкритого вихідного коду є ризикованим. Ми знаємо це з різноманітного програмного забезпечення та служб, які виявляють уразливості. Але, принаймні для цієї публікації, розглядайте це як виняток, а не як правило.
Це означає, що нам залишається дивитися на те, що ми можемо використовувати, але хочемо не використовувати, тому що це, здається, написано не так, як ми вважаємо, що повинно бути написано.
Пріоритет однолітків над користувачами
Розробка складна, тому що є кілька компромісів, на які ми або інший розробник повинні йти щоразу, коли вони щось будують.
Ми повинні враховувати:
- обмеження часу та бюджету,
- яка парадигма допоможе нам створити твердий продукт у межах зазначених обмежень,
- чи справді остаточне рішення вирішує основну проблему,
- чи будуть витрати на обслуговування, пов’язані з тим, як ми щось зібрали?
І список можна продовжувати.
Розгляд різних аспектів розробки та обговорення філософії того, як щось має бути побудовано, зовсім не рідкість у нашій галузі
Але це також займає багато часу, і це може виявитися вправою, яка дає чистий нульовий результат, оскільки з цього нічого не виходить. (Так, це часто може бути корисним, але не завжди.)
Фотографія Хосе Алехандро Куффіа на Unsplash
Дивлячись назовні
Хоча з практичної точки зору:
- Чи впливає парадигма, яка використовується для створення рішення, на використання програмного забезпечення?
- Чи вирішує програмне забезпечення проблему?
- Якби ви не змогли побачити, як був зібраний проект, який би висновок ви зробили про програмне забезпечення?
І останній пункт може бути найбільш критичним, оскільки він стосується програмного забезпечення з відкритим кодом.
Я достатньо довго працюю в галузі, щоб знати, що часто люди хочуть функціональне рішення, яке вирішить їхню проблему, і вони припускають, що воно надійно створене.
Розробники, з іншого боку, уважно вивчатимуть код більше, ніж рішення, яке він надає, і проблему, яку він вирішує.
Якщо ви розробник, для обох є час і місце. Але якщо ви дозволите останньому перешкоджати вам відправляти перше, то ви ніколи не отримаєте щось для використання іншими, тому що ви надто стурбовані тим, що можуть подумати ваші колеги.
І коли ви вирішуєте проблему для інших людей, вони мають бути важливішими за ваших однолітків.