Note the difference between "SMART CONTRACT" and "your APPLICATION"

"Your Application" will still exist there.
"Smart Contract" DOES NOT MEAN "your application" for blockchain networks.

You were using Intermeditary services before.
Your Application code was submitting some inputs and waiting some time for outputs from intermeditary.
also you were paying for its service to that intermeditary.
Now, your smart contract will hold the conditions and operate with consensus among all participants.
Smart contract will replace intermeditary function, there will be more transparency for you and you won't pay anymore.
Additionally blockchain has builtin security features for trust and immutability, so you can safely replace indermeditary.
Blockchain is an absolute safe and secure replacement for intermeditaries.
At the end, your application will call your smart contract with APIs smart contract provided.

Smart contract is common and unique among all participants at that blockchain communication channel.
  (All participants may declare their own criterias. All merged criterias are then coded inside smart contract.)
But any participant can run its own different application using same common and unique smart contract inside blockchain network.

Smart contracts are uniquely described by their NAME+VERSION.

It is better to keep smart contract simpler and easier.It is undesirable to have complex smart contract codes.
It will be better if all transactions inside the block can be operated as fast as possible during maximum elapsed time period.
Smart contract computation complexity may be off-loaded to some off-chain methods and outputs can be retrieved through ORACLEs.
But computation off-loading is not so much desirable, if smart contract is simple, such necessity will not occur.

Smart contracts must always be like TEMPLATE, changing parts must always be received as PARAMETER.
Data coming from off-chain through ORACLES must also be parameter and every peer must receive same parameter.
For example if random value necessity exists, your application will determine random value and send as parameter to all smart contracts.
All smart contracts must get same values. Smart contract code must also be deterministic. ( = return same output for same input )
Those are critical to achieve a consensus. Otherwise 3,99 and 4,00 are different values preventing consensus.
*** HyperLedger Fabric is a unique technology having non-determinism detection due to its endorsement. ( none else has it. )

Smart contracts must not change so often. It is not desirable for blockchain. 
Blockchain itself is not by design for so often dynamically changing systems. Its core functions are security,trust and immutability.
But smart contracts will of course need changes during time.
For smart contract changes, it is important to have KILL destructer function of smart contract.
KILL function is something like DISABLING. 
TRANSACTIONS MAY WANT TO RUN THIS SMART CONTRACT BUT IT WONT ACCEPT TRANSACTIONS IF IT IS KILLED.IT WILL DISABLE ITSELF.
BUT ALSO TAKE CARE WHO CAN CALL KILL FUNCTION, PERMISSIONS MUST BE WELL-FIT BECAUSE HACKERS USE KILL FUNCTION FOR DoS ATTACK.

Smart contract must handle any problem or exception issue carefully. 
There can be many try-catch blocks inside smart contract code for this handling.
Because any bug inside smart contract can cause big unexpected chaos for blockchain network, network may halt etc.
It will be good design for debugging if everything is well messaged and logged.

Agile methodologies are not so much important for Blockchain projects because agile is needed for rapid changes.
Rapid changing systems are not so much suitable for blockchain.

HyperLedger Fabric also stores invalid transactions inside blockchain.
Invalid transaction may also be well logged and notified to your application to understand if there is DoS attack or not.

*** Exact test implementation must absolutely exist for safer production. (Ethereum has TestNet called Ropsten,Rinkeby etc.)