Я порівняно новий розробник, свіжий з коледжу. Під час навчання в коледжі та під час подальшого пошуку роботи я зрозумів, що існує багато "сучасних" методологій розробки програмного забезпечення, яких не вистачало моїй освіті: тестування блоків, ведення журналів, нормалізація бази даних, спритна розробка (проти загальних спритних концепцій), стиль кодування посібники, рефакторинг, огляд кодів, відсутність стандартизованих методів документації (або навіть вимог) тощо.

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

Спочатку я почав із програмного забезпечення для реєстрації даних (log4J), але потім швидко перейшов до написання власного керівництва по стилю, потім відмовився від цього для стилю керівництва Google - і тоді зрозумів, що наша веб-розробка Java використовує ручні написані фронтальні контролери, тому я натиснув на наше прийняття Весни - але тоді я зрозумів, що у нас також немає одиничних тестів, але я вже вивчав Весну ... і, як ви бачите, вона занадто швидко стає надзвичайною, особливо, коли вона поєднується з нормальною роботою з розвитку. Крім того, мені важко стати "експертом" у цих методологіях, щоб навчити когось іншого в них, не приділяючи занадто багато часу ні одному з них, не кажучи вже про них усім.

З усіх цих методів, які я вважаю "очікуваними" в сучасному світі розробки програмного забезпечення, як я інтегрую їх у команду як нового гравця, не перевантажуючи і себе, і команду?

Як я можу вплинути на свою команду, щоб стати більш спритною? пов'язано, але я не Agile-розробник, як аскер, і я дивлюся на набагато ширший набір методологій, ніж Agile.

Мені це здається, ніби ти ставиш візок перед конем.

З якою основною проблемою стикається ваша команда та які технології допоможуть її виправити?

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

Пам'ятайте, що метою бізнесу, в якому ви працюєте, є заробляти гроші, а не робити коди.

Java? Сучасний ?! Ви провалилися під час першої перешкоди. Якщо ви хочете бути по-справжньому сучасними і уникати "професійного самогубства", тоді ви повинні написати код Rust. Звичайно, на наступному тижні це все зміниться, і вам доведеться навчитися чомусь ще новішому, щоб не відставати!

Або ви можете погодитися з тим, що жодна кількість технологій, методологій чи рамок, а також будь-яка інша дура не змінить того, що ви хочете створити якісні продукти, які працюють. Не має значення, якщо ви не використовуєте спритний, якщо ви успішно виробляєте правильний вихід. Звичайно, якщо ви цього не зробите, можливо, ви захочете щось змінити, але, швидше за все, певна практика не вирішить проблеми. Вони залишаться людськими проблемами, які можна виправити будь-якою кількістю різних способів.

Що стосується професійного самогубства, якщо ви знаєте, що ви робите, і гнучкі, то вам не потрібно нічого із згаданих вами речей. Люди й надалі придумуватимуть нові способи виконання старої роботи, і ви завжди будете наздоганяти. Або ви можете просто використовувати будь-які методи, якими користується ваша нинішня компанія. Змінюючи свою компанію, ви просто вивчаєте та використовуєте методи, якими вони користуються.

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

Багато компаній застрягли так; Ви можете навіть здивуватися, дізнавшись, що деякі ваші колеги-розробники є самоучками та стали розробниками, які не мають жодного офіційного досвіду. Ці розробники часто краще працюють на своїх робочих місцях, оскільки саме вони будуть змушені вчитися новим навичкам і досягати успіху, а не просто виконувати завдання. На жаль, це також може означати, що, хоча вони відмінно програмують, вони можуть не знати про переваги цих практик. Справа в тому, що це найкращі практики, а не поширені . Краще використовувати їх, але вони не всі вимоги , щоб домогтися успіху, вони просто інструменти , щоб допомогти зробити успіх легше.

Ви абсолютно праві, це намагатиметься реалізувати все і відразу, і це буде непереборно. Ви, ймовірно, спалите себе (а може, і свою команду), намагаючись це зробити, що демотивує майбутні поштовхи до прийняття нових методологій / технологій. Найкраще , що можна зробити в такій ситуації , як це вибрати одинріч (ведення журналів - це, мабуть, вдалий початок, оскільки ви, мабуть, перед вами нелегка дорога, знайти помилки без реєстрації, і помилки обов'язково є), і поговоріть з цим про команду. Вам не доведеться це одноосібно реалізовувати; ви набагато краще обговоріть плюси і мінуси з командою (і вашим начальником, який абсолютно ОБОВ'ЯЗКОВО бути на борту з чимось подібним) і придумуєте план її виконання. Це повинно бути максимально безболісним (пам’ятайте, ви говорите людям, що їм тепер доводиться писати додатковий код на додаток до того, що вони вже роблять).

І дозвольте сказати ще раз, переконайтеся, що ваш шеф купує . Це має вирішальне значення; ви, ймовірно, виявите, що швидкість виправлень / випусків сповільнюється під час впровадження нових речей. Справа в тому, що ви платите заздалегідь, щоб заощадити лінію; вони ПОВИНЕН зрозуміти це і бути на вашому боці. Якщо ви не отримаєте їх на борту, ви в кращому випадку ведете програшну битву, а в гіршому випадку вони можуть вважати вас активно саботувати команду (запитайте мене, як я знаю).

Як тільки ви внесете ці предмети до столу, обговоріть їх із командою, сплануйте, як їх реалізувати, і слідуйте за цим, другий, третій, восьмий тощо будуть легшими. Мало того, що для колективу та вашого начальника є можливість поважати вас, оскільки ваші пропозиції реалізуються та визнаються як додаткові значення. Чудово! Просто переконайтеся, що ви залишаєтесь гнучкими: ви протидієтеся інерції тут, і змінити непросто. будьте готові повільно робити малізміни та переконайтесь, що ви можете відстежувати прогрес та отриману вартість. Якщо ви впроваджуєте журнал в новому процесі, і це допомагає вам заощадити години на пошук помилки за три тижні, зробіть велику справу про це! Переконайтеся, що всі знають, що компанія щойно заощадила $ XXX, зробивши правильну справу раніше часу. З іншого боку, якщо ви отримаєте відсіч або у вас обмежений термін, не намагайтеся примушувати проблему. Нехай нова зміна ковзає на мить і обертається назад. Ви ніколи не виграєте, намагаючись змусити команду робити те, чого вони не хочуть робити, і ви можете бути впевнені, що перше, що вони запропонують відмовитись, - це нова "додаткова" робота (наприклад, написання журналу чи наступне керівництво стилем, а не просто "налагодження його роботи").

Я сподіваюся, що ви не представляли своїх питань колегам, як ви це робили нам у своїй посаді. ЩО було б професійним самогубством.

Перше питання полягає в тому, що ви намагаєтеся навчити технологіям і методам, з якими навіть у вас немає досвіду роботи з групою програмістів, які, можливо, трохи застаріли, але отримаєте роботу "виконаною". Можливості цього зворотного розгону безмежні, і, ймовірно, принесуть багато радості вашим колегам. Цікаво і приємно, що ви хочете вдосконалити себе та свій відділ, але уникайте використання таких термінів, як "очолюючи голову". З повагою, не вживайте цього слова.

Як побічне питання вищезазначеного, перевірте, чи виконуєте ви якусь роботу . Я багато часу працюю як самотній програміст, який самонавчається, і знаю, як легко відкласти фактичну роботу з метою вивчення перспективних рамок, технологій тощо. Переконайтеся, що ваша ефективність знаходиться в межах очікуваних параметрів (ні, ніхто не піклується про те, щоб ви витратили 20 годин на дослідження Весни, якщо цього звіту, про який ви просили, не буде зроблено).

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

Тепер для представлення цих "найкращих практик" є два способи пояснення їх своїй команді:

• Тому що я кажу, що це найкраща практика, і цього достатньо.
• Тому що вони корисні і допомагають вирішити проблему.

Використовуючи перший аргумент, якщо ви не начальник чи дуже старший член команди, навряд чи вони привернуть вам будь-яку увагу. І "я читаю книгу з Кнут, яка так говорить", або "хлопці ДП кажуть, що" не викличе жодного враження, також ("ці хлопці не працюють тут, щоб вони не знали, що добре для цього ІТ-магазину "). У них є свої методи, процедури, процедури і речі, «більш-менш» працюють, тож навіщо вживати зусиль і ризикувати зміни?

Для другого підходу до роботи необхідно усвідомити, що існує проблема . Тому:

• не натискайте день і ніч на автоматичне тестування. Зачекайте, коли оновлення порушить деякі функції, і команді доведеться попрацювати понаднормово, щоб виправити це, а потім запропонуйте створити автоматизовану тестову систему.
• не вимагайте перегляду коду. Зачекайте, поки Джо буде у відпустці, і потрібно змінити той модуль, про який знає тільки Джо, і вкажіть вашому начальнику, скільки часу було втрачено, просто намагаючись зрозуміти код Джо.

Звичайно, зміни будуть повільними та прогресивними (тим більше у великій корпорації). Якщо ви зможете впровадити перевірку коду та автоматичне тестування через п’ять років, вам слід привітати себе за виконану роботу. Але, якщо не виникне повного перепису через зовнішніх причин, забудьте про будь-яку фантазію, що вони перемкнуть ядро ​​ІС, скажімо, на Весну ( Джоел пояснив, що так краще, ніж я міг, навіть до того, як ви народилися ¹ ); в цей час ви могли, максимум, потрапити Spring у список підтримуваних платформ для запису некритичних систем.

Ласкаво просимо у світ корпоративних ІТ, хлопчик! :-p

¹ : Добре, можливо, я трохи перебільшую, але не дуже.

Слід почати з книги « Ефективно працюючи зі спадщинним кодексом » Майкла Пера. Зі вступу книги "Йдеться про те, щоб заплутану, непрозору, згорнуту систему і повільно, поступово, поступово, крок за кроком, перетворити її на просту, добре структуровану, добре розроблену систему". Він здебільшого починає з автоматизованого тестування, так що ви можете безпечно перефактурувати (ви дізнаєтесь, чи зламаєте ви що-небудь), і він включає безліч стратегій введення складного коду під час автоматичного тестування. Це корисно для кожного проекту, який ще розробляється. Після того, як ви набули базового замовлення, ви зможете побачити, від яких інших сучасних технологій ваш проект дійсно може отримати користь - але не вважайте, що вони вам потрібні.

Якщо ви хочете навчитися новій структурі (або чомусь) з професійних причин, а не тому, що ваш поточний проект насправді потребує цього, тоді вам слід використовувати його в якомусь особистому проекті (у свій час).

Контроль джерела.

Ви не згадали про це, сподіваємось, тому, що він вже є, але, у випадку, якщо його немає, починайте там.

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

І ви можете почати один, якщо спочатку ніхто не купує.

Прямий відповідь

Інші відповіді дають хороші «метапотоки» щодо прийняття кращих практик, але, лише для того, щоб дати вам декілька безпосередньо релевантних вказівок, ось приблизний порядок найкращих практик, які я пропоную вашій команді (або будь-якій команді) прийняти (першою):

1. Контроль джерела
2. Відстеження питань (управління проектами та завданнями)
3. Автоматизовані побудови ¹
4. Автоматизовані розгортання

^{1 _{Дуже пов'язана практика - це автоматизувати або принаймні документувати налаштування середовища збирання та розробки кожного додатка чи програмного проекту, який ви розробляєте або підтримуєте. Це набагато менш корисно тхо, тому що ви (сподіваємось) це робите нечасто або рідко.}}

Все інше

Ви згадуєте кілька інших належних практик - "тестування одиниць, ведення журналів, нормалізація бази даних, ... рефакторинг, ... документація", - але це все практики, які можна і слід застосовувати поступово та поступово. Жоден з них не повинен бути прийнятим відразу, і вам, мабуть, краще прийняти їх взагалі , прийнявши їх обережно та уважно.

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

Деякі з інших практик, які ви згадуєте, - "спритна розробка, ... посібники зі стилем кодування, ... огляди коду, ... стандартизовані методи документації" та рамки (наприклад, Spring) - насправді необов'язкові або мають сумнівну цінність. І це правда для багатьох (більшості?) Можливих практик, які ви відкриєте чи зустрінете.

Agile розробка, очевидно, не перевершує будь-яку іншу використану методологію. І багато людей (в тому числі і я) мали жахливі переживання з цим. Але багатьом дуже подобається (або це подобається) теж. Спробуй це!

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

Огляди коду можуть також бути дуже корисними - ви попросили своїх колег переглянути свій код? Майте на увазі, що для прийняття передового досвіду вам не потрібен офіційний процес!

Документація чудова - у вас взагалі є така? Якщо так, тобі добре! Чи стикаєтесь ви з великою кількістю додаткової роботи, яку можна запобігти, якщо (більше) "стандартизована" документація? Якщо ви є, то, напевно, це щось варто зробити. Однак скажіть, якщо вашим програмним забезпеченням користується невелика група людей, вам може не знадобитися жодна документація. (Або ви можете безпосередньо включити документацію у своє програмне забезпечення. Це завжди мої переваги.)

Каркаси - це (дуже гострий) меч з двома кінцями. Чудово капсульоване та доглянуте рішення для непрофільної функції вашого програмного забезпечення є чудовим ... поки це не так. Я не впевнений, що таке "рукописні фронтальні контролери", але немає очевидних пояснень, чому вони поступаються коду, який використовує Spring. Ви розглядали можливість інкапсуляції загальної логіки всіх цих контролерів у власну внутрішню структуру? Прийняття весни та перезапис усіх існуючих вами кодів може бути величезним проектом рефакторингу (або, що, швидше за все, переписуванням), і це може бути не найкращим зміною, яке ви могли внести у свій код . Звичайно, ви не повинні писати все програмне забезпечення, яке ви використовуєте - рамки (і бібліотеки) чудові!Але, можливо, вам не доведеться використовувати Spring (або альтернативу) для написання чудових (або хороших) веб-додатків.

Огляньте команду, до якої ви входите. Чи можете ви побачити будь-які докази того, що розробка тестів або нормалізація бази даних покращать якість програмного забезпечення, яке ви пишете, або роблять людей більш продуктивними?

Чи намагалися ви про це поговорити з одним із керівників розробок чи керівником відділу розвитку? Справді неформальний чат був би гарним початком. Що змушує вас думати, що люди вище вас не мали однакових ідей, але не можуть / не зможуть їх реалізувати, оскільки бізнес цього не дозволить?

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

Знайдіть недолік. Виправити недолік. Покажіть виправлення.

Візьмемо спочатку нормалізацію *. І дійсно, я б запропонував вам взяти це спочатку, оскільки відсутність нормалізації може призвести до фактичних помилок, які не могли б існувати інакше, тоді як решта - це випадки, коли найкраща практика може допомогти, але важче сказати "Помилка A викликано недотриманням політики X ". Якщо у вас база даних не нормалізована, то у вас є місце, де дані можуть бути непослідовними.

Це гарна обставина, що ви зможете знайти фактичний випадок суперечливих даних. Зараз ви знайшли дві речі:

1. Помилка у ваших даних.

2. Помилка у схемах вашої бази даних.

Ви насправді знали про другу помилку, але перший легше продемонструвати, а також те, що викликає справжню проблему, а не те, що теоретично могло б зробити.

На жаль, одна з реальних причин протистояти нормалізації денормалізованої бази даних полягає в тому, що питання, що робити з такими помилковими даними, не завжди є простим, але ви знайшли фактичну помилку.

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

Для решти, введіть їх, коли вони допоможуть в короткостроковій перспективі, щоб згодом розвивати їх на тривалий термін. Наприклад, якщо вам надано невеликий фрагмент коду для складання, напишіть для нього одиничний тест. Ще краще, якщо вам дано помилку, напишіть одиничний тест, який не вдався через помилку, а потім, коли ви виправили помилку, згадайте той факт, що він проходить, коли ви закриєте помилки (або надішліть електронний лист із повідомленням, що це виправлено або що завгодно).

* До речі, не дуже сучасний. Причина, по якій називається нормалізацією , а не нормалізує або що - то інше, то , що в той час це було актуально жарт дотримуватися -ization на кінці речей , щоб зробити задоволення від імені Річарда Ніксона в'єтнамізації політики.

Я йду проти зерна і кажу: знайдіть нову роботу, витративши трохи часу на цю, щоб трохи скласти своє резюме. Мета на рік або близько того. Хоча багато речей - це "казкові слова", такі проблеми, як повна відсутність тестування одиниць, не можна вирішити для одного розробника, і, швидше за все, якщо програмісти, які працюють там, не мають бажання тестувати, ви ніколи не отримаєте покупку і навіть можете поставити під загрозу вашу позицію в компанії, змушуючи людей думати про вас як про грубе. Потрібно знаходитись у місці, де можна отримати наставництво, не намагаючись підштовхувати культуру до базової компетентності.

Було багато пропозицій щодо вдосконалення парадигми програмування . Зараз найгарячіші модники здаються гнучким програмуванням та об'єктно-орієнтованим. Або вони? Обидва значно зів’яли в порівнянні з тим, що були лише п'ять років тому.

Ви можете бути досить впевнені, що будь-яка методологія, що застосовується, намагається досягти одного і того ж кінцевого результату: допоможіть інженерам економічно виготовити кінцевий продукт, який є досить хорошим.

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

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

Ви згадуєте agileметодології як щось позитивне. Близько півроку я був в одній команді розробників, яка навмисно дотримувалася встановленого спритного режиму. Я виявив, що це подібно освіченим методологіям управління проектами з десятиліть тому, за винятком того, що все перейменовано. Можливо, шляхом перекомплектування та перепродажу ідей для спілкування з ким-небудь заробляє на життя, і компанії можуть почувати себе добре "побачити" новий одяг імператора .

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

Із написання керівника анти-гото Едсгера Дійкстра:

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

—Dijkstra, у: Dahl, Dijkstra & Hoare 1972, стор. 6. (див 6 тут .)