14 рекомендацій з особистого досвіду для розробників

via Shutterstock .

Всім привіт .
Я як розробник з невеликим стажем хочу поділитися рекомендаціями , які можуть виявитися корисними деяким з вас . Чим досвідченіший розробник , тим більша кількість перерахованих нижче рад здасться йому очевидними і банальними . Для новачків деякі пункти можуть здатися що йдуть врозріз зі здоровим глуздом. У цьому немає нічого страшного - досвід лікує : ) Рекомендації 1 . Пишіть тільки той код , який вам дійсно необхідний в даний момент ( принцип YAGNI ) Невикористовуваний код з'являється через наступних « відмазок » : « В майбутньому нам точно знадобиться дана функціональність. Чому б не реалізувати її прямо зараз? " « Дана абстракція виглядає незавершеною без цієї функціональності , яка зараз не використовується. Але ж в майбутньому вона обов'язково буде використовуватися ! " Код «про запас » поганий з наступних причин : Істотна його частина ніколи так і не буде використана. Такий код постійно забирає час розробників на його підтримку (читання , аналіз і оновлення ) . До моменту , коли довгий час лежав без діла код знайде застосування , в ньому може накопичитися купа багів і « косяків » , на виявлення та виправлення яких піде більше часу , ніж на написання « з нуля» аналогічного коду . Невикористовуваний код може ускладнити рефакторинг або розширення функціональності проекту , що в підсумку призведе до зниження загальної якості коду та швидкості впровадження нових « фіч » . 2 . Безжально видаляйте застарілий код Під застарілим я розумію весь код , який перестав використовуватися внаслідок розвитку проекту. Таким чином , весь застарілий код є невживаною. Ще раз прочитайте попередній пункт , якщо не розумієте , навіщо видаляти закинутий код . Якщо ви залишаєте застарілий код в надії використовувати його в майбутньому , то даремно . Як показує практика , набагато простіше і дешевше заново реалізувати функціональність , коли вона знадобиться знову , ніж намагатися « воскресити » застарілий код , адаптувати його під нові потреби і виловити всі баги . Якщо ви турбуєтеся , що в видаляється коді містяться дуже цінні алгоритми , то їх завжди можна « витягнути» з історії будь-якої системи контролю версій . Адже ви користуєтеся хоч однієї ? 3 . Починайте новий проект з мінімального набору функціональності ( Minimum viable product ) Успішний проект автоматично обросте свистілки з перделкі в майбутньому , навіть якщо всіляко перешкоджати цьому . Якщо спробувати реалізувати в новому проекті відразу ж мільйон фіч , то , швидше за все , проект ніколи не побачить світ , а якщо і побачить , то навряд чи стане успішним . 4 . Проводите постійний рефакторинг Будь-якому успішно розвивати проекту властиві дві постійні тенденції: Погіршення якості коду за рахунок неминучого додавання нових свістелок з перделкі . Поява нових можливостей для рефакторінга , що приводить до підвищення якості коду . Очевидно , що якість коду в розвивається проекті може втриматися тільки за допомогою постійного рефакторінга . Якщо « забути » про рефакторинг , то з плином часу проект перетвориться на говнокод , з яким ніхто не захоче мати справи. Це може привести до зупинки його розвитку. 5 . Віддавайте перевагу прості рішення складних ( принцип KISS ) Прості рішення легше піддаються подальшому розширенню , рефакторингу і налагодженні, у порівнянні зі складними рішеннями . Все геніальне просто. Завжди намагайтеся спростити , а не ускладнити архітектуру проектів , над якими працюєте . 6 . Тупий , але зрозумілий код завжди краще геніального , але заплутаного Подумайте про програмістів , які намагатимуться розбиратися , підтримувати , розширювати , рефактору і виправляти баги в вашому «розумному » коді . Я їм не заздрю ??. До речі , одним з цих програмістів можете стати ви через півроку після розробки « геніального » коду . Тому не намагайтеся відразу ж впровадити в продакшн всі ідеї , почерпнуті з наступних спеціальних дисциплін ( список неповний) : Аспектно - орієнтоване програмування . Функціональне програмування . Шаблони проектування . Нові , неймовірно поліпшені можливості С ++ або іншої мови програмування . Event loop . Node.js . Впроваджувати в продакшн « геніальний» код особливо люблять початківці програмісти . Набравшись досвіду і набивши гуль з підтримкою , вони сильно жалкують про скоєне. По собі знаю :) Вищевказані дисципліни можуть бути корисними лише в руках досвідчених розробників , які усвідомлюють не тільки переваги описаних там ідей , але і їх недоліки. 7 . Не захаращуйте проект непотрібними абстракціями у вигляді проміжних API , фреймворків , класів та інтерфейсів Наступні ознаки дозволяють виявити непотрібні абстракції : Якщо для реалізації нової функціональності , не передбаченої в абстракції , доводиться переписувати пів- проекту , то під час переписування сміливо видаляйте таку абстракцію . Якщо абстракція істотно ускладнює налагодження коду , то швидше випилюють її з проекту. Якщо тільки одна людина на проекті може коректно використовувати наданий абстракцією API , то є привід задуматися про сенс її існування. У більшості випадків такою людиною є автор абстракції . Якщо проблеми , пов'язані з використанням абстракції , виправляються методом випадкових правок коду , то щось не так з цією абстракцією . Якщо новачкам на проекті доводиться витрачати більше тижня на вивчення правильного використання , занадто заумної абстракції , то варто подумати над її спрощенням або повною відмовою від неї. Якщо обсяг корисного для проекту коду , що міститься в абстракції і в місцях її використання , становить лише невелику частину від обсягу допоміжного коду , то краще замінити абстракцію парою простих у використанні функцій . Якщо захований за абстракцією функціонал простіше використовувати безпосередньо, минаючи абстракцію , то з великою часткою ймовірності дана абстракція перетвориться на leaky abstraction , зробивши безглуздим власне існування. 8 . Не намагайтеся продумати архітектуру нового проекту або « фичи » до дрібниць перед її реалізацією Краще витратити один день на створення працюючого прототипу з не дуже якісним кодом , ніж півроку на продумування « ідеальної» архітектури. Як показує практика , в обох випадках доведеться переписувати майже все з нуля . Відмінність лише в тому , що в першому випадку ми можемо за решту півроку « вилизати » архітектуру , ідеально відповідну для практичних потреб. А в другому випадку через півроку у нас буде лише сферичний кінь у вакуумі , навряд чи ідеально працює на практиці . 9 . Не бійтеся копіпасти копіпаст в майбутньому простіше згорнути в окремі функції , ніж намагатися відразу ж придумати правильний набір функцій , відповідний для всіх можливих місць з потенційною копіпаст . 10 . Не намагайтеся сильно оптимізувати код до того , як він почне гальмувати IRL Оптимізуйте тільки знайдені за допомогою профілювання вузькі місця. Зазвичай вони складають максимум пару відсотків від усього коду . Це не означає , що за кодом потрібно спеціально розкидати O ( n ) алгоритми замість O ( 1 ) алгоритмів . Але й вичавлювати максимум зі всіх підряд алгоритмів в коді не варто - даремно витратите час (тому абсолютна більшість « прискорених » алгоритмів будуть рідко виконуватися на практиці) а також можете погіршити якість коду занадто « розумними» алгоритмами . 11 . Не витрачайте багато часу на highly scalable архітектуру в нових проектах Як показує практика , абсолютна більшість нових проектів ніколи не виходять за рамки пари-трійки серверів . Так навіщо витрачати час на high scalability там , де вона з ймовірністю 99.999 % не знадобиться ? Якщо ж вашому проекту пощастить і його відвідуваність почне стрімко наближатися до відвідуваності Facebook , то у вас з'явиться достатньо коштів для оплати роботи кращих фахівців з високонавантажених системам , щоб вони в мінімально стислі терміни адаптували вашу архітектуру під мільярд одночасних відвідувачів. 12 . Краще мати 10 різних простих у використанні функцій , які приймають по одному-два параметра , ніж одну функцію - швейцарський ніж , приймаючу 5 обов'язкових та 5 опціональних параметрів Чим більше у функції параметрів , тим складніше її використовувати , розширювати , налагоджувати і рефактору . Тому розбивайте функції зі зростаючою кількістю параметрів на окремі функції . 13 . Намагайтеся дати всім публічним ідентифікаторам в коді ( модулям , класам , функціям , змінним ) різні імена , навіть якщо вони належать різним класам/модулям/бібліотекам/пакетам Тупий рада ? Для кого як . Мені він допомагає швидко знайти всі місця використання конкретного ідентифікатора в коді за допомогою програми grep :) Якщо ви думаєте , що це призведе до занадто довгим ідентифікаторам у великих проектах , то це теж не так - див . , наприклад , код ядра linux , що складається з десятків мільйонів рядків . 14 . Чітко розділяйте відповідальність - за кожну ділянку коду має відповідати одна розробник Якщо на проекті працює кілька розробників , то бажано чітко розділити обов'язки . Це дасть такі переваги порівняно із загальним (тобто нічиїм ) кодом : Кожен адекватний розробник буде намагатися підтримувати якість коду , за який він відповідає. Якщо сторонній розробник спробує редагувати чужий код , то буде негайно виявлений і « покараний » господарем. Кожен розробник з плином часу стане « профі» на своїй ділянці . Розробники не зможуть грати в пінг - понг з багами , ссилаяь на те , що «це не мій код» . Все це призведе до поліпшення якості коду , до зниження кількості багів і до прискореного впровадження нових « фіч » . Висновок Вищевказані рекомендації не слід сприймати як догму. Вони підійдуть не всім , тому що у кожного свій досвід і свої погляди на розробку. Як і будь-які інші поради , вони не позбавлені недоліків . Серед них немає silver bullet , магічним чином вирішальною всі ваші проблеми. Я б порадив проаналізувати їх і , може бути , почерпнути корисну інформацію для себе .

Опубліковано: 11/08/14 @ 06:35
Розділ Різне

SEO Блог

14 рекомендацій з особистого досвіду для розробників

Рекомендуємо: