Я змушений писати поганий код. Як зберегти обличчя? [зачинено]

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

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

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

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

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

Погодьтеся з С.Лоттом з коментарів * (на раз :) Ніхто не змушує вас писати поганий код. Річ у тому, молодший дев. часто (цей сайт також винен у цьому) губляться в кращих практиках, "прекрасному коді", ... як би ви цього не хотіли назвати ... і вони не роблять багато чого; або вони це роблять, але витрачають багато часу. Повідомляючи їм писати поганий код (який є кодом, який також працює), він отримує, ніж "через це", просто змушує їх щось доставити. Із часом виходить, що (зараз вже не :) молодший розробник дуже швидко придумує швидке та брудне рішення, але витрачає решту часу на його вдосконалення. І як проходить час, ви дізнаєтесь більше, і в якийсь момент ви починаєте доставляти швидкі та брудні рішення, які насправді є хорошим кодом.

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

Отже ... пишіть неправильний код, ... багато його ... код, який ледь працює, а потім ІТЕРАТУЙТЕ. Кожна ітерація трохи краща!

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

* це, якби він був коротшим, був би коментар.

Коментарі до коду - ваш друг тут.

Кожного разу, коли вам здається, що вам доведеться написати якийсь дешевий злом через тиск, просто скажіть щось на кшталт: "Цей код робить X через часові обмеження. В ідеалі я б зробив Y замість цього - Соромно, 5 липня 2011 року"

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

Це залежить від того, як вони вас змушують.

На мій досвід, є дві можливості:

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

У цьому випадку, як уже говориться в більшості інших відповідей, вам належить «оптимізувати прохолоду». Можливо, у вас немає часу переписати кодову базу на MVC, але, як перший крок, наприклад, ви можете перестати склеювати свій SQL вручну і замість цього написати хороший execute_sql($query, $params), що закладає основу для абстракцій fetch_customer($filter_params), тощо. Пам'ятайте, все найкраще Зрештою, практика полягає в тому, що ваш начальник отримує продукт раніше, тому існує лише конфлікт у тому, скільки часу інвестувати в майбутнє проти цього в даний час.

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

Вам прямо наказано реалізувати це так, як вважаєте непридатним

Спроба відокремити перегляд від моделі не перегляне огляд, оскільки "це занадто складно, чому ви просто не робите звичайні запити sql?" Ви execute_sqlотримуєте консерви, оскільки "кодеру з дисципліною цього не потрібно".

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

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

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

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

Якщо все інше не вдасться, ідіть шукайте іншу роботу.

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

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

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

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

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

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

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

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

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

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

Я впевнений, що існує багато інструментів, які можна безкоштовно використовувати для аналізу коду PHP http://en.wikipedia.org/wiki/Code_analysis

Також, звичайно, це http://en.wikipedia.org/wiki/Code_smell

Прочитайте його, підведіть підсумки, що ви можете знайти у своїй заявці, і, звичайно, перелічіть альтернативи . Його погана практика - просто встати і кричати "Мені не подобається, як це робиться", не представляючи альтернативного (бажано) кращого способу зробити це.

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

чт

Перш за все, ви ВИ ВИКОРИСТОВУєте джерело керування джерелом, правда? Якщо ні, почніть звідти. Це допоможе вам першим і швидко буде прийнято рештою команди.

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

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

Щоб навести мій приклад, я одного разу прийшов в середині проекту з програмою Perl / CGI, де весь код був у коді. Весь додаток було в одному файлі без чіткої структури. Нічого не піддавали сумніву. Я почав з налаштування репортажу CVS (на той час немає SVN), поставив на нього веб-інтерфейс для замовника. Спочатку я сам розбирався з комітами. Потім я розділив усі методи на різні модулі (файли). У цей момент колеги почали приймати CVS. Потім я перемістив HTML-код із коду. Потім, кожного разу, коли мені доводилося вносити зміни в якусь частину коду, мені потрібно було небагато часу, щоб переробити частину цього коду. Зрештою, швидкість розвитку настільки зросла, що клієнт був надзвичайно задоволений. Вони б просили косметичну зміну, і замість того, щоб ми сказали їм "це займе 2 дні",

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

І останнє, повне перезапис - це часом єдине рішення, але, як правило, дуже важко виправдати свої витрати на управління.

Оскільки ви молодший розробник, це насправді гарна річ. Перекинувшись в середину великого безладного коду, ви навчите вас набагато більше того, чого не робити, ніж працювати лише над ідеально «чистим» кодом. Скористайтеся ситуацією і дізнайтеся, як відновлювати поганий код і повільно перетворювати його в щось більш кероване. І не нарікайте на це, що треба як можна швидше. У цьому суть - навчитися переробляти та прибирати код, роблячи справи у строгий термін. Адже будь-хто може написати ідеальний код, якщо у нього є нескінченний час.