15 жахливих порад веброзробникам

Упевнені, ви чули чимало хороших настанов про те, як підвищити якість своєї роботи. Але... як щодо поганих порад? Переклали для вас статтю про 15 жахливих порад веброзробникам. Тож, якщо раптом ви давно мріяли трохи пожартувати над колегами, записуйте варіанти!

1. Шари абстракції. Використовуйте якомога більше рівнів абстракції, поки:

  • код важко зрозуміти та налагодити;
  • зміни до коду вносити важко;
  • код повільний або неефективний;
  • код не багаторазовий.

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

  • зробіть ім’я змінної довшим;
  • зробіть імʼя змінної коротшим;
  • перейменуйте імʼя змінної;
  • зробіть код ще більш DRY.

3. Ні комітам! Аби написати хороші коміти, потрібний ваш дорогоцінний час. Не витрачайте його на це! Замість цього напишіть, наприклад:
[JIRA-1234] build: replace vue-cli with vite
Ви можете використати цю команду, аби запушити ваш код з пустим комітом:
git commit --allow-empty-message -m "" && git push --force

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

window.scrollTo({
 top: 89,
 left: 12,
 behavior: "smooth",
});

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

function shouldPayTax(income) {
 if(income.amount < 20_000) {
   return false
 }
 if(income.amount > 20_000 && income.country == 'USA') {
   return true
 }
 if(income.country == 'Panama') {
   return false
 }
 if(this.totalWorkingHoursPerWeek > 60) {
   return true
 }
 if(income.amount > 20_000 && income.isCelebrity == true) {
   return false
 }
 if(income.amount > 20_000) {
   return true
 }
}

6. TypeScript. Якщо хтось мав нахабство додати до проєкту TypeScript, ви можете уникнути type-перевірку: використовуйте any повсюди.

function add(a:any, b:any):any {
 return a + b
}

7. Використовуйте два знаки рівності == замість трьох ===. Памʼятайте, ваше головне завдання: зекономити такі цінні байти у bundle-продакшені.

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

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

9. Використовуйте пропозиції для синхронного стейту. Передача стейту за допомогою пропозицій — чудовий спосіб об’єднати ієрархію компонентів і зробити рефакторинг простішим.

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

11. Довгі файли компонентів. Використовуйте великі та монолітні компоненти, аби мати кращий вигляд обовʼязків компонентів та можливість повторного використання змінних у різних функціях.

12.Ніяких лінтерів. Лінтер може аналізувати ваш код і виявляти потенційні помилки, невідповідності та відхилення від встановлених стандартів кодування, а це те, чого ми точно не хочемо.
Різниця між двома фрагментами очевидна:

const props=defineProps({
elements:Array,
counter:{
type:Number,
default:0,
},
});
const{data,method}=useComposable();
const isEmpty=computed(()=>{returnprops.counter===0;});

watch(props.counter,()=>{console.log("Countervaluechanged");});
const emit=defineEmits(["event-name"]);

function emitEvent(){
emit("event-name");
}

function getParam(param){
return param;
}
const props = defineProps({
 elements: Array,
 counter: {
   type: Number,
   default: 0,
 },
});

const { data, method } = useComposable();

const isEmpty = computed(() => {
 return props.counter === 0;
});

watch(props.counter, () => {
 console.log("Counter value changed");
});

const emit = defineEmits(["event-name"]);

function emitEvent() {
 emit("event-name");
}

function getParam(param) {
 return param;
}

Порада для професіоналів: єдине прийнятне використання правила лінкування — це коли файл довший за задану кількість рядків. 1000 — дуже симпатичне початкове число.

13. Використовуйте HTML у перекладах. Використання жорстко закодованих рядків — це завжди гарна ідея. Але іноді використання перекладів, які містять html-елементи та класи, може бути ще кращим:
translation.key.name = Hello <span class="red">World!</span>

14.Пишіть тести. Не писати тести — це хороший варіант, але поганий набір може принести ще більше розчарувань. Як правило, тест повинен бути:

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

15. Вчіться довіряти. І нарешті: безпечне програмування — це для слабких. Хто взагалі думає заподіяти вам шкоду?

А що порадите ви?

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Що таке пропозиції? )))) і де посилання на оригінал? 😏

Добрий день підскажіть як в коді знайти блок на зміну в Atmel studio 7.0 буду дуже вдячний)

Кент Бек — Extream programming, Роберт Мартін — Clean Code, та Мартін Фаулер — Refactoring у якості статті токсичного frontender-а :) Як то кажуть читати книжки, де галузеві спеціалісти діляться знаннями набутими в галузі це — ні, а от набити шишки власним досвідом — це так.

пункт п’ять неповний. один з returnів має повертити null або 0

не заради срачу, але я б порадив не використовувати google translate для перекладу або хоча б давати розробникам(тим які працюють в dou) прочитати переклад перед публікацією.

хз шо гірше: дієвидло чи запит на вилучення(pull request, запит на злиття/стягнення/стягування) чи пропозиції (props в реакті, атрибути/характеристики мабуть)

Такі речі як pull request, cache, display, merge і інші терміни краще взагалі не переркладати взагалі. Це така російсько радянська звичка, шкідлива. Як перекласти System Variable українською досі не знаю — «Змінна середи» як на мене жодним чином невірний переклад. Переклад Source Code — як вихідні коди, особисто мене коробить. Термін в такому перекладі не відповідає суті того, що він означає, навідміну від похідного коду, чи старого доброго «сорци».

у будь який спосіб намагайтеся знайти шлях до пуш-у прямо у master/main гілку — та пам"ятайте що пулл реквести то для тих хто не впевнений в своєму коді АЛЕ ваш код завжди вірний він завжда працює

У нас створення нових MR налаштоване в main гілку по дефолту) Тиждень тому новий розробник (2 місяці на проекті) замержив свій MR прямо в main опівночі і зламав прод. Потім сказав нам, що ніколи не зустрічав, щоб прод-гілка називалась main, типу, повинна мати те саме імʼя, що й енв. В людини близько 10 років досвіду.

замержив свій MR прямо в main

вибачаюся але чи налаштован у вас захист основної гілки? Якщо ні то те що не заборонено то є дозволено

Тільки захист від видалення. А ви маєте на увазі якийсь захист від мержу в неї — комусь дозволено, комусь ні? Так то, у нас в усіх розробників однакові права.

ну то мабудь й проблеми з неконтрольованими комітами напряму у головну гілку.
авжеж то вам вирішувати як краще але на багатьох проєктах де я працював був певний захист головних гілок сховищь коду. ну тобто- злиття з головною гілкою тільки чезер PR як мінімум 2 ревьювера які дозволяють злиття, покриття тестами > 90%, усі модульні та інтеграційні тести пройдено ну та й інші ступені захисту. Це допомогає підтримувати год у основній гілці у досить високому стані тож після того як він проходить автоматичні тести, він одразу попадає на прод — тобто 1-2 рази на місяць коли закінчені певні фічі яки потрібно додати... Деякі помилки всеодно є але вони більш функціональні і не критичні. В жодному разі ніхто ніколи не може напряму заливати код напряму у головну гілку — навіть архітектори котрі іноді «бавляться» з кодом

У нас таких процесів немає і боюсь, що й не буде. Проект відносно невеликий і новий (зарелізили менше року тому), команда маленька — всього два бекендера + фронт, який з Гітлабом не працює взагалі. Тестів немає взагалі, нашим кастомерам тести непотрібні, їм аби швидше розробляли нові фічі. При мені за 2,5 роки з компанії кастомерів втекло два архітектори, які хотіли щось змінити на краще (не тільки у нас, а й на інших проектах компанії, які, навідміну від нашого, ще й старі, як гівно мамонта), але так і не вдалося(

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

замержив свій MR прямо в main опівночі і зламав прод.

Ну це якось поганенько там налаштовано, бо пайплайни CI/CD в принципі мають запобігати виникненню неробочого коду в проді, та/чи його гілці, тобто ніяких прямих мерджів, а тільки через PR/MR з запуском всіх QA пайплайнів, як і при релізі. Зламати продукт пересічному можна тільки при поганому покритті тестами, чи кривих тестах і відповідно поганих процесів ревью.

Потім сказав нам, що ніколи не зустрічав, щоб прод-гілка називалась main

Може пропустив хвилю толерантності і подумав що то dev гілка типу feature -> main(dev) -> master(prod)

В чому проблема то? Він ж не робив прямий коміт

Проблема в тому, що мерж реквести повинні проходити ревью. Створити реквест і тут же самому замержити його в прод — це, фактично, те саме, що й закомітити в прод напряму. В прод на даний момент мержу лише я. Для нього процедура стандартна (і це було обговорено одразу) — створення feature branch + merge request по готовності, все. Друга проблема в тому, що зроблено це було опівночі, коли куа не може швидко потестити зміни на проді.

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

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

тоді «война і мір» вийде, а треба проект на реакті.

Підписатись на коментарі