Якщо моя команда має низьку кваліфікацію, чи варто знижувати вміння свого коду? [зачинено]

Наприклад, у JS є загальний фрагмент, щоб отримати значення за замовчуванням:

function f(x) {
    x = x || 'default_value';
}

Цей фрагмент не легко зрозуміти всім членам моєї команди, рівень їх JS низький.

Чи не повинен я тоді використовувати цей трюк? Це робить код менш читабельним однолітками, але більш читабельним, ніж наступний, відповідно до будь-якого розробника JS:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

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

Отже, чи варто знижувати рівень свого коду, якщо товариші по команді мають нижчий рівень, ніж я?

Гаразд, тут я берусь на цю велику і складну тему.

Плюси збереження вашого стилю кодування:

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

Мінуси щодо збереження вашого стилю кодування:

• Програмістам нижчого рівня буде важче йти в ногу. Це часто люди, які підтримують ваш код, і ті, кому доведеться насправді читати те, що ви пишете.
• Підтримувачі коду, часто JavaScript-код походять з інших мов. Ваші програмісти можуть бути компетентними на Java або C #, але не розуміють, як і коли точно відрізняється JavaScript. Ці пункти часто ідіоматичні - вираз функціонування, що негайно викликається (IIFE), є прикладом такої конструкції.

Моя особиста думка

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

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

Найголовніше - залишатися послідовними.

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

Прокоментуйте добре

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

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

Питання стилю?

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

Як уже сказано в іншій відповіді, зберігайте її послідовно .

Навчіть людину рибалити ...

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

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

«Розумні» хитрощі

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

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

KISS

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

Здається, існує величезна неприязнь до створення функції в JS. Ця відраза змушує людей намагатися бути кмітливими та використовувати смішні хитрощі лише для того, щоб утримати речі в одній лінії, як це було б виклик функції. Звичайно, ім'я функції в дзвінку також є додатковою документацією. Ми не можемо прив’язати коментар до хитромудрого висловлювання, оскільки тоді це призведе до перемоги над точкою його виконання, тому ми просто називаємо це "js idiom" і раптом це зрозуміло.

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

x = x || 'default_value';

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

Коли я дивлюся на цей код я бачу « , якщо це nullабо undefined, то встановіть його значення по замовчуванню. Незважаючи на те, що буде також побічно ставитися +0, -0, NaN, falseі , ""як не підходять значення. Я повинен пам'ятати , що 3 місяці з цього моменту , коли що потреби щоб змінити. Я, мабуть, забуду це ".

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

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

Ви можете піти з:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

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

Тепер, як ви розмежовуєте функцію розширеної мови, як передача функції в якості аргументу чи розумну хитрість, як || "default"?

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

| 0або культова версія, що ~~numвикористовується для підлоги, передбачає позитивні і 32-бітні цілі межі.

|| "default" припускає, що всі хибні значення такі ж, як взагалі не передавати аргумент.

І так далі.

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

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

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

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

Загальна інструкція

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

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

Конкретний приклад

У нашій кодовій базі є велика кількість сценаріїв perl. Ми зазвичай використовуємо perl лише для дуже простих операцій, і переважна більшість кодів написані розробниками java, тому він стильно схожий на java. У нас є набір сценаріїв perl та фреймворк, який був написаний 'гуру Perl', який з того часу покинув нашу фірму. Цей код містить багато більш незрозумілих ідіом Perl, і ніхто з наших розробників, включаючи мене, не може прочитати цей код Perl без великих зусиль. Ми часто проклинаємо його за це. :)

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

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

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

Читаючи це запитання та наступні відповіді та дискусії, схоже, є два моменти. Перше: чи добре використовувати розширені функції мови? Друге: як я можу це зробити, не здаючись, ніби я "показуюсь"?

У першому випадку має сенс використовувати вдосконалення та розширені функції. Наприклад: у C # вам не потрібно використовувати вирази Linq або Lambda, але більшість людей це робить, оскільки це робить код більш чітким і легшим для розуміння, коли ви насправді знаєте, що це робить. Спочатку це просто дивно виглядає.

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

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

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

Тоді не працюйте на Royal McBee Computer Corp тоді, хто може сказати, що ви не досвідчений програміст.

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

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

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

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

Ну, а для початківців, що мені схоже на базовий JS.

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

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

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

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

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

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

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

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

Таким чином, ви можете вводити та читати, x = x || 10а інші програмісти будуть читати це як

if (0 == x) { x = 10;}

emacs має всі частини, щоб зробити це легко.

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

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