С чего начать моей команде с того, чтобы стать «современным»? [закрыто]

106

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

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

Сначала я начал с программного обеспечения для ведения журналов (log4J), но затем быстро перешел к написанию своего собственного руководства по стилю, а затем отказался от него для руководства по стилю Google - и затем я понял, что в нашей веб-разработке на Java используются рукописные фронт-контроллеры, поэтому я настаивал на наше принятие Spring - но потом я понял, что у нас также не было модульных тестов, но я уже изучал Spring ... и, как вы видите, он слишком быстро становится подавляющим, особенно в сочетании с обычной работой по разработке. Кроме того, мне трудно стать достаточно «опытным» в этих методологиях, чтобы научить кого-либо еще в них, не уделяя слишком много времени одному из них, не говоря уже о всех них.

Из всех этих методов, которые я считаю «ожидаемыми» в современном мире разработки программного обеспечения, как мне интегрировать их в команду как нового игрока, не перегружая себя и команду?

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

WannabeCoder
источник
92
"современный"? Уберите это «ловкое» модное слово из вашего списка, и я могу видеть только вещи в возрасте> 20 лет.
Док Браун
10
Может быть, «современный» в том смысле, что их широкое распространение - это современность, а не генерация идей? Я не эксперт в этом вопросе, это только мое впечатление.
WannabeCoder
41
Уверяю вас, юнит-тестирование, ведение журнала, нормализация базы данных, руководства по стилю кодирования, проверки кода (= обзоры) - все старше 30 лет. Термин «рефакторинг», по крайней мере, 15 лет (Фаулер написал свою книгу в 2000 году). И отсутствие формальной документации или письменных требований - это не «современная техника», это ИМХО даже не «техника».
Док Браун
69
@DocBrown признайся, ты только что отправил Марти обратно во времени, чтобы создать все эти вещи, прежде чем сделать свой комментарий.
ноль
17
Я больше обеспокоен тем, что его колледж не преподает эти вещи заранее - я не учился в школе более 15 лет, и большинство из этих вещей были покрыты довольно рано. (Минус модные слова, конечно).
Аллен Гулд

Ответы:

165

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

С какой главной проблемой сталкивается ваша команда и какие технологии помогут ее решить?

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

Помните, что цель вашего бизнеса - зарабатывать деньги, а не делать код.

Jaydee
источник
35
Довольно много. Отчасти с прагматической точки зрения необходимости начинать где-то, а отчасти с репутационной точки зрения, что, если вы можете решить проблему для команды, они могут быть более охотно выслушать другие предложения. Также имейте в виду, что эта компания делала деньги до того, как вы приехали, используя свои существующие методы, поэтому то, что вы внедрили, должно увеличить способность компании зарабатывать деньги.
Джейди
6
Признаю это, но я был бы признателен за продолжение работы по устранению профессиональных рисков (например, «в моем резюме было бы больше материала, но моя старая работа не очень хорошо воспринимала изменения».)
WannabeCoder
4
@WannabeCoder - вы должны начать использовать его, прежде чем стать опытным. Вы все еще можете ввести код в производство. Иногда кодирование это как врач. Мы все еще тренируемся.
JeffO
5
Отличный ответ. Вы должны реализовывать эти вещи только для решения проблем, а не для производства проблем.
Кик
5
@WannabeCoder Важно понимать, что ни одна из этих методологий не была создана в вакууме. Они становятся широко распространенными, потому что они помогают решать проблемы . Если вы попытаетесь их реализовать, а они не помогут решить проблемы, с которыми сталкивается ваша команда, то вы ничего не добились и, возможно, совершенно неправильно поняли и злоупотребили методами. Как разработчик, вы должны сосредоточиться на решении проблем в каждом своем действии. Ищите небольшие выигрыши, где применение этих практик чуть больше улучшит ситуацию. Это помогает создать основу для их расширения.
jpmc26
77

Ява? Современный?! Вы потерпели неудачу на первом препятствии. Если вы хотите быть по-настоящему современным и избегать «профессионального самоубийства», тогда вы должны писать код на Rust. Конечно, на следующей неделе все изменится, и вам придется учиться чему-то еще более новому, чтобы не отставать!

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

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

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

gbjbaanb
источник
4
Очень хороший ответ (+1), особенно последний абзац. Очень современная книга (современная в том смысле, что я считаю ее очень актуальной сегодня), которую я читаю в последнее время, называется SICP.
Джорджио
1
+1 за упоминание о том, как быстро меняются эти модные слова и популярные языки. Хороший разработчик, создающий хороший код, превосходит любую методологию. Делай то, что работает и работает хорошо!
WeRelic
2
Хотя вы правы в том, что их нужно использовать правильно, я не согласен с тем, что «они не так важны, как вы думаете в настоящее время». Хорошо, конечно, это может относиться к некоторым методам (я несколько скептически отношусь к модульному тестированию), но другие чрезвычайно ценны. Я получил возможность начать много заниматься CI и автоматизацией, а также правильно использовать управление исходным кодом, и теперь, работая над проектом, которого нет, я вижу все проблемы, которые мы хотели решить в действии: ошибки, несоответствия Никто не знает, что код где, работает. Эти практики имеют огромное значение.
jpmc26
6
Никто не говорит «не решать проблемы», проблема в том, когда вводятся решения в поисках проблем для решения. Они не так важны, как многие думают, грузовые культисты считают, что инструменты являются важной частью, где они на самом деле просто инструменты. Практик имеет значение, и какие инструменты работают в нужных местах, это те, которые нужно выбрать. моя цель - никогда не выбирать инструмент просто потому, что он в наборе инструментов.
gbjbaanb
2
Дурак с инструментом все еще дурак.
Пит Беккер,
40

Многие компании застряли так; Вы даже можете быть удивлены, обнаружив, что некоторые из ваших коллег-разработчиков самоучки и стали разработчиками без каких-либо формальных знаний. Эти разработчики часто лучше справляются со своей работой, поскольку именно они будут стремиться получить новые навыки и добиться успеха, а не просто выполнять свою работу. К сожалению, это также может означать, что, хотя они отлично умеют программировать, они могут не знать о преимуществах этих методов. Дело в том, что это лучшие практики, а не обычные практики. Лучше использовать их, но они не все требования , чтобы добиться успеха, они просто инструменты , чтобы помочь сделать успех легче.

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

И позвольте мне сказать еще раз, убедитесь, что ваш босс покупает . Это очень важно; вы, вероятно, обнаружите, что скорость исправлений / выпусков замедляется по мере внедрения новых вещей. Дело в том, что вы платите аванс, чтобы сэкономить; они ДОЛЖНЫ это понимать и быть на вашей стороне. Если вы не получаете их на борт, вы в лучшем случае ведете проигрышную битву, а в худшем случае они могут посчитать, что вы активно саботируете команду (спросите меня, откуда я знаю).

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

DrewJordan
источник
6
Я сомневаюсь, что вы имели в виду это, но я немного обижен на нас, таких как я, без университетского профессионального образования. Мой опыт (довольно, к сожалению) показал, что университетское образование мало связано с качеством разработчиков. И до сих пор в моей карьере я был одним из тех, кто защищал и применял лучшие практики. Ваш совет отличный, хотя.
Джейкиб
5
На самом деле, я имел в виду другое: OP был бы удивлен тем, сколько хороших разработчиков без формального образования. За последние 20-30 лет открылись многие технические должности, которые были заполнены людьми, желающими учиться, а не детьми со степенью. И мои выводы отражают ваши: опыт всегда лучше, чем образование. Вот почему ОП должен идти медленнее ... подталкивание команды к слишком быстрому принятию новых практик заставит их обидеться на него, и у него не будет опыта, чтобы умерить такое отношение. Также важно понять, что некоторые команды никогда не будут использовать эти инструменты; вот когда ты получаешь новую работу.
DrewJordan
1
«Многие компании застряли так: вы можете даже удивиться, обнаружив, что некоторые из ваших коллег-разработчиков самоучки и стали разработчиками без каких-либо формальных знаний». Они часто оказываются наиболее ценными разработчиками благодаря своей экспертизе в своей области.
pmf
Хорошо, я полностью согласен. Перефразировал первый абзац, чтобы он звучал менее снисходительно. Я просто хотел убедиться, что ОП знал, что значительная часть рабочей силы на самом деле не имеет формального образования. Плохой выбор слов с моей стороны.
DrewJordan
18

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

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

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

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

Теперь, чтобы представить эти «лучшие практики», есть два способа объяснить их вашей команде:

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

Используя первый аргумент, если вы не начальник или очень старший член команды, вряд ли они уделят вам какое-либо внимание. И «Я прочитал книгу от Кнута, которая так говорит», или «ребята из SE говорят, что» не вызовут никакого впечатления, ни («эти ребята здесь не работают, поэтому они не знают, что хорошо для этого IT-магазина» «). У них есть свои методы, процедуры, процедуры и вещи, которые «более или менее» работают, так зачем же предпринимать усилия и рисковать изменениями?

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

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

Конечно, изменения будут медленными и прогрессивными (особенно в большой корпорации). Если вам удастся внедрить проверку кода и автоматизированное тестирование через пять лет, вы должны поздравить себя с хорошо проделанной работой. Но, если не произойдет полное переписывание из-за внешних причин, забудьте о любой фантазии о том, что они переключат ядро ​​IS, скажем, на Spring ( Джоэл объяснил это лучше, чем я когда-либо мог, даже до того, как вы родились 1 ); в то же время вы можете получить Spring в списке поддерживаемых платформ для написания некритических систем.

Добро пожаловать в мир корпоративных информационных технологий, мальчик! :-п

1 : Хорошо, возможно я немного преувеличиваю, но не слишком.

SJuan76
источник
1
В основном не согласен. Единственный способ добиться изменений в команде - это если кто-то захочет провести исследование и увлечь остальных. Конечно, вы должны оставаться продуктивными, но если все держат голову низко, вы в конечном итоге «немного устарели, но вы сделали работу». И полностью сгорел от скуки.
winkbrace
@winkbrace Я не утверждаю, что вы не должны пытаться улучшить (на самом деле я утверждаю обратное). Но продвигать эти изменения без поддержки со стороны руководства и без какого-либо разрешения на старшинство может быть довольно сложно и вызвать некоторое сопротивление; добавьте, что ОП не является экспертом и может иметь проблемы с реальной реализацией. Было бы неплохо, если бы ОП мог добровольно предложить команду исследователей / прототипов для правильного внесения изменений; но запретил ему быть осторожным в выборе правильного подхода, чтобы продвигать их и быть терпеливыми.
SJuan76
@winkbrace для скуки, это зависит от вашей личности и того, что вы ищете в работе. Разумно попытаться устроиться на работу, которая вас устраивает, а не идти куда-либо и пытаться изменить организацию по своему вкусу. И обычно крупные корпорации (за исключением отделов исследований и разработок) - это не место для людей, которые любят тестировать новые технологии каждые несколько месяцев.
SJuan76
Это немного запутанно говорить: «Убедитесь, что вы на самом деле делаете работу». Конечно, вы должны выполнять работу, но вы также должны думать о долгосрочной перспективе, и каждый день вы должны улучшаться. Мне понадобилось 5 месяцев, чтобы наш менеджер согласился с тем, что модульные тесты помогают, даже когда мы пытаемся «быстро» кодировать. Но мне нужно было проводить 10 минут здесь и там каждые несколько дней, чтобы это произошло.
Рудольф Олах
@omouse Я просто указывал на риск, который иногда поражал меня, когда я проводил исследования. Конечно, я не вижу такого риска в ситуации, которую вы описываете, но форма, в которой ОП описывает свое исследование («сначала я начал с ... потом я быстро переехал ...»), заставила меня добавить это предостережение. Обратите внимание, что я не утверждаю, что ОП не выполняет свою назначенную работу должным образом (это то, чего я просто не знаю, и это работа его босса), я просто предупреждаю его, чтобы он не слишком увлекся ,
SJuan76
12

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

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

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

Управления источником.

Вы не упомянули об этом, надеюсь, потому что он уже на месте, но, если это не так, начните там.

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

И вы можете начать в одиночку, если никто изначально не покупает.

Эмилио М Бумачар
источник
1
Самая большая отдача больше похожа на несколько ASSERT в нужных местах.
Питер Мортенсен
@PeterMortensen Верно, но только если вы знаете, каковы правильные места.
Эмилио М Бумачар
Ты подтолкнул меня на это. Независимо от того, в каком направлении OP берет свою команду, попасть туда с Git будет гораздо проще и продуктивнее, чем без него.
dotancohen
6

Прямой ответ

Другие ответы дают хорошие «мета-точки» в отношении принятия лучших практик, но просто для того, чтобы дать вам несколько непосредственных рекомендаций, вот примерный порядок лучших практик, которые я бы посоветовал вашей команде (или любой команде) принять (сначала):

  1. Управления источником
  2. Отслеживание проблем (управление проектами и задачами)
  3. Автоматизированные сборки 1
  4. Автоматизированные развертывания

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

Все остальное

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

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

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

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

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

Обзоры кода также могут быть очень полезны - вы просили своих коллег пересмотреть ваш код? Имейте в виду, что вам не нужен формальный процесс для принятия хороших практик!

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

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

Кенни Эвитт
источник
Я бы поставил на место автоматизированное регрессионное тестирование с автоматической сборкой и развертыванием. Это также имеет то преимущество, что вы можете работать над этим постепенно.
Сденхэм
Сначала должно быть выполнено модульное тестирование, начните с того, что вручную всегда запускайте его локально (или при каждой проверке / регистрации), а затем заставьте остальную команду купить автоматическое регрессионное тестирование. Действительно, существуют разработчики, которые по какой-то причине боятся постоянно проводить тесты.
Рудольф Олах
5

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

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

Я считаю, что подавать пример - хороший путь. Люди гораздо менее устойчивы, если кто-то уже выполнил работу и может показать им, как ее воспроизвести. Введите TDD в проект, над которым вы работаете. Попросите дать презентацию остальной части команды или даже нескольким другим и показать им, что вы сделали. То, что @DrewJordan сказал о том, чтобы получить бай-ин от босса, важнее, чем вы, вероятно, понимаете.

markp3rry
источник
5

Найдите недостаток. Исправить недостаток. Показать исправление.

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

Хорошая ставка, что вы сможете найти фактический случай противоречивых данных. Теперь вы нашли две вещи:

  1. Ошибка в ваших данных.

  2. Ошибка в схемах вашей базы данных.

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

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

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

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

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

Джон Ханна
источник
4

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

asthasr
источник
3
Это именно то, что я сделал. Был только один раз (из ~ 5 попыток в разных местах), когда я успешно представил новую «хорошую практику» или внес существенные изменения в существующие практики, и это было, когда команда была свежа, и мы начали большинство проектов с нуля. , Все остальные времена хорошие практики были либо внедрены сверху (командные лидеры), либо просто провалились, потому что никто больше не участвовал. Я верю, что все зависит от того, как вы можете быть лидером / боссом.
скрипт
1

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

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

Существует одна парадигма , которая была спорно введена в 1960 - е годы: структурное программирование : использовать только «высокий уровень» конструирует как while, for, repeat, if/ then/ else, switch/ caseоператоры вместо этого активно используется gotoзаявление , которое было принято по умолчанию. Все еще ведутся споры о том, gotoимеет ли какое-либо законное использование вообще.

Я принимаю, что минимизировать использование goto- это хорошо, но, как и все хорошие вещи, можно зайти слишком далеко.

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

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


Из письма лидера антигото Эдсгера Дейкстры:

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

—Dijkstra, в: Dahl, Dijkstra & Hoare 1972, pg. 6. (см. Стр. 6 здесь .)

wallyk
источник