Як керувати випадковими складностями в програмних проектах

Коли Мюррея Гелль-Манна запитали, як Річарду Фейнману вдалося вирішити стільки важких проблем, Гелл-Манн відповів, що Фейнман має алгоритм:

1. Запишіть проблему.
2. Думайте по-справжньому важко.
3. Запишіть розв’язку.

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

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

Коли ви бачите хороший хід, шукайте кращий.
—Емануель Ласкер, 27-річний чемпіон світу з шахів

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

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

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

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

"Навички архітектури програмного забезпечення не можна навчити" - це поширена помилка.

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

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

Справа зі складністю - це навичка, яку ви здобуваєте значною мірою, намагаючись і невдало кілька разів. Просто багато загальних вказівок, які спільнота виявила для програмування у великих (використовувати шари, боротися з дублюванням, де б вона не головувала, релігійно дотримуватися 0/1 / нескінченність ...) не настільки очевидно правильна і потрібна для початківців, поки вони насправді не програмують щось велике. Поки ви насправді не вкусили дублюванням, що спричинило проблеми лише через кілька місяців, ви просто не можете «зрозуміти» важливість таких принципів.

Прагматичне мислення Енді Ханта вирішує це питання. Він посилається на модель Дрейфуса, згідно з якою існує 5 етапів володіння різними навичками. Початківцям (етап 1) потрібні точні вказівки, щоб вміти щось робити правильно. Фахівці (5 етап), навпаки, можуть застосувати загальні зразки до даної проблеми. Посилаючись на книгу,

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

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

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

Це питання з Workplace є актуальним, і IMHO було б цікаво прочитати в цьому контексті.

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

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

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

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

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

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

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

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

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

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

" Все повинно бути зроблено максимально просто, але не простіше ",
- приписують Альберт Ейнштейн

Дозвольте накреслити свій особистий алгоритм боротьби з випадковою складністю.

1. Напишіть історію користувача або випадок використання Огляд з власником продукту.
2. Напишіть тест на інтеграцію, який не вдається, оскільки функції немає. Повідомте з QA або головним інженером, чи є у вашій команді таке.
3. Напишіть одиничні тести для деяких класів, які могли б пройти тест на інтеграцію.
4. Напишіть мінімальну реалізацію для тих класів, які проходять одиничні тести.
5. Перегляньте тестові одиниці та реалізацію з іншими розробниками. Перейдіть до кроку 3.

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

Примітно, що саме уявлення про те, що ти маєш рішення, здається, є однією з головних рекомендацій людей, які пишуть про вирішення проблем (звані «бажаним мисленням» Абельсоном та Суссманом у структурі та інтерпретації комп’ютерних програм та «робота назад» у «Полі» як Розв’яжіть )

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

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

Випадкова складність

Первісне питання (перефразоване) було:

Як архітектори управляють випадковими складностями програмних проектів?

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

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

Уникнення зайвої складності

Виходячи з основного питання, я б перефразував це так:

Як архітектори управляють складністю програмних проектів?

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

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

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

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

Побудова рішення

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

Повернення до конкретних заключних питань:

Конкретні методи приборкання випадкових складностей можна знайти в таких джерелах.

• Принципи програмування Unix
• Шаблони дизайну
• та посібники зі стилів ( наприклад, PEPhon PEP 8 )

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

Це, можливо, було важким питанням кілька років тому, але ІМО вже не важко усунути випадкові складності.

Що Кент Бексейд про себе, в якийсь момент: "Я не чудовий програміст; я просто хороший програміст з великими звичками".

Варто виділити дві речі, ІМО: він вважає себе програмістом , а не архітектором, а його увага зосереджена на звичках, а не знаннях.

Спосіб вирішення важких проблем Фейнмана - єдиний спосіб зробити це. Опис не обов’язково дуже простий для розуміння, тому я його розсічу. Голова Фейнмана була не просто сповнена знань, вона також була повна майстерності застосовувати ці знання. Коли у вас є як знання, так і вміння ними користуватися, вирішення важкої проблеми не є ні важким, ні простим. Це єдиний можливий результат.

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

Зараз багато програмістів навіть не знають про всі знання, необхідні для написання чистого коду. Молодші програмісти, як правило, відкидають знання про алгоритми та структури даних, а більшість старших програмістів, як правило, це забувають. Або аналіз великих записів і складності. Старі програмісти, як правило, відкидають шаблони або запахи коду - або навіть не знають, що вони існують. Більшість програмістів будь-якого покоління, навіть якщо вони знають про шаблони, ніколи не пам’ятають точного, коли використовувати та запчастини драйверів. Мало хто з програмістів будь-якого покоління постійно оцінює свій код відповідно до принципів SOLID. Багато програмістів повсюдно змішують усі можливі рівні абстракції. Наразі мені не відомо, що один із програмістів, який постійно оцінює його код, проти смутків, описаних Фаулером у своїй книзі про рефакторинг. Хоча деякі проекти використовують певний інструмент метрики, найбільш використовуваною метрикою є складність, того чи іншого роду, тоді як дві інші метрики - з'єднання та згуртованість - значною мірою ігноруються, навіть якщо вони дуже важливі для чистого коду. Ще один аспект, який майже всі ігнорують - когнітивне навантаження. Мало хто з програмістів розглядає одиничні тести як документацію, а ще менше хтось усвідомлює, що складно написати або назвати одиничні тести - це ще один сморід коду, який зазвичай вказує на поганий факторинг. Крихітна меншина знає про мантру дизайну, керованого доменом, щоб максимально наблизити кодову модель та модель ділового домену, оскільки розбіжності повинні створювати проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. найбільш використовуваною метрикою є складність, того чи іншого роду, тоді як дві інші метрики - з'єднання та згуртованість - значною мірою ігноруються, навіть якщо вони дуже важливі для чистого коду. Ще один аспект, який майже всі ігнорують - когнітивне навантаження. Мало хто з програмістів розглядає одиничні тести як документацію, а ще менше хтось усвідомлює, що складно написати або назвати одиничні тести - це ще один сморід коду, який зазвичай вказує на поганий факторинг. Крихітна меншина знає про мантру дизайну, керованого доменом, щоб максимально наблизити кодову модель та модель ділового домену, оскільки розбіжності повинні створювати проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. найбільш використовуваною метрикою є складність, того чи іншого роду, тоді як дві інші метрики - з'єднання та згуртованість - значною мірою ігноруються, навіть якщо вони дуже важливі для чистого коду. Ще один аспект, який майже всі ігнорують - когнітивне навантаження. Мало хто з програмістів розглядає одиничні тести як документацію, а ще менше хтось усвідомлює, що складно написати або назвати одиничні тести - це ще один сморід коду, який зазвичай вказує на поганий факторинг. Крихітна меншина знає про мантру дизайну, керованого доменом, щоб максимально наблизити кодову модель та модель ділового домену, оскільки розбіжності повинні створювати проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. тоді як дві інші показники - з'єднання та згуртованість - значною мірою ігноруються, навіть якщо вони дуже важливі для чистого коду. Ще один аспект, який майже всі ігнорують - когнітивне навантаження. Мало хто з програмістів розглядає одиничні тести як документацію, а ще менше хтось усвідомлює, що складно написати або назвати одиничні тести - це ще один сморід коду, який зазвичай вказує на поганий факторинг. Крихітна меншина знає про мантру дизайну, керованого доменом, щоб максимально наблизити кодову модель та модель ділового домену, оскільки розбіжності повинні створювати проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. тоді як дві інші показники - з'єднання та згуртованість - значною мірою ігноруються, навіть якщо вони дуже важливі для чистого коду. Ще один аспект, який майже всі ігнорують - когнітивне навантаження. Мало хто з програмістів розглядає одиничні тести як документацію, а ще менше хтось усвідомлює, що складно написати або назвати одиничні тести - це ще один сморід коду, який зазвичай вказує на поганий факторинг. Крихітна меншина знає про мантру дизайну, керованого доменом, щоб максимально наблизити кодову модель та модель ділового домену, оскільки розбіжності повинні створювати проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. Ще один аспект, який майже всі ігнорують - когнітивне навантаження. Мало хто з програмістів розглядає одиничні тести як документацію, а ще менше хтось усвідомлює, що складно написати або назвати одиничні тести - це ще один сморід коду, який зазвичай вказує на поганий факторинг. Крихітна меншина знає про мантру дизайну, керованого доменом, щоб максимально наблизити кодову модель та модель ділового домену, оскільки розбіжності повинні створювати проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. Ще один аспект, який майже всі ігнорують - когнітивне навантаження. Мало хто з програмістів розглядає одиничні тести як документацію, а ще менше хтось усвідомлює, що складно написати або назвати одиничні тести - це ще один сморід коду, який зазвичай вказує на поганий факторинг. Крихітна меншина знає про мантру дизайну, керованого доменом, щоб максимально наблизити кодову модель та модель ділового домену, оскільки розбіжності повинні створювати проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. s мантра підтримувати модель коду та модель ділової галузі якомога ближче одна до одної, оскільки невідповідності обов'язково створюють проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати. s мантра підтримувати модель коду та модель ділової галузі якомога ближче одна до одної, оскільки невідповідності обов'язково створюють проблеми в дорозі. Все це потрібно постійно враховувати, якщо ви хочете, щоб ваш код був чистим. І багато іншого, чого я зараз не можу згадати.

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