Ви повинні написати гарну документацію та чистий код, щоб збільшити "Фактор шини"?

Одна з головних цілей компаній, що займаються розробкою програмного забезпечення, - збільшити їхній фактор Bus. Про це також заявляють у розмові, організованому Google .

Це означає, що ви повинні кодувати і документувати все таким чином, що якщо завтра ви переїдете автобусом, проект все ще може продовжуватися. Іншими словами, ви повинні зробити себе легко замінюваним іншим програмістом з аналогічним вашим навичкам.

Це може бути замінено, чи не проти інтересів розробника? У книзі 48 законів влади Правило 11 зазначає, що вам слід намагатися утримати людей залежними від вас, щоб отримати владу, що потім переводиться на грошову винагороду.

Крім сценарію, коли вам потрібна певна документація для себе, щоб продовжити проект після 6 місяців паузи, тут, між розробником та компанією з програмного забезпечення, очевидно, існує чіткий конфлікт інтересів.

Отже, як програміст, чи справді ви повинні написати чудову документацію та легко читаючий код для всіх; або ви повинні писати код і документацію таким чином, щоб це робило роботу, і ви самі це можете зрозуміти, але інша людина може мати проблеми з її розумінням?

Ви повинні прагнути стати незамінними не за допомогою написання коду, який ніхто не розуміє, а шляхом збору більше досвіду та знань, ніж інші. Колишній спосіб робить вас розробником, з яким всі намагаються уникати роботи, оскільки вони побоюються і ненавидять підтримувати написаний вами код. Останнім чином ви стаєте затребуваним членом команди, якого менеджери хочуть мати у своїй команді.

На мій досвід написання чистого, добре задокументованого (і, бажано, самодокументування) коду завжди окупається. Насправді я використовував майже кожну можливість допомагати та навчати інших (як і вчитися у них, коли вони знали щось краще), і я навряд чи коли-небудь відчував небезпеку замінити когось менш здатного, ніж я. Насправді це зазвичай допомагало всій команді працювати краще і вирішувати проблеми швидше, що є мрією кожного менеджера - і розумний менеджер не хоче замінювати членів хорошої команди.

Якщо ви збираєтеся маніпулювати організаціями чи людьми настільки прозоро, то їм краще бути дурними або забитими, що не залишає іншого вибору. Добре запущений магазин з розробки програмного забезпечення перегляне ваш незрозумілий код і відсутні документи і просто звільнить вас, перш ніж ви зможете зробити велику шкоду. Якщо вони погано працюють або не в змозі змусити інших розробників працювати на них, чому б ви хотіли мати синекуру з ними?

PS Ні містер Грін, ні Макіавеллі насправді багато чого не оминули від написання книг, які намагалися поласувати потенційними «жорсткими людьми» того часу. Скористайтеся їх порадою з зерном солі.

Якщо ви незамінні, ви не можете просуватися.

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

Якщо ви це зробите зі своїми роботодавцями, вони намагатимуться застосувати заходи до вас, щоб зменшити вашу монополію на знання. Переважно, це будуть смішні вказівки щодо того, як ви повинні виконувати свою роботу, і тим самим перетворите своє робоче життя на живе пекло. Крім того, вони зателефонують вам о 3 годині ночі, коли щось зламається, адже ви єдина людина, яка може це виправити. Намагаючись скористатися такими ситуаціями, як важелі, швидше за все, може призвести до зворотного спалаху і доставить вам більше проблем.

Кладовища сповнені незамінних чоловіків.
- Голль, Чарльз Де

Тож виріжте лайно і виконайте свою роботу належним чином. Якщо ні для чого іншого, то для вас, тому що ви, швидше за все, бідна душа, яка повинна змінити код протягом 2 років.

Негативні відповіді не надто дивні, враховуючи кількість кращих середніх програмістів, які приваблює цей сайт. Талановитим людям взагалі не потрібно вдаватися до таких видів тактики безпеки через затуплення. Але я працював у постачальника автомобілів Fortune 500 з кількома не настільки талановитими розробниками, які вирізали для себе маленькі воєнності, які вони ревно охороняли, створюючи велику кількість документації для жахливих інтерфейсів, які вони розробили.

Завданням одного хлопця було підтримання коду для модуля, який з'єднав дві цілком окремі підсистеми, що дозволило модулям в кожній системі спілкуватися через UART. В основному це було послідовне програмування 101. Замість того, щоб просто створити загальний інтерфейс, який виглядав приблизно так:

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, void * data, size_t maxBytes);

він створив окремі коди для кожного повідомлення, яке будь-які два комунікаційні модулі можуть захотіти надіслати іншому. Це означало, що його модуль повинен знати про кожне повідомлення та потребувати оновлення щоразу, коли повідомлення додається чи змінюється. Говоріть про невідповідну близькість!

Справа в тому, що цей хлопець дотримувався Word doc акуратно перелічуючи всі опкоди / повідомлення та старанно оновлював його за необхідності. Це стало його цілою роботою . Кілька разів на тиждень він розсилав нову редакцію для всіх нещасних людей, щоб пережити його на критичному шляху. І це вважалося "професійним", оскільки керівництво любило бачити документацію. Свого роду змушує мене плакати за автомобільною промисловістю.

Я здогадуюсь, що іноді написання документації може захистити посередніх програмістів. Часто менеджери не можуть визначити різницю між хорошим дизайном і поганим, і багато хто змушений приймати технічні рішення з обмеженою інформацією. Для них це неймовірно стресово. Побачити документ Word з десятками чітко відформатованих таблиць може бути дуже втішним - навіть якщо те, що він описує, є принципово поганою ідеєю.

Незважаючи на те, що це замінюється, це не проти інтересів розробника?

Я ненавиджу порушувати це вам, але кожен є змінним. Звичайно, іноді це може бути легким завданням замінити вас (якщо ви досвідчені і досить яскраві), але це світлові роки від неможливого.

Шлях по-справжньому бути цінним товаром для вашого роботодавця (не лише нинішнього роботодавця, але будь-якого роботодавця) - продемонструвати здатність писати код, який легко вподобати будь-хто, хто читає код (трохи збільшить час для роботи з ним) та документувати код (кожен може отримати огляд ваших систем на високому рівні, не заглиблюючись у код).

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

Чистий і добре задокументований код також вартий того, щоб його надсилали до резюме (принаймні, відчутні результати від нього, тобто "нам вдалося залучити nнових розробників з мінімальним збільшенням та наданням допомоги завдяки моїй документації), де неприховано робити рішення себе "незамінним" не є.

Незважаючи на те, що це замінюється, це не проти інтересів розробника?

Залежить від інтересів цього розробника. Якщо ви є тим, хто хоче дотримати його в одній роботі протягом усієї своєї кар'єри, будьте абсолютно незамінними для компанії, яка винагороджує некомпетентність і добре заробляє гроші, то так, абсолютно.

Але що відбувається, коли компанія виходить з ладу, можливо, тому що вони найняли занадто багато таких людей? Куди ти підеш далі? Що робити, коли вони запитують вас, чому ви пробули на одній роботі 15 років? І так далі.

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

Єдина ймовірність того, що це станеться, якщо компанія переживає проблеми і робить людей зайвими. Якщо це відбувається, вам краще вийти, і ви будете дуже добре підготовлені до майбутніх інтерв'ю. Плюс ваша совість буде абсолютно вільною - ви не залишите після себе незрозумілого коду, який ви написали для власного виграшу.

Я не знаю, яка ти людина, але це краще слугує моїм інтересам.

Особисто я вважаю, що одна з моїх найбільших сильних сторін - автоматизація власної роботи. Як ви думаєте, що компанія схильна думати, коли я стала надлишково власною потребою? Вони думають, що "гаразд, ми зараз його позбудемося" чи вони думають, "чому б ми не перевели його в іншу роль і не дозволимо йому зробити це знову"?

Незважаючи на те, що це замінюється, це не проти інтересів розробника?

Ви маєте рацію, але я думаю, що ви неправильно зрозуміли значення змінного. Я міг знайти 1000 розробників, які пишуть гектичний код, недокументований, який може швидко перетворитися на незбагненний безлад.

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

Я вирішу це питання з іншої точки зору, оскільки вже є кілька відмінних відповідей.

Поміркуйте, що станеться, коли ви граєте в дріб'язкові ігри, намагаючись зробити себе «незамінними», хоча заважаєте іншим дізнатися, як працює ваш код. Ви залишаєтесь на тій же роботі, зберігаючи свої власні помилки, поки компанія терпить вас. І це найкращий сценарій, найгірший сценарій - це те, що інші, більш талановиті та більш етичні інженери та менеджери у вашій компанії бачать перешкоду, яку ваші погані практики накладають на компанію, і вони вирішують щось зробити: розстріляючи вас та переписавши все з нуля. Це зроблено. Насправді це трапляється досить часто.

Тепер подумайте, що станеться, коли ви пишете хороший код та хорошу документацію. Ви створюєте компонент або систему, яка працює добре, що через деякий час у процесі роботи помилки працюють безперебійно і навряд чи потрібно їх шукати. Для його утримання потрібно мало зусиль. Потім ви можете перейти до більших та кращих проектів із солідною перемогою під поясом. Люди впізнають вас за те, що ви зробили добру справу, і почнуть поважати вашу думку. Ви будете мати можливість рухатися в ланцюзі харчування і приймати більш значущі рішення, або робити важливішу і ефективнішу роботу, або керувати проектами на більш високому рівні. Ваша кар’єра покращиться, ви будете просуватися, ви будете заробляти більше грошей, ви отримаєте визнання та схвалення з боку своїх ровесників, ви додасте все більше і більше успіхів дедалі важливіших проектів у свій досвід.

Який маршрут ви б віддали перевагу?

Якщо ви є єдиною точкою невдачі, ваш клієнт (або роботодавець), ймовірно, спробують замінити вас; Завжди є момент, коли замінити програмне забезпечення дешевше, ніж підтримувати його, незалежно від того, наскільки це суттєво виглядає. Існує причина, що ІТ - одна з найпопулярніших професій.

З іншого боку, зміна дає кілька безцінних переваг:

• можливість взяти відпустку
• не перебуває за викликом
• свобода виїзду та робота над новим і існуючим проектом

Якщо ви не витрачаєте 5 хвилин на написання швидкої документації, ви збираєтесь витратити годину на повторне читання та пояснення людям, коли їм потрібно використовувати ваш код.

Ще гірше може витратити дні на пошуки нової роботи, тому що ваш начальник дізнався, що ви не писали коду, який можна отримати.

Відмінна документація згодом буде застаріла з рефакторингом / еволюцією, і постійне її оновлення дійсно забирає багато часу.

Чистий код + тест одиниці> відмінна документація

Відповідь на ваше запитання - «так». Так, ви повинні написати гарну документацію та чистий код. Навмисне дія в іншому випадку виявляє відсутність цілісності, що, хоча все більше переважає у світі бізнесу, не є якось раптом "доброю" річчю.

Ніхто не є незамінним. Люди, які створюють ситуацію, за якої вони думають, що прагнуть з'ясувати важкий шлях, яким вони не є. Виробляти взаємозалежність для себе є контрпродуктивним, оскільки це також обмежує вас, а не лише роботодавця.

Однією з головних цілей компаній, що займаються розробкою програмного забезпечення, є підвищення коефіцієнта шин

Неправдиве приміщення. Основні цілі компанії, що займається розробкою програмного забезпечення (у будь-якому випадку, в якому я працював), - виробляти найкраще програмне забезпечення, яке вони можуть, і заробляти гроші, не обов'язково в такому порядку. Зменшення "коефіцієнта шини" - це лише один із способів уникнути втрати грошей.

Закон 11 Навчіться тримати людей залежними від вас.

Що це означає для вас?

Ви хочете, щоб люди залежали від вас, тому що ви підірвали їх таким чином, що вони можуть рухатися вперед лише з вашою допомогою? Або ви хочете, щоб люди залежали від вас, тому що ви розумні та проникливі, надійні, надійні та вмієте допомагати іншим також робити свою роботу краще? Ви хочете, щоб ваші колеги виглядали погано без вашої допомоги, чи ви хочете, щоб вони цінували вас за те, що вони виглядають добре?

Це ваш дзвінок.

(припускаючи виробничий код)

Я схильний піти трохи далі. Я писав про те, щоб зробити програми "бездоганними", але я не завжди кваліфікую це: я пишу багато коду, з яким інші люди не побачать і не працюватимуть (принаймні, таке очікування, коли воно написане). Яя ідіот, від якого я намагаюся захищатись у цій справі. Це добре, коли ваша програма виявляє проблеми для вас, і проблема настільки спрощена, що цілком очевидно, що є помилка та її походження. Правда, деталі реалізації очевидні, коли ви пишете програму (якщо ви її не реалізуєте передчасно), але вони повинні бути абстрагованими та захищеними від помилок для клієнтів (навіть коли локалізація модуля існує). Причина в тому, що програми стають дуже складними. Іноді можна відокремити проблеми, але не весь час. Якщо ви тримаєте ваші компоненти дуже суворі, прості, добре укладені та бездоганними, вони, як правило, добре масштабуються, і більшість дефектів виявляються ще до їх доставки. Це простіше повторно використовувати, і ви маєте більше впевненості та простіший час повторного використання програм. ті складні програми, які ви пишете, лише стають складнішими (навіть вам) через деякий час, відібравшись від програми. Коли ви прочитаєте його через 6 місяців, це може зайняти абсурдну кількість часу, щоб зрозуміти та налагодити помилку у порівнянні з версією, що підтверджує ідіот. Якщо компонент вносить переломну зміну, в іншому випадку він може довго не виявлятися, інакше. Програми складні; ти не можеш уникнути цієї реальності, але ти можеш зробити це ідіотським доказом, що полегшить твоє життя, коли щось піде не так або коли його потрібно повторно використовувати чи змінити. Тому підхід, що підтверджує ідіотизм, означає, що ваше програмне забезпечення може бути зрозумілим, використаним або підтримуваним вашими юніорами або людьми, які є новішими в команді (а не лише хтось такий хороший / досвідчений, як ви). Заміна - це окрема проблема: якщо люди люблять працювати з вашими програмами, ви робите гарну роботу - не робіть не переживайте про заміну. Звичайно, я міг би придумати сценарії, коли нерозбірливі програми могли врятувати вашу роботу, але написання хорошої програми, яку можуть використовувати та підтримують інші, явно менше зло (подивіться на відгуки інших). Якщо я зловживаю, як пишу щось, що не є ідіотським доказом, я намагаюся це виправити.

Крім сценарію, коли вам потрібна певна документація для себе, щоб продовжити проект після 6 місяців паузи, тут, між розробником та компанією з програмного забезпечення, очевидно, існує чіткий конфлікт інтересів.

Ви дійсно не маєте уявлення про те, про що думали в той час, коли ви переглядали спокійні реалізації. Коли ви справді досвідчені, то проблема простіша, оскільки ви можете більше покладатися на усталені методології чи підходи, якими ви користуєтесь. Це, однак, також передбачає, що ці методології є інваріантними. Незважаючи на те, що документація може бути слабкою, ви все одно повинні бути захисними у своїх реалізаціях (наприклад, ви знаєте краще, ніж передавати NULL в цьому сценарії - перевірити цю умову).

Отже, як програміст, чи справді ви повинні написати чудову документацію та легко читаючий код для всіх; або ви повинні писати код і документацію таким чином, щоб це робило роботу, і ви самі це можете зрозуміти, але інша людина може мати проблеми з її розумінням?

Я рекомендую ідіотівський підхід, який ще чіткіший і стійкіший до помилок, ніж підхід із фактором шини. Напишіть свої програми та документацію так, щоб їх легко зрозумів хтось із зовнішніх проектів - це теж добре для вас. Це зробить вашу цінність для вашої компанії та команди, вони не захочуть замінити вас.

Ви принципово неправильно зрозуміли гру. Гра не в тому, щоб продовжувати робити ті самі старі речі, що ви робили раніше, нести відповідальність за весь код, який ви написали, тому що ніхто більше його не отримує. Гра полягає в тому, щоб завершити проект і перейти до наступного, залишаючи після себе код, який хтось інший може легко зрозуміти і працювати з вашою відсутністю, щоб ви могли робити нові речі і брати на себе більше і різних обов'язків. Ваша передумова працює лише в тому випадку, якщо ви щасливі, що заважаєте робити те саме і знову і знову, не маючи шансів вчитися чи вдосконалюватися.

Я також зазначу, що якщо у вас не буде приводу дуже часто дивитися на цей код, у вас теж виникнуть проблеми з його з'ясуванням через шість місяців, якщо ви навмисно придушите його.

Я документую той маленький код, який я пишу, не для того, щоб його могли прочитати інші, а щоб я міг прочитати його через 3 місяці! Йдеться про полегшення обслуговування. Якщо ви несете відповідальність за написаний вами код і не можете виправити помилки, які з’являться пізніше внизу рядка, то ви хочете, щоб це було добре задокументовано ... Це зовсім неважливо, наскільки ви заміни, якщо не можете робити свою роботу!

Кожного "незамінного" комп'ютерного професіонала, з яким я мав нещастя взаємодіяти, було замінено, значною мірою тому, що вони намагалися утримувати ресурси своїх роботодавців в заручниках. Коли у мене з’явилися люди, які повідомляють мені, що вони вважають, що їх час є цінним «марнувати» документування, я замінюю їх якнайшвидше.

Здавалося б, якщо потенційний працівник вважає 48 законів влади етично чи морально прийнятними, то вам краще було б без них.

Якщо ви дійсно хочете бути незамінними (що, можливо, ви хочете переглянути, прочитавши всі відповіді ...) - навіщо зупинятися на тому, щоб не документувати код?

Є справді геніальний посібник про те, як написати нездійснений код, який ви обов'язково повинні прочитати: http://thc.org/root/phun/unmaintain.html

Насолоджуйтесь! (Я, безумовно, робив ...)