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


10

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

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

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

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


2
@Haylem - Я думаю, що оригінальна редакція, яку я зробила, була кращою. Якщо заголовок такий самий, як і перше речення, то який сенс заголовка?
BlackJack

1
@BlackJack Я повернув твій заголовок і ще трохи уточнив питання. Я думаю, що нас троє зачепили за ту саму посаду в історії редагування. Має бути добре зараз.
Томас Оуенс

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

1
@Chad: Хоча я згоден з усім, що ви сказали, я не зовсім впевнений, що ОП мав намір сукатися про його начальника (безпосередньо).
хайлем

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

Відповіді:


32

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

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

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

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

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

@Ivan: Дякую Довгострокове мислення завжди виграє.
haylem

@haylem - Я згоден з вами, тому що люди швидко змінюють роботу. тому кращий код стане в нагоді для нових столярів, які швидко підкреслять код
Jitendra Vyas

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

6

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

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

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

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

5
Iffy кращий чи гірший за Sketchy?
HLGEM

1
@HLGEM: Прибутково завжди краще, ніж невигідно.
Дональні стипендіати

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

1
Присвоювання прибутковості виключно на звороті розробника - це надмірне спрощення. Як щодо управління продуктом, інфраструктури розгортання? Чи вони також не можуть відігравати роль у прибутковості?
DavidS

5

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

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

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


6
Найкращі практики не допомагають правильно виконати всі проекти за менший час. Це просто речі, які, як було помічено, більшу частину часу справляли добре.
Томас Оуенс

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

5

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

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

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

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


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

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

3
@Jitendra - Я не сказав, що це не так. І написання коду в читаному вигляді - це чудово. Якщо ви хочете "виправити" погляд інших кодів, коли у вас є власні завдання, це не так.
SoylentGray

1
@Chad - Справа не в тому, щоб переписати власний код або виправити код інших людей, він повинен написати код в перший раз з належним відступом для гарної читабельності, належних коментарів для майбутнього розробника та використання кращих практик, що робить код повторно використаним і все потребує часу, а потім написання коду безладу, який може зрозуміти лише оригінальний розробник. Хороший код завжди потребує часу.
Житендра Вяс

4
@Ivan: Я мав прямий досвід з цим менталітетом. Виходить так. Компанія розпочинає проект «Грінфілд». Hotshot Developer X збирає речі якомога швидше, використовуючи велику кількість ctrl + cта ctrl + v. Продукт запускається в дуже короткому порядку. Компанія в захваті від Developer X. Надходять звіти про помилки та запити щодо функцій. Developer X не може йти в ногу і звільняється / переходить до наступного завдання. Наступні 3 роки розвитку - це воротаючі двері нових команд інженерів, які не можуть досягти жодного прогресу, і компанія X втрачає всі ринкові переваги, які колись мала.
Грег Бургхардт

4

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


2
+1 за те, що він короткий, до речі і правильний. Компанія, яка не піклується про стандарти якості, є або дурною, неосвіченою або шахрайською.
Уейн Моліна

3

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

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


3

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

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

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

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

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

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


2

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

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


2

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

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


2

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

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

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

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

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

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

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


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

1

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

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


1

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

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

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

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


Залежить від ІМО "найкращої практики". Такі речі, як тестування (не обов'язково TDD, але автоматизовані тести взагалі), дотримання SOLIDпринципів, використання моделей дизайну, використання абстракцій / інтерфейсів - це базовий рівень, який повинен робити будь-який компетентний розробник.
Уейн Моліна

Наскільки мені подобаються тести ... вони не є базовими.
CaffGeek

1

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

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

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

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


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

Я не погоджуюсь. Це, безумовно, траплялося в багатьох дрібних і середніх веб-проектах, в яких я брав участь, і також є багато інших відомих прикладів компаній, які повертаються назад і переробляють свою кодову базу основними способами - наприклад, перехід Twitter від Ruby до Scala, Facebook та їх прагнення до оптимізувати мову PHP тощо. Насправді я впевнений, що більшість успішних зрілих додатків (веб і настільних ПК), якими ми користуємося щодня, не мають багато спільного коду з їх предками v1.
timh

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

0

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

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

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

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

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

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


0

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

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

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

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

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

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

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


1
Ніколи не кажи ніколи. Цілі програми кидають у смітник. Перетворення даних з однієї системи в іншу звикають один раз і загнивають.
JeffO

Утримання чистим кодом часто знижує швидкість розвитку за короткий термін . Важлива частина полягає в тому, що нечистий код призводить до набагато більшого скорочення в довгостроковій перспективі. Я бачу кілька інших відповідей, які це згадують.
Іксрек
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.