Яка практика програмування, яка вам колись сподобалась, ви змінили свою думку? [зачинено]

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

Прикладом практики, яку я колись використовував досить часто, але в останні роки змінився, є використання об'єктного шаблону Singleton .

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

Мої запитання до громади в дусі самовдосконалення:

• Які схеми чи практики програмування ви нещодавно переглянули, а тепер намагаєтесь уникати?
• Чим ви вирішили замінити їх?

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Одні точки повернення.

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

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

• Намагаючись кодувати речі ідеально з першої спроби.
• Спроба створити ідеальну модель ОО перед кодуванням.
• Розробити все для гнучкості та майбутніх удосконалень.

Одним словом перенапруження .

Угорське позначення (і форми, і системи). Я звикла все префіксувати. strSomeString або txtFoo. Зараз я використовую someString та textBoxFoo. Набагато легше читати і легше, щоб хтось новий прийшов і забрав. Як додатковий бонус, тривіально тримати його постійним - camelЗмініть контроль та додайте корисну / описову назву. Форми угорської мови є недоліком того, що він не завжди є послідовним, і Система Угорська насправді не дуже заробляє вас. Поєднання всіх змінних разом не дуже корисне, особливо це стосується сучасних IDE.

"Ідеальна" архітектура

Я придумав THE архітектуру пару років тому. Підштовхував себе технічно, наскільки я міг, щоб було 100% вільно з'єднаних шарів, широке використання делегатів та легкі предмети. Це було технічне небо.

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

Зараз у нас набагато простіша, менш технічно досконала архітектура, і швидкість доставки зросла.

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

Коментуючи код. Раніше я вважав, що код є дорогоцінним і що ви не можете просто видалити ті прекрасні дорогоцінні камені, які ви створили. Тепер я видаляю будь-який коментований код, на який я натрапив, якщо там не додано TODO або NOTE, оскільки це занадто небезпечно, щоб залишити його. На кшталт, я натрапив на старі класи з величезними коментованими частинами, і це дійсно збентежило мене, чому вони були там: чи нещодавно їх коментували? це зміна середовища для розробників? чому це робить цей непов'язаний блок?

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

Перевикористання / зловживання директивами #region. Це лише маленька річ, але в C # я раніше використовував директиви #region для впорядкування моїх занять. Наприклад, я б згрупував усі властивості класу разом у регіоні.

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

Розвиток водоспадів загалом, і конкретно, практика написання повних та вичерпних функціональних та конструкторських специфікацій, які, як слід очікувати, є канонічними, а потім очікують, що їх виконання буде правильним та прийнятним. Я бачив, як це замінено на Scrum, і я гадаю, що це добре. Простий факт полягає в тому, що мінливий характер потреб і бажань замовника робить будь-яку фіксовану специфікацію ефективно марною; єдиний спосіб дійсно правильно підійти до проблеми - це ітеративний підхід. Не те, що Scrum - це срібна куля, звичайно; Я бачив це зловживань і зловживань багато, багато разів. Але це б'є водоспад.

Ніколи не врізаючись.

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

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

Моя улюблена схема "не збої" така:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

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

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

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

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

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

Дійсно, рабське дотримання будь-чого може бути згубним.

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

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

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

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

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

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

Тепер я просто залишаю їх у проекті, в якому я створив їх. Ймовірно, мені це не знадобиться, і якщо я це зробити, я завжди зможу їх переробляти на щось для багаторазового використання пізніше. Іноді я позначу їх // TODO для можливого вилучення в загальну збірку.

Дизайн більше, ніж я кодував. Через деякий час це перетворюється на параліч аналізу.

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

Виконання будь-якої бізнес-логіки всередині об’єкта конструктора. Завдяки успадкуванню та можливості створювати перевантажені конструктори, як правило, ускладнюють обслуговування.

Скорочена змінна / метод / таблиця / ... Імена

Раніше я робив це весь час, навіть коли працював на мовах без обмежених обмежень щодо довжини імен (ну, мабуть, це було 255 чи щось). Одним із побічних ефектів було чимало коментарів, котрі пояснювали (нестандартні) абревіатури. І звичайно, якби назви були змінені з будь-якої причини ...

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

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

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

Я вперше почув про об’єктно-орієнтоване програмування, читаючи про Smalltalk у 1984 році, але я не мав доступу до мови oo, поки не використав компілятор cfront C ++ у 1992 році. Нарешті я став користуватися Smalltalk у 1995 році. Я нетерпляче очікував, що oo технології, і задумав, що це врятує розробку програмного забезпечення.

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

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

В C #, використовуючи _notation для приватних членів. Я зараз думаю, що це некрасиво.

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

Я перестала ходити за рекомендованим університетом методом проектування перед впровадженням. Робота в хаотичній і складній системі змусила мене змінити своє ставлення.

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

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

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

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

Перевірили винятки

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

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

Що-небудь варте було зашифровано лише однією конкретною мовою. У моєму випадку я вважав, що C - найкраща мова коли-небудь, і я ніколи не мав причин кодувати що-небудь іншою мовою ... ніколи.

З тих пір я оцінив багато різних мов та переваги / функціональність, яку вони пропонують. Якщо я хочу зашифрувати щось невелике - швидко - я би використав Python. Якщо я хочу працювати над великим проектом, я б кодував C ++ або C #. Якщо я хочу розвинути пухлину мозку, я б зашифрував Perl .

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

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

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

Ініціалізація всіх членів класу.

Я використовував, щоб явно ініціалізувати кожного члена класу з чимось, як правило, NULL. Я зрозумів, що це:

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

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

Коротше кажучи, я використовую "міні" рамки, щоб допомогти у створенні програмного забезпечення швидше та ефективніше. Ці міні-рамки економлять багато часу, і якщо зробити все правильно, це може зробити додаток дуже простим для підтримки в дорозі. Plug 'n Play для виграшу!