Программное обеспечение переписывает по сравнению с производственными затратами анализ
Я предлагаю установить промежуток вокруг информации о сотруднике, например:
<td class="td-align"><span id='eFullname'>'.$employees["fullname"].'</span></td>
<td class="td-align"><span id='eFanme'>'.$employees["faname"].'</span></td>
<td class="td-align "><span id='eSid'>'.$employees["sid"].'</span></td>
<td class="td-align "><span id='eNid'>'.$employees["nid"].'</span></td>
<td class="td-align">
<button type="button" name="update" id="'.$employees["id"].'" class="buttons edit-button">
<span class="fa fa-anchor"></span> insert
</button>
</td>
, тогда вы сможете получить текстовое текстовое содержимое из него, например, с помощью. document.getElementById ("eFullname"). textContent и вставить его в другой ввод из текста типа с помощью
<input type="text" id="anotherTextfield" />
document.getElementById("anotherTextfield").value=document.getElementById("eFullname").textContent
6 ответов
Во-первых, профиль консультанта, в котором Вы нуждаетесь, очень конкретен. Если Вы не можете найти кого-то, кто работал в подобном домене с теми же языками, не нанимайте его.
Во-вторых, существует 99%-я вероятность (мне нравятся поразительные числа), анализ пойдет следующим образом:
- Консультант исследует приложение
- Консультант действительно понимает 10% приложения
- Время, время для отчета
- Советы консультанта, которые переписывает полное (никакой рефакторинг, плоскость переписывает),
Таким образом, можно также сделать экономику того, чего будет стоить консультант.
У Вас есть только два решения здесь:
- Оставайтесь с фактическим исходным кодом, но определите правильные методы решить проблемы так, чтобы у Вас было очень длинное выполнение, осуществляющее рефакторинг, который является progressly, сделанным теми, кто знает приложение
- Заставьте вторичную команду подавать новую заявку для замены старой
Если я говорю о вторичной команде, это - потому что Вы не можете принести всего одному архитектору, чтобы подать новую заявку и иметь старую работу в команде с ним:
- Они слишком заняты на старом приложении
- Будут трения, потому что вновь прибывший, несомненно, недооценит задачу под рукой
Я говорю на основе опыта, верю мне.
Если Вы идете "новым приложением" путь, не помещают Ваши надежды слишком высоко. Вы закончите с приложением, которое имеет меньше чем половину технических возможностей текущей, просто потому что Вы не можете переполнить 30 +, годы особого случая и исключительной ситуации фиксируют в недавно программное обеспечение дизайна.
О, также, если Ваши разработчики, оказывается, говорят Вам, у них есть план, любой ценой, выслушайте их. Они по всей вероятности знают то, о чем они говорят.
Первая вещь, которая приходит на ум, состоит в том, что Вы преждевременно обращаетесь к переписать/осуществить рефакторинг/заменить аргументу. Первый шаг два шага, которые я рекомендовал бы, будет:
- Модульные тесты
- QA
Это хорошо в техническом объеме для реализации их. Модульные тесты являются существенным предварительным шагом, прежде чем любой разумный осуществит рефакторинг или перепишет, мог возможно произойти. 'Модульным тестом' я имею в виду, переносят каждый вызов функции с соответствующим кодом, который доказывает работы кода для всех известных условий. В сложных модификациях этого не может на самом деле произойти на самом детализированном уровне, но любые автоматизированные тесты помогут очень.
И QA - имейте независимого политика (и агрессивный) команда гарантии качества, которая строго тестирует бета-версии перед производством. Их планы тестирования и процедуры тестирования становятся важными для любого вида заменяющего усилия.
После того как у Вас есть код под управлением, затем Вы в состоянии, где бизнес может обоснованно рассмотреть значительные изменения.
Просто примечание о Вашем комментарии о внешних консультантах - никакое консультирование будет когда-либо заботиться достаточно о коде для обеспечения реалистической гарантии качества. QA заканчивает тем, что был женат на бедре бизнеса, защищающего нижнюю строку компании. Это - внутренняя функция в конечном счете, и внешний консультант не может обеспечить намного больше, чем получение, Вы запустили действительно.
Я думаю, что Ваше описание предоставляет всю необходимую информацию о качестве кода (отсутствие этого). То, что столько ресурсов поддержки требуется также, указывает на высокую стоимость, связанную с обслуживанием существующей системы.
Как я ответил здесь, хороший подход для рассмотрения осуществляет рефакторинг одну часть системы за один раз, пока все не работает на допустимом уровне. Я соглашаюсь с ре Joel, не выбрасывая существующий код (см. Вещи, которые Вы Никогда не должны Делать. Части Вашей работы кода, таким образом, необходимо оставить их на месте, когда это возможно, и внимание на разделы тот вывод ко времени простоя.
Andy также высказывает большое мнение о начинании с малого также.
Другая вещь попробовать, рассматривает процессы вокруг системы. Когда Вы делаете это, необходимо ли попытаться определить, какие ситуации с отказом вызываются прямо или косвенно пользовательским действием?, есть ли конфигурация или проблемы среды? Если Вы испытываете затруднения при фиксации кода непосредственно, то можно все еще поддержать его, занимаясь внешними проблемами эффективнее.
Читайте книга, Работающая Эффективно с Унаследованным кодом (также, видят короткую версию PDF), и окружите код автоматизированными тестами, как проинструктировано в той книге.
Осуществляйте рефакторинг систему постепенно. При перезаписи некоторых частей кода сделайте это маленькая подсистема за один раз. Не пытайтесь сделать Главную Модернизацию.
Мы недавно решили полностью переписать значительные части нашего бизнес-кода с нуля, и он не пошел, а также мы надеялись. Я видел много кавычек, говоря, что Вы никогда не должны пытаться переписать что-либо с нуля, и теперь я вижу почему. Я рекомендовал бы начать с малого - не пытаются переписать все это сразу. Определите большие проблемные области и внимание на рефакторинг небольших частей системы за один раз. С тех пор существует 30 + ценность лет работы в системе, будет требоваться много времени для возвращения его к разумному состоянию. У нас была ценность приблизительно 5-8 лет работы для перезаписи, и это было трудно. Я не могу вообразить 30 + годы работы!
Код был вокруг в течение 30 лет?
Парадигмы разработки сместились существенно за прошлые три десятилетия во многих отношениях, и наиболее относящийся к Вашему затруднительному положению, я чувствую, с точки зрения количества времени (в дни человека) требуется создать что-то для ввода->, процесс-> произвел что-то.
300 000 строк кода 30 лет назад, мог, вероятно, вписаться в 100 000 строк или меньше сегодня, и расходующий меньше человеко-часов (?), это могло казаться оптимистическим/смешным некоторым, но с другой стороны достижимо, в зависимости от типа рассматриваемого приложения. Вы не дали признака относительно классификации системы - действительно ли это - своего рода система управления производственного процесса в реальном времени с датчиками и приводами, связанными с ним? Система бронирования авиакомпании? Это выполняет последующую обработку некоторое отставание данных? Другими словами, это могло быть восстановлено в чем-то как Java и быстро с агрессивной, небольшой командой? Требования были зарегистрированы, и раз так им нужны обновление или перестройка с нуля? Действительно ли человеческая безопасность является фактором?
Просто быстрая проверка работоспособности, я думаю, необходимо ли восстановить, зависит от (любой порядок означает то же самое):
- Число чуваков кода требуется.
- Уровень экспертных знаний упомянутых чуваков.
- Какие языки не соответствуют.
- Какие языки действительно соответствуют.
- Какого количества это стоит для использования выбранного языка (языков) их с точки зрения аппаратного и программного обеспечения.
- Насколько бизнес зависит от этого для оставлений в живых.
- Это - действительно слишком много времени простоя, или Вы просто придираетесь к мелочам? (возможно, они действительно не заботятся, но притворяются на).
Удача с этим!