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

13

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

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

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

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

SH7890
источник
2
Какую парадигму программирования вы используете? Процедурный, объектно-ориентированный, функциональный, другой?
Тулаинс Кордова
2
Чтобы избежать переписывания - отделите вашу базу данных и прикладной уровень. Это не простая концепция, применяемая к тому, как вы пишете код. Это сложная концепция, которая делает ваш код простым и адаптируемым.
StackOverFowl
6
Похоже, требования не были ясны или вы их неправильно поняли. Никакие принципы или лучшие практики не могут спасти вас от повторного выполнения всего приложения, если реализация была сделана на основе ложных предположений. Перед тем как печатать на машинке вниз один LOC это хорошо , чтобы спросить требованиям « что , если ... » ... Не ждать , пока менеджер удивив вас с новым , что , если ... . Если потратить некоторое время на поиск функциональных пробелов, фактор сюрприза тоже уменьшится .
Laiv
3
Инъекция зависимости - ваш друг. Найдите его в Google и узнайте, как применить его к вашему языку / структуре. Это позволит вам писать гораздо более модульный код, что должно уменьшить объем кода, который необходимо переписывать при изменении требований.
Eternal21
2
Хотя может показаться, что переписывание - это плохо, на самом деле важно то, насколько быстро вы можете отвечать на запросы ваших конечных пользователей. Хотя это зависит от сложности проекта, я бы сказал, что 1 день - это довольно хорошее время для выполнения - вы должны делать что-то правильно! На самом деле программное обеспечение, которое видит значительные изменения, является хорошим знаком - это значит, что оно полезно и совершенствуется. Программное обеспечение, которое не претерпело существенных изменений в течение многих лет, гораздо сложнее поддерживать.
Джастин

Ответы:

22

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

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

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

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

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

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

LAIV
источник
3
Эта. Этот ответ - лучший способ, которым он мог быть поставлен. Получить эти требования, прежде чем делать что-либо абсолютно.
Рис Джонс
1
Это хороший ответ, но у меня есть ноющее чувство, что есть лучший способ структурировать приложение, чтобы облегчить выполнение этих запросов. Я не верю, что какой-либо из так называемых «принципов», о которых я говорю, поможет; решение должно быть конкретным для проблемы. Без дополнительной информации ваш ответ является единственным, который имеет смысл.
Фрэнк Хайлеман
Ну, у меня было сильное чувство, что проблема была той, которую я прокомментировал, потому что это было именно то, что случилось со мной в мои первые годы в качестве разработчика. Я мгновенно перевел фразы в LOC или модули, и когда мне пришлось что-то менять, это было довольно драматично для меня. Рефакторинг над рефакторингом каждый день или неделю. Даже не стараясь изо всех сил с SoC, SPR, полиморфизмом, ... Многие конфликты, которые я имел с изменениями, были вызваны моей утечкой общего видения.
Лайв
2
Чтобы развить этот ответ: важно также быть гибким в сборе требований. Иногда люди получают новые идеи или вспоминают то, что забыли, когда увидят продукт. Они могут сказать: «Я знаю, я просил тебя построить это, но я не это имел в виду» или «Я знаю, что просил об этом, но теперь, когда я это вижу, я хочу что-то еще». Вы можете предотвратить это, вызывая разочарование и переделки, создав быстрое и грязное «Доказательство концепции». Это может быть даже макет, как фальшивый граф. Это помогает вашему клиенту думать.
Ахил
1
Некоторые могут утверждать, что абстрагирование базы данных от кода не является обязательным, потому что «поставщики базы данных редко меняются». Я согласен с вами, но суть моего ответа такова: собирая требования, забудьте, что вы разработчик, сосредоточьтесь на сборе требований. Думай как менеджер, спрашивай как менеджер. Не спешите думать как разработчик.
Laiv
4

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

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

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

Джонни
источник
Хорошая статья, которую вы связали.
SH7890
1
Хорошая статья действительно! Я думаю, что это не случай OP, но я не мог согласиться больше с автором.
Laiv
1
Я не думал, что это было один за одним, но это читало, как будто это мог быть один день. Надеюсь, это поможет ОП.
джонни
2

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

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

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

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

ipavlu
источник
2

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

введите описание изображения здесь

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

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

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

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

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

Fuhrmanator
источник
Я бы предпочел, чтобы этот ответ был принятым. Итерация в направлении решения лучше, чем попытка установить все требования заранее. Особенно, если все заявление может быть переписано в течение дня.
Euphoric
Я уверен, что босс не знал, чего они хотели во второй итерации, пока первая не была завершена. «Собрать больше требований заранее было бы невозможно.
gnasher729
1

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

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

jmoreno
источник
1

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

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

gnasher729
источник
-1

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

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

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

h22
источник