Чи "норма, поки це працює" є нормою? [зачинено]

Дивіться моє останнє запитання: чи програмування як професія перемагає донизу?

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

Вони випустили речі, які, на їхню думку, мали проблеми. Їм було все одно, як все написано. Не було оглядів коду - незважаючи на те, що там було кілька розробників. Вони випустили програмне забезпечення, яке вони знали, що баггі.

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

Отже, по суті, моє враження таке: програмування зводиться до наступного:

1. Читання книги про найновіший інструмент / технології
2. Складаючи код разом на основі цього, уникаючи написання будь-якого індивідуального коду, оскільки компанія не хоче "підтримувати спеціальний код"
3. Показати це і перейти до наступного, "поки це працює".

Я завжди казав собі, що на наступній роботі я збираюся отримати кращий магазин. Це ніколи не буває. Якщо це все, то я відчуваю, що застряг. Технології завжди змінюються; якщо єдиним професійним розвитком тут є читання новітньої книги технологій MS Press, то що ви побудували за 10 років, але поверхневі знання різних технологій? Мене хвилює:

1. Найкращий спосіб мати професійні стандарти
2. Як розвивати значущі знання та досвід у цій ситуації

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

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

Щоб більш прямо відповісти на ваше запитання, так, я думаю, «поки це працює» часто є нормою. Але погляньте на це по-іншому: ви в чудовому стані навчати своїх колег і намагатися впровадити деякі кращі практики. Але не йдіть до крайності і пам’ятайте, чому ми все це робимо: щоб вирішити проблеми нашого замовника.

>> На моїй попередній роботі у людей було таке ставлення, поки це працює, це добре.

Можливо, я тут меншість, але у мене таке ж ставлення, і я твердо вірю, що для того, щоб переписати щось, повинні бути чіткі докази, навіщо нам це потрібно. І я не маю на увазі щось на кшталт "uf, мені не подобається, як це було закодовано" - кожен розробник має свої переваги щодо коду. Мають бути деякі проблеми з частиною, яку ми хочемо переписати:

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

Agile не несе відповідальності за те, щоб людина вирішила випустити програмне забезпечення; люди є.

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

Проблема полягає в тому, що перфекціонізм призводить до зволікання, а зволікання призводить до посередності .

Тому бізнес надаватиме пріоритет у таких продуктах, як час на ринок та використання спритних швидку доставку вартості та передбачуваними темпами.

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

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

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

І якщо ви виявите, що вони не знають, що вони роблять, ваш єдиний варіант - це кинути .

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

Якщо ви пишете алгоритми проводки по дроту для системи FA-18, тоді краще побудувати якомога досконаліше.

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

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

Я думаю, що тут діє правило 80/20. В основному, вам потрібно миритися з шаленими 80% і працювати на 20%. Однак розумійте, що навіть їм доведеться робити компроміси. У бізнесі зазвичай не має значення, що ти маєш це абсолютно правильно. Важливо, що у вас це є зараз.

якщо єдиним професійним розвитком тут є читання новітньої книги технологій MS Press, то що ви побудували за 10 років, але поверхневі знання різних технологій?

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

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

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

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

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

Я з тих пір почав працювати в іншому магазині і тут все краще. Справа в тому, що ви не можете змінити свою думку. Просто піди на роботу кудись інше.

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

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

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

Його відповідь до критиків була: "Все, що я знаю, це те, що моє лайно працює".

Досить хорошою нормою є принцип Парето

У мене є досвід проекту з правилом 80-20, і він спрацював дуже добре. Я думаю, що відповіді на це запитання "Де ви проводите межу свого перфекціонізму" також можуть бути корисними.

Термін "принцип Парето" також може означати ефективність Парето. Принцип Парето (також відомий як правило 80-20, закон життєво важливих кількох та принцип факторної розрідженості) стверджує, що для багатьох подій приблизно 80% наслідків виникають із 20% причин. Мислитель з управління бізнесом Джозеф М. Джуран запропонував цей принцип і назвав його на честь італійського економіста Вільфредо Парето, який у 1906 р. Зауважив, що 80% земель в Італії належить 20% населення; він розробив принцип, спостерігаючи, що 20% стручків гороху в його саду містило 80% гороху. Це звичайне правило в бізнесі; наприклад, "80% ваших продажів надходить від 20% ваших клієнтів". Математично, коли щось ділиться між досить великим набором учасників, повинно бути число k між 50 і 100 таким, що "k% приймає (100 - k)% учасників". Кількість k може змінюватись від 50 (у випадку рівномірного розподілу, тобто 100% населення мають рівні частки) до майже 100 (коли незначна кількість учасників складає майже весь ресурс).Немає нічого особливого в кількості 80% математично, але багато реальних систем мають k десь навколо цієї області проміжного дисбалансу в розподілі. Принцип Парето лише тангенціально пов'язаний з ефективністю Парето, який також був введений тим самим економістом. Парето розробив обидві концепції в контексті розподілу доходу та багатства серед населення.

Посилання на джерело

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

Без образи, але я, як менеджер, читав цю заяву десь у руслі:

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

Якщо ви скаржитеся на власний код - вам не доведеться багато стояти.

ОНОВЛЕННЯ

Я розумію, що ця ПОВ непопулярна. Але я не думаю, що це зовсім не несумісне з обов'язками та ставленнями професійного розробника.

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

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

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

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

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

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

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

Якщо для програмування нижчого рівня ви не можете отримати задоволення від навчання своєю роботою, то, можливо, саме час переглянути проект з відкритим кодом?

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

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