Яка ваша суперечлива думка щодо програмування?

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

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

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

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

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

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

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

Єдина «найкраща практика», яку ви повинні використовувати весь час, - це «Використовуйте мізки».

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

EDIT: Просто для уточнення - я не думаю, що люди не повинні ігнорувати кращі практики, цінувати думку тощо. Просто людям не слід просто сліпо стрибати на щось, не замислюючись про те, Чому ця «річ» така велика, чи застосовна вона до того, що я Я роблю, і Яку користь / недолік він приносить?

"Гуглити це" добре!

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

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

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

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

Більшість коментарів у коді насправді є згубною формою дублювання коду.

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

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

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

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

XML сильно завищений

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

Мої 5 копійок

Не всі програмісти створюються рівними

Досить часто менеджери думають, що DeveloperA == DeveloperB просто тому, що вони мають однаковий рівень досвіду тощо. Насправді продуктивність одного розробника може бути 10x або навіть 100x більшою.

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

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

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

З іншого боку, я вважаю, що люди, які не мали досвіду налагодження витоків пам'яті в C / C ++, не можуть повністю оцінити те, що Java вносить у стіл.

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

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

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

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

Продуктивність має значення.

Друковані висловлювання є дійсним способом налагодження коду

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

Просто переконайтеся, що вилучите оператори друку, коли ви переходите до виробництва (а ще краще - перетворите їх на оператори журналу)

Ваше завдання полягає в тому, щоб поставити себе без роботи.

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

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

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

1) Фарс ділових додатків :

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

Візьміть будь-яку звичайну Java або .NET ORM або будь-яку нібито сучасну основу MVC, яка робить "магію" для вирішення виснажливих, простих завдань. Ви в кінцевому підсумку пишете величезну кількість некрасивих шаблонів XML, які важко перевірити і швидко записати. У вас є масивні API, де половина з них полягає лише в тому, щоб інтегрувати роботу інших API, інтерфейсів, які неможливо переробити, та абстрактних класів, які потрібні лише для подолання гнучкості Java та C #. Нам просто цього не потрібно.

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

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

Я б спробував замінити всі ці корпоративні програми простими веб-рамками, БД з відкритим кодом та тривіальними конструкціями програмування.

2) Необхідний досвід n-років:

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

3) Загальна навчальна програма ступеня "інформатика":

Більшість ступенів інформатики та інженерії програмного забезпечення - це бики. Якщо ваша перша мова програмування - Java або C #, ви робите щось не так. Якщо ви не отримаєте кілька курсів з алгебри та математики, це неправильно. Якщо ви не заглиблюєтесь у функціональне програмування, воно неповне. Якщо ви не можете застосувати циклічні інваріанти до тривіального для циклу, ви не варті своєї солі як передбачуваний комп'ютер. Якщо у вас є досвід роботи з мовами x та y та орієнтація на об'єкт, він повний s ***. Справжній вчений-комп’ютер бачить мову з точки зору понять та синтаксисів, які вона використовує, і розглядає методології програмування як одну з багатьох, і має таке добре розуміння основних філософій обох, що вибір нових мов, методів проектування або мов специфікацій повинен бути тривіальним.

Геттери і сетери сильно використовуються

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

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

ОНОВЛЕННЯ:

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

Перш за все: кожен, хто використовує громадські поля, заслуговує на в'язницю

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

Багато хто думає:

private fields + public accessors == encapsulation

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

Нарешті, дозвольте мені процитувати дядька Боба в цій темі (взятої з розділу 6 "Чистого коду"):

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

Діаграми UML сильно завищені

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

Думка: SQL - це код. Ставтесь до цього як до такого

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

Я ненавиджу, коли бачу неохайний вільний формат SQL-коду. Якщо ви кричите, коли бачите обидва стилі фігурних дужок на сторінці, то чому б ви не кричали, коли бачите вільний відформатований SQL або SQL, який затуляє або затьмарює умову ПРИЄДНАННЯ?

Читання - найважливіший аспект вашого коду.

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

Якщо ви розробник, ви повинні мати можливість написати код

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

Враховуючи, що Pi можна оцінити, використовуючи функцію 4 * (1 - 1/3 + 1/5 - 1/7 + ...) з більшою кількістю термінів, що дають більшу точність, напишіть функцію, яка обчислює Pi з точністю до 5 знаків після коми .

Це проблема, яка повинна змусити вас задуматися, але не повинна бути недоступною досвідченому розробнику (на нього можна відповісти приблизно в 10 рядках C #). Однак багато наших кандидатів (які, мабуть, попередньо перевірені агентством), навіть не змогли відповісти на це, або навіть пояснити, як вони можуть відповісти на нього. Тому через деякий час я почав задавати простіші запитання, такі як:

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

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

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

Редагувати:

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

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

Застосування угорської нотації повинно бути покарано смертю.

Це повинно бути досить суперечливим;)

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

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

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

Менше коду краще, ніж більше!

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

PHP смокче ;-)

Доказ - у пудингу.

Тестування блоку не допоможе вам написати хороший код

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

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

Насправді я це ще більше узагальнить,

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

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

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

Я думаю, що метод повинен бути створений там, де його можна назвати.

Добре писати коди сміття раз у раз

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

Код == Дизайн

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

Ось стаття на тему Код як дизайн .

Розробка програмного забезпечення - це лише робота

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

Але у грандіозній схемі речей це просто робота.

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

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

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

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

Кожен розробник повинен бути знайомий з базовою архітектурою сучасних комп'ютерів. Це стосується також розробників, які орієнтуються на віртуальну машину (можливо, навіть більше, тому що їм знову і знову казали, що їм не потрібно турбуватися про управління пам’яттю тощо).

Архітектори / дизайнери програмного забезпечення завищені

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

Як це спірне?

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

Не існує підходу "один розмір, який підходить усім" до розвитку

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

Речі , які я бачив рекламується як на правильний підхід до будь-якого проекту - перш , ніж будь - яка інформація про нього відомо - це такі речі , як використання Test Driven Development (TDD), Domain Driven Design (DDD), об'єктно-реляційного відображення (ORM) , Agile (капітал A), Об'єктна орієнтація (OO) тощо тощо, що охоплює все, починаючи від методологій від архітектури до компонентів. Звичайно, все з приємними акронімами.

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

Це не так.

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