Чи характерні погані практики програмування в галузі програмного забезпечення? [зачинено]

Я тільки почав свою першу роботу як розробник програмного забезпечення понад місяць тому. Все, що я дізнався про OOP, SOLID , DRY , YAGNI, шаблони дизайну, SRP тощо, можна викинути у вікно.

Вони використовують C # .NET Webforms і роблять майже все, що знаходиться в кодексі позаду, із дуже малою кількістю зовнішніх класів, які точно не називаються об'єктами. Вони використовують користувацькі елементи керування та використовують їх повторно. Про єдині використовувані об'єкти - це Entity Framework . Вони повторно використовують Код Задуми для кожного клієнта. У них є методи, які довжиною 400 рядків роблять всі види матеріалів. Для нових клієнтів вони беруть aspx та aspx.cs і викреслюють код клієнта і починають додавати новий код, специфічний для клієнта.

Їх першим приводом було б додавання додаткового обслуговування, а більше коду - це більше обслуговування. Це невеликий магазин з трьох розробників, включаючи мене. Один розробник має понад 30-річний досвід, а інший - 20+ років досвіду. Один раніше був розробником ігор, а інший завжди працював у C та C ++.

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

1. Принципи, які ви цитували у своєму питанні, - це саме такі ... принципи. Вони не є мандатами, законами чи розпорядженнями.
2. Хоча люди, які придумали ці принципи, дуже розумні, вони не є абсолютною владою. Вони просто люди, що пропонують свої уявлення та настанови.
3. Немає «правильного» способу програмування. Про це свідчить той факт, що "прийнятий" спосіб, яким ми це робимо, змінився і продовжує змінюватися, радикально з часом.
4. Доставка товару часто може мати перевагу над тим, як робити це "правильним" способом. Це така поширена практика, що вона має назву: Технічний борг.

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

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

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

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

3. Вивчайте позачасовість. Деякі принципи витримали випробування часом і завжди будуть актуальними. Системи типу універсальні. Функції першого класу універсальні. Структури даних є універсальними.

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

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

Це не рідкість. Слід усвідомити, що галузь програмного забезпечення неймовірно різноманітна. Деякі компанії передують. Провідні університети та інноваційні програми програмного забезпечення (навіть деякі лабораторії у великих!), А також благословенні особи або групи, як банда з чотирьох, аналізують проблеми, що виникають із загальними способами робити речі та винаходити нові мови, машини, інструменти та зразки. Нові компанії, часто спін-оф або відщеплення, намагаються використовувати їх комерційно, а іноді мають надзвичайний успіх. Подумайте Facebook або Google.

Але програмне забезпечення використовується майже скрізь сьогодні, можливо, переважно в компаніях, які насправді не є компаніями, що займаються програмним забезпеченням. Я працював здебільшого в транспортній галузі (автомобільній та залізничній), і є змішаний мішок досвіду. Але жодне з них не було десь близько до "передового краю". Іноді їх не може бути; Програмне забезпечення для безпеки залежить від добре перевірених інструментів (зараз ми використовуємо перевірений компілятор C ++ з 1990-х років). Іноді вони не мають потрібних людей. Часто програмне забезпечення розробляється інженерами в інших галузях, які просто траплялися в розробку програмного забезпечення у своїй компанії, коли програмне забезпечення набувало все більшого значення. Не можна сподіватися, що вони знатимуть або використовувати принципи інженерії програмного забезпечення.

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

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

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

Вони використовують веб-форми C # .Net і роблять майже все, що знаходиться в коді позаду, із дуже маленькими зовнішніми класами

Там є ваше пояснення. Якщо ви не знаєте, нестандартний код веб-форм є майже полярною протилежністю OOP, SOLID, DRY, YAGNI, Шаблони дизайну, SRP тощо. Навіть офіційні приклади від Microsoft за кілька років тому змусив би тебе сьогодні скупитися.

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

І це досить часто в просторі .NET Web Forms, btw.

Наскільки це поширене в індустрії програмного забезпечення?

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

Це є вагомою причиною, чому це трапляється: людям, які насправді не навчені (або не в ентузіазмі), доводиться щось реалізовувати під тиском.

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

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

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

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

Є два можливі відповіді:

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

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

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

Той головний розробник, який навчає вас, цілком ймовірно, дізнався, що саме таким чином ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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