Що так поганого в творчому кодуванні? [зачинено]

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

Спільнота людей тут і на Stack Overflow, здається, відкидає будь-який потік недосконалості. Моя мета - написати респектабельний (а отже, підтримуваний та функціонуючий) код, вдосконалюючи свої навички. Та все ж я творчо кодую.

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

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

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

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

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

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

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

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

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

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

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

Я завжди віддаю перевагу чіткому, читаемому, простому коду будь-якому візуально представленому, UMLed, дизайнерському коду, де клас / інтерфейс містять назви шаблонів типу "ItemVisitor" (?!). Шаблони проектування, методи ОО та все інше - це формалізувати правила. Ці правила виходять із здорового глузду.

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

Ніколи не соромтесь переписати свій код. Я збираюся отримати для цього зворотний потік X (X> = 10), але зроблю це сміливо: повторне використання коду - не найважливіше .

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

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

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

Здається, ви є:

1. Випробування речей, щоб знайти найкращий підхід (експерименти, поступовий дизайн)
2. Перезапис коду, щоб очистити його (рефакторинг)
3. Постійно писати тести (тестова розробка)

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

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

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

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

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

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

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

Я вважаю, що варто доповнити відповіді вище цитатою Алана Дж. Перліса з передмови відомої книги MIT «Структура та інтерпретація комп’ютерних програм», що зазвичай називається «SICP»:

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

Є хороший розумний і поганий розумний.

Хороший розумний - високе співвідношення між розумними лініями коду та рядками у не розумній альтернативи. 20 рядків коду, які рятують вас від написання 20000 - це надзвичайно добре. Good Clever - це заощадити на роботі.

Bad Clever - низьке співвідношення між записаними кодами рядків написаними та збереженими рядками коду. Один рядок розумного коду, який рятує вас від написання п'яти рядків коду, - це поганий розум. Поганий розумний - це про "синтаксичну мастурбацію".

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

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

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

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

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

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

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

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

Дві перспективи:

1. Ніхто не повинен підтримувати картину.

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

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

Але мені цікаво про це:

Спільнота людей тут і на Stack Overflow, здається, відкидає будь-який потік недосконалості. [..] Моя процедура, схоже, суперечить тому, що є прийнятним у професійній спільноті розробників, і я хотів би зрозуміти, чому.

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

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

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

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

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

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

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

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

Одного разу я почув розмову Едсгера Дайкстра, що говорила про творчість у програмуванні. Він згадав, як студент знайшов спосіб зробити n-бітне обертання n + m-бітного слова. Це було зроблено за допомогою 3-х бітних змін. Спочатку ви поміняєте n n бітів, потім поміняєте m бітами, потім поміняєте цілими n + m бітами. Корисно? Ні, Розумний? Так.

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

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

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

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

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

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

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

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

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

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

І як казали інші: це мій шлях, ваш пробіг може відрізнятися.