Чи хороший код неможливий у сучасній розробці програмного забезпечення? [зачинено]

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

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

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

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

Як було заявлено Демарк і Лістер в Peopleware близько 20ish років тому, переважна більшість невдалих програмних проектів не зменшилась з - за технічних проблем, але соціологічні проблеми . Це не змінилося протягом останніх десятиліть, незалежно від того, наскільки наші інструменти покращилися.

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

Чому писати хороший код важче?

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

Це лише через згадування факторів, часу та складності?

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

ОТОГ, оскільки поле зросло настільки сильно, зараз існує набагато більше "малих" або "відомих" проблем, ніж було 30 років тому. Ці технічні проблеми технічно (не повинні) вже не бути викликом, але ... тут вводиться вищенаведена манія :-(

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

Хіба що методики не застосовуються правильно?

ІМХО звичайно ні. DeMarco та Lister мають кілька суворих слів про методології великих М. Вони кажуть, що жодна методологія не може зробити проект успішним - тільки люди в колективі можуть. ОТО маленькі методології, які вони хвалять, досить близькі до того, що ми зараз знаємо як "спритний", який широко поширюється (ІМХО з поважної причини). Не кажучи вже про таку добру практику, як тестування та рефакторинг, які лише 10 років тому не були широко відомими, а сьогодні про них знають навіть багато випускників.

Проблеми, пов’язані з кодуванням у нереальні терміни та вирішенням технічної заборгованості, відомі ще з Вайнберга '71, а також Брукса '72. Літературу стає важко викопати в Інтернеті до цього, але я впевнений, що старі звіти CDC, IBM і NASA говорять про те саме.

Я думаю, що всі ми маємо власні ідеї та пороги «хорошого кодексу». Однак є ряд питань, які сприяють:

• Неправильне застосування "примусимо його працювати, тоді поліпши його" означає, що ми залишаємо мертвий код та 10 різних варіантів того самого методу, коли кожен використовується лише один раз у базі коду. Цей матеріал, здається, ніколи не прибирається.
• Брак часу та бюджету. Клієнт хоче 100 нових функцій за 3 місяці, деякі з них нетривіальні, і вони не хочуть витрачати гроші на речі, які вони безпосередньо не бачать.
• Відсутність турботи. Подивимося, що деякі розробники дбають про те, як виглядає і поводиться код більше, ніж інші. Для прикладу дивіться першу точку кулі.
• Ми дійсно не знаємо, як створити "хороший код". Моя концепція хорошого коду постійно розвивається. Те, що я вважав гарним десятиліття тому, вже не так добре.
• "Хороший код" - це судження про значення. Окрім "це працює", і немає жодних відомих помилок, будь-які інші критерії хорошого коду по суті є питанням думки.

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

Чому писати хороший код важче?

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

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

Дійсно, це неможливо. Але не з жодної причини, про яку ви вже чули.

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

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

Для нас це все ще занадто складно.

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

Ми ніколи цього не зможемо зробити.

І якщо ми не можемо, ми ніколи не виробляємо якісний код.

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

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

Немає можливості домогтися взаєморозуміння між менеджерами та програмістами (і навіть між програмістами). І навіть якби вони були, здібності людського мозку не могли б впоратися з цим.

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

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

Я не хочу вибирати будь-якого конкретного постачальника, але порівнюю Windows 1.0 з Windows 7. Остання містить тисячі разів більше коду, але середній час між збоями збільшився в сто разів. Ми повинні були вставити електронну таблицю Excel в документ Word ще з Windows 3.1, але сьогодні це фактично більш-менш працює.

Не бажаючи потрапляти в сентиментальність "Ви, діти, сьогодні, набравши качок та VM", я б припустив, що ви не маєте уявлення про те, як важко було писати хороший код ще в 80-х: МОДУЛЬНІ, МАЛІ і ВЕЛИЧЕЗНІ моделі пам'яті, накладки , нерентантні дзвінки в ОС (здригаються). Гарна загадка на все це.

Сучасні програми є складнішими, ніж вони були 20-30 років тому, оскільки їхнє середовище багатше та універсальніше.

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

Будь-яке сучасне додаток, де ви не можете використовувати мишу ВСЕ ні для чого, має серйозну проблему пояснення. І все може статися в будь-якому порядку, оскільки користувачеві цілком можливо вводити, клацати мишкою та продовжувати вводити текст під час оновлення RSS-каналів у додатку, де відображаються новіші записи для користувача під час його введення.

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

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

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

Я думаю, що є давній закон науки, який варто пам’ятати:

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

Франсуа Рабелас (французький монах і сатирик 1494-1553)

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

То чому б нам не?

Основна причина ІМО полягає в тому, що ми постійно шукаємо шляхи та виправдання для зловживань. Замість того, щоб піти старомодним, простим, напевно, нудним способом, як, наприклад, створення виконавчого файлу Windows, ми розсуваємо межі можливого і шукаємо способи, наприклад, відтворити щось на зразок PhotoShop як веб-програми. Чому? Тому що ми можемо. Або принаймні так думаємо.

Коли востаннє НІКОМИ не писав подвигу чи не вчився робити це за допомогою збірки (не рахуючи хакерів ядер та хлопців ASIC)? Скільки помилок було виявлено у основних бібліотеках С? Майже ніхто і нечисленні. Все, що я говорю, - це те, що люди здатні чудовий код. Кращі інструменти та мови просто роблять його менш "необхідним" та "додатковим". Не те, що я думаю, що ми всі повинні писати дійсно жахливий код, але коли я думаю про складні логічні конструкції ... ніхто б не мріяв написати щось з хеш-масивами в зборі. Повинно було бути "кращим" способом управління логікою замість використання складної конструкції. Навіть якщо код красивий, іноді підхід не такий елегантний. Я думаю, це наче вирішує проблему, яку ви згадали. Хороший код не завжди організований,

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

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

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

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

Як людям стало гірше, коли виробляли хороший код?

Якщо ви, наприклад, візьмете .NET і таку мову, як C # (і я розумію, що це не єдина платформа / мова), я б стверджував, що кодування добре стало набагато простіше за рахунок автоматизації багатьох речей у Visual Studio середовище.

Якщо що, просто факт, що зараз у нас є дуже складні IDE, здатні вести нас через процес кодування та розробки, полегшує досягнення «хорошого коду».

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

Мої два центи.

Так, ми як галузь не практикуємо те, що, як відомо, є хорошими методологіями. Довідково: низько висячі фрукти Стіва Макконнелла Construx Software Software Software Development .

якість коду не покращилася

будь ласка, не зациклюйтесь на тлумаченні "хорошого коду"

Велика логічна тавтологія.

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

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