Проект почти завершен, но процедурный код спагетти. Переписывать или просто пытаться отправить его? [закрыто]

Я начинающий веб-разработчик (один год опыта).

Через пару недель после окончания обучения мне предложили работу по созданию веб-приложения для компании, владельцем которой не является технический парень. Он нанял меня, чтобы избежать кражи его идеи, высокой стоимости разработки, взимаемой сервисной компанией, и иметь кого-то молодого, которому он может доверять на борту, чтобы поддерживать проект в долгосрочной перспективе (я сам пришел к этим выводам после того, как был нанят ).

Кокетливый, как я был тогда, с дипломом по информатике, я принял предложение, думая, что смогу что-нибудь построить.

Я вызывал выстрелы. После некоторого исследования я остановился на PHP и начал с простого PHP, никаких объектов, просто уродливого процедурного кода. Два месяца спустя все становилось беспорядочным, и было трудно добиться какого-либо прогресса. Веб-приложение огромно. Поэтому я решил проверить структуру MVC, которая облегчила бы мою жизнь. Вот где я наткнулся на классного парня в сообществе PHP: Laravel. Мне понравилось, это было легко узнать, и я сразу начал кодировать. Мой код выглядел более чистым, более организованным. Это выглядело очень хорошо.

Но снова веб-приложение было огромным. Компания оказывала на меня давление, чтобы предоставить первую версию, которую они хотели развернуть, и начать искать клиентов.

Поскольку Ларавелу было весело работать, это заставило меня вспомнить, почему я выбрал эту отрасль в первую очередь - что-то, что я забыл, застряв в дерьмовой системе образования.

Итак, я начал работать над небольшими проектами в ночное время, читая о методологиях и лучшей практике. Я снова просмотрел ООП, перешел к объектно-ориентированному дизайну и анализу и прочитал книгу дяди Боба Clean Code .

Это помогло мне понять, что я действительно ничего не знал. Я не знал, как создать программное обеспечение THE RIGHT WAY. Но в этот момент было уже слишком поздно, и теперь я почти закончил. Мой код не чист вообще, просто код спагетти, настоящая боль, чтобы исправить ошибку, вся логика находится в контроллерах, и мало объектно-ориентированного дизайна.

У меня такая настойчивая мысль, что я должен переписать весь проект. Однако я не могу этого сделать ... Они продолжают спрашивать, когда все будет сделано.

Я не могу представить этот код, развернутый на сервере. Кроме того, я до сих пор ничего не знаю о эффективности кода и производительности веб-приложения.

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

Я переписываю или просто пытаюсь отправить, или есть другой вариант, который я пропустил?

239 голосов | спросил solidsnake 15 J000000Tuesday14 2014, 07:48:42

16 ответов


251

Вы наткнулись на ахиллесную пяту большинства образований CS: они учат вас инструментам и приемам, но не торговле. Построение программного обеспечения - это ремесло, которое вы приобретаете только через многолетнюю практику и опыт использования вашего программного обеспечения (пользователи гораздо более резкие критики, чем учителя). Программное обеспечение для построения также довольно часто является бизнесом, где бизнес-цели могут переопределить технические амбиции.

Прежде всего, корабль. Если вы покажете владельцу бизнеса программное обеспечение, и они чувствуют, что оно готово к отправке, тогда отправляйте его. Если это не так, но близко, закончите. Единственное программное обеспечение, которое имеет значение, - это то, что фактически используется. Единственный программный бизнес, который зарабатывает деньги, - это продукт, который имеет продукт.

Во-вторых, вы узнали много ценных вещей, поэтому вам следует оценить опыт того, чему он вас научил :

  1. Slinging code без плана или архитектуры - это рецепт катастрофы
  2. Программирование гораздо больше, чем написание кода
  3. Нетехнические владельцы бизнеса часто не понимают влияния технических решений (например, тех, кто нанимает), и разработчики должны объяснять им вещи.
  4. Большинство проблем уже решены намного лучше, чем вы их решаете в существующих рамках. Он платит, чтобы знать рамки, которые существуют и когда их использовать.
  5. Люди, которые недавно вышли из школы, назначенные на большой проект с небольшим руководством, как правило, создают миску кода спагетти. Это нормально.

Вот еще несколько советов для вас о том, как действовать:

  1. Общайтесь, общайтесь, общайтесь. Вы должны быть очень откровенными и откровенными в отношении состояния проекта и ваших идей о том, как действовать, даже если вы не уверены и видите несколько путей. Это оставляет владельцу бизнеса выбор того, что делать. Если вы сохраняете знания для себя, вы лишаете их выбора.
  2. Сопротивляйтесь соблазну полного переписывания. Пока вы переписываете, у бизнеса нет продукта. Кроме того, переписывание редко получается так хорошо, как вы себе представляли. Вместо этого выберите архитектуру и постепенно переместите кодовую базу. Таким образом, даже ужасная кодовая база может быть спасена. Читайте книги о рефакторинге, чтобы помочь вам.
  3. Узнайте об автоматическом тестировании / модульном тестировании . Вы должны укреплять доверие к коду, и способ сделать это - покрыть его автоматическими тестами. Это идет рука об руку с рефакторингом. Пока у вас нет тестов, проверьте вручную и всесторонне (попытайтесь сломать свой код, потому что ваши пользователи сделают это). Запишите все найденные вами ошибки, чтобы вы могли расставить приоритеты и исправить их (у вас не будет времени исправить все ошибки, никакое программное обеспечение не будет загружено без ошибок в реальном мире).
  4. Узнайте, как развернуть веб-приложение и сохранить его. Книга Веб-операции: ведение данных вовремя - хорошее начало.
ответил Joeri Sebrechts 15 J000000Tuesday14 2014, 11:39:43
113

Это звучит, как любая другая система, которая была брошена мне на исправление.

Расслабьтесь, это случается с большим количеством людей. Юниор, брошенный в глубокий конец без опыта, который не имеет никакой помощи, никакой поддержки и никакого руководства не является точно рецептом успеха. Наем и ожидая, что младший программист построит совершенно новую систему с нуля, которая хорошо работает, хорошо работает и поддерживается не совсем реалистично. Черт, тебе повезло, если все это происходит со старшим программистом.

По-моему, вы должны прийти в себя. Это не будет весело. Скажите им, что вы сделали все возможное, он работает (в основном), но вы обеспокоены тем, что он может плохо работать и что будет много ошибок (есть ошибки всегда ). Он должен быть рассмотрен старшим программистом, и они должны иметь возможность быстро устранить любые вопиющие проблемы с производительностью /безопасностью. Или они могут развернуть его и скрестить пальцы. Это будет либо нормально, либо дым. Возможно, вы можете исправить проблемы по мере их появления. Если у вас большая база пользователей, возможно, нет.

Или вы могли бы сделать то, что делают большинство людей в этой ситуации: взять деньги, исчезнуть и позволить им разобраться. Я оставлю это для вас, чтобы понять, каков этический выбор.

Изменить (поскольку у этого вопроса много голосов, я мог бы добавить еще немного контента)

Часть радостей быть программистом состоит в том, что нетехнические люди (возможно, ваш менеджер, безусловно, остальная часть бизнеса) не знают, что вы делаете. Это хорошо и плохо. Часть плохого заключается в том, что вы должны постоянно объяснять, как работают проекты разработки программного обеспечения. Планирование, требования, обзоры кода, тестирование, развертывание и исправление ошибок. ваша работа объясняет важность тестирования и выделяет время для тестирования. У вас есть , чтобы стоять здесь. Люди не поймут важность ( «не можем ли мы начать использовать его?» ), но как только они начнут тестировать (не в живой среде!), Они быстро поймут преимущества. Одной из причин, почему они наняли вас, является то, что они ничего не знают о разработке программного обеспечения, поэтому вам решать, как их обучать. Вы должны подчеркнуть важность тестирования и исправления ошибок здесь - помните, что они не программисты, они не знают разницы между делением на ноль и сломанным тегом html.

Часто многие проблемы, которые возникают, на самом деле не являются ошибками. Они будут проблемами удобства использования, пропущенными требованиями, измененными требованиями, ожиданиями пользователей (почему я не могу использовать это на своем мобильном устройстве?), А затем фактические фактические ошибки. Вам нужно их сгладить, прежде чем вы начнете жить - часто многие проблемы могут быть обработаны или исправлены несколькими днями позже. Если люди ожидают идеальной системы, у них будет много боли. Если они ожидают ошибок, ваша жизнь станет намного проще в течение следующих нескольких недель.

Ох и не путайте тестирование пользователя с модульным тестированием и с системным тестированием.

  • Unit Testing - возвращает ли моя функция кода правильное значение
  • Тестирование системы - это ошибка, когда я нажимаю X
  • Тестирование приёма пользователей (UAT) - соответствует ли программа требованиям? Делает ли это то, что они просили вас сделать? Может ли он жить?

Если вы не указали требования того, что они просили вас сделать, UAT будет намного сложнее. Здесь падают многие люди. Наличие того, что они хотели, чтобы система записывалась на бумаге, сделает вашу жизнь намного проще. Они скажут: «Почему он не делает X?» и вы можете сказать: «Ты сказал, чтобы я сделал это». Если программа неправильная, исправьте ее. Если требования неверны, исправьте документ, попросите дополнительный день или два (нет, настаивайте на нем), внесите изменения, обновите документацию и повторите проверку.

Как только вы пройдете этот процесс несколько раз, вы можете начать изучать Agile .. но это другой мир:)

TL; DR Тестирование хорошее

ответил Rocklan 15 J000000Tuesday14 2014, 09:21:51
61

Всякий раз, когда вы начинаете с нуля, вы почти наверняка совершите столько же ошибок или больше из-за второго системного синдрома . Ваши новые ошибки будут разными, но количество времени, необходимое для отладки, будет схожим, и поэтому будет отчаиваться от того, как это не подходит. Это также задержит развертывание в производство или развертывание новых функций, если первая версия будет развернута, что будет проблемой серьезной для компании. Joel Spolsky называет его «одной наихудшей стратегической ошибкой» , которую могут сделать любая компания или разработчик.

Рекомендуемый подход заключается в том, чтобы очистить начальный беспорядок бит за битом во время обслуживания. И даже не пытайтесь реорганизовать его только ради этого. Кроме того, менеджеры обычно видят это как трату денег (что часто бывает), и это приносит ненужный риск введения новых ошибок. Как только вы болезненно отлаживаете код, он может быть некрасивым, но он будет работать. Так что пусть это будет, пока вам не придется прикасаться к нему по другим причинам (будь то исправление ошибок, новая функция или просто изменение, запрошенное маркетингом). Затем очистите детали, которые наиболее трудно настроить. Это часто называют Правило бойскаута .

И в этот момент вам не придется спорить с менеджером. Просто укажите минимальный желаемый рефакторинг в оценке для запроса. Вы научитесь чему-то опыту, когда можете позволить себе немного уступить, потому что компания действительно исправлена, и когда вы не хотите создавать проблемы в будущем и просто не допускаете возможности быстро взломать ее.

Наконец, еще один бит рекомендуемого чтения: Большой шар грязи .

ответил Jan Hudec 15 J000000Tuesday14 2014, 11:36:12
28

Я забыл, где я его сначала прочитал, но я просто хотел повторить, несколько более решительно, что другие люди сказали:

  

Доставка - это функция.

Нет ничего хуже, чем тот парень, который держит «очистку» существующего (возможно, взломанного, уродливого, грязного) кода, который отлично работает , вводя новые ошибки и т. д. Что важно в реальном мир выполняет вашу работу. Вы сделали это. Корабль. Не теряйтесь в редизайне проекта, который работает отлично, даже если он уродливый под капотом. Когда вы это исправите, сделайте это постепенно и сделайте себе хороший набор тестов, чтобы иметь как можно меньше регрессий.

ответил Patrick Collins 16 J000000Wednesday14 2014, 09:38:42
24

Каждый проект оставляет вас умнее, чем вы были раньше. После каждого проекта у вас будет накопленный больше опыта, который был бы очень полезен, если бы у вас было это с самого начала. Я знаю, что трудно не пересмотреть все и применить то, что вы узнали. Но помните:

Идеал - враг добра.

Для клиента всегда лучше иметь хорошее программное обеспечение, чем идеальное программное обеспечение, которое никогда не будет выпущено.

Это был ваш первый проект. В будущем будет еще много проектов, где вы сможете применить все, что вы узнали, с самого начала.

ответил Philipp 15 J000000Tuesday14 2014, 16:09:19
15
  

Я [...] прочитал чистый код дяди Боба.

  

У меня такая настойчивая мысль, что я должен переписать целое   проект.

В этой книге есть раздел, названный очень хорошо, «Великий редизайн в небе».

Не пытайтесь переписать все, потому что, в маловероятном случае, когда у вас есть время, вы все равно столкнетесь с теми же проблемами. Когда вы закончите редизайн, вы узнаете новые вещи и поймете, что первые его части очень непрофессиональны, поэтому вы захотите переписать его снова.

Редизайн и переписывание хороши, но только если они выполняются постепенно по рабочей системе. Как заметил другой пользователь, следуйте правилу бойскаута, мало-помалу, обновляя свой код, когда вы работаете над ним.

ответил abl 15 J000000Tuesday14 2014, 19:03:59
9

Вы делаете хорошо.

Вы говорите, что ваш код работает, и он почти готов к отправке, не так ли? И вы понимаете, что ваш код может быть значительно улучшен. Хорошо.

Ваша дилемма очень напоминает мне мой первый опыт работы с фрилансом (нанятый во время моего второго года в uni для создания многоязычной POS-системы). Я прошел бесконечные допросы, так как я никогда не был доволен кодом, хотел масштабируемости, хотел изобрести лучшие колеса ... Но я просто отложил проект (например, примерно на 12 месяцев) и ... что? Как только вы разворачиваете эту вещь, ей все еще нужно много проверки, тестирования, исправления и т. Д.

Есть ли у вас опыт работы с профессиональными кодовыми базами? Многие кодовые базы полны изворотливого, трудноподдерживаемого кода. Альтернативой обнаружению сложности программного обеспечения, пытаясь построить большую программу самостоятельно, будет поддержка /распространение одинаково грязного кода, написанного другими людьми.

Единственные случаи, когда я видел полные перезаписи, приносят много пользы, когда команда одновременно приняла новую toolchain /framework.

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

Вам нужно, чтобы у вашего клиента было что-то, что они могут использовать. Затем, когда они просят вас улучшить его /добавить функциональность, вы решаете, нужен ли рефактор, и все в порядке, чтобы ваш клиент знал, что «требуется какая-то техническая работа для интеграции указанной новой функции». Благодаря чему они поймут, что это будет стоить им больше денег, и им придется подождать дольше. И они поймут (или вы можете вытащить).

Лучше всего переписать все, когда другой клиент попросит вас создать нечто подобное.

Короче говоря, если вы не сможете продемонстрировать, что все это нанесет удар по лицу каждого, если оно будет развернуто, отсрочка развертывания будет непрофессиональной и не принесет пользы ни вам, ни вашему клиенту. Научитесь делать небольшие рефакторины, исправляя ошибки или добавляя новые функции, которые будут для вас ценным опытом.

ответил 16 J000000Wednesday14 2014, 12:09:14
7

Большинство из того, что я сказал бы в ответ на ваш вопрос, говорили другие. Прочитайте «Вещи, которые вы должны делать, часть I» Джоэла Спольского (наряду с некоторыми другими его сообщениями о «астронавтах архитектуры»). Помните, что «совершенное - враг добра». Учитесь рефакторингу постепенно. Доставка важна и т. Д.

Я бы добавил следующее: вам было поручено что-то, что считалось выполнимым одним новым выпускником, работающим с небольшим стартовым бюджетом /таймфреймом. Вы не должны нуждаться в гораздо более сложном, чем хорошее, структурированное, процедурное программирование. (И, FYI, «процедурное программирование» - не плохое слово. Это необходимость на каком-то уровне в большинстве случаев, и это вполне адекватно для многих целых проектов.)

Просто убедитесь, что вы на самом деле делаем структурированное, процедурное программирование. Повторение в вашем коде не обязательно является признаком того, что вам нужны грандиозные полиморфные структуры. Это может быть просто признаком того, что вам нужно взять повторяющийся код и поместить его в подпрограмму. Управляющий поток «Спагетти» может быть просто возможностью избавиться от глобального.

Если есть аспекты проекта, которые законно вызывают полиморфизм, наследование реализации и т. д., я бы предположил, что, возможно, размер проекта был недооценен.

ответил user1172763 16 J000000Wednesday14 2014, 18:36:43
4

Если вы действительно заинтересованы в дилемме, которую вы имеете, вы также должны прочитать «Lean Startup». Много советов, которые вам дадут здесь, будут больше резонировать с вами, если вы прочтете эту книгу. В принципе, ресурс с годовой скоростью - ваш злейший враг, а ничего больше ценный для вас и вашей организации, чем отзывы конечных пользователей /клиентов. Итак, заведите свой продукт в жизнеспособное состояние (минимальный жизнеспособный продукт или MVP), а затем отправляйте его в дверь (независимо от того, как выглядит код). Пусть ваши клиенты диктуют ваши будущие изменения и версии, а не наоборот. Если вы сосредоточитесь на этом подходе, вы и ваш босс будете счастливее в долгосрочной перспективе.

ответил Unknown Coder 15 J000000Tuesday14 2014, 18:48:49
4

По причинам, которые были подробно объяснены другими, пришло время завершить проект и отправить его, как бы это ни было больно.

Я хотел бы подчеркнуть, что testing приложение также является частью «завершения». Если значительная часть функциональности не была тщательно реализована и исправлена результаты подтверждены, тогда вы будете обоснованы в своей обеспокоенности тем, что люди будут проблема с этим приложением при развертывании.

Модульные тесты и автоматизированные тесты более высокого уровня являются отличными, и вы должны иметь столько, сколько сможете, прежде чем пытаться реорганизовать (или переписать) это приложение. Но прямо сейчас вам нужно проверить , даже если вам нужно выполнить каждый тест «вручную» и подтвердить правильное функционирование «на глаз». Если вы сможете выяснить, как автоматизировать эти тесты позже, это поможет, когда приступит к работе над следующей версией продукта.

У некоторых людей есть умение сидеть перед новым программным проектом в качестве пользователя альфа-теста и делать все по-другому. То есть, они хорошо разбираются в вещах. Если вам повезет, что у вас есть такой талантливый человек, пусть сначала попробуют приложение, чтобы вы могли исправить какие-либо очевидные ошибки раньше. Если вам нужно выполнить эту задачу самостоятельно, выполните следующие действия:

  • Быть методичным.
  • Попробуйте каждую функцию.
  • Предположите, что вы неопытный пользователь вашего приложения. Сделайте глупые ошибки и посмотрите, как их обрабатывает программное обеспечение.
  • Запишите, что вы делаете, чтобы повторить попытку после того, как вы решили устранить проблемы.
ответил David K 16 J000000Wednesday14 2014, 21:29:44
1

В вашем вопросе говорится: «Началось неправильно, я должен начать все сначала», в то время как дополнительный текст на самом деле говорит «Законченный проект, но сделал это неправильно, я должен начать все сначала». Только для одного заголовка вопроса: если объем работы по программированию, который вы сделали, мал по сравнению с общей работой, необходимо начать все сначала. Это случается очень часто, когда проблема сложна и плохо понята, и довольно давно потрачено на то, чтобы выяснить, какова проблема на самом деле. Нет смысла продолжать плохое начало, если выбросить его и начать все сначала, на этот раз с хорошим пониманием проблемы, означает, что вы на самом деле закончите быстрее.

ответил gnasher729 21 J000000Monday14 2014, 04:16:49
0

Это то, что я сделал бы лично:

  1. Бросьте, сделайте предлог и сдайтесь (вы даже можете вернуть часть своей зарплаты, чтобы вы не выглядели плохо).
  2. Очистите свой код как можно больше
  3. Сделайте документацию на всех хороших частях вашей работы, как ваш хороший дизайн, хорошие идеи и т. д.

Почему я предлагаю вам все это?

Потому что думай о будущем. Будет время в будущем, когда некоторые люди овладеют этим кодом. Они будут делать всевозможные предположения и суждения о вас и ваших способностях. Им все равно, когда вы его написали, им все равно. Они только хотят видеть в нем то, что они хотят видеть, чтобы подтвердить все, что они хотят подтвердить.

Вы будете заклеймены как любое плохое имя, срок, который они могут придумать, чтобы негативно повлиять на вас. И хотя вы в будущем вполне могли бы быть совершенно разными с точки зрения технических возможностей, навыки, знания, стиль и ситуация будут такими разными, этот код будет использоваться против вас всеми возможными способами. Это похоже на суд, где они могут сказать все плохие вещи о вас и вашем коде и дизайне, и вы даже не подозреваете об этом, чтобы вы могли объяснить и защитить себя. (и вы можете очень часто учиться, что они глубоко ошибаются, неоднократно). Так что не делайте этого. Откажитесь.

Поверьте мне, есть люди, которые сделали много предположений о вас, потому что в какой-то момент вы делали что-то с какой бы то ни было целью. Для них, если вы сделали это в ситуации A, вы сделаете это в ситуации B. Они думают очень просто.

ответил InformedA 17 J000000Thursday14 2014, 11:25:39
0

Еще два предложения, я поспорю, хотя бы один из них вы не сделали.

1) Поместите контролер ошибок на место и научите своего босса его использовать. Это может быть частью разговора о том, как вы напортачили, узнали лучше и намерены исправить его планомерно

2) Начните использовать управление версиями, хотя, надеюсь, вы уже это делаете.

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

изменить

Ничего себе, кому-то действительно это не понравилось - downvote И флаг удаления? Почему?

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

ответил Andy Dent 21 J000000Monday14 2014, 16:28:27
-2

Чтобы ответить на ваш вопрос: как многие другие говорили, нет. Загрузите его и почистите его по частям в процессе исправления ошибок.

Кроме того, в то время как книги /StackExchange /webforums являются хорошими учебными ресурсами, вы, вероятно, обнаружите, что ничто не может сравниться с обучением, которое вы получите от работы (или даже просто обсуждения работы) с другими программистами. Поиск и посещение местной группы для технологии, которую вы используете или хотели бы узнать, - прекрасная инвестиция вашего времени. Помимо технических знаний, которые необходимо приобрести, это простой способ подключения к сети, который неоценим, поскольку вы с нетерпением ожидаете будущих выступлений.

ответил Chris Kelly 16 J000000Wednesday14 2014, 20:55:25
-2

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

ответил David Carpenter 15 J000000Tuesday14 2014, 20:34:38
-2

Вы начинающий веб-разработчик, без хорошего присутствия разработчика, чтобы советовать вам, ваш босс нанял вас, зная это полностью. Я думаю, вы делаете так же хорошо, как и каждый мог ожидать от вас. Фактически, тот факт, что у вас есть представление о том, что работа могла быть лучше, и что вы на самом деле научились вещам, которые позволят вам сделать это лучше, означает, что вы делаете лучше, чем большинство. Помните о своем собственном здравом рассудке, что версия того, кто начал работу, не смог бы сделать это лучше. Кто-то более опытный (и, следовательно, лучше оплачиваемый), или вы с опытом одного проекта, мог бы сделать это лучше.

Что делать сейчас : будьте счастливы, что вы лучший разработчик, чем год назад. В следующем проекте вы будете лучше (и в конце вы будете более опытными и не довольны тем, что вы сделали, это нормально). Изменение или переписывание последнего проекта даст бизнесу очень мало преимуществ для стоимости. Что вы можете сделать, это заменить плохой код хорошим кодом, когда вам нужно вносить изменения; это имеет смысл, потому что изменение плохо поддерживаемого кода может быть сложнее, чем замена его хорошим кодом. И если вам нужен новый неопытный разработчик, скажите им, что этот код не является примером, который они должны копировать.

ответил gnasher729 20 J000000Sunday14 2014, 16:05:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132