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

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

Отже - це нормально і прийнятно, що я записую свої думки та рішення у якийсь файл Notepad ++ під час кодування?

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

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

Мало того, що це нормально, це гарна ідея.

Є відома цитата

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

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

Так, це цілком прийнятно і нормально.

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

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

Це чортово гарна ідея. Праворуч до тих пір, поки це не стане способом зволікати.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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