Как избежать переписывания частей приложения

Я работаю в компании над проектом для их отдела продаж. Это моя первая профессиональная работа по программированию, но я сам программировал и учился годами. Часть проекта включает в себя сбор некоторых данных и их объединение с вводом для производства и построения графика. Затем сохраните данные ... и так далее, и тому подобное. Поэтому я написал код для этого чуть менее одного дня. На следующий день я показал своему руководителю проекта, и ему понравилось, но «что если бы у нас было это», и захотел, чтобы я добавил что-то в график. Это не было значительным изменением внешнего вида или функций программы, но оно кардинально изменило то, как мне нужно было хранить данные, обрабатывать их и т. Д.

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользовательский интерфейс сложный, обычно 5 человек имеют 15 разных взглядов. И данные, и структурирование данных, и анализ данных имеют тенденцию меняться, умножаясь на коэффициент 10 :). Интерфейс похож на моду, некоторые комбинации крутые, некоторые ужасные или лишены здравого смысла.

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

Ответ так прост: нет такой вещи, как переписывание вообще.

Итеративная разработка (это то, что вы делали в основном, хотя и однодневные итерации) часто так. Ранние попытки найти решения часто не соответствуют действительности, и, собирая отзывы, система сходится к решению. Я позаимствую рисунок 2.2 из материала инструктора Крейга Лармана для его книги « Применение UML и шаблонов проектирования» .

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

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

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

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

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

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

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

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

Это первая крутая кривая обучения. Когда вы справитесь с этим, возникнет вторая проблема: как вы справляетесь с измененными требованиями, когда пользователи хранят данные за год, которые они не хотят выбрасывать?

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

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

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