Що ви вважаєте 1-м принципом програмування?


59

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

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


Ми не говоримо про бойовий клуб.
Робота

Відповіді:


97
  1. KISS - Нехай це буде просто
  2. СУХО - не повторюйте себе
  3. ЯГНІ - Вам це не знадобиться

KISS повинен бути Keep It Simple Smart. Перший раз, коли вам доведеться переписати великий фрагмент свого коду, оскільки ви не створили розумний і розширюваний, ви погодитесь на це. :)

8
Я думаю, що KISS має бути "Прості, дурні!"
Денніс С

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

10
Я також додам YAGNI.

3
@Programmin Tool - Я не думаю, що "дурний" є зайвим. Я думаю, що це свідчить про те, що ми маємо тенденцію хотіти бути «розумними», і це проявляється як непотрібна складність. Як я бачу, «дурні» намагаються нагадати нам про цю тенденцію, допомагаючи нам пам’ятати, що ми спочатку вважаємо «розумним», як правило, це не так.
codekaizen

37

Напишіть код, як якщо б саме вам довелося підтримувати цей код.


Це дуже практична евристика, 3х :)

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

10
... і психопат, що володіє сокирами, знає, де ти живеш.
CAD заблокував

2
.., і він щойно загострив сокиру ...
Роальт

1
... і він працює з вашого боку.
Broken_Window

29

Будьте максимально ліниві.


2
Знову ж занадто загальне, ІМО. Тут виникає запитання "Наскільки насправді лінива відповідна кількість лінощів?", Адже очевидно "неохайність" - це те, чого ви теж не хочете бути.

Це посилання на «Лінь, нетерпіння та хубріс» Perl

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

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

3
@Kyle: Так, у цьому справа. "Справжня лінь" полегшує справи як зараз, так і в майбутньому. Що виявляється таким же, як робити речі правильно. Якщо ви робите менше роботи зараз, але більше працюєте пізніше, ви не будете "якомога лініші" :)

23

Дзен, частина I: Програмування - це лише дорога, а не шлях.

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

Дзен, частина II: Якщо ви поспішаєте, повільно прогулюйтесь. Якщо ви дійсно поспішаєте, зробіть об'їзд.

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

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

Дзен, частина III: Знай свій шлях, Нео.

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


Ну, а потім знову: я приземлився в земельній ділянці Дзен, розмовляючи про програмування :)

@ Частина III - не додайте "фантазійні нові речі", якщо вам не заплатять за це!
Джейсон

+1 для посилання на матрицю. Я хороший присоска (що і дзен. Змушує мене думати про Python)

19

KISS (нехай це буде просто, дурно).

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


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

3
і якщо ти дурний, як би ти знав, якби це було просто?
Стівен А. Лоу

Це добре, Стівен :)

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

1
@Dima: ти маєш рацію, я маю на увазі, що якість і простота (принаймні, в цьому випадку) є і невизначеними, але ми це знаємо, коли бачимо, якщо наші очі тренуються.
Адріано Варолі П'яцца

18

Передчасна оптимізація - корінь усього зла. - Дональд Кнут


Будь у впровадженні АБО дизайні.

16

Не винаходити колесо.


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

5
Деякі «колеса» потрібно заново винайти.

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

3
Як щодо:
Винайдіть

16

Зрозумійте проблему спочатку!


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

@ e-satis: Так, що я думав, коли вперше відповів на це. Я прокручую всю відповідь і напрочуд ніхто раніше не публікував.
OscarRyz

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

Проблема полягає в тому, як ви знаєте, що розумієте проблему?
CamelCamelCamel

13

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

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


12

Знаючи, коли не програмувати.


що на землі це має означати?

А коли це?

Іноді потрібно вирішити проблему користувачів по-різному - не просто кодувати рішення.

Людські судження та прийняття рішень є частиною всього; іноді немає сенсу намагатися автоматизувати судження.
С.Лотт

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

11

Кава, код.


3
Чай у моєму випадку =)

+1 хмм більше, як "Кава в, код + багато лоу-брейків?" :) Я люблю і каву, і чай, я розмахую обома способами ...
Darknight

10

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


Я згоден на це

7

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

- Чарльз Антоні Річард Хоар


6
  1. Розрізняти причину та наслідки (робота з комп'ютерами)

  2. Розрізняти факт і думку (робота з людьми)

  3. Як можна простіше, але не простіше (дизайн)


5

Програмування - це засіб не мета. А може, "Може, не означає, що слід".


5
  1. Зрозумійте, чому програма зробить когось щасливим (інакше, чому ви поза межами не граєтеся з усіма іншими дітьми?). (Ця людина може бути ти.)
  2. Розробіть концептуальну модель ділової галузі, яка б охоплювала всю необхідну складність, і не більше.
  3. Розробити концептуальну модель архітектури програмного забезпечення, яка б охоплювала всю необхідну складність, і не більше.
  4. Безжально утримуйте всі інші складності.

добре сказано! не могла погодитися більше
Антоній

5

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

Це включає

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

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


4

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

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


4

він не працює, поки ви не показали це в тесті


6
Це неправда, я написав тонни коду, який працює і не перевіряється! : D

1
"Я цього не перевіряв, я лише довів, що це правильно" :)
Даніель Даранас

4

Подумайте спочатку, код пізніше.

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

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

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


3

Будь-яку проблему можна вирішити іншим шаром непрямості.


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

вирішено ... ще одним шаром непрямості! =)
Ерік Форбс

Як не дивно, це правда. Подивіться на весну ...


3

Принцип: Програмне забезпечення - це захоплення знань .

Наслідки: Багато методів представлення знань, всі засновані на абстракції . Дає нам шари, яруси, інкапсуляцію, розділення проблем.

Багато методів представлення процедур, всі засновані на послідовності , виборі , повторенні .



3

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

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


2

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



2

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


2

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


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