Як написати ефективний код, незважаючи на важкі терміни

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

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

Чи є поради, за допомогою яких я міг би зробити свій код ефективним, але вчасно доставити його?

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

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

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

• Добре харчуватися
• Роздумуйте
• Висипайтеся (7-9 годин залежно від людини)
• Дрімайте, коли ваш мозок нечіткий
• Лягайте спати з невирішеною проблемою. Не закінчуйте свій день всім завершеним. Залиште одне непросте завдання - ваша підсвідомість надзвичайно ефективна.
• Носіть зручний одяг
• Вправа
• Знайдіть час, щоб зробити розумні вправи - судоку (не запрограмовано), кросворди, математичні вправи, просторові пазли тощо
• Виконайте об'єктивні експерименти над собою, щоб побачити, яка з ваших поведінок впливає на ефективність (для цього вам знадобиться надійний спосіб перевірити продуктивність).
• Займіться своїм духовним здоров’ям
• Бавовняні труси
• Займіться своїм сексуальним здоров’ям
• Знайдіть час для своєї родини та друзів
• Будьте досвідченим у чомусь поза вашою професією (музиці, кулінарії, спорті тощо) та спілкуйтеся з іншими людьми, що роблять те саме
• Для деяких людей домашня тварина - обов’язкова

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

Джерела:

1. Ваш чудотворний мозок: Максимізуйте свій мозковий потенціал, підвищуйте пам’ять, піднімайте настрій, покращуйте IQ та творчість, запобігайте та зворотному розумовому старінню
2. Кількісно оцінене Я
3. Сет Робертс - в науковій американській

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

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

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

Шукайте іншу роботу.

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

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

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

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

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

Макет коду чисто, використовуючи стільки рядків, скільки потрібно. Складний код може заплутати оптимізатор і може призвести до уповільнення коду. Сучасні компілятори дуже добре оптимізують код, довіряють йому зробити свою роботу.

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

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

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

Роберт висвітлив найважливіші аспекти.

Я працював у таких середовищах, де код не (не може) жити більше шести місяців. Є декілька правил, які я можу придумати:

1. Використовуйте бібліотеки з відкритим кодом, сторонні рішення тощо.,. Навчання окупається за рахунок меншого обслуговування та налагодження. Однак якщо ви застрягли в бібліотеці-баггі, ви приречені.
2. Суворо переконайтеся, що ваш дизайн розширюється. Обов’язкова вимога: більша частина роботи надходить як покращення, а не побудова нових функцій.
3. Побудуйте жорсткі плани випробувань. Отримайте QA або автоматизуйте тести, щоб забезпечити тест регресії.
4. Використовуйте розумні інструменти - IDE, утиліти для генерації коду тощо.
5. Зберігайте речі максимально налаштовані. (Зворотний бік - посилення тестування)
6. Підвищити швидкість набору тексту :-)

На стадії проектування поговоріть з колегами .

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

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

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

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

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

Нарешті: як я вже говорив *, вам потрібно навчитися говорити "ні" .

* Як кодувати за дуже щільним графіком?

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

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

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

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

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

Вони не можуть скоротити рамки або перенести термін, якщо ви нічого не скажете.

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

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

Іноді це частина вашої трудової етики, чи просто ви зшивати пацієнта, не миючи руки, бо "немає часу"?

Перш за все, пам’ятайте: пізнішого немає.

Я розробник .Net, який працює над веб-додатками.

Що я почав робити -

Якщо це код C #, я спробую спершу записати цей код у LinqPad (якщо можливо).

Якщо це код Javascript, я спершу записую цей код і перевіряю його у jsfiddle / jsbin (якщо можливо).

Я виявив, що це допомагає в якості коду, але не сповільнює мене (і в кількох випадках я виявив, що це швидше).