Чи допомагає робота зі спадковим кодом розвиватися як програміст? [зачинено]


18

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

Чи вважаєте ви справу з великим і, мабуть, не дуже добре написаним додатком гарною практикою для початківців?


можливий дублікат « Стати розробником»
gnat

1
Навчитися на помилках інших людей - це найбезпечніший спосіб отримати досвід ...
Майкл Боргвардт

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

Ява може бути гарною, але важче знайти jr. dev ніж devs більшості інших початкових мовних фонів, я б міг уявити, виходячи з досвіду, який, в першу чергу, є розробником веб-розробників на передньому кінці, який зазнав дуже широкого спектру задніх цілей. Я думаю, проблема полягає в тому, що мова Java є бездоганною, але культура Java полягає в тому, щоб грати абсолютно все як можна безпечніше і без вини.
Ерік Реппен

Відповіді:


34

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

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

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

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


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

1
@RossPatterson, оскільки це банківська справа, так, я сподіваюся, що вони справді працюють правильно. У будь-якому випадку, якщо немає тестів, ризик внесення змін є величезним у банківських і письмових тестах, що допоможуть вам дізнатися, що система повинна легко продати.
HLGEM

3
Програмування - це знати, як рухати фігури. Розуміння системи - це знати, як грати в гру. Ви не пошкодуєте про досвід з точки зору формування навичок. Працювати для компаній, які крадуть у вдів та сиріт - це те, що ваша совість може не терпіти.
Мередіт Бідна

8

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

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


2
Це також допоможе вам зрозуміти, що метод, на який ви думаєте, що вони повинні були використовуватись, був недоступний під час написання коду.
HLGEM

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

6

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

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


2

Це вам абсолютно допоможе, але потрібно бути обережним.

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

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


2

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

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

Спостереження про спортивну аналогію: чи вважаєте ви, що гравець, який працює в лінії НФЛ, дізнається більше і стає більш цінним, граючи в команді з найгіршим результатом чи найкращим? Моя відповідь: Вони не тільки цінніші, граючи за найкращі команди, але, ймовірно, підбирали кращі практики та знання та уникали підбирати практику та погляди на завершення кар’єри.

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

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

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

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

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

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

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

Відмова: Цей пост буде жити набагато довше, ніж моя думка, тому прийміть його із зерном солі. Завтра я можу полюбити спадщину! (Сумніваюся).


1

Це дуже залежить від того, як ви визначаєте "спадщину" в цьому контексті. Дозвольте навести приклад із C та C ++. Багато програмістів на C ++ вважають поганою практикою використання рядків C у додатках C ++, інші не вимагають змішування, а інші, у свою чергу, стверджують, що використовувати будь-які біти коду С, оскільки вони давні, тобто абсолютно безглуздо, оскільки вони старі, тобто " спадщина "код. Деякі йдуть далі і уникають використання попереднього C ++ X (замінити "X" на відповідне число) стандартними ідіомами, стилем - це синтаксис, оскільки це "спадковий" стиль.

Залишаючи осторонь випусків потоків та рядків C ++ та декілька особливостей STL, це впевнено, що це чудова практика, щоб переглянути те, що знаходиться у вашій такій улюбленій директиві препроцесора #include <string.h>. Якщо ви будете слідувати по шляху до реалізації і знайти себе на Unix / Linux машини на /usr/include/string.h(і отримати LibC джерела реалізації, наприклад, від gnu.org ) і читати strcmp.cабо strlen.cабо strtok.c, я впевнений , що ти збираєшся почути «Який прекрасний світ "поетапне введення.

Однак у цій прозі є застереження, а саме - застарілі класи та методи. У Java досить багато застарілих матеріалів досі доступні з недавнього середовища, але якщо я пам'ятаю правильно, не все. У секторі ІБ, з мого власного досвіду, добре, що не все програмне забезпечення написано хорошими програмістами. У багатьох випускників було практично нульове опромінення програмування в реальному світі, перш ніж вони почали працювати на посаді аналітика / розробника. Але не узагальнюйте це твердження. Я знаю безліч людей, які використовують Java та C # в основі високопропускної та низької затримки. Я не згоден з ними, але добре, це, на щастя, їхня справа. Якби вони справді стали HFT, вони б відсунулися позаду в лінії. Але знову ж таки, З цього речення легко зробити висновок про припущення (а в багатьох випадках і факт), що код Java є оптимізованим. І якщо ви можете досягти успіху в оптимізації, якщо потрібно, не тільки виправляючи те чи інше, ви станете неоціненними як розробник. Це дуже задовольняє спосіб зрозуміти, як багато ви внесли свої внески. Я б пішов на це.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.