Що найважливіше, корисніше чи найсвітніше, що ви дізналися за останні 12 місяців? [зачинено]

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

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

Отже, якби вам довелося вибрати одне з останніх 12 місяців, що ви дізналися, що це буде?

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

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

Можна включити досить багато елементів функціонального програмування в імперативну мову, таку як Java, і навіть якщо це не завжди ідіоматично, це може бути дуже корисним у деяких проблемах. Наприклад, анонімні класи приблизно дорівнюють закриттю, як описано у wikipedia . Ледача оцінка повинна бути нормою, а не чимось незвичним. Незмінюваність навряд чи можна використовувати. Просто перейдіть на (майже) застарілу думку про те, що побудова нових об'єктів замість мутації існуючих є дорогим через споживання GC та купи - у 99,9% випадків це просто не актуально. Насправді паралельна обробка може перевернути навіть аргумент ефективності навпаки: створення нових незмінних об'єктів може бути дешевше, ніж мутація існуючих, оскільки ви позбудетесь від блокування.

Більше інформації про те, як робити FP в чистому Java тут , тут , тут і тут .

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

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

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

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

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

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

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

Справжня цінність безпроблемного програмування.

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

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

Ось моя відповідь на моє власне запитання:

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

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

Крім політики, про яку говорив Франк Ширар , я нещодавно відкрив для себе QUnit та JSCoverage, які зробили свій день. І місяць. Ніколи не думав, що можна буде тестувати JavaScript з покриттям коду, але є ... :-)

Мої три найкращі подяки за останній рік програмування отримали б наступне (у порядку зменшення важливості та вдячності):

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

  (Моя особиста подяка Томашу Петрчечеку за його чудову книгу « Реальне функціональне програмування» .)

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

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

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

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

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

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

Я б сказав, використовуючи тестування модулів Microsoft у Visual Studio 2010.

Налагодити налагодження конкретного методу тестування було дуже просто.

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

• Навчений базовий Python (з його допомогою іноді писати швидкі сценарії)

• Встановлено ArchLinux в VM (раніше Ubuntu у VM, мій ПК зараз швидкий!)

• Розпочато з MATLAB (особливо для побудови графіків та швидких числових перевірок)

• Переключено на Mercurial (від SVN) (розгалуження та злиття!)

Вивчення шаблону MVVM допомогло мені стати набагато меншим злом.

Мені довелося почати підтримувати веб-додаток Python - тому я вирішив, що прийшов час вивчити і Vim . Тепер я використовую плагін IdeaVim для Intellij для моєї розробки Java та Flex, і я, безумовно, вважаю, що це робило моє введення швидше та ефективніше.