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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прямой ответ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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