Чи розробники програмного забезпечення, які ігнорують якість / стандарти, кращі для компанії? [зачинено]

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

Як порівнюються ці різні методології, коли мова йде про індивідуальні огляди ефективності?

Як ці стилі порівнюються в експертних рецензіях?

Який найкращий спосіб вплинути на вашу команду впровадити більше кращих практик під час SDLC?

Ні, вони отримають повагу лише від власника проекту на даний момент.

Вони потраплять у сміття роками:

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

Вони можуть навіть отримати таке ж лікування від:

• поточні тестери,
• нинішні автори технічної документації.

Помилкова дихотомія: якості є ортогональними.

                Висока якість Низька якість

Вигідний ДУМОВИЙ Ескізний

Нерентабельна Iffy ПОЖЕ ПЕРШИЙ

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

Стандарти кодування більш складні; можна прописати занадто багато деталей вашим кодерам, що призводить до зниження ефективності. Але з досвідом стає досить легко розповісти корисні вказівки від анально-затримкового мікроуправління, тому те саме стосується: фактичні найкращі практики завжди варті, псевдо-кращі практики - зазвичай.

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

Чи погоджуюсь я з розробниками, які не переймаються оптимізацією коду та практикою? Ні.

Вони роблять ту роботу, яку потрібно зробити? Так.

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

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

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

Так і ні, що трохи бажано мити, але це найкраща практика, а не досконала практика. В ідеалі ви повинні постійно дотримуватися їх, але завжди буде ситуація, коли бізнес хоче поставити свої потреби перед потребами вашої продукції.

Вас будуть ненавидіти технічні працівники, але їх любить ваш начальник.

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

Ви пишете систему наведення космічного супутника (напевно, ні)? Тоді пекло Ніякі неякісні / якісні коди ніколи не є прийнятними для подібних робіт.

Ви одноразово пишете веб-сайт для викидання (ви, мабуть, не робите цього чи не ставили б питання, але це швидше, ніж супутник)? Тоді пекло Так, вийміть цей шматок пуху через двері будь-якими засобами, необхідними для дотримання терміну, наступний директор з маркетингу, ймовірно, все одно буде робити щось інше з іншою компанією. ЩО ВИ НЕ МАЄТЕ МИСТЕЦТВО ТА НАУКУ - ОПЛАТИ.

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

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

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

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

Скільки поваги вони отримують, ймовірно, конкретні випадки. У якийсь момент, проте, хтось помітить.

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

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

Все залежить від замовника.

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

Подумайте про побудову шафи.

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

Багато хто не стане. Багато хто вирішить придбати дешевий матеріал з ДСП, який ви отримаєте у великому магазині коробки. Вони хочуть, щоб їх встановили за 2 дні. Невеликий розрив тут і там цілком прийнятний. Їм байдуже, що вони розпадуться через 10 років.

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

Тільки час покаже. Робіть те, що хочуть менеджери, або знайдіть іншу роботу.

Ні ніколи. Оптимізація коду IMO, кращі практики, фактична майстерність - НАЙБІЛЬШЕ важливе, що потрібно мати в кодовій базі; без цього вся справа перетворюється на мул і тримається разом з клейкою стрічкою. Це нестійка конструкція. Це як ігнорувати пухлину, бо вона маленька, і ти зараз здоровий; впевнений, що ти зараз здоровий, але через кілька років він стає термінальним, оскільки ти так довго його ігнорував.

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

Гарне прочитання: http://www.joelonsoftware.com/items/2009/09/23.html

Але ІМХО, одна з найкращих практик чоловіків - це інший чоловічий кошмар. І кожна нетривіальна база коду буде кошмаром для сторонніх людей.

Що б ти не думав, не шукай з цього приводу.

EDIT: Я не захищаю жодної позиції, залежно від завдання, яке я можу схилити до будь-якої сторони.

Краще для компанії? Це залежить.

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

Для зрілого продукту, де багато користувачів, які покладаються на якість програмного забезпечення, все слід робити «належним чином».

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

Залежить від розробника та проекту / ситуації.

Позачергові часи вимагають надзвичайних заходів.

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

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

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

Це залежить від конкретного випадку. За винятком стилю кодування - виправдання там немає.

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

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

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

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

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

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

Так що ніколи поганій якості, з точки зору гнучкості, ніколи!